My second measurable goal in web accessibility for 2020 was to pass the Web Accessibility Specialist-exam. I thought that I would receive the results in 2021. However, I got a Christmas surprise. The message congratulating me on passing the exam was in my inbox on Christmas Day. If you want to read how I felt pretty soon after getting the results, I wrote a blog post about that:
This post is a similar wrap-up-post from the WAS-exam, as I did from the CPACC (Certified Professional in Accessibility Core Competencies)-exam.
What is WAS?
International Association of Accessibility Professionals (the organization providing the certification) describes WAS with the following words:
The Technical-level credential is intended for accessibility professionals who are expected to evaluate the accessibility of existing content or objects according to published technical standards and guidelines, and provide detailed remediation recommendations.
IAAP WAS Certification
It is a more technical certification, which requires more understanding of how to build web that is more accessible. It doesn't necessarily require much coding experience, but some HTML, CSS, and JavaScript knowledge is needed.
Learnings
Again, as with CPACC, I can say that I learned a lot. I used Deque's WAS-package for learning, and I liked it. It contains lots of different courses and took a long time to go through, but it was worth the time. Also, I used the WAS BOK (Body of Knowledge) as a guide for studying.
WAS, too, consists of three parts:
- Creating Accessible Web Solutions
- Identify Accessibility Issues in Web Solutions
- Remediating Issues in Web Solutions
I'll go through each category, picking up some points from each. They're all broad themes, and I can barely scratch the surface on this post, but hopefully, you'll get something out of my notes!
Creating Accessible Web Solutions
In the first section, the first topic is all the relevant guidelines and techniques for meeting the success criteria. These mean, for example:
- WCAG 2.1 (Web Content Accessibility Guidelines)
- WAI-ARIA (the Accessible Rich Internet Applications Suite)
- ATAG (Authoring Tools Accessibility Guidelines)
Before studying for WAS, I had some idea about each of them - more about some and less about others. For example, WCAG was somewhat familiar to me, and I knew what it was, but this was the first time I actually read the whole set of guidelines. It was refreshing and educational.
Another thing in this section was "Basic knowledge of programming" - I thought I knew a lot about programming accessible interfaces, but oh boy, was I wrong. I learned a lot about semantic HTML and different techniques for creating a more accessible web. Also, I got to know about WAI-ARIA Authoring Practices and Design Patterns, which has been a valuable source of information when creating custom widgets.
Before studying, I had only a vague idea, how assistive technology can affect websites. For example, when a user uses a screen reader on mobile, it disables all the website's custom gestures. It means that if something is based purely on, for example, swiping content and there is no alternative way to access it, a user can't use that feature or app.
Another interesting bit of information I acquired from the studying process was how people using assistive tech use the web. For example, navigation with a screen reader happens differently from how a person who sees, navigates through the web page.
I have to admit that I came across many things that made me realize how ignorant I've been when coding (and still often am, as I am still learning every day). I've created so many inaccessible interfaces, and this feeling of being ashamed pushes me towards reading more.
Identify Accessibility Issues in Web Solutions
This section was an interesting one, and the focus is on finding the accessibility issues from the websites and identifying the relevant guidelines and principles regarding these issues. A big part of this section was the testing methods - be it automatic or manual testing. I'll write some words about the latter.
Manual Testing
I took a deep dive into different screen readers. I even turned my old Windows computer on for some JAWS testing. However, I never got there because, well, all the Windows updates took a remarkably long time, and in the end, I didn't have enough space on the computer. π
I've used VoiceOver on Mac before but going through the material taught me more about the keyboard shortcuts in VoiceOver. I still have to check the shortcuts almost every time I'm testing something with VoiceOver, but I'm getting better! I also learned the basic gestures for Android Talkback and tried VoiceOver on iOS.
I am adding a comment here before proceeding. I am a sighted person and can't be an expert on how actual screen reader users use the program. However, learning to use a screen reader helps with testing and understanding what needs to be taken into account for screen reader users. Anyway, this should not be the only testing made to an app with screen readers. In the perfect world, actual screen reader users would be included as testers in the quality assurance process.
One other thing I want to point out: Often when talking about assistive technology on the web, the first (and sometimes only) thing that people think of is the screen readers. That's not the case - for example, Windows High Contrast Mode, ZoomText and MAGic (for screen magnification), and keyboard-emulating assistive technology are widely used, to name a few.
Testing with Keyboard
And yes, the keyboard is on the list too. It is maybe the most straightforward testing you can do for a website - in most cases, you already have all the equipment and can start testing. Can you navigate the website without a mouse? Is everything usable? Do you know where the focus currently is? If you open a modal, can you access elements behind it while it's open? Where does the focus go when you close the modal? And so forth.
Ah, and by the way - if you're navigating on the webpage on a keyboard for the first time: There are some patterns to note about keyboard navigation. In WAI-ARIA Authoring Practices, there is a chapter about Developing a Keyboard Interface. In short, the keyboard navigation patterns users expect on the web are borrowed from different GUI-applications. For example, that means that tab-key is usually used to get into the widget, and arrow keys are used for navigation within that widget.
Remediating Issues in Web Solutions
This section has only two subsections - "Level of severity and prioritization of issues" and "recommending strategies and/or techniques for fixing issues." For me, especially the first one was helpful and gave loads of new information.
Some factors influence the priority of an accessibility bug: The severity of the user impact, how fast developers can fix it, business priority, location of the issue, and how often that same bug appears, to name a few.
From these examples, what surprised me was "how fast developers can fix it". I mean, it totally makes sense that the low hanging fruits should be picked and fixed, but I just hadn't thought about it. But then again, according to WebAIM Million, there are automatically detectable WCAG-failures in 98.1% of the top 1,000,000 websites' homepages. Here's percentages of most common types of failures:
| WCAG Failure Type | % of home pages in February 2020 |
|---|---|
| Low contrast text | 86.3% |
| Missing alternative text for images | 66.0% |
| Empty links | 59.9% |
| Missing form input labels | 53.8% |
| Empty buttons | 28.7% |
| Missing document language | 28.0% |
These detectable errors include, for example, missing alt-texts, missing form labels, and empty links, which are relatively easy to fix. It means that when fixing those issues, the accessibility of a website improves a lot.
Summing up
Again, I can't stress enough how much I've learned while studying for the Web Accessibility Specialist-exam. It has opened my eyes to new things in accessibility, and I've found many new tools for making a more inclusive web.
However, I must note that this is only the beginning. Now I have the tools for learning more, but I recognize that the learning must continue. Most of all, I'll need practice, practice, and practice. I've noticed that even if I have all the knowledge, I still keep making those mistakes in code and realize later that I should have known better.
Are you IAAP certified or studying to take the exam? If so, I'd love to hear your thoughts! Also, I'd love to answer if any questions arise about the topic! π
Top comments (4)
How prepared did you feel for the certification after getting through the coursework. I am a UX designer with 3+ years of focus on accessibility and I completed the WAS coursework last year. I am wondering if my experience and coursework education is enough for me to successfully pass the test.
That's an interesting question. I mean, I was pretty confident on some topics, but, for example, WCAG was something I was a bit afraid. I had, however, set myself this deadline of taking the test in 2020, so I just decided to try. If I'd fail, then I would know what the exam is like. So yeah, I could say I felt prepared, but was still afraid I wouldn't pass π
Thank you so much for this series! Just mentioning that most companies only test their site(s) with open source screen readers (e.g., Salesforce using NVDA) but majority of blindness non-profits in California only teach JAWS - because that is what most workplaces and Department of Rehabilitation support (which is a shame because it is proprietary with terrible support); NVDA can be configured to resemble JAWS, but it has features that cannot be replicated in the latter. Also, talking of features, accessibility is spectrum: companies claim their pages are accessible for screen readers because all content can be reached using available commands, but JAWS web browsing commands take up 30 pages (support.freedomscientific.com/Cont...) and ca. 80% of users will only get comfortable with about 10-20% of them. Blindness is a spectrum as well and most blind people I know have other disabilites (cognitive, auditory, neuropathy, etc) that limits their abilities. Not to mention that huge percentage of folks are seniors (as their various conditions deteriorate with age causing visual impairment). Bottom line is that if you are serious about accessibility then consider taking a tour at a (blindness) nonprofit near you; talking with an instructor (especially with an assistive technology instructor) will give one a whole another perspective.
That is an interesting piece of information, thank you a lot for sharing!
You're right, and even though it would be so easy to just put people in boxes, every person and their limitations in abilities are unique. And as you mentioned, ageing brings its own challenges to the mix.
I'll be sure to check the nonprofits around here, thank you!