The first rule of web accessibility is that doing nothing is better than doing the wrong thing. https://www.w3.org/TR/wai-aria-practices/#no_aria_better_bad... explains a bit.
There’s a reason why the class attribute exists. You can also validly use custom elements and attributes, which are approximately any name containing a -.
It's just a handy shortcut for building a landing page in like 20 minutes or sprucing up your "haven't gotten around to writing the CSS yet" web app so you can kick it out the door.
What's extra frustrating is that it would be so easy to fix, by just adding a few classes. But they wanted to be "semantic", so they forced their users to be unsemantic.
It was also in the grey area in HTML4.01 spec, note B.1 provides for user agents rendering any unknown elements.
For me personally, the accessibility issues would be with elements used out of their usual role.
For example: When I, blessed with being sighted at this time, but without a mouse, ask my browser to identify the clickable/actionable elements on the page, it mis-identifies both unclickable elements as clickable, and clickable elements as unclickable.
I would call that a serious usability issue. And if I was not sighted, using a screen-reader, I would be very confused indeed by this landing page.
I agree that whether this qualifies as a "huge" usability issue is indeed a matter of opinion. I would certainly argue that it is a huge usability issue.
`section` has an `h2`, but no `h1` for some reason. Other failures like this.
Other than that what's wrong?
User agents rely on ``a`` elements being clickable, and ``span`` elements not being clickable, for example, to determine which actions to present to the user.
When you use them outside of these use cases, the user agent has to do extra work to figure out whether something is actionable or not, and not all can do it adequately.
I agree that semantic only would be a big limitation in production, but that's always been the chasm of web dev: taking your hacky "bash it together" code and massaging it into something durable, without wasting time over engineering everything from day 1.
If you’re wanting a lightweight starting point for rapid prototyping, <div class="card"> is much nicer and more obvious than sticking an <aside> inside… hang on, was it an <article> or a <section> that I had to put it inside to make it a card?
So largely I’m saying that for something targeting the space mvp.css is targeting, rabidly avoiding classes is a bizarre and pretty much indefensible choice.
Copied the css file into my source
I viewed mvp.css as a starting point that'll get something looking nice enough on top of my raw html, and then I can (did) make tweaks from there.
In cases of (color)blindness, vision loss or cataract, deafness, vertigo etc. the presentation needs to adapt to the user needs while ideally presenting the same content.
With OP's stylesheet it is possible to create a visual representation that is flexible and robust, but the classlessness nature makes it impossible to support certain type of content altogether.
To hammer this home - there is nothing bad about divs when it comes to accessability which, to be honest, is the only concern that "semantic html" should be about.
There certainly is. Prefer h1 over div, button over div, etc whenever appropriate.
You can try them all out here as well: https://dohliam.github.io/dropin-minimal-css/
> Q: Is there a minified version? A: No, you don’t need one for an MVP
> Q: What if I [still] don’t like it? A: That’s OK, you probably shouldn’t love your MVP
Just to pick a couple. Philosophy of this is spot on!
I took a look at your site and have a few comments:
- The "How it works" section is fantastic. Thank you for including all the intermediate steps such as Github authorization/linking.
- It was not clear to me exactly what role Mavo plays. It appears as the in-browser editor but but looks to be much more capable than I was expecting.
- I like the Worklog - it's interesting to get a peek behind the scenes.
- What sorts of topics are you planning for your tutorials? Will it get as direct as "how to add a shopping cart to your website" or focus on bigger picture topics?
- In the Limits section of the Pricing page, I recommend you make it more visible that Netlify, Render, and Vercel are under the Yax umbrella as hosting options. I know you covered it in the "i" hover text but something like an additional table header would help. Non-coders are not as familiar with these companies and how they fit into the larger system.
(The only thing that I dislike is that the table is not centered on desktop. But whatevs...)
@sdan: Thanks much for those links, BTW. Super-helpful stuff right there. https://newcss.net/ is my current favorite, but it's nice to have so many options now to play with. :)
I agree that we should be as semantic, as reasonably possible. But I'd rather have reusable CSS.
One little error ia that the textarea is too wide, you'll see on this page (smartphone):
It makes the entire page have a horizontal scrollbar.
Excited to learn more about this! Dig the design for his page as well - wish I could hire a designer / dev hybrid for $300-400 to make a single page site like this! (inquiries welcome)
I find <a class="button-solid">... easier to remember than <a><b>... vs. <a><i>...
I kind of prefer this. When Im just throwing something quickly, this is easy and when I want proper styling, I can use proper CSS frameworks.
i don't see a usecase for Tailwind, atleast for myself