I sometimes give talks on Web accessibility, and one of the top questions I get is: What can I do right now to make my website more accessible? When I began practicing accessibility, I would’ve probably talked about WAI-ARIA authoring practices, and adding
In reality, the most common accessibility problems can be fixed with simple solutions. What follows is a list of some of the quick wins I’ve compiled from online survey results, third-party auditors, and the A11y Slack group.
This one’s truly easy. Check the color contrast on your page. This should be the designer’s job, but frontend developers should be diligent to double-check and make suggestions as necessary. Usually, it doesn’t take many tweaks to ensure the correct contrast ratio.
This is a super-quick win. According to the 2020 WebAIM Million survey, one of the top accessibility errors online was missing
alt attributes on images. It’s always a good idea to include effective alt text on images that are not purely decorative.
It’s important to note that if you don’t add an alt attribute, the default behavior of screen readers is to announce the source link of the image, which can be annoying, especially if you’re including hashes in the filename for cache-busting. So what about images that are decorative? Use a null value (
alt=""). Better yet, add decorative images as background images via CSS (
One way screen reader users can quickly navigate content is by jumping through all the available page links. When all the links on the page are either “Click here”, nonsense (e.g. icon fonts), or empty (e.g. an SVG icon without a label), navigating by page links becomes impossible.
If you’re being asked to create “Click here” links, talk to the content authors about the difficulties of that type of phrasing. As a bonus, using descriptive link text is better for your SEO. You can learn more about link text in WebAIM’s article about links and hypertext, and Scott O’Hara has a great article I continually reference for accessible SVGs.
This goes along with the last tip. Form elements (
button, etc,) must have properly associated labels.
button elements are easy to label:
<button>I'm a label</button>
For the rest, you need to associate a
label element with the form element in question:
<input id="element-id" name="username" />
label has a
for attribute that’s the same as its sibling
id. That’s how accessible technology knows what label is associated with what input. Avoid using
placeholder as a label. In fact, you probably should avoid using the placeholder attribute altogether.
ARIA (Accessible Rich Internet Applications) is a collection of roles and attributes that enrich plain old HTML to support interactions that are currently not possible with HTML. The first rule of ARIA is Don’t use ARIA. Great marketing, right?
The truth is, modern HTML can cover most UI needs. Don’t believe me? There are over 100 current HTML elements, and many of them have ARIA roles already baked into them. This brings me to my next tip.
spans are great to style with, but they have no meaning whatsoever to accessible technology. Wrapping large blocks of text directly in a
div should be avoided with few exceptions, and those exceptions involve manually adding semantic meaning via
<div>This text has no meaning whatsoever because divs are a
<p>This is a paragraph of content.</p>
Wrapping text in a
span is a great way to style a select group of text, just make sure it’s inside another element that has semantic meaning:
<p>This is a paragraph. <span class="red">This span has no semantic meaning,
but we're still inside a paragraph, so it's fine.</span></p>
<span>Without a semantic parent, this text has no meaning.</span>
You can restyle the focus ring, but make sure it meets contrast guidelines. The reason is keyboard users need to be able to see where they are while tabbing through interactive elements.
One reason why the focus ring gets hidden is that clicking on interactive elements in certain browsers focuses them, activating the focus styling. If you only want to show the focus indicator for keyboard users, try
So when would you want to do this? How about a cards that link to other pages:
<a class="card" href="/page">
<h2>Title of Article</h2>
<p>Small blurb here.</p>
Why avoid this? For starters, you can’t easily select text inside of links. Second of all, links are announced in screen readers by reading off the contained text content. The more content inside the link, the more inconvenient the link text becomes. I’ve made a Codepen showing a couple of approaches to get around this.
Valid HTML is important to ensure that your content renders correctly for years to come and that it works well with accessible technology. Little things like adding closing tags, properly nesting elements, and following the HTML spec can make a huge difference for your SEO as well. The W3C has a solid HTML validator that works well.
This one’s something you should probably put into a snippet. Specifying the document’s language helps translation apps, improves the SEO of the page, and improves a screen reader’s ability to pronounce certain words. Here’s how that looks:
Of course, use the ISO language code that pertains to your chosen document language. This attribute is inherited by all children, so placing it on the document element (
If you keep this list in mind, you will be well on your way to ensuring your website is accessible to the widest audience possible. Not only will it improve performance, SEO, and readability for all of your users, it’s the right thing to do.
If you enjoyed this article, please consider sharing this article with others. And if you have any questions about any of the points above, feel free to ask me on Twitter.