5 ways we make sure our sites are accessible

Accessibility is an often overlooked but extremely important part of any website. Not only to comply with AODA, but also because we want everyone to be able to use our sites! Here are 5 things that we do to make sure our websites are accessible.

1. Check the Flow of Document Headings

Just like a document, written content on the web is made up of headings and paragraphs. HTML provides specific tags for these headings and paragraphs that have semantic meaning. That means that when content is read by a screen reader, the screen reader provides context by letting the reader know what kind of text they are reading.

Users are also able to jump from heading to heading within a page.  But just like a well vs. poorly organized paper, the contextual information only makes sense if these tags are used correctly. If you strip away all the extra visual information, a well structured page should resemble an outline — with only one main heading, and then the next heading levels flowing in a logical order.

We check all our pages for this logical structure:

  • Each page should only have a single H1
  • Heading levels should not be skipped. Eg. an H2 followed immediately by an H6
  • Headings accurately represent an outline of the page content.

2. Test Keyboard Navigation

A second key component of accessibility is to ensure that keyboard users are able to navigate the pages. There are many reasons that someone may not be able to use a mouse, and we need to make sure that anyone who relies on a keyboard does not become frustrated with our site and leave the page. If you are curious about keyboard navigation on the web, you can do a little experiment and try navigating a couple of your favourite sites using your tab key. You can tab to move from one interactive element to the next, and shift + tab to move to the previous.

How did it go? Here are some questions you might ask yourself:

  • Were some interactive elements skipped?
  • Were you always able to tell where your tab was?
  • Were you able to actually interact with the element that you were on by hitting enter?
  • Did you get stuck anywhere? Were you able to escape out of any modals or menus that you activated? Did your focus return to a logical place after escaping or did your tab get lost?

These are all questions that we ask as we test our sites, and we ensure that any problems we find are flagged and fixed.

3. Make sure Images have Alt Text

Alt text is one of the most important accessibility features on a site. It provides a text description of any image in your site. This description is read by screen readers, but it also provides a fall back if an image file is not loaded or if a user has turned off images (for example if they have a slow connection or limited data).

Alt text can either be provided in the content of a page within the context of the image, or we can use something called the alt attribute if we do not want this content to be visible. Every image must have an alt attribute, even if it contains no content. If it does not, a screen reader will attempt to read the image path name, and it is usually unintelligible! Thankfully WordPress handles this for us, so you don’t have to worry about this happening to any users.

Even though WordPress ensures that we don’t confuse our users, we still want to make sure that any image that has semantic meaning and doesn’t have a contextual description has appropriate alt text. We want any non-sighted users to have as complete an experience of your site content as your sighted users! We go through each page and ensure that every image that conveys content has appropriate contextual content or text in the alt attribute.

Read more about why alt text is important.

4. Run Automated Accessibility Testing

Next we run automated accessibility tests. These will check for issues with poor color contrast, missing context from buttons and links, as well as some semantic and structural issues. While automated testing can’t catch everything, when we combine it with manual testing, it provides another line of defense in our accessibility checks.

5. Test VoiceOver Navigation

Finally, we utilize VoiceOver in order to do a full functional test of the site using a screen reader. This step is really important because no amount of automated testing can truly replicate the user experience!

Here are some questions that we ask as we test sites:

  • Do the headings make sense and give an accurate overview of the page?
  • Is there any text being read in a way that doesn’t make sense (for example, screen readers will interpret text written in all caps as an acronym and read each letter, this is why we write all our content in sentence casing, and then apply styles to any text we want to visually capitalise!)?
  • How does navigation go? Is there a way to skip to the main content?
  • Are interactive elements properly identified by the screen reader?
  • Is it clear where links are going?
  • Can we navigate any modals, accordions, and carousels on the page, or do things get confusing?

If you are curious about what it is like to navigate the web with a screen reader and you have a device with MacOS, you can try this too by going into System Preferences->Accessibility->VoiceOver and Enable VoiceOver. The button for VoiceOver Training will teach you how to use it. You can then try navigating through some of your favourite sites.

View more Posts