Fata Morganas in Accessibility

Originally posted on marcus.io.

Sometimes you stumble over things where your first thoughts are, "Hey, thats great for accessibility!" or "Nice, it's always better to solve things in a browser-native way instead of relying on JavaScript". And this has happened to me before.

Unfortunately, once you dive in deeper in to these, at first, perfect solutions you read more and more about their imperfections or downright disadvantages. Here are some elements, attributes or techniques that initially piqued my interest. But luckily, after that "Using <details>/<summary> for a menu" episode, I decided to do some research before diving into the phase of building demos and excitedly writing about that new shiny a11y thing. Because sometimes these new techniques turn out to be some kind of fata morganas, or solutions that are not yet ready for prime-time.

No. 1: Using aria-role="feed" solves accessibility issues for all users

I was happy when I first read about the feed role. To give context: It is meant to help in situations where there is infinite scrolling and a continuous stream of content (like for example Twitter's, Mastodon's or Facebook's status message list). And I wasn't alone. Quote Deque employee Raghavendra Satish Peri:

Just like many developers and the accessibility professionals, I initially believed that role=”feed” would solve any accessibility-related problems for infinite scrolling.

But the disadvantage of relying on role="feed" alone to solve a feed's accessibility problem is that there are more than just screen reader users who are negatively affected by infinite scroll interfaces. Additionally, keyboard-only users, speech regocgnition software users, people using zoom, or switch devices and people with cognitive disabilities also have their problems with this pattern.

Aforementioned Raghavendra Satish Peri wrote an interesting article about the scope of the problem and the potential misunderstanding that comes with this role. Furthermore, he suggest an accessible infinite scroll design pattern, which looks promising and worth a look for everybody who plans to implement a feed of this sort themselves in the future (especially since there's no consensus on the "official" usage example by WAI-ARIA Authoring Practices).

No. 2: Detecting screen readers in CSS with the speech media query

If you look at it superficially, @media speech seems to be a way to address screen readers via CSS, and a means to avoid .visibility-hidden classes, for example. On a second, more thorough look you'll notice that there is a discussion ongoing in CSS Working Group (Drafts), regarding its removal.

Because one the one hand, it is not supported in user agents at all and on the other, screen readers use screen media type anyway, the agreement is to add a warning regarding @media speech: it "is for pure-audio UAs, not screen readers". So in the future it could be a way to detect Alexa, Siri or Google Home. In the present, though, it is no method to recognize screen readers.

Bear in mind that even it it would work, it wouldn't be a good idea to use it:

• There are more screen reader users than the ones who are 100% blind: Also, people who are partially sighted use these types of software, in addition to people with good eyesight but cognitive issues
• You shouldn't aim to detect screen readers for ethical privacy reasons.

No. 3: Using the <dialog> element for perfectly accessible modal windows

It's actually quite hard to build an accessible modal dialog, so <dialog> appears like a gift at first. To quote Eric Bailey:

I like what dialog represents. HTML should pave the cowpaths of popular UI patterns. They should especially do this when those patterns come with tricky implementation concerns that developers may fail to consider, especially when those considerations include accessibility.

Additionally most of the time the advice – when it comes to ARIA and JavaScript in general – is: "Don't rebuild element or widgets when there is a native one at hand" (ARIA Rule #1). And while this is true in most cases (like using and styling a <select> instead of trying to re-build one) this advice is out of place when it comes to the <dialog> element.

Admittedly, at first glance the native dialog implementation looks rather good: It is, like Chris Coyer states, "not just a semantic element, it has APIs and special CSS". It brings .show(), .showModal() and .hide() methods (and hitting the ESC key closes it), a new mode for forms, namely method="dialog". This means that in the following example, a button click would close the modal in the same way a button in a "normal" form would submit the form's data:

<form method="dialog"><button>Close</button></form>

Furthermore, <dialog> brings a ::backdrop CSS pseudo to precisely style the often darkening overlay, and it even takes care of focus management (minus implementing a focus trap when a modal is open).

Sounds too good to be true? Well, it kind of is. Part of the reason for that is the well-intended focus algorithm that is built in. Unless there is an autofocus attribute present in the dialog it will focus the first focusable element. But it is not granted that this element will be one of the first items in a dialog. Scott O'Hara paints in his article "Having an open dialog" the picture of a scenario where a dialog contains a long text, for example our most favorite internet texts (legal ones like terms of service). Would the first focusable element be at the end of this long, scrolling text a user would experience that a dialog would start in state where the content is already scrolled. Also, one important thing of dialog is focus management is still missing: the return of focus to the dialog-triggering element once it closes. So developers might think they take care of accessibility by using <dialog> – but in fact need to programmatically fill these gaps.

Aside from these problems Scott discovered some problems with the dialog in various screen reader and browser combinations. He concludes:

tldr; I’m just going to say right now that the dialog element and its polyfill are not suitable for use in production. And it’s been that way since the dialog’s earliest implementation in Chrome, six-ish years ago.

No. 4: Using aria-label as a means to describe everything

Maybe you were like me: When I first heard about aria-label, I thought: "Wonderful, a way to send more information to screen Reader (and screen readers only)."

But don't stop at this thought for three reasons:

• Firstly, don't go over the top and try to explain the usage of standard HTML controls and standard ARIA widgets. Adrian Roselli has summed it up wonderfully in his article "Stop Giving Control Hints to Screen Readers" a few days ago.
• Secondly, you couldn't just apply aria-label on anything. If you aim to add the attribute on static content (minus elements with landmark roles like <nav>) be aware that you open pandora's box and can't rely on consistent screen reader behavior. To learn more, read "What happens with aria-labelledby, aria-label and aria-describedbyon static HTML elements?" by David MacDonald.
• Thirdly, if you are using aria-label and a realtime translation service like Google Translate its values won't be translated in every browser (only in Google Chrome at the time of writing). To circumvent this issue, you could use text perceivable for everyone, and, if you want to influence the accessible name of a given element, you could point to it via aria-labelledby .