week11y issue 132

Your weekly frequent11y newsletter, brought to you by @ChrisBAshton:

‘Accessibility at the Edge’ W3C CG Is an Overlay Smoke Screen

Adrian Roselli brings attention to the Accessibility at the Edge community group, hosted on W3.org. People would be forgiven for assuming that such groups are supported by the World Wide Web Consortium (W3C), but Adrian talks us through the process, which requires just five people to show their support for a proposed group in order for it to be created.

This group started off as the “Overlay Community Group”, founded by the Chief Operating Officer at UserWay – an overlay company. Adrian argues that the renaming of the group was an attempt to distance the founders from the original purpose of the group, which would have been quite easy to argue a self-serving interest in.

What follows is seemingly a long history of careful censorship, with difficult questions and critical comments never getting past the ‘approval’ stage on the group, thus never being seen. Adrian worries that the group could now be used to “provide a veneer of credibility”, by “using the W3C brand [in] their own ongoing marketing efforts”.

Definitely food for thought, and something to keep an eye on.


Are Captions More Accessible on the Top of the Screen?

An interesting article about the placement of closed captions, which so often is put at the bottom of the screen by default.

The author describes how they were seated in an auditorium, which tall people sat in front of them, making it difficult to read the captions at the bottom of the screen (“I lean to the left. I lean to the right”).

On Zoom, the captions window can be moved anywhere on the screen by dragging it. It’s also possible to reposition the captions on YouTube videos.

No solid conclusions here, unfortunately, but some more interesting experiences in the comments, e.g. captions covering the name of the speaker in news bulletins.


For Blind Internet Users, the Fix Can Be Worse Than the Flaws

A (paywalled) New York Times article, offering a rare mainstream insight into the use of overlays that claim to fix accessibility problems and defend companies from litigation.

It tells the story of Patrick Perdue, who had been happily using a radio equipment shop website for some time, before the shop started using an automated accessibility overlay from accessiBe. Patrick found that the site was suddenly unusable, hiding checkout and shopping cart buttons from his screen reader, as well as hiding the site’s search box and headers.

“I’ve not yet found a single [overlay] that makes my life better”, says Patrick. And the litigation promise doesn’t appear to be holding water either, with over 400 companies sued over accessibility last year, despite having an accessibility widget or overlay on their website.

The three major overlay providers, AudioEye, UserWay and accessiBe all claim their products will get better over time and acknowledge that their current offerings “aren’t perfect”. Accessibility experts would prefer companies not to use such overlays, believing that hiring and training employees to build their websites to be more accessible is the answer. Mr Moradi of AudioEye advocates a hybrid approach that combines automation and manual fixes, with the expectation that automation abilities will gradually improve.


aria-label is a code smell

Eric Bailey highlights a snippet from the WebAIM Million report:

Increased ARIA usage on pages correlated to higher detected errors. The more ARIA attributes that were present, the more detected accessibility errors could be expected.

He references the increased complexity of ‘support’ in the context of ARIA, which is determined by:

  • Operating system being used,
  • Operating system’s version,
  • Browser being used,
  • Browser’s version,
  • Assistive technology being used,
  • Assistive technology’s version, and
  • Complexity of the underlying code.

When aria-label is used on a non-interactive element – which is not what it is intended for – assistive technology handles it in different ways. It will either not be announced at all, or will be announced in strange ways.

Even when declared on an interactive element, there are known issues. It only has partial support in Edge with Narrator, and, if you think of a play/pause toggle, in many cases it does not convey name changes when focused.

Eric also cites examples of people using aria-label to override an otherwise visible name. Users who use their voice to navigate, such as “Click ‘snapshot'”, may be surprised when their voice command does not work, as the underlying accessible name is different (and not visible to them).

Some browsers do not translate aria-label content, so things like Google translated pages won’t work properly. Finally, aria-label content is not very robust to things like stylesheets failing to load. An alternative – visually hidden text – will at least still be visible if the styles fail to load.

Worth reading the Hacker News comments on this too.


Did you know that you can subscribe to dai11y, week11y, fortnight11y or month11y updates! Every newsletter gets the same content; it is your choice to have short, regular emails or longer, less frequent ones. Curated with ♥ by developer @ChrisBAshton.

Loading...