<header role="banner">
  <h1>Your main page title</h1>
    <a href="#main-content">Skip to the main content</a>
 </header>
    
<!-- Further down the document -->
<main id="main-content">
  <!-- Put your main body of content in here and other really important stuff -->
</main>

This little trick should help your screen reader users out in a big way, because they can go ahead and skip the fancy bits and dive right into your important content. It’s also great for keyboard users for the same reason.

Another nice touch is to add a :focus style to the skip link that makes it visible. Try pressing your tab key on GitHub.com. Pretty neat, right?

Use Elements Appropriately

So, elements are a pain in the butt to style right? That doesn’t mean you should attach your JavaScript events to a

or an though. You see, when you use a

, you get keyboard events for free. You’re also helping screen reader users out because it’ll announce the element correctly. Check out this example:

document.getElementsByTagName('button')[0].addEventListener('click', evt => {
  alert('Oh, hey there!');
});

If a user focused on that button and hit the enter key, that event would fire. That makes both yours and the users’ lives a bit easier. Well worth it, right?

See the Pen Button click example by Andy Bell (@hankchizljaw) on CodePen.

Get Your Heading Hierarchy Locked-Down

It’s really common for screen reader users to navigate a page by using the heading structure. That means we should help them out and create a nice hierarchy for them. Let’s take a look at a standard blog post:

<main id="main-content">
  <article>
      <!-- The page title is up in the main <header> in this instance -->
      <h2>My awesome blog post</h2>
      <p>Vestibulum id ligula porta felis euismod semper.</p>
      <p>Vestibulum id ligula porta felis euismod semper.</p>

      <h3>A sub-section of this post</h3>
      <p>Vestibulum id ligula porta felis euismod semper.</p>

      <h4>A sub-section of the sub-section</h4>
      <p>Vestibulum id ligula porta felis euismod semper.</p>
  </article>
</main>

With that sample, the user can navigate to the start of “My awesome blog post” and then have the ability to skip to sub-sections and nested sub-sections easily. They can also skip back up. It’s just a nice way of helping them consume the content you’ve produced as easily as possible.

It can be recommended that a page has a single

element, even though the W3C HTML5 spec says you can have many. I personally agree with the use of a single

, but you can have many, as long as you follow a nice structure and hierarchy. That’s the key here.

Get Your Color Contrast Right

To be WCAG 2.0 AA compliant, you need to have a contrast ratio of 4.5:1 for normal text. This is your paragraphs, buttons, navigation, etc. You need to go for a ratio of 3:1 for larger text, such as headings. I’d say this should be your minimum as it’s incredibly achievable with tools such as Tota11y, Contrast and the WebAim contrast checker. You can still get plenty of color balance and variation in your design too.

The reason that contrast is so important is because there’s so much variation in environment that you probably don’t even consider, such as bright sunlight and poor quality displays. Add this to a visual impairment or, say, a migraine and you’re potentially causing problems for your users.

Getting the contrast right will have a huge, positive effect across a wide spectrum of your users.

Responsible Text Labels

We’ve all built out a list of items with a non-descriptive, but visually appealing “More” button, right? More what though? We need to be more responsible with this and provide some context.

One way to achieve this is by visually hiding descriptive text with CSS and hiding the non-descriptive text from screen readers. It’s tempting to use display: none;, but screen readers can ignore elements with that set, so we need to be more creative. I use something like this little helper:

.visually-hidden { 
  display: block;
  height: 0px;
  width: 0px;
  overflow: hidden;
  clip: rect(1px, 1px, 1px, 1px);
  visibility: hidden;
}

With this CSS in place, we can do something like this:

<a href="/link-to-your-page">
  <!-- This is hidden from a screen reader, but visible visually -->
  <span aria-hidden="true">More</span>

  <!-- This is visible to a screen reader, but visually hidden -->
  <span class="visually-hidden">Continue reading: "Your post title here"</span>
</a>

A sighted user will only see “More” and a screen reader user will hear “Continue reading: ‘Your post title here.'” Both sets of users are happy.

You can also achieve the above by using an aria-label on the tag. This will override the text within for a screen-reader:

<a href="/link-to-your-page" aria-label="Continue reading: 'Your post title here'">
  More
</a>

Small Typography Tweaks With a Big Impact

It’s always worth remembering that people with a visual impairment or learning difficulty could be trying to read your content, so some small tweaks to your typography can go a long way.

A body of content such as an article should be sized at 16px (or equivalent unit) at a minimum. It’s also worth increasing your line-height to around 1.5 too. Space between lines can help readers with dyslexia to understand your content better. The combination of size and space is also great for older people and/or short-of-sight people. Even small summaries and aside content should be at least 12px (or equivalent unit). Anything smaller than that will alienate users who struggle to read.

Another trick is to highlight key words and phrases if your content is quite complex. This not only benefits users who are slightly slower at processing content but it also helps people who like to scan over an article, like I do.

Lastly on this section, I’d advise you to be careful with your font choices. Fonts with complex ligatures and decorative elements can be really distracting, so maybe limit the usage of those to key, large headings only. It’s also been advised that sans-serif fonts are better for readers with dyslexia. Check out this article for more on that and other text formatting tips.

Enhance Keyboard Support

There are a few little tweaks you can do to help users who primarily use their keyboard to navigate your website.

Say you’ve got a little button that shows a dialogue when you click it. You should attach an event to the escape key that hides it. Here’s a sample snippet:

document.addEventListener('keyup', (evt) => {
  if(evt.keyCode === 27) {
    // Run whatever code hides your dialogue
  }
});

See the Pen Escape key demo by Andy Bell (@hankchizljaw) on CodePen.

Another tweak you can do for our keyboard-navigating buddies is not hiding focus from them. Browsers give us focus states for free with outline. I know it can look ugly, but hot-damn it’s useful for keyboard users. If you want to get rid of that blue glow, I get it—just please use the :focus pseudo selector to add an obvious state change to it instead. Here’s a sample:

.your-element {
  background: red;
}

.your-element:focus {
  outline: none; /* Reset the default */
  box-shadow: 0 0 0 3px black; /* A very obvious state change */
}

Don’t Rely on Color Alone to Communicate State Changes

Let’s end on a really important one. Color shouldn’t be relied upon alone to communicate state changes. Take this scenario as an example:

You’ve got a button that posts a form. You wrote some neat JavaScript that makes it go grey while it sends the data. It then either turns green or red, depending on what the status is.

For a colorblind user, this is a nightmare. To them, the button may have barely changed enough for them to notice, so they may just keep clicking and clicking while getting really frustrated. This isn’t ideal.

So, instead of relying on color, let’s enhance that with a status message that supports the button’s state on response.

See the Pen Enhanced state change communication demo by Andy Bell (@hankchizljaw) on CodePen.

That sample is a great way to quickly communicate to the user that something has changed and the use of color, text and iconography clearly communicates that change. Disabling the button whilst the response is processed is also a great help to the user.

Wrapping Up

These little tips should make a big difference to your users, and I hope you dive into your projects and implement some of them.

You should also keep learning about accessibility. I recommend following people such as Heydon Pickering, Scott O’Hara, Laura Kalbag, and Rob Dobson on Twitter. I also recommend that you check out resources such as Inclusive Components and the A11y Project.

The greater your knowledge gets, the better your websites and products will be for a much wider audience. That can only be a good thing, right?

---

Small Tweaks That Can Make a Huge Impact on Your Website’s Accessibility is a post from CSS-Tricks