Web Accessibility Interview

Web accessibility standards cannot be an afterthought. Web accessibility extends to every part of how a site is built from themes to link structure to navigation. The consequences for failing to meet web accessibility guidelines can result in expensive lawsuits for an organization and a loss of trust from your users. The Drupal community believes that web accessibility is essential to building a truly inclusive open source project, and has made strides to ensure Drupal 9 complies with the World Wide Web Consortium (W3C) guidelines: WCAG 2.0 and ATAG 2.0.

Drupal Core's Accessibility Gate, required for all core changes, is a major show of commitment to web accessibility that ensures any new feature added to core is accessible right out of the box. Drupal 9 worked to eliminate some critical accessibility barriers including the proper use of semantic markup, improving color contrast, adding skip navigation to core themes, and overall providing a more accessible and functional user experience.

I recently interviewed Ben Mullins, a Drupal Acceleration Team member and fellow Acquian, to learn about his experience earning two web accessibility certifications. Ben shares his thoughts on how developers can incorporate accessibility practices into their daily work, and why it is important to be proactive about addressing potential accessibility concerns before starting to build a site. See why Ben believes in Drupal's commitment to web accessibility, and the educational resources available to help developers live up to these standards.

Who are you and what do you do?

I'm Ben Mullins, I'm a senior software engineer for the Drupal Acceleration Team at Acquia. So my full-time responsibilities are to move various Drupal Core initiatives forward.

I understand you recently took two accessibility certifications. Which certifications were they, and how did they differ?

You're going to be assaulted with multiple acronyms. So there is a certification called CPWA which is Certified Professional in Web Accessibility. That is a combination of two certifications. The first is Certified Professional in Accessibility Core Competencies (CPACC), which demonstrates knowledge of general accessibility concepts, including laws, the various types of disabilities to be addressed, and other broad generalist concepts. The second certification is the Web Accessibility Specialist (WAS) credential, and that's engineering targeted and it proves that you're aware of concepts for actually implementing accessibility on web applications. [They are both overseen by the International Association of Administrative Professionals (IAAP).]

So would you say one is more technical-focused and the other one is more general?

Yes, WAS is by far more technical. The exam includes looking at bits of code and markup and determining what the accessibility problem is and things like that.

Whereas the other one is more life-focused?

Yes. Things like knowledge of laws, the many different types of color blindness and the various tools that someone with a given disability may use. It's much broader.

Seems that the more technical certification (WAS) would have a pretty broad impact on your day-to-day work, but has the CPACC in any way changed how you think about things in your daily interactions?

The CPACC exam had more of an impact than WAS, in my opinion. Because it covers foundational accessibility concepts, I learned more about the many disabilities and use cases that need to be accounted for. This knowledge helped me anticipate and address many issues that would otherwise have been caught at a very late stage, if at all. Being more aware of disabilities overall proved as useful as technical documents such as WCAG standards.

Was there any specific statistic or finding or thing you learned that stuck with you?

One that definitely stuck with me was that automated accessibility error tools catch maybe a third of accessibility issues. These uncaught issues are not trivial, many are glaring compliance violations that could result in lawsuits or lost contracts. I'm aware those tools are valuable, and they're certainly better than nothing. but finding out that they only catch a third of violations is a nice statistic that makes it easier to argue for the need for accessibility expertise.

What made you decide to get certified in the first place?

My original motivation wasn't particularly noble, I mainly wanted great Drupal features to be available sooner. My decision to get certified stemmed from my work on Layout Builder and Media Library (two Drupal modules recently added to Drupal Core). In both cases, as we grew very close to making those modules stable, accessibility issues would be identified. The issues were severe enough to be stable blockers, sometimes appearing weeks or days before a stable deadline.

I wanted to develop my accessibility knowledge so I could preemptively address these accessibility problems. I wanted to reduce the chances of release-blocking surprises.

In approaching this certification, what sort of resources would you recommend to someone for studying and preparing?

Deque, which is a great accessibility organization, has paid courses that I used. I found them very helpful in helping me study for the exams, but I don't think that they are absolutely necessary if funds aren't available.

The IAAP website has Body of Knowledge documents that cover all the material needed for the WAS and CPACC exams. I used those Body of Knowledge documents to supplement the Deque courses, but I suspect they're sufficient on their own. Some concepts were easier to understand and retain when I used the Body of Knowledge to inform self-directed research.

There was also a blog called 100 Days of A11y. The author Amy Carney, did a daily documenting of their journey studying for, and ultimately passing, the two exams. It was a thoughtful account of the study process and the concepts that tripped them up. This was one of the better resources I encountered, but there are many additional free online resources to learn the topics covered by the exams.

Having started with some hands-on experience before you started on certification, do you think that in hindsight, that's a good approach? Or would you recommend someone start with learning and certification and then move on to implementation?

CPACC can be taken at any time. I think it's a great structured way to learn accessibility concepts and learn their importance. The WAS exam is significantly easier for someone with prior experience dealing with the technical implementation of web accessibility issues.

Unlike the CPACC exam, most of the topics covered by WAS were ones I had reasonable familiarity with. That said, there were enough new concepts to make studying for the exam worthwhile. For example, I needed to familiarize myself with all currently available screen readers, not just the two I typically test with. I also left with a better understanding of how assistive tools such as speech control are actually used.

If someone who has no need or desire to work on a technical level doing implementation, would you still recommend the CPACC to them if they're, for example, a project manager, a product owner, or team lead?

