Welcome to your monthly frequent11y newsletter, brought to you by @ChrisBAshton. I hope you enjoy these a11y articles I’ve collated and summarised for you. (Psst – if you find these emails too long, consider switching to shorter, more frequent updates). Now on with the show!
Martin Underhill writes about the problems of using abbreviations such as NGL (“not gonna lie”) and how inaccessible these cultural shortcuts can be.
There is an official ‘fix’ for this in HTML: <abbr title="Not gonna lie">NGL</abbr>, but it doesn’t show a tooltip when a touchscreen user touches it, nor is it necessarily exposed in things like RSS feeds. It isn’t always announced to screen reader users, and it isn’t included in the browser’s tab index.
The best solution is simple: don’t abbreviate, and use the words. Or, if you must use an acronym multiple times, define the first appearance with brackets.
Someone in America who tried sending an email to their township (district/council) was unable to, because the anti-spam measures used on the site was not accessible to colour-blind people.
It showed a little square box filled with a green colour, and asked the user to select the right colour from a dropdown list. As RealLaurenBoebert wrote: “If you wanted to intentionally design a captcha that would let bots through, and keep colorblind people out, it would look exactly like this.”
The name of the township is not mentioned, nor is there a link to the web page that contains (or contained) the issue. I imagine the measure would also have been impossible for screen reader users to pass. Let’s hope it’s been replaced with an accessible alternative now.
This story highlights the risks of rolling out your own anti-spam measures, which require careful consideration to be accessible.
Vitaly Friedman writes a lengthy analysis of the different approaches to inline validation.
There are places where it is useful and non-controversial, e.g. a password strength indicator, where a live feedback mechanism lets you know whether or not your password is strong or weak as you fill in the field.
Other places are full of nuance. It is difficult to know whether a user has deliberately or accidentally skipped a field, and whether or not they intend to go back to it. At what point do you intervene?
You could validate on page load, which is a poor experience for users: all error messages by default, until they fill in the form. This is more distracting than helpful.
Or you could validate on form submit, which is a clear message of intent from the user: “I think I’m finished”. But then the resulting errors can be overwhelming, especially if there are several things the user has to go back and fix.
Vitaly gives many snippets of general guidance to follow, such as:
- Never disabling copy and paste
- Validating early when the format is predictable (e.g. if an input must begin with a particular sequence of characters, like a country code at the beginning of an IBAN)
- Use the ‘reward early, punish late’ mechanism (don’t show errors by default, but do show an error when leaving the field, if the input is wrong. When the user goes back to fix it, remove the error as soon as the input looks good – NOT waiting until the user leaves the field again).
Definitely worth a skim!
Adrian Roselli explores how different screen readers deal with superscript and supscript text.
Firstly, it’s useful to note that there are multiple different positions of super/sub script, set using the vertical-align CSS property:
baseline is used for representing the lower character in fractions and abbreviations, alongside super for the upper charactertext-top is used for going above the ascender line, such as to represent footnotessub is used for going below the baseline, such as to represent the numbers in chemical compounds
This is hard to describe textually, and difficult to represent visually due to the limitations of WordPress, so I suggest you check out the examples on CodePen!
But that’s all really more of an aside. Adrian’s focus here is on what screen readers do with the <sub> and <sup> elements. What isn’t hugely clear from Adrian’s article is what he actually hopes to hear from his screen reader. That can be deduced from one of his bug reports:
I expect to hear the sub- and super-script text as marked up by <sub> and <sup>. Failing that, I expect there is at least a setting… to expose superscript and subscript text audibly to users.
Adrian tests each screen reader in turn. Where the super/sub text is not ‘enabled’, it’s unclear whether the contents are simply not announced as <sub>/<sup> elements, or whether the contents of those elements are ignore completely, which would be far worse! In my experiment with VoiceOver, the elements’ contents were announced but not the markup. Anyhow, these are Adrian’s findings:
- NVDA has a setting to enable them, but this only works if
vertical-align has NOT been set to text-top or baseline.
- VoiceOver has no such setting, but does have an option for exposing the contents to Braille readers. There is also an option to increase text verbosity to the level that it exposes sub/super text, but this also announces the typeface and font size, for everything, so is completely impractical.
- JAWS has no settings, and “ignores them completely”.
A handy resource for learning about accessibility guidelines for the web. It covers common design patterns such as saving data after session timeout. It covers how to prevent interesting buggy edge cases such as accidentally hitting a button when trying to scroll past it. And it covers common accessibility problems such as identifying and describing form error messages to users.
An interview with Patrick Garvin, former worker of Boston Globe.
Patrick noticed that a lot of newsrooms tended to omit alt text on their social media, excluding a lot of people from reading that content. So he built an @AltAwareness Twitter bot, which listens for tweets that contain journalism-related hashtags and, essentially, calls them out when they include images but no alt text.
He was inspired by an earlier bot by Matt Eason, which performs a similar service for people who use the #accessibility hashtag but fail to provide alt text. He’s also built a similar one that scans tweets from the UK government.
Patrick found that his bot would get blocked a lot, and not have the effect he was hoping. So he built an @A11yAwareness bot which is more advisory in tone. “It doesn’t retweet anyone, it doesn’t call anyone out” – it tells people “Here is stuff that you might not know”. This has had a much more effective response from people who had been tweeting inaccessibly.
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 <input type="numeric">.
Léonie Watson shares a design problem she encountered on Twitter. When you have ‘buttons’ grouped together in a row, and only one can be ‘active’ at any one time, how should it be marked up?
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.
Lea Verou, the person who asked the original question on Twitter, ended up creating a custom component and accompanying article.
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.
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.
Whew, that was a long newsletter! Did you know that you can subscribe to smaller, more frequent updates? The dai11y, week11y and fortnight11y newsletters get exactly the same content. The choice is entirely up to you! Curated with ♥ by developer @ChrisBAshton.