Yesterday I published the first in a series of articles about accessibility standards . But reading it over again, I should have taken the time to explain the difference between usability and compliance, and why accessibility standards can be useful for usability at the same time as being required for compliance.
Defining Compliance and Usability
Compliance means meeting a defined set of rules, standards or legal regulations. With compliance, it's important to consider two different types of compliance: compulsory and voluntary. Compulsory compliance is something you have to comply with under threat of some kind of penalty. For example, if you are not PCI-compliant, you may not be able to process credit card transactions or may be subject to fines.
Usability is about how easily, efficiently and comfortably a person can use something. In software, it mostly refers to the user interface, but it should also extend into things like how you acquire the software and access technical support. Like compliance, there are a lot of rules and standards around usability. Unlike compliance, nobody has ever been fined for building software that is really hard to use. Well, not directly. Usability does directly impact sales.
Compliance, Usability and Accessibility Standards
When I wrote yesterday's article, I hovered around this point without making it. In retrospect, it's likely bigger than I could have crammed into that article, so this may have been for the best. You may not be in a situation where you have to comply with an accessibility standard, but accessibility standards make your sites or applications more usable for a large portion of the population.
Consider alt text in img tags. A compliance check may indicate that there is missing alt text. That has to be fixed in order to comply. Adding alt text to an image will make a page more usable for people who use screen readers.
Contrast ratios are another example. A compliance check could indicate that your contrast ratios are too low for even A-level WCAG conformance. It's a really bad experience having to strain your eyes or select all the text before you read it because the contrast between the text and background colour is too low.
There is another interesting aspect to accessibility, specifically higher-level accessibility testing. Fundamentally, if you want to build highly accessible websites or applications, use colours with a lot of contrast, focus on semantic HTML as much as you can and, when you have to build a custom control, ARIA has to be implemented perfectly. And most importantly, test with a screen reader.
There is a technical side effect to following those steps. The proper use of semantic HTML will make your front-end code easier to reason through and will make diagnosing problems in certain browsers/platforms a lot easier. This is one of the little things that make life so much easier when everything goes wrong. For me, if I have spent too much time looking at an interface while I am building it, I find that turning off my monitor and listening to what I built helps me find a lot of mistakes. While your experience may be different, I see signs that accessibility improves usability for everyone.
Of course, just because something makes my development process easier doesn't mean that introducing it to a team will be easy. I've worked on teams that spent months complaining about adopting Webpack, which is a considerably less controversial change than accessibility. Changing how people work can create its own problems, and you don't always know where those problems are hiding until you've made the change.
Accessibility standards are fundamentally about making websites or applications easier for people with disabilities to use. They are usability enhancements, sometimes with a big legal stick to enforce compliance. In my experience, they often help me build better software that is more usable for everyone. And the worst-case scenario when I have done stricter accessibility testing is that I get to spend more QA time experiencing something I built in a totally different way than I built it. This is the most risk-free way to legitimately make people's lives better.
Accessibility for Whom
This is sometimes where the link between accessibility standards, usability and compliance can get messy. In many technical organizations, accessibility gets treated like a checklist. That is excellent because many places don't even do that. But there are even higher levels of accessibility work.
In software testing, teams will also work on user personas as a prerequisite to designing good test cases. I think that a persona with a disability is a very valuable addition. It not only makes users with disabilities first-class citizens during the QA process, but it humanizes the process. In other words, it can move the testing process from 'there is alt text' to 'this alt text is meaningful'.
Conclusion
Tomorrow, I'll be publishing the next real article in the series. The first article was about the four core principles of WCAG, written towards software developers . Now that we share common ground on the relationship between accessibility standards, compliance and usability, we're in a great place to start talking about how to share some of this foundational information with stakeholders to get early buy-in.