Once you see more than one of the items below, you can be fairly sure that accessibility was not considered in design and development

People frequently reach out to me* asking if a particular site is accessible. This happened last night, and I only had 15 minutes to spend on checking it. I started with a mental checklist of “does the person who created this site care about accessibility?” I realized then that others might benefit from that list, so here it is — signs that I feel are indicative that people didn’t know or didn’t care about accessibility when building their website/apps.

#1 Poor color contrast

Red on Green? Red/Green on a dark background? White on pale blue? Gray below 40 % saturation? None of these will pass the 3.0:1 minimum contrast ratio requirement in WCAG for text, keyboard focus indicators, or activatable icons.

An experienced accessibility tester can tell with one glance whether or not colors on a page satisfy these requirements. Everyone else should probably check using a color contrast analyzer. My personal favorite is the one from The Paciello Group.

Poor color contrast is #1 on my “signs of not caring about accessibility” list because fixing colors requires changing a couple of characters in the code. Sometimes it can be fixed through a content manager, you don’t even have to know how to code. That’s it. If the site/app owners didn’t care enough to do that, it is all but guaranteed that they didn’t follow any of the other 49 WCAG 2.1 Level AA guidelines either.

#2 Inaccessible tech stack

It is not possible to make flash accessible (thank goodness it is just about dead). I have yet to find someone who has made D3 charting completely accessible. CAPTCHAs are problematic — honey pots are a much better solution for preventing DOS attacks. v3 of the Google “I am not a robot” is the only CAPTCHA you should be using, and then only if it is absolutely necessary. Invision is another inaccessible tool where I just don’t think you can make it truly both accessible and usable. If a website or mobile app is built using inaccessible tool choices, that’s a sign that no thought has been given to accessibility.

#3 No (or only automated) close captioning

Close captioning is another “so easy a caveman can do it” accessibility choice. My father refers to things like close captioning as “checkbook engineering” — you write a check, in this case a very SMALL check, and the problem disappears. Close captioning costs ranges from $1 to $4 a minute largely depending on what language you are captioning in. And it is a curb cut — it benefits people without hearing loss as well.

Automatic captions are getting better but still NOT an equivalent experience, especially if your speakers are non-native English speakers or you use a lot of technical/medical terms that don’t show up in common dictionaries. You need at least 92 % accuracy for people who rely on the captions to be able to fill in the blank for the rest. Some autocaptioning hovers around 60–70 % accuracy that just isn’t good enough. Read here for more information on why good close captioning is important to accessibility.

#4 No accessibility statement

Accessibility statements are not a guarantee of accessibility. They are more like a statement of intent. They indicate the company at least knows about accessibility, and if you call them out on something that is inaccessible, they may try to fix it. They may provide you information on the best environment to try things out on. Most importantly, they may give you contact info for people who are responsible for accessibility within the organization. No statement means that the company doesn’t know enough to do one, and doesn’t have a named person to reach out to if you find something wrong.

#5 You hit tab button and a skip to content link doesn’t come up

I am a keyboard only user, but even if I wasn’t, the first thing I do when I go to a site I haven’t visited before is hit the tab button. What *should* happen is a “skip to content” link should come up. If it doesn’t, chances of keyboard testing having been exhaustively conducted and bugs resolved is vanishingly close to zero.

#6 Vertical text or other objects that can’t be reached by swiping or keyboard

Who thought that vertical text is cool or a good idea? It is so unusable, I wouldn’t be surprised if WCAG bans it in a future version. I am sighted but I have a severe spinal curvature that makes turning my head to read vertical text impossible. Screen readers rarely pick up vertical text, and the way it is implemented frequently means the objects that are vertical aren’t in the tab order and can’t be reached from a keyboard. Which means keyboard only users (which includes screen reader users and switch users) absolutely won’t have an equal experience.

#7 Custom objects when the word “ARIA” doesn’t appear in their code anywhere

It is almost impossible to make custom objects (like tabs) completely accessible without using ARIA code. Another place where ARIA code is 100 % required is when you want to announce something more than what is visually displayed. “Click here” and “learn more” links come to mind as the most common example of that.

If you run across one of these really common situations there is an easy way to check to see whether or not they are accessible without knowing how to use a screen reader or being able to code. Display the source in the browser and search for the word ARIA. If it doesn’t show up, chances are no consideration was given to making the website accessible.

#8 Floating nav bars

It is really really hard to make floating nav bars accessible. I know, I’ve tried. When a nav bar (usually horizontal) is fixed and text rolls behind it, this can be a very confusing experience for partially sighted screen reader users. Things are announced and can be activated without being completely visible. You can see an example of this at Museum of Ice Cream (the link is in the article). They also violate the color rule. And the accessibility statement rule. And the inaccessible partner rule.

#9 Lots of non-modal dialogs with poor focus management

Modal dialogs are pop-ups where you can’t interact with the stuff behind the dialog until the dialog is dismissed. Non-modals do allow you to interact with things behind the dialog while it is still active.

Non modals can be very disorienting to screen reader users because like floating nav bars discussed above, non-modals allow people to interact with text behind what is visible. That is why focus management is important. Non-modals without focus management are really not accessible

#10 Inaccessible third party partners

It is hard to find a major name brand site these days that doesn’t integrate with a third-party partner, though they try to make these integrations seamless. The most common source of third party interactions on a website or mobile app:

• Maps
• Payment gateways
• Cookie management
• Privacy
• Advertising

Choosing one or more inaccessible partners is a sign that you don’t care about whether or not your site is usable by people with disabilities. You are responsible for the inaccessibility of the companies you chose to do business with. Full stop.

This article was followed by a related article titled “7 things that turn good accessibility into great accessibility”

---

*with thanks to Kim Pettman who gave me the idea for this article