My 10 second accessibility audit
2 min read
One of the simplest audits I do on websites to gauge accessibility and user experience is to keep my hands on the keyboard and hit
Tab repeatedly on a page (I do this in Chrome, see note below on Firefox/Safari).
Try it right now. What do you notice?
Your focus probably went to the "Alex Writes" header first. Great! I know where I am on the page navigation-wise. I also know that if I hit
Enter the page will navigate.
After that though... uh oh. Where am I?
I have to hit
Enter to realize I'm on the search icon in the header. If I keep moving along it becomes clear that any time I'm focused on an element in that top right navigation I can't tell where on the page I am.
You get the point, right?
This is one of my favorite gut-check tests. It generally won't get picked up in an accessibility tool like Wave or Axe, but it has pretty big implications for accessibility and usability.
It's revealing not only in that it uncovers a detail that's been overlooked, but that the browser default is being overridden. Someone has made the active choice to remove the focus outline by setting its color to transparent.
As a front-end developer with a big passion for UX and accessibility, I'm a strong advocate that accessible interfaces aren't a "feature". Accessibility should be the default, and it's the job of front-end and UI developers to advocate for best practices. If a stakeholder asks me to remove focus styling, I'm going to ask why, educate, and offer alternative solutions.
Enabling focus styles in Firefox and Safari
I went to test this in Firefox and Safari and was surprised to find their defaults are different on Mac. This StackOverflow post should get those settings to account for focus states on all focusable elements.
Resources for styling focus states
- W3C's WCAG 2.0 2.4.7 Guideline
- Don't remove default focus styles, enchance them from Sean McPherson
- CSS Almanac
:focus-visiblefrom CSS Tricks
- Tailwind's states documentation