Your fortnightly frequent11y newsletter, brought to you by @ChrisBAshton:
Abbreviations can be problematic
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.
Website Slammed for Not Allowing Users To Send Emails if They’re Colorblind
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.
Designing Better Inline Validation UX
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!
Brief Note on Super- and Subscript text
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:
baselineis used for representing the lower character in fractions and abbreviations, alongsidesuperfor the upper charactertext-topis used for going above the ascender line, such as to represent footnotessubis 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-alignhas NOT been set totext-toporbaseline. - 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”.
accessguide.io
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.
Two new bots can help newsrooms prioritize accessibility and alt text
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.
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.
