We recently upgraded our accessibility checklist to include a combination of WCAG AA and AAA criteria. This entry should soon be updated with those details.
Our core philosophy is “Digital Hospitality” – The idea that websites are spaces people inhabit, not billboards to be viewed at a distance. Central to implementing that philosophy is making our websites accessible to the broadest number of visitors, and building them such that visitors with visual or physical impediments can use them successfully.
Many courts have ruled that many websites count as "Places of Public Accommodation" under the Americans with Disabilities act. So a website that disregards accessibility (A.K.A. "a11y") is not only bad for users, it may be illegal.
However, the ADA does not explicitly state what constitutes compliance. Government sites must comply with Section 508, but private sites do not have as clear a bar to hit. A commonly accepted standard is WCAG, which has three levels:
- A: Urgent problems that prevent users from using a site at all
- AA: Biggest and most common issues that affect many disabled users
- AAA: The most stringent accommodations one can make to ensure that any user can use the site optimally
Cantilever sites should, by and large, comply with level AA of WCAG. By shooting for this standard we can ensure we are providing good hospitality to disabled users, but also protect our clients from legal challenges. The point of building our sites in an accessible way is for the most people to be able to use it, not simply to tick the boxes of WCAG, so we should treat it as a guidebook, not a rulebook.
At the beginning of Cantilever, we thought a lot about accessibility. As the company grew, our practices deteriorated, and we ended up being weak in the area. In the last few years we have been working hard to fix this deficiency. Our standard accessibility benchmark is a combination of WCAG 2.1 AA and AAA criteria.
Making websites WCAG-compliant used to take significant extra time. But in the HTML5 era, and with clean, efficient markup, basic accessibility is really not much additional effort. Our default development methodology is "vanilla", so lots of a11y concerns are much simpler for us than for the "let’s use React for everything" crowd. We don’t really mention it as an "extra" during sales processes, we just say that best-practices a11y is a part of our standard development offering.
Perhaps even more significant than the a11y’s effect on development is the one it has on design. From the start, Cantilever sites should be designed to work for the broadest number of users. Our grid-driven, minimalist aesthetic lends itself to this mentality, but we still make mistakes.
Our goal is to confidently tell current and prospective clients that our sites are ADA-compliant, and to feel that users of any physical and visual ability will have a great experience on our sites. Our current "best practices" approach is getting us closer, but we need more stringent testing and focus on a11y throughout the design and development process. A lot of the aspects we currently miss are low-hanging fruit, so once we start testing more specifically for a11y, we should rapidly close in on our goal.
Current “Best Practices”
Here are the standard practices that we should nail every time:
- Using clean, semantic markup with a sensible markup structure – this is the basis for all accessibility practices
- Keyboard navigation – every piece of content and functionality on the site should be easily accessible via keyboard
- Alt text for media and UI elements
- Using aria tagging for interactive components to define the relationship between elements
- Using alternative data for graphics that can’t be read in screen readers
- Use alternative layout methods for tables for smaller devices and screen readers
- Using a11y helper classes instead of `display: none;` to hide elements which should remain legible to screen readers
- Allowing browser default focus styles instead of customizing or suppressing them
- Color contrast – We should not have text that will be too faint to some users
- Text size – We should not use text that will be too small for some users
- Full screen reader compatibility
- Making sure that form errors are easy to parse
WCAG AA standards that we are still working on achieving regularly
- Text zoom compatibility – user should be able to zoom up to 200% on the page without a major layout breakage
- Making sure all our sites’ languages are tagged properly.