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…