I think it's valuable for any team to have at least one person with CPACC certification, assuming they want their application to be accessible. That said, people who don't think accessibility is a priority may change their mind based on what they'd learn from the CPACC exam topics. It helps people understand the many reasons it's desirable to have accessible applications beyond it being the right thing to do. You can completely cut out all the moral arguments (which, in my opinion, I agree with) and argue on a financial level that it's in one's best interest to build with accessibility in mind. The CPACC Body of Knowledge is full of information backing up why that's the case.

You mentioned accessibility tools, specifically like screen readers and whatnot. Can you talk more about what tools you usually use?

For general feature testing, I usually test with Mac OS VoiceOver screen reader and then NVDA on Windows. For voice control or speech navigation. I'll use Mac OS's built in tools and for text magnification, same thing.

For more in-depth audits there's also the JAWS screen reader, and the screen readers provided by iOS and Android. These are screen readers that I rarely use, to be honest. The certification process highlights the main differences between these screen readers, which made it easier to identify issues that should be tested with more than just my usual VoiceOver and NVDA, and which ones I can be reasonably confident work without the need for manual testing. While manual testing is always desirable, it might not be critical or feasible. It's helpful to know when it's useful to fire up a prototype on a mobile device or endure the slowness of testing multiple Windows screen readers in Virtualbox .

You spoke about resources for studying. Do you find yourself consulting any specific resources when focused on implementation?

W3.org has all the Web Content Accessibility Guidelines (WCAG) standards. I'd been referencing those since I'd been aware of accessibility as a thing. but the courses I took made those documents much easier to understand. I probably reference them as often as I did before taking the exams, but I understand them much better. I'm consulting WCAG for more granular data versus in the past when I primarily used to get the deer out of the headlights.

Drupal has made itself a differentiator by embracing accessibility as a central focus. How has your view of this promise changed since going through these certifications?

A commitment to accessibility is a very easy thing to claim. The knowledge I gained via the certification process has provided me a better sense of what software actually provides good accessibility and what doesn't.

I think in some cases claims of accessibility could mean we make a point of running automated tools before we commit code, which is better than nothing. But that doesn't feel like a true commitment to accessibility. I've also seen these claims backed up by the mere presence of aria implementations, even if the implementations are done poorly.

Drupal, on the other hand, I feel does have a commitment to accessibility. I rarely had doubts about that, due to how difficult it was to get certain issues resolved based on accessibility gates.

Now that I know the topic a better, I have confirmation that the completion-blocking accessibility issues I encountered were not nitpicks. These were legitimate issues that could absolutely impact users. It's now easier to confidently say Drupal is committed to being an accessible application. It's also easier to handle disappointment when a feature gets kicked back and requires more work. I can see how the requested changes will benefit users with disabilities, making it difficult to dismiss the request as engineering minutiae or gotchas from somebody fastidious enough to identify small deviations from WCAG.

Do you find yourself becoming more of an advocate for accessibility?

I find myself being more of a technical advocate. And I think some of the other [Drupal] accessibility maintainers are very good at promoting accessibility as a broader topic and essentially being accessibility evangelists with messaging that is helpful for a wider audience. I find myself primarily encouraging other engineers to embrace accessibility. My hope is that I point out issues to Drupal contributors in a way that doesn't create the sense their work is being assaulted. When I do that well, it's clear my intent is to help their work be enjoyed by a wider audience, not obstruct their work with technicalities.

Anything you want to call out that surprised you about the exam?

In the WAS exam, there were multiple questions about screen reader shortcuts, including ones that I didn't necessarily use on a regular basis. I was surprised to get asked such specific questions, but fortunately, I was prepared. That was a level of specificity I doubted would actually wind up on an exam, but they did it. I'm cool with them demanding that level of knowledge.

There were several questions that were tricky but in a good way. They wouldn't trip anybody up that actually knew the material, but I could see how they'd confuse test takers with only cram session-level knowledge. The limitations of a test to accurately measure someone's knowledge or abilities is well known, but these seemed like legitimately well-written tests that do a better than average job .

Any final thoughts?

The value of a certification is debatable for any technical discipline. For a topic like accessibility, which is arguably still new territory, having a structured way to expose myself to new concepts was valuable. Prior to studying for these exams, much of my familiarity with accessibility topics would come from someone identifying accessibility bugs in my code. While I see the value in learning from one's mistakes, a mistake-centric learning process is pretty inefficient. I'm able to avoid things like spending two days building a feature that I'd ultimately discover does not work with speech control.

I also think the professional listings of people (and their companies) who have received certifications are a great way of showing the companies and individuals that truly value accessibility. It seems like web accessibility is more valued than it was even a few years ago, but I feel like there's still room for it to benefit from more exposure and more awareness.

I keep returning to the practical benefits of accessibility vs. the ethical ones. Ethical arguments are easier for management to dismiss and are more likely to come across as indignant. It extends beyond financial benefits like procurement and lawsuit avoidance. Among other things, an accessible website is typically less irritating and much easier to maintain. Things like parallax, slideshows and autoplay content are difficult if not impossible to implement accessibly. It's nice to have a non-subjective means of arguing against such features. It's oddly a very handy way to push back on flash over function.

The Web Accessibility Initiative is truly thinking about how to make full-featured web applications successful and not just giving people a list of what not to do. They're not trying to be restrictive necessarily.

---

Learn more about how you can earn your own CPACC and WAS certifications by visiting the IAAP website and registering for an exam.