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.
Lately I have been focusing upon subtly improving the way I commit my work to the repository, trying to write a story with my commits.
New team, new procedures
Not too long ago I transferred to a different development team within my company, and besides the different social culture I also encountered a distinctly different technical culture. I think this is mostly due to two things.
First, my new team lacks a dedicated tester, making each developer ultimately even more responsible for not only their own code, but also for the code that they test from the other developers. Second, the team is responsible for one of the real back bones of the product. In other words, mistakes tend to become showstopper problems that disqualify builds for use.
So, to make sure that the quality of our work is up to snuff, the team has introduced a mandatory peer review step before code is even considered ready for testing. This means that another developer of the team, who wasn’t involved in creating the story, has to sign off on the code as if it was his own. This has the added benefits of knowledge sharing as a side effect!
Going into the transfer to this team, I wasn’t really worried about my code being reviewed. Additionally, reviewing other people’s code is proving to be a great learning experience. But lately I have started to notice that maybe I could have made life a little easier for my colleagues.