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.
https://news.ycombinator.com/item?id=25168303
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
s/aside/\.card/g
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.
https://www.w3.org/WAI/tips/developing/#use-mark-up-to-conve...
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 -.