Sample Client Emails re: Accessibility

The ADA has no specific language to say what constitutes an "Accessible" website (it was written in the 90s). It has been up to courts to decide what they consider "accessible" when lawsuits have been brought.

Most of the time lawsuits center around specific functionality that cannot be used properly for people with certain disabilities. For example, if it were impossible to buy something for users who cannot use a mouse and rely on a keyboard.

In recent times courts have been standardizing around telling websites deemed "inaccessible" to abide by the WCAG AA standard. This is the most common framework for quantifying accessibility. WCAG also has a less-stringent “A” ruleset and a more stringent “AAA” ruleset.

The entire legal issue around Accessibility is complex. It is great that courts have affirmed that people should not be discriminated against in their ability to use websites. However, companies are focusing on the legal side rather than seeing accessibility as something you should do to make your business more successful, which is ultimately the more important thing. It may be possible to be "ADA Compliant" but still provide a crappy experience for people, and that’s not a good outcome.

We never promise “ADA Compliance” on our websites. The reason is that because there is no strict definition, we can’t say for sure what a court would find to be “Accessible” and what not. Our focus is on building a site to deliver a great experience for any user, and we spend a lot of time taking disabled users into account when we design and build sites. We do test for the WCAG standards and strive to hit the AA criteria level at a minimum. This involves checks throughout the process, because much of accessibility comes down to design. So you can‘t just develop any website to be accessible, much of it comes down to the decisions made earlier on. This is often the trickiest part to manage, since you can’t just show clients a design that looks good, you have to make sure it meets WCAG, which limits your color and type choices.

What we typically tell someone who is looking to shield themselves from liability is:

There is a new category of accessibility helper software like Accessible and Userway which claim to shield websites from legal liability. The disability community seems to have consensus that this software does not substantially improve their ability to use websites which are fundamentally not accessible. It may patch some simple issues (for example, they will add AI-powered alt text to images) but it can’t fix fundamental underlying problems. For more information check out this article from a disability tech expert we trust: https://adrianroselli.com/2020/06/accessibe-will-get-you-sued.html

Many sites are still being sued despite having overlays like that, and in fact the suits show flaws in the software which add to the problems that disabled users ran into originally.

Another problem is how they work. The overlays basically modify the page after it is loaded. This means that the entire page loads, and then must be changed again to be ostensibly more accessible. Even if they were successful, this means the page kinda loads twice, which feels slow and janky.

The best part of them is they add easy controls for text size and additional contrast modes which may be useful to some specific users, but TBH users can change these things on their own computers too.

All in all, we can’t recommend the overlay approach. It would be cool if someone came up with a way to bundle certain frequently-required accessibility features without causing the problems these tools seem to have, but that doesn’t seem to exist yet.

The only method to ensure accessibility on the site would be to modify its design and code.

On the design side, we should be able to make sure that nothing in the design breaks WCAG rules. We could give you our checklist we use for this purpose or we can have our QA tester (who is trained on this) review the site and give you feedback.

On the code side, since you would be using a theme, we would be substantially restricted in how much we can do to support accessibility criteria. Many criteria (like alt text) are doable in this context, while others (adding a "skip to main" button or something else requiring custom coding) are harder. It’s all technically doable, but it could be very time consuming.

I did a quick glance at the Retina theme code and it does not seem super focused on accessibility. There are a lot of big-picture things not done properly.

So...

The best way to hit the WCAG AA standard is with custom code, but I presume that the Shopify theme approach is in play because of cost. Assuming so, perhaps the best method would be to set aside a separate accessibility budget. We could work with you to identify and fix the highest-importance accessibility issues with the site within the budget allocated. We would not be able to reach WCAG AA and would have to be clear about that, but this method would allow the site to provide a much-improved experience to users with disabilities and would head off many of key complaints disabled users have. Perhaps over time they could put continued budget into accessibility so the site keeps getting better and better (both for users and for their legal liability).

The other approach would be to tell them that in order to truly make the site accessible, it can’t use a theme, so it needs a full, beautiful custom design by you 😀