Rapid Accessibility Assessments

One of the most important steps of the accessibility journey is understanding where you are right now. To do this you need to test your website, you can test it yourself, use tools and/or pay someone to audit it for you.

The best advice I can give for accessibility is don't wait to get started. Yes getting a full audit done by experts can be a useful step but don't pay someone to find the issues you could find and fix yourself. This is where the rapid assessment comes in.

A rapid assessment should take no more than two days. This means it has to be heavily scoped and limited it terms of the depth of testing. It involves manual and tool-based testing that should give you the headlines, the major issues that affect your user on the core journey.

A majority of this testing can be done by anyone with a computer and a smartphone. The screen reader testing will be new to most people but is exceptionally important to do, we've provided the link to some screen reader guides.

It helps to understand accessibility, the more you know, the more issues you'll spot. That being said the methodology below will highlight issues for people with or without prior accessibility knowledge.

Here is how we do rapid accessibility assessments:

1. Define Scope

We separate the scope into core features and core pages to make it easier to test and group related issues.

Core features include header and footer navigation or anything else that is present on every page. Features like navigation are often very different between mobile and desktop so we split those out too.

Core pages are the 5-6 pages of your website that are most important to yourselves and your audience/customers. When assessing the core pages you do not record issues that have already being found in the core features, this avoids duplication of issues raised.

Example for an eCommerce website:

Core Features

• Desktop Header Navigation
• Mobile Navigation Menu
• Footer

Core Pages

• Home
• Product list page
• Product details page
• Basket
• Checkout

2. Assess

Our methodology for accessibility assessments for each scope (feature or page) is as follows:

Step 1: Scan with Lighthouse

• Lighthouse highlights most colour contrast issues, missing labels on images/links and a range of other issues.
• All the issues come with descriptions
• Lighthouse is available on Chrome - here is a Lighthouse Guide
• There are a lot of issues that lighthouse and other automated testing tools can't find which is why we move on to manual testing

Step 2: Mouse on Desktop

• Start by identifying the interactive elements e.g. links and buttons, they should have hover styles when you hover over them and the cursor should change to a pointer to indicate that they are interactive
• Especially identify any “hover functionality” i.e. when you hover over something a menu appears, this is especially important for later when testing with keyboard
• Are all the buttons big enough to be easily clicked? Also important for later when testing on mobile, are they easily tapped with a finger

Step 3: Keyboard on Desktop

• Put the mouse aside and use your TAB key to navigate the page (it’s the right pointing arrow button left of Q key), you can navigate a page’s interactive elements (buttons, links and forms) with the TAB key and you can SHIFT+TAB to go backwards.
• Now test that you can access everything you were able to access with your mouse with only your keyboard
• If there are modals on your website (AKA dialogs, AKA popups) test that you can you easily navigate in and out of them with a keyboard
  

Step 4: Screen Reader on Desktop

• This is the first time in the assessment you need any new skills. Using a screen reader for the first time can be tricky, here are some guides to get started on your machine: Deque University Screen Reader Helpsheets
• The method is the same as for keyboard. Test that you can do everything you were able to do with a mouse, this time with a screen reader.
• Are the images described with labels? Do the link and button labels explain what they do?
• If something appears on the screen e.g. a success or failure message, is that message announced to the screen reader
• If there are modals on your website (AKA dialogs, AKA popups) can you easily navigate in and out of them with the screen reader

Step 5: Touch on Mobile

• Similar to mouse, this step is about identifying the functionality of the page e.g. I tap this button and this menu opens etc
• Identify any swiping functionality
• Are the buttons big enough to tap?

Step 6: Screen Reader on Mobile

• You should be able to see a pattern by now, test that you can do everything you were able to do with a tap or a swipe with the mobile screen reader. Here are the guides again: Deque University Screen Reader Helpsheets
• If there are modals on your website (AKA dialogs, AKA popups) test that you can you easily navigate in and out of them with the mobile screen reader

Record any issues you find, next I'll talk you through the templates we use for recording results.

3. Recording Results

When recording results we try our best to avoid duplicates and try to group problems in to distinct issues that can be picked up by the most relevant team.

We use a google document to record the results into a digestible report. This can be useful for some otherwise we'd recommend using a spreadsheet.

In our report document we give each test scope it's own number and heading e.g. 1. Desktop Navigation, 2. Mobile Navigation Menu.

Each scope gets its own table with the following columns:

• ID is used to refer back to a specific issue in a specific scope
• Description describes the issue
• Method is the assessment method used to find the issue e.g. Keyboard
• Success Criteria is optional but we use it to refer to the Accessibility Guidelines called WCAG
• Severity is a grading of the issue, we use STOP, Critical, High, Medium, Low and Bug, which we explain below
• Correction is how the issue should be fixed e.g. change colour to meet contrast level or add label to image
• Examples is where we put screenshots to make it easy to find

How we grade severity:

Stop denotes that the issue blocks access to such an extent that it prevents testing for other issues. Once the issue is corrected, additional testing will be required.

Critical points out the issues that will block access for a person with a disability or would make the content very difficult to understand. The issue will cause the page to fail the accessibility guidelines and should be fixed as soon as possible.

High means that the corresponding errors are the most important to fix and result in the page failing the accessibility guidelines.

Medium indicates that the corresponding issues will cause the page to fail the corresponding guideline. However, in the evaluator’s opinion they are a bit less critical than the issues marked High.

Low points out minor divergences from the details of the guideline or best practices associated with the guideline. This issue does pass the accessibility guidelines but could be improved and made more usable for people with disabilities.

Bug is unrelated to accessibility but we found it so thought you should know.

4. Fixing issues and Reassessing

Fix the issues in order of severity. Assess again fix the other issues you find. If you need more assurance either for legal or accreditation reasons now get a professional audit, they'll assess with multiple assistive technologies and multiple screen readers and they'll assess a much broader scope of your site.

What's next?

One very important point, that I probably should have started with, is Audits are rubbish. They cannot tell you that your site is accessible. They tell us is that: we found no issues, on this date, in the defined scope of testing (if you've fixed all the issues you found).

Any website that is being actively worked on, will change and new issues will be introduced.

The real solution is cultural, accessibility must be treat a priority in every aspect of a business including design, development, site management, social media and so much more.

But that's for another blog post, it's a journey and annoyingly I think it has to start with an assessment.