Adobe Creative Cloud

May 26, 2016 /

Part 2: How to Conduct a Basic Accessibility Audit on Your Site

In case you missed it, catch up on Part 1 of How to Conduct a Basic Accessibility Audit on Your Site. In this post, we are going to learn how to do keyboard, screen reader and automated code testing.

Testing with a keyboard

Understanding how people might be using your site with assistive technology is a great way to gain empathy and insight into the impacts of poor accessibility.

Remember that some people may not be able (or not want to!) use a mouse, due to motor impairments or personal preferences. Navigating by keyboard takes some practice. The basics are:

  • The tab key moves forward through interactive elements on the page and shift tab moves backwards.
  • Using the enter key should select a link or button.
  • The arrow keys should navigate within dropdowns.
  • The space bar works with form controls for example checking or unchecking a checkbox.
access3

Gov.uk has a skip to main content link and a clear visual focus state when using a keyboard.

To run a keyboard test on your site:

  1. Go to your site.
  2. Unplug your mouse – you are not allowed to use it. No cheating!
  3. Hit the tab key to get started.
  4. Is there a skip to main content link? This allows users to skip the navigation or repetitive elements across pages.
  5. Is it visually clear which element of the page you are on (this is called the focus state)?
  6. Do interactive elements have the same functionality as they do when using a mouse?
  7. Is the order of the focus states logical?

As you get the hang of keyboard navigation, you will learn how important the order of focus states is, as well as discovering interactive elements which don’t function well. A common problem is a ‘keyboard trap’ – where you cannot move away from an interactive element using the keyboard alone.

Screen Reader testing

You can get a sense of how people use screen readers by watching demo videos on YouTube. Here, someone is using NVDA on Firefox.

Screen readers do what the name suggests – they read the content on screen aloud. This allows a visually impaired person to use a computer and browse the web, using a keyboard and screen reader software. There are many different screen readers available. Mac products have built in accessibility features, including a screen reader called VoiceOver. A popular free one for Windows is NVDA. Popular paid options include Jaws and ZoomText.

When you are starting out, you will likely want to use free screen readers rather than investing in a paid option. The first thing to do it to get familiar with how it works. VoiceOver on Mac and iPhone have practice tutorials you can use to familiarise yourself. Windows users can download NVDA and access tutorials.

access1

Access VoiceOver Training on your Mac through System Preferences > Accessibility > Open VoiceOver Training

When you are somewhat comfortable using the screen reader software and your keyboard to navigate, you are ready to try out your site.

  1. Have screenreader software turned on
  2. Go to your site
  3. Close your eyes and start using the site, using keyboard and audio only
  4. Listen carefully for anything that does not make sense
  5. Can you move around the page and understand the content?
  6. Does the tabbing order make sense?

It’s ok to find this process challenging – it takes time and practice. It is a great way to build empathy and understanding for a range of users. Some things to look out for include the way the screen reader reads abbreviations or date ranges, or punctuation marks. When you feel lost on a page, it can be helpful to refresh the page and start again to orient yourself.

Best practice is to test with a couple of screen readers on a few browsers, and on several devices, as different browsers can product different results. When you are starting out however, you may want to focus on one browser and screen reader combination as you get comfortable.

Automated Code Checks

There are several tools available which are designed to automatically check website code for accessibility compliance. These can be really helpful for conducting accessibility audits, however, it is strongly recommended that you do this as the last step of your process. Code checker results need human interpretation by someone who understands accessibility – they often show false positives, for example flagging the lack of an alt tag for a decorative image that doesn’t need one. Doing this last will reduce the number of errors you see as well as make you confident that you have examined issues like color contrast.

access2

Toggling on the types of issues you want HTML CodeSniffer to include in the report. This site has no errors, but the 8 warnings are worth examining.

  1. Install the HTML CodeSniffer bookmarklet
  2. Go to your site and open the bookmarklet
  3. Select the WCAG standard you will test against (2.0 Level AA is a good rule of thumb)
  4. Toggle the types of issues you wish to see in the report
  5. Review the report and interpret the errors and warnings

Remember that an automated code checker has limitations and cannot assess whether alt tags or links make sense. With practice you will learn to understand the results and warnings of an automated test and whether they need to be actioned.

Basic accessibility audits can go a long way

Accessibility is multi-faceted, and improves UX for everyone. There are many aspects, including using plain language, designing with visual impairments in mind, and creating compliant code.

Throughout this post and in part one, you have learned the steps to assessing the accessibility of the websites you are involved in designing and developing. By taking the time to do these basic audits you can start to build your understanding and skill, and make huge improvements to the accessibility of your site. Remember to start small, build your knowledge and work step by step. Your users will thank you!