Accessibility (a11y) is so much bigger than just making things work for people with no or low vision. But, even if you define it so narrowly, that’s still 285 million people or ~5% of the world’s population.

Here are all of the techniques in both software and design that I have used to make this site accessible to all!

Note: I‘m using The A11y Project‘s helpful checklist as a rough starting point for this post.

Reducing My Reliance on JavaScript

This site is built using React, a JS library. But, it renders everything from the server before all that JS does anything. The JS then progressively enhances the site to enable things like super-fast additional page loads. This means that the site will be accessible even if the JS were to fail for any reason. While javascript is fairly reliable it does have a small chance of failure, of around 1%. Keep in mind that it’s not 1% of people who always encounter a broken site, and 99% of people who don’t. It’s 1% of visits.

As an architect, I am constantly considering the  “-ilities” . When considering availability people often focus on the infrastructure design but application design also plays a huge part. The site will always work without JS, meaning that I don’t need to cut the mustard by creating a two tiered experience, essentially tweaking code so that my JS only runs on the supported browsers.

Making it responsive

The definitive guide to ensuring a website is usable on any device/software is Responsive Web Design. I followed it throughout the design for this website.

Writing semantic HTML

The easiest way to make something accessible is when you get it for free. By using <header>, <footer>, <nav>, <button>, and other elements appropriately, you build accessibility into the very structure of your site. This includes using <h1>, <h2>, etc… in a sensible order.

Supplanting semantic HTML with aria landmark roles

While most browsers automatically associate, say, <main> with aria-role="main", not all do. So it’s best to go ahead and define those manually.

Focus states

A lot of sites have some CSS like this to remove the default dotted outline when elements are focused in some browsers:

a:focus {
  outline: none;
}

Don‘t do that! If you absolutely must remove it, you also must define your own focus styles.

Use alt text (and the equivalent for SVG)

Any image in the content of a site must have an appropriate alt attribute defined. The only exception is images that are purely decorative.

For SVGs, you can use the <title> and <desc> elements to describe the graphic in combination with aria attributes.

Test for sufficient colour contrast and colour blindness

Researchers have determined a minimum threshold for foreground/background colour contrast that is readable by most people, which is specified as part of WCAG. You can use a tool like aXe, which integrates into Chrome‘s Dev Tools, or tota11y, which can be integrated into your site or used as a bookmarklet, to check if the text of your site meets this threshold. There are some gotchas, though:

1. It will only test actual text and backgrounds, not text that is part of or on top of an image.
2. It cannot determine the contrast of pseudo-elements (::before & ::after)

After running checks, if I find any colours that need changed, I like to use Colorable to find values with sufficient contrast.

Consider a “Skip to content” link

Sometimes a site can have a lot of stuff that a person using a screen-reader or restricted to a keyboard would have to wade through before they get to the content. Including a link to skip down to the content in the very beginning of your page that is visually hidden until focused is a nice way to help them out.

This site has a very minimal header and the primary navigation is at the bottom of the page, so the link I‘m adding will be “Skip to navigation”.

Make sure to use descriptive links

Consider the post teasers on my articles page. They have a title, a brief excerpt of the post, and a Keep Reading… link. Sighted users can see that the “Keep Reading…” belongs to the post above it, but screen readers have no way of relaying that information to their users. That is, not without a little help.

We can use aria attributes again to add a more descriptive label to those links:

<article role="article">
  <h3 id="making-this-site-accessible">
    <a href="/articles/making-this-site-accessible/">
      =Making This Site Accessible
    </a>
  </h3>
  <em>
    <span title="Janurary 1, 2018">1 days ago</span>
  </em>
  <div>
    I want to be able to share this website with everyone, 
    no matter who they are, what device/software...
  </div>
  <a 
    href="/articles/making-this-site-accessible/" 
    aria-labelledby="making-this-site-accessible"
    >Keep reading…</a>
</article>

You should also generally avoid using generic phrases like “Click here” for your links, because they provide very little context.

Test, test, test

After you’ve done everything you can, you should test your site using assistive technology tools. Ideally, you‘d do so with someone who uses such tools on a regular basis, but you can simply use the tools yourself in a pinch. If you‘re on a Mac, you have handy tools like VoiceOver built in.

Well there you have it a short list of key things that I feel are important for accessibility. This code as with the rest of the website is available on GitHub. This article as part of a series of articles about the making of this blog.

By Damilola Payne