Hacker News new | ask | show | jobs
by willeh 1833 days ago
Most of the heavy lifting in accessibility is in the ARIA attributes and being thoughtful about actually including those. The problem faced by semantic tags is that not all websites use them and that the information that they carry is of very limited use for a screen reader. A section-element without any other information is just a div.

Unfortunately adding semantic information to website has gone from a promising avenue for building websites usable from many different kinds to part of the SEO cat-and-mouse game played by Google et al.

Unless you're doing SEO, everything semantic is just a distraction. That said do take accessibility seriously, it will never be justified by profits but doing the right thing is a feeling no amount of money can buy.

4 comments

> Most of the heavy lifting in accessibility is in the ARIA attributes and being thoughtful about actually including those

This isn’t true. Semantic HTML is also very important, often more so.

> Unless you're doing SEO, everything semantic is just a distraction.

This is also not true. Besides actively harming accessibility (or making it substantially more difficult to improve), non-semantic HTML also breaks Reader Mode. And it can also add cognitive burden to maintenance and future feature work.

Since reader mode is often "no annoying ads" mode, I'm wondering when sites are going to start breaking it on purpose.
From my understanding, this is part of why reader mode is not standardized or well documented. Its heuristics are definitely revised, likely in part to address this.
Reader mode probably has a pretty low impact on ads. The full page is usually going to load before you activate reader mode, so the only ads it's actually hiding from you are ones below the fold, which are much lower value to begin with.
Not if you use Safari's feature to always load pages on a domain in Reader mode or add a Firefox extension that does the same.

Gizmodo articles should load in Reader mode but don't, I assume they're doing that intentionally.

Yes, but at some point advertisers have to realize that people who use reader mode don't actually see the ads. The ads might load, but the user is just staring at the reader mode button waiting for it to turn on.
> Unless you're doing SEO, everything semantic is just a distraction

Accessibility and SEO are (usually) desirable system effects that rely on meaningful semantic code-inputs to the system.

But that doesn't mean that only software system effects matter, and everything else is a distraction.

Consider that when you're programming your various identifiers -- the names of variables, functions, classes, types that you choose -- are largely without any semantics to your system. To the computer, they're simply keys. And yet we sometimes say that one of two the hard/important problems in computer science (besides cache invalidation) is naming things. Why?

Because the actual system isn't just the software & machine. The system includes the developers groking and shaping the software. And names and their relationship with domain concepts matter to people and help them manage their work.

I've found that the first benefit to semantic markup -- not necessarily the most important, but the first -- is helping me better conceptualize the domain and my code. It functions as an orientation anchor when I'm working with components that look different between their source and rendered as part of a sprawling document in the browser. And it helps me get reoriented faster when I've been away from it for days/weeks/months.

The heart of "semantic" anything is the idea that code is for people too. Maybe not all people, but definitely at least anyone who's writing it.

> "Most of the heavy lifting in accessibility is in the ARIA attributes"

Best practice is use to use HTML semantic tags and only add ARIA attributes if it is relevant. For example, HTML5 has a <nav> tag, therefore it is not necessary to add the ARIA attribute "role=navigation". Even the Accessibility section on MDN (Mozilla Developer Network) states: "developers should prefer using the correct semantic HTML element over using ARIA if such an element exists" (Source: https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...)

> "The problem faced by semantic tags is...the information that they carry is of very limited use for a screen reader."

That's precisely why those semantic HTML tags are important - so that screen readers navigate the page more easily (among other reasons).

> "...semantic is just a distraction"

Accessibility is not difficult if you follow HTML5 semantic markup. Compared to CSS, HTML5 semantic tags are easy. If you use HTML5 semantic tags, accessibility comes built-in - you get it for free.

Where accessibility fails is when you're using a JavasScript framework that generates non-semantic markup. Or you're using a CSS framework and your HTML markup is littered with endless <divs> rather than HTML semantic tags.

I recently posted this video playlist of quick accessibility tips for websites (each tip is just 1 minute). Many websites don't follow these best practices. However, I think people might be surprised by how simple and low-effort it is to incorporate these tips into any website.

Quick accessibility tests: https://www.youtube.com/playlist?list=PLTqm2yVMMUKWTr9XWdW5h...

> That said do take accessibility seriously, it will never be justified by profits but doing the right thing is a feeling no amount of money can buy.

Why can accessibility not be justified by profits? If you sell something, lack of accessibility will cause you to lose sales. How much you will lose depends on the demographics of the potential customers.

Cost of ensuring a site is accessible is greater than the profit from the sales which you get in addition?
Yes but what is the the cost of accessibility? How much more expensive is it to use a <button> compared to a <div> with attached event handlers?
The cost of doing accessibility is the cost of doing accessibility testing. If you're not actually testing your accessibility work, using a button instead of a div is pissing in the wind.
Surely a button is more accessible than a div regardless?
Maybe, maybe not. ("Surely" using the browser's CSS animations would be more efficient than reimplementing them yourself in JavaScript - but if actually you benchmark it, the opposite is true). If you're not actually testing it, how could you possibly know?
If only it were so simple.
For what kind of site? If you just use semantic HTML as this article recommends, the cost is quite low for development, and your QA people should already know the basics of accessibility testing.