Conducting accessibility design reviews

Accessibility design reviews are sessions with Designers for the Accessibility team to help with any accessibility considerations that would improve their product and align with the WCAG.

We see them as an opportunity to up-skill someone who might not know much about the technical side of accessibility, address changes before work gets into production, as well as an awesome chance for us to get exposure to different parts of the business.

What we check for

Before starting, we usually ask if they’re using XUI (our design system). The session can go in two different ways from there:

1. If they’re using XUI, we tend to focus on how they’ve implemented it. It can be useful to align the review with the Inclusive Design principles.
2. If they aren’t using XUI, we would default back to more fundamental questions. If we have enough time, we go through each item in a design checklist with them.

I’ll explain each scenario and some of the most common things we check for below.

Review when they’re using XUI

If they’re using XUI it’s likely they’ll have a mostly accessible design. These are the sessions that we pay extra attention to as we’ll be looking for implementation and customisation of the components. Here are some things we look for:

1. Page title
   The title will sometimes be the same as the H1, but it’s important to pay attention to pages where the content may impact the title, like when a user submits a form, for example.
   
   
2. Use of headings
   Does the page have a clear hierarchy? Have heading levels been annotated? Are there too many/not enough headings? Do they follow a logical order?
   
   
3. Consistent use of components (Principle: ‘Be consistent’)
   Let’s say tabs are being used on a few different pages: Do they all have the same function? Do they have the same trigger? Do they behave the same way?
   
   
4. Naming of components
   Some components will have an accessible name by default, but some of them will need a custom one. We look out for these scenarios:
   1. Multiple buttons that perform the same action (for example: a table with multiple ‘submit’ buttons related to different items),
   2. Group of fields (for example: group of radio buttons without a label),
   3. Buttons with a word and an icon, where each performs a different action (for example: moving a file to a new folder on Google Drive).
      
      
5. Focus order
   Focus order can be tricky to explain when only the design is being reviewed, but we usually think of it as the next logical step when navigating through a page. For example: If I start tabbing, will the focus follow a logical order of steps? If the user needs to open a modal, is it clear where the focus should go after closing it?
   
   
6. Buttons and links
   We look for buttons and links that might not be descriptive enough. For example: ‘Read more’ calls to action. Is the copy specific about what the action is? If the link text was read in isolation, would it still make sense? We would also send them to the Product Language Guide.
   
   
7. Non-text content (Principle: ‘Provide comparable experience’)
   For any non-text content such as icons or images, it’s important to ask if they thought about an alternative text for that element. Icons in a design system usually come with alt text, but they might have customised it, so it’s still important to ask. This sometimes triggers some cool conversations around meaningful vs. decorative images!
   
   
8. Field labels
   Look for customisation to the system components that involve removing a label. Removing labels will impact navigation with assistive technologies such as screen readers or speech to text software. One example is when two fields are combined under the same label, e.g. “full name”.
   
   
9. Animation (Principle: ‘Give control’)
   It’s important to give the user control over the interface they’re using. Look out for animations, videos, parallax or any other moving components on the page and if the user is given the option to pause it.
   
   
10. Hierarchy of information (Principle: ‘Prioritise content’)
    Some pages will be more complex and offer a few different actions for users to take. Is the purpose of the page clear? Is it easy to know what to do first? Are we enabling users to focus on one task at a time?
    
    
11. Complex patterns
    Cards, interactive elements inside interactive elements, interactive elements inside a toast, and any other patterns that involve a few different components can be tricky. We check these against Heydon Pickering’s ‘Inclusive components’ and recommend running usability sessions using platforms like Fable.

Reviews when not using XUI

If the team isn’t using XUI, we ask questions focussed on the implementation and fundamentals of accessible design. If we have time, we go through a design checklist with them. The most critical areas to cover are:

1. Colour contrast (Principle: ‘Consider situation’)
   Have you used any contrast checking tools? Does anything look like it might not be meeting the right contrast ratio? Remember this refers to the colour of the border of fields as well.
   
   
2. Touch target
   Is there enough area for an accurate selection? Especially for:
   1. List of links
   2. Two opposing actions side by side (for example: ’Submit’ and ‘Cancel’ buttons)
   3. An icon that triggers an action
   4. A toggle component
      
      
3. Different states for interactive components
   Have they designed the different states for interactive components? Does the selected state have a clear focus indicator?
   
   
4. Use of colour
   Look out for any elements that might be using colour alone to convey meaning. The most common are graphs, validation states, and destructive actions. We usually suggest applying a pattern to the area, or adding text to clarify what it refers to.
   
   
5. Do all of the checks from the other list as well
   1. Page title
   2. Use of headings
   3. Consistent use of components
   4. Naming of components
   5. Focus order
   6. Buttons and links
   7. Non-text content
   8. Field labels
   9. Animation
   10. Hierarchy of information
   11. Complex patterns

Session outcomes

We usually wrap up the session with:

• Summary of the main issues we found and recommendations on how to fix them
• Links to resources we might have mentioned during the meeting
• An open channel for communication for any other questions that might come up

‍