UX Designer David Kennedy writes a short article with some useful quick wins for accessibility, focussed around asking questions.
- Is the content specific enough in important areas?
- People skim when they read. Make sure your link text describes the content of the target link, and use concise headings to form the outline of the page.
- Where does the visual hierarchy put pressure on font sizes and colours?
- Avoid small font sizes, low colour contrast, relying on colour alone to communicate state.
- Also avoid confusing alignment, and excessive motion.
- What components are doing too much?
- Consider avoiding autocomplete and tooltip components, in favour of simpler ones.
- Are all states communicated in an accessible way?
- Pay careful attention to designs for your error states, disabled states, focus states, etc.
Dot Tomczak draws us in with a clickbaity headline, and rants about designers that claim their work is accessible without being able to back it up.
Dot says that following a WCAG checklist isn’t enough – how many designers have actually included at least one person with a disability in their initial user research?
A nice looking, minimalist, high-contrast design isn’t necessarily an accessible one. As Dot points out, there is such a thing as too much contrast. Designs may break horribly when zoomed in, or may make no sense with assistive technologies. Fonts may be at least 16 pixels in size (good) but the font itself may not be very readable (bad).
Dot implores designers to start including people with impairments, in their user testing. To start using your favourite apps and websites with accessibility settings turned on, to get a feel of how things should work. To test their products with accessibility tools. And above all, to “stop bullshitting that you mastered it – no one did”.
The comments on the article are largely in full support and agreement – including a number of famous faces from the world of accessibility (whose own articles I’ve covered in previous issues of frequent11y!).
So many good tips in this article – though don’t be fooled by the title. This isn’t about the native browser focus styles; the participants in this podcast do advocate that it’s fine to provide your own custom focus styles. This is about removing any focus styles whatsoever, and why that’s a bad thing.
Many of us have come across this before: a designer insisting we remove the outline provided by browsers, but not providing their own focus style to replace it with. The analogies in this article are great:
- Focus styles are like streetlights. Even if you think they’re ugly – they’re extremely useful.
- Want to remove focus styles? How about removing all handles from your doors and windows, to avoid breaking the smooth flow of the design.
And some tips:
- Ask designers to try to navigate their own designs via keyboard only.
- Ask what the alternative for the native focus state should be. If the answer is that there shouldn’t be a focus state at all, then this discussion isn’t about the outline.
The article contains a podcast recording and a transcript. Worth a read/listen.
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.