When making a web site accessible, you inadvertently run into the topic of screen readers. Screen readers help people with visual impairments understand what is on the screen.
Few people think about the implications of having visual content translated into an auditory representation. In this article, I want to explain how screen reader users “hear” the web, what strategies they apply when confronted with a new web site and how you can make their life a bit easier.
There are many tools out there that help you check if your website or webapp is accessible. Most of them do an automatic check based on some accessibility guidelines. Some also provide functionality to do checks yourself, for example, to check the color contrast. The open source tool Accessibility Insights takes a different approach: on top of the usual automated checks there is a set of guided manual checks. This makes it a great tool to learn about accessibility testing and programming.
The WCAG 2.1 update published in 2018 was a backwards compatible, additions only version. It adds 12 new A and AA (and 2 AAA) level success criteria focused on mobile accessibility, people with low vision, and people with cognitive and learning disabilities.
Reading through all the documentation can be intimidating, whereas a checklist can be too brief. Inspired by the session on WCAG 2.1 at NCDT of 2019, this post summarizes each success criterion; hopefully creating a middle ground between the full specifications and a checklist.
At the end of each section you’ll find a link to the “Understanding” document of the success criterion. Here you’ll find all exemptions, recommended techniques, and more.
If you are in fact looking for a checklist, WebAIM has created a checklist of all 2.x success criteria. Alternatively, the How to Meet WCAG (Quick Reference) is always a good place to start.
“Software programs should be usable by everyone.”
I think everyone can agree with that statement. Unfortunately, there is some extra work needed to make a program truly accessible. Even worse, this is often only thought of in the last bit of a project. This leads to accessibility often being cut out because of time and budget constraints. If accessibility would be considered from the start, it could be built in more easily. But how can we make us as developers more aware so that we actively think about accessibility when building the software?
Our answer: let’s experience first hand how (in)accessible our software is!
We decided to host an accessibility challenge for our colleagues. Read below how this turned out…