Hacker News Reader

Comment by ehnto | Hacker News Reader

This was definitely built to solve a very specific problem in a very specific way, I think you're asking too much of it.

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.

View on HN

The point is that the marketing is false. This CSS framework forces to you to abuse HTML semantics if you want to use it, which is exactly what it claims it doesn't do.

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.

Or they could have just used arbitrary elements, like <myelement>. Folks forget that this is valid HTML, and it’s just treated as a div.

I don't think they forgot, because it was never true. It needs a dash `-` in it.

https://html.spec.whatwg.org/#valid-custom-element-name

It needs them now, but it wasn't always the case. In html5-20121025 User agents must treat elements and attributes that they do not understand as semantically neutral.

It was also in the grey area in HTML4.01 spec, note B.1 provides for user agents rendering any unknown elements.

Semantically neutral yes, but they are not divs -- they're "unknown elements", which have more annoying behavior (similar to pseudoelements from memory)

I think that's right. They start out life as inline-block elements.

A landing page with huge accessibility issues

I wonder how you justify your use of the word "huge" here, given that it'll most likely be far better than most landing pages out there and not everyone will use the problematic components.

I think this comment makes a pretty clear case for it:

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.

Using the software you've got, would using role attributes be a sufficient workaround?

Accessibility is not something I know much about (I mostly work backend). What's the issue with this type of approach? I was tempted to use it as a starting point for a little side project, but Id rather not start with something with inherent accessibility issues.

The biggest issue I noticed right away is that it uses elements outside of their traditional use cases.

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.

Thanks, that makes sense.

The light grey text under "MVP.css works with the following HTML elements:" surely fails (WCAG2).

`section` has an `h2`, but no `h1` for some reason. Other failures like this.

Other than that what's wrong?

Is a lack of H1 a dock against accessibility?

I think it would be, because a screen reader will try to call-out the topic of the document accurately and quickly. You don't want a user to have to dig through elements to find the real title of the page they're on.

hm I've worked at plenty of places that touted accessibility, and we would often leave out h1 on a lander page (there might be a few h2 instead as the highest ranking headers)

Reply on news.ycombinator.com