In multiple talks and posts, I’ve been known to push back against the idea that Accessibility (A11y) is difficult or costly. This ruffles some feathers among certain folks, but having worked both on the agency side and in the corporate environment, I will hold that position until the end of time.
Yes, there is absolutely some investment needed to get a proper A11y program up to speed. Yes, if your hiring process has not vetted employees properly it will take some training/learning time. Yes, there are always going to be folks that just don’t get the importance and need to be educated. However, A11y work (even in-depth remediation) is far less time consuming than switching to the hottest JS framework that’s taken the internet by storm.
The biggest hurdle in this line of work is shifting A11y “left” into the content, design, and planning roles. To help that along, I will outline the most common problems I’ve run into, and help you target what qualifies as inaccessible (and, more importantly, why).
To get clicks I’ve made it a top 10 list, so let’s start with the easiest (both to fix and test), and dig into more complicated issues as we go.
- Missing: ALT Text on Images, Captions on Video
- Low contrast ratios (especially text vs background)
- Relying on color alone to convey info/errors
- Skipped Headings (H1 -> H6) and Missing Labels
- Links have generic names (eg: learn more)
- Content is a mixture of reading levels, jargon-y
- Inconsistent use of icons/graphics
- Missing: Focus styling for keyboard users
- Missing: Skip links (content, nav, sitemap, etc)
- Mouse (Pointer) required to trigger UI elements (“keyboard traps”)
1) Missing: ALT Text and Captions
Most sites today are built on content management systems (CMS) like WordPress. That means our first problem is usually a content issue. You don’t need a designer or developer to remediate content problems, but to keep it from becoming an infinite loop, you need to start planning for accessible content much earlier than you’d think.
The typical failure point looks like this: a contractor is tasked with doing content entry for a new page/section, a task that’s a lot like color by numbers; they pull together the docs they’ve been provided which involves copy docs and image folders. Everything there has already been proofed, reviewed, and approved before it was handed-off to them, so they just do what it says (for better or worse). When upload images, the CMS includes a field for alternative text (alt-text)… there’s nothing about alt-text in the copy doc or image folders, so they enter nothing; they aren’t writers, and it’s not part of the acceptable criteria for completion, so it would be a waste of time to do otherwise. Some CMS’s treat empty alt-text as decorative images, in which case you’re mostly fine; others, however, provide the file name to assistive technology which can be confusing and disorienting for a user (which can be especially bad depending on the naming convention).
Allow this to happen for long and you’ve got an Everest sized mountain of work ahead of you and accessibility becomes a real chore. But the image’s alt-text should have been part of the project to start with! This is where “shifting-left” will make the problem non-existent in the future. Once images are selected (or maybe once they’re edited), someone should write a short description for them, or declare them as decorative, so everyone down the line knows what to do when/if the time comes to enter alt-text.
Captions should be easier, since most video content is scripted to begin with. Once the video is recorded, have someone double-check the script against the audio and convert it into a caption format; then upload it along with the video file. For non-scripted content, there are great tools and services to throw the job off to, like OtterAI and Descript. But in the smartphone era, captions aren’t just for those with an impairment; videos on social media are often viewed without audio, especially while users are in public. So, if you plan to share your content across platforms, skipping the captions means you’re losing a large chunk of potential viewers immediately.
In both cases, the job of writing alt-text or captions needs to be done well before final content is approved and handed off to the people who push it live. The earlier it’s considered, the better outcome you’ll have moving forward.
2) Low Contrast (Text on Background = 4.5:1)
One of the shortcuts made by new or self-taught designers is to use small, low-contrast text as a stand-in for something that feels refined or expensive. I blame Apple for this, due to the abundance of tiny gray text on their white charger bricks and packaging. It’s bad design that’s impossible to read and serves no one… when it’s regulatory text or mostly unimportant product specs, it’s fine to sort of hide it in plain sight. But when it’s copy on your website, it’s a lawsuit waiting to happen.
For UI elements, you need a contrast ratio of 3:1 compared to the background it sits upon. So if the color is white, the lightest gray you can use is #949494. This helps your design hold together when a device’s contrast is washed out thanks to a bright and sunny day, or harsh overhead lighting. The point of this rule is that you don’t want dividers or cards to vanish, leaving text & images floating in a confusing, hard to parse way. You designed those elements for a reason, so give them enough contrast to be clear no matter what.
For text, you need a higher contrast ratio of 4.5:1 compared to it’s background color. So if your background is white, the lightest gray you can use is #767676 (but I urge you to go with something darker). If it’s anything lighter than that, assume it’s unreadable. No one wants eyestrain because of your app/site, we would rather abandon the content or skim past it. After all, we have too much pulling at our limited attention spans to bother with your poor choice in font colors.
3) Relying on color alone to convey info/errors
One of the most common visual impairments, especially for men, is color-blindness. This is not something people broadcast to others and there aren’t many tools (like a screen-reader) to help counter this impairment; it’s instead something your users quietly struggle with throughout their life.
An example of this effecting your work: designers tend to put important text (like error messages) in red, because it’s the color of stop signs, warning labels, etc. Red demands attention and forces most users to pause. But for color-blind users, that red will look like a shade of green, brown, or gray… and if you didn’t check your color palette against a simulator, it may be barely distinguishable from non-required fields or labels that sit nearby.
This is why it’s important to not rely on color alone. Instead, include an icon or graphic as well. A small X icon beside the input that has an error clearly shows that something is wrong, no matter the color they perceive it to be.
4) Skipped Headings & Missing Labels
SEO nerds will probably appreciate this one as well, but a page should follow a meaningful sequence from top to bottom. The main headline of the page should be your only H1, section headings should be your H2, and everything inside of there should start at an H3 and work down towards H6.
Assistive technology relies on this structure to make judgements about what content is related to each other, and provide users with skip-links to hop across sections. If you follow semantic structure, it knows that this group of H3’s act as sub-sections to the larger H2 surrounding it; and that H2 is itself a section of the page’s H1 tag. Not only will users appreciate this clarity, but SEO crawlers/bots work a similar way, so this gets you a better score from search engine’s as well. Good, logical structure is always a benefit to your site/app!
As for labels, I know it’s trendy to drop the label from an input field and rely on placeholder text, but if you do that, know you’ll have to rely on ARIA attributes to make your site usable for anyone with an impairment. And if your placeholder text is low-contrast, that’s a problem twice-over.
5) Links have generic names
It’s not the mid-90s, so you shouldn’t still be using “click here” text for all your links. We know how links work, and many of your users are probably tapping them anyway.
We should be able to tell your link apart from the rest of the text, the copy for it should be descriptive (like a product name or page title), and if you’re using a card UI element, either make the whole card clickable or just the image and headline, that way your alt-text and/or headlines will act as the descriptive link-text.
This is super important because most disabled users rely on tech that looks at all links on the page to help them quickly scan and find what they’re interested in. If all they get back is a string of “Read Now” and “Learn More” text, you’ve inconvenienced them in a major way.
6) Content is a mixture of reading levels, jargon-y
Hopefully this is something your copywriters take into consideration already, but the general reading level of your site/app should fall around a 9th grade reading level. One major part of complying with this will be explaining any jargon or abbreviations before using them, avoiding use of the passive voice, and giving pronunciation guides for difficult, or technical, words the average consumer isn’t familiar with.
These rules don’t just help your content follow an accessibility guideline, but make it more scannable and easy to parse for everyone; bots included.
Approachable and understandable text helps everyone.
7) Inconsistent use of icons/graphics
Once you’ve declared an icon is short-hand for a specific thing, don’t misuse it elsewhere.
A great example of this would be the heart icon: you don’t want to use the same heart for saving products on your e-comm site as liking posts on the blog. Instead, one of them should be a star or thumbs-up icon to show that these two interactions, while similar, result in a different outcomes. On the product page, this will add the item to your list of favorites that’s associated with your profile. On the blog, it’s a method of feedback; you enjoyed or liked their content and would like more of it.
This may sound obvious, but when you start doing an audit of your products, you’ll soon find instances of content reusing product icons in ways you wouldn’t expect. It’s a brand issue, sure, but it’s also confusing for anyone with a cognitive impairment that relies on those visual shortcuts to navigate your site.
8) Missing: Focus styles for keyboard users
This is easy to test! Load up your site, ignore the mouse/trackpad, and start hitting the tab button. If the active item doesn’t get an outline, underline, or any other sort of styling, then it’s something your devs turned off and it’s making your site super inaccessible.
There are a lot of reasons someone may not be able to use a mouse to navigate your page, so focus states should never be turned off. This is a great time to review the idea of permanent, temporary, and situational impairments if you haven’t heard of them before.
Restyle your focus state to get them more subtle or on-brand if that was the concern. Whatever you do, just make sure the focus is high-contrast enough for everyone to follow it around the page.
9) Missing: Skip Links (content, nav, sitemap, etc)
Similar to the item above this, load up your page, ignore the mouse, and use the tab button. The first thing that appears should be a “skip to content” link, which appears even before your logo. Clicking the button that just appeared, should take you down to the “main” landmark in your code, so that a user can skip the header, navigation, and any sidebar/aside content that would otherwise precede the page’s main content.
This may not seem like a huge deal if you’ve a mouse user, or if your header and nav is very simple, but try using your computer without a mouse for an entire day and you will quickly get tired of skipping past the same header/nav items over and over again as you use the site to browse or compare items.
10) Mouse required to trigger UI elements (“keyboard traps”)
The most common place this becomes an issue are in menus, drop-downs, modals, pop-ups, tool tips, and any other “mode” that appears after interacting with a static area of your site. If you can’t access and close them via your keyboard alone, then you’ve created something a large number of users will never be able to use successfully.
This usually stems from a developer using mouse listeners (eg: onclick) but not pairing them with a keyboard listener (eg: onkeydown). It also comes from using CMS’s or frameworks with built-in methods which weren’t tested thoroughly because of it’s size or status in the industry.
I hate this one last because it definitely takes some dev and testing time to remediate, but it’s well worth the trouble. Any time a user is trapped or unable to access an essential part of your site, it’s a bug worth fixing; accessibility issue or otherwise.
If you made it to the end of this blog, congratulations! You’re now a novice in accessibility concerns and considerations. In most of my workplaces, understanding a list like this is the bare minimum to becoming part of the A11y Champions group. We don’t need everyone to be experts, but we do need people asking these questions and knowing when to look for help.
That wide, vs deep, pool of expertise will help make lists like this obsolete. When that inevitably happens (optimism is important folks!), make sure to check back for my next top ten list, because if you can’t already tell… I could talk about this for days.
