I often get questions about where to start implementing web accessibility. If there are easy parts to WCAG, and if it’s OK to start from there.
Yes, there are easy parts to WCAG. The easiest parts are those you really don’t have to do. Non-applicability, I mean all those success criteria that do not apply to your product or website. According to WCAG’s definition of conformance. If there is no content to which a success criterion applies, then the success criterion is satisfied. Consequently, there is great value in identifying those first. Every project is different, but for instance, if you don’t have video or audio in your project. In that case, you can skip those parts completely.
In my experience. I would say anything in the realm of automatic testing is easy. Easy to test, easy to fix. Then things start to get difficult when we need to manually test the User Interface. Mainly because there is a steep learning curve as to how exactly it needs to be tested and by who. Therefore, testing for Screen Reader is the most difficult part, in my opinion.
The easy parts
Now getting back to the easy parts. The following are easy: non-text content, sensory characteristics, use of color, contrast, page titled, link purpose, multiple ways, consistent navigation, consistent identification, language of page, link purpose and maybe error identification too. Mostly all those things on the web designer’s end. It almost seems logical to start there. Although, in my experience with transactional websites, these are huge time wasters. I’m not saying don’t implement them, they must, but not first. Change or adjust them at any time. However, implementing them first usually gives a false sense of accomplishment.
By the way, I’m intentionally removing the success criteria numbers in the previous paragraph. Removing the numbers makes articles more digestible, some readers have told me, especially for beginners. It seems numbers give the article a technical flavor. So, I will do this when possible. This is not a technical article, it’s more of a cautionary tale.
The disadvantage
One disadvantage of starting with the easy parts is thinking your website is accessible because an automated test says so. Tests such as Chrome Lighthouse, may indicate your project is 98% accessible. This could be misleading for your project stakeholders (e.g., client, high management, project manager, developers, designers, etc.). Especially if they are not familiar with web accessibility and falsely think they have reached a near-perfect accessible website. As it turns out, automated tests only cover 18 to 20% of the accessibility issues. And doing it so, page by page.
It should be clear: there’s no replacement for manual testing. So, if you make it to 100% in Lighthouse, that’s really only 20% of the accessibility for the tested page. Not for the full website. I have come across this misconception many times. It’s demoralizing for stakeholders and developers, finding out there is still a remaining 80% work to be done. Once they thought it was ALL done.
It’s also tempting for some stakeholders to claim a site is “half-accessible”. By taking fulfilled success criteria based on non-applicability, and then add them to the previous automated test percentage. Inflating numbers is a terrible idea. This doesn’t make a site more accessible.
So, where to start?
I have heard many times the claim that the first 3 steps to Accessibility are “easy”. Those steps being: Keyboard Navigation, Form Labels and Automated tests. I agree with this approach, but I kindly disagree with Keyboard Navigation being easy. The more interactions you have on one single page, the more complex the Focus Management becomes. However, I definitely agree Keyboard Navigation is the best place to start, even if it’s not easy.
Form labels, in a perfect world, are easy only if using native HTML elements. Yet, a rarity in real life these days. The more developers use <div>s and <span>s for everything while coding forms, the more dependent on ARIA roles and attributes those forms will be. Once crossing the ARIA imaginary point-of-no-return, then the next thing we will run into is Accessibility Patterns. Defining or reconstructing these patterns takes a lot of focus management work. Not an easy task past that point, but a must-have by then.
Anyway, in my experience, implementing the “hard parts” first sets a foundation. To support what you will add on top. The previously mentioned easy parts. Accessibility is not a one-time project, it’s a process. There could be regressions and we want to know where they are and how to avoid them.
Hard parts are time consuming
Yes, it takes time to do the hard parts first, and time is money. In real life, stakeholders get desperate with deadlines. Developers want to start features and functionality without mockups. Managers want to add look and feel quickly to show progress. Those efforts need direction. Developers for sure can start features, but making sure they are operable with the keyboard, not just the mouse. Progress on design is perfect as long as it doesn’t break keyboard navigation.
If you are working on a website that the client will customize later. Then fine-tuning contrast, fonts size and use of color is something you can put at the bottom of the to-do list. Better to concentrate on building on top of the keyboard navigation experience and visible (and audible) labels. But here’s the thing, this is also no different if you are working on a website that is “final”. Meaning the client won’t customize further. In this case, keyboard navigation will give designers better arguments as to where to place components. Other than just “design trends” or fashionable practices. It’s harder to roll back a component’s position and break keyboard navigation, than it is to roll back from color, contrast, or size changes.
Having said all that. The hard parts don’t have to be “that hard”. UX designers can help from the very beginning. By identifying things like Intended Keyboard Patterns, Visual and Audible Sequences, Minimal or Specific Screen Reader Narration.
The choice is yours. As I said before, every project is different. Just don’t let the easy parts consume the time you could be spending on the difficult parts. Accessibility needs to be implemented gradually, like onion layers, following Inclusive User Journeys. Instead of just literary complying with success criteria without understanding their meaning.
