“Built-in” accessibility: blessing or curse?

So, in defense of websites… for developers, can be hard to find good code examples. There’s plenty of them, but it can be tricky to dinstinguish between low and high quality).

People also commonly misunderstand the diffference between conformance and guidance, WCAG being the normative document for conformance, and documents like the Authoring Practices being merely guidance.

Working with developers, I often see them struggle with finding out how well ATs and browsers support features. There’s some support charts, but they’re not part of bigger initiatives like Baseline. And that’s not even including actual usability, your perfect ARIA tabs may confuse users if they don’t know the keystrokes, I’ve seen this in user tests.

And then there’s the thing that WCAG often doesn’t tell you what to do. That’s for a reason, if WCAG was very concrete it would need thousands of guidelines and criteria, that would go out of date real quick.

There are features that make a11y possible, e.g. support for alt text in the image tag.

<img src="" alt="" />

And features that do accessibility or semantics for you, like headings, they have a built in role:

<h1>Top news</h1>

A more complex example of that is popover, a recent addition to HTML that has a bunch of accessibility properties built in. Thanks to a lot of effort from Scott O’Hara in particular, aria-expanded is set, and aria-details too in specific cases, and keyboard behaviour is taken care of too.

See this post I co-wrote with Scott O’Hara: On popover accessibility: what the browser does and doesn’t do.

Code example:

<button popovertarget="p"> Toggle popover </button> <div popover id="p"> … </div>