The “Websites and Software Applications Accessibility Act” (or #A11yAct) has been put forward to the United States Congress. If it succeeds, it will build on the Americans with Disabilities Act (ADA).
Its aim is to lead to clearer regulations for digital accessibility requirements in the US. Here, Ben Myers looks at it from a web developer’s perspective. He opens with a disclaimer that he’s not a lawyer. For a legal perspective, read “Proposed web and software accessibility legislation introduced in United States Congress“.
Ben summarises the bottom line for us:
- Websites and apps will need to be accessible, period – no longer any need to demonstrate a link to a physical, bricks-and-mortar place (an idea called “nexus”).
- Regulations would be updated every three years.
- It’s not a silver bullet, but it will give disabled users more recourse against inaccessible products.
Ben then gives a short history of the ADA and why new legislation is necessary. One issue is the idea of ‘nexus’, and another is that it did not keep up with the times, but the main issue is ambiguity. The lack of published regulations means individual courts are left to interpret the act, leading to inconsistent outcomes in accessibility lawsuits.
Kilian Valkhof highlights how
<input type="number"> is often used incorrectly, despite it being available in browsers for around 8 years now.
Number inputs display a ‘spinbox’ (up and down buttons) to make it easier to increment or decrement the input. This kind of indicates the type of thing this input type should be used for: non-identifying numbers.
Instead, a lot of sites use number inputs for things like 2FA codes, social security numbers and credit card numbers. These are identifiers, where if you’re off by just 1 digit it’s much the same as being off in ALL the digits. Having a spinbox for this provides no value.
If your input is a set of digits that is used to identify someone or something, it’s not a
number type, even if the input itself is entirely made of numbers. What you want in those cases is
This fits quite nicely with a standard radio button form control, where you can only select one radio input. Choosing any other radio input automatically de-selects the previously chosen one. Exactly what we’re trying to achieve in this design problem.
However, whilst that might work well enough for sighted users who use a mouse, it creates a UX issue for keyboard users and screen reader users. This is because, whilst the inputs may look like buttons – which can be tabbed between – they are marked up as radio buttons, which require a different key input to navigate between the options. Once on a radio control, hitting ‘tab’ simply skips to the next interactable element after the radio control (with the exception of Firefox).
Léonie explains quite a bit about ‘affordance’: designing things in such a way that users can use their past experiences to already have a good idea about how something is supposed to work. She argues that whilst this concept works in the real world, it hasn’t translated to the digital world very well.
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.
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.
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.
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.
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.