Your weekly 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!
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.
