100 Days of A11y

Day 80: Manual A11y Testing Tools

Published on

Yesterday I browsed through automated accessibility testing tools. Today, per their mention in the WAS Body of Knowledge, I discovered some manual accessibility testing tools that offer more insight into problems that can't be caught in automated reports. These tools go beyond the easy checks, like color contrast, headings, and keyboard access, that I'm used to checking for.

Tomorrow I hope to dig in a bit deeper to compare the difference between automated and manual testing, along with the drawbacks of each.

Things I accomplished

Permalink for "Things I accomplished"

What I learned today

Permalink for "What I learned today"

Manual testing tools, much like automated testing tools, offer reports and automated tests for all audiences within the development process to get a start on addressing accessibility issues. The advantage that manual tooling provides is that it offers additional guidance and education to fix problems that cannot be systematically evaluated through automated checkpoints. However, no tooling replaces human judgement and end-user testing.

Manual testing tools can include:

Another observation about manual testing tools, they may take more time to work through results, but there are many more of these tools that are free to use compared to automated full website testing.

Though I found that many manual testing tools seem to fall with between the development and testing, there are some system-wide tools that help earlier on in the life cycle. Color Oracle is one such application that can assist designers during the earlier design process before any code is written. It takes colorblindness into consideration at the beginning of the site's life cycle.

An Aside

Permalink for "An Aside"

Ran across an accessibility basics article by Microsoft, and loved this catchphrase:

Accessibility is a built-in, not a bolt on.