If you’ve inherited someone else’s website code and wanted to check it for accessibility, or simply wanted a practical explanation on how to audit your own website for accessibility, Marcy Sutton’s post is for you.
In her post published this week, Marcy shared her journey for auditing the accessibility of Distiller, a website founded by and for people who love whiskey.
Marcy started working on Distiller a few months ago. Like many developers, she was working with existing code. And as she explained:
One of my personal goals for the project was to expose the product’s “cool factor” to people who couldn’t see it or use a mouse.
In Marcy’s post, she focuses on:
- Headings
- Keyboard interactivity
- Automated testing
- Screen readers
- Color contrast
- Tools
What I enjoyed about Marcy’s post was the explanation of her approach, tools used for testing (many of them built-in browser tools or free online applications), and how her team worked together to learn about, share, and resolve the accessibility issues in Distiller.
Her explanation of focus management is spot-on, with a case study on how the team identified and resolved “freak-out mode” within Distiller’s personal profile.
Checking for accessibility can be done easily with the tools and applications we already have, something I think many web developers and designers don’t realize.
At our Refresh Detroit and Detroit User Experience meetups, I’m often asked by web developers and designers how to check their work for accessibility, and what tools to use. I’ll be pointing them to Marcy’s post.
