Creating more usable accessibility guidelines

Simplify guidelines to ensure your teams design with accessibility in mind.

Brian Grellmann
UX Collective

--

Accessibility guidelines, such as W3C’s WCAG 2.1, are often criticised for being overly technical and difficult to understand. They require experts to understand them and expertise to implement them. Even if your company has access to people with enough accessibility knowledge to apply them correctly, there can be disagreement on how each guideline should be interpreted. What’s more, your company likely has fewer accessibility experts than people involved in making design decisions. This presents a challenge when you want teams to create and build products with accessibility in mind.

Easy-to-understand checklists do already exist; however, the very nature of a checklist is to be an evaluative exercise, at the end of a design review or development cycle. By this time, accessibility becomes an add-on instead of an integral part of the product’s inception. In comparison, guidelines are intended to be a reference throughout a user-centred design process, making them more useful, but they need to be usable and understandable by all the people who use them, at all stages of the product development lifecycle.

The approach for a simple set of guidelines

One way to include accessibility in your process is to transform or translate accessibility guidelines into a simple set of requirements for the people who will use them. By doing so, you make the guidelines easier to understand, more applicable to a person’s role, and perhaps more relevant to your design or build process.

Many companies and organisations have already taken this approach and you can use these as a starting point. Some have incorporated accessibility guidelines into an existing website like a design system website or accessibility toolkit website, and others have a standalone guideline website. Within the guidelines, the information architecture can vary. Some websites organise guidelines by component, and others organise by job role. Indeed, there may be other solutions or formats, and many companies also choose to not publish their guidelines publicly. Have a look at what other companies have done. Below is a screenshot of one of the latest set of company guidelines to be created and shared by Expedia.

A list of guidelines related to colour that have been translated from W3C’s WCAG for the Expedia product teams
Expedia have shared what they call Expedia Accessibility Guidelines, or ExAG. They’ve created a standalone website with guidelines that have been translated from WCAG 2.1

Examples of published guidelines:

Below are some examples of accessibility guidelines which have been created by companies and organisations.

  1. Standalone guideline website
    Expedia Accessibility Guidelines (ExAG)
    Visa Global Accessibility Requirements (VGAR)
    BBC Mobile Accessibility Guidelines
  2. As part of an accessibility toolkit or website
    Government of Southern Australia Online Accessibility Toolkit
    GOV.UK Service Manual
    Harvard’s Online Accessibility website
    Orange Digital Accessibility
    Government of British Columbia Accessibility and Inclusion Toolkit
  3. As part of a design system website
    IBM’s Carbon Design System
    Sainsbury’s Luna Design System
    Adobe’s Spectrum Design System
    Bulb’s Solar Design System
  4. As a printable poster
    Home Office Digital’s dos and don’ts posters

If you know of other examples or formats to add, let me know in the comments and I’ll update this list.

Considerations for creating a set of guidelines

Your approach will of course differ depending on the budget and resource you have available to undertake this. If you need to create your own set of guidelines, here are some considerations:

Know your users

Like any project, some upfront research will go a long way to help you understand your users and their requirements. Talk to the people who will use them: designers, content writers, developers and testers to find out what works for them. You might consider usability testing existing guideline websites, or running card sorts to understand mental models, among other methodologies. Understanding your user’s requirements will ensure that whatever you build will be useful to the way they work.

Get the right people together

You’ll need an accessibility expert to help distill the guidelines. If you don’t have access to experts, you can hire an accessibility consultant to help you. Most importantly, involve the people who will ultimately use the guidelines, and co-design to find a solution that will be useful for everyone. This won’t be a one person job; what a developer deems easy to understand may be difficult for a designer, and a designer’s mental model of an interface may be very different to a developer’s.

Consider the structure

There are a number of ways you can present your guidelines. You might embed them within the components of your design system website, or perhaps a standalone microsite will be more appropriate for your users and the size of your organisation. You might also consider where your company is at in terms of accessibility maturity, what the most impactful format would be, or where your other brand, design, and experience guidelines are published.

Your guidelines won’t replace industry standards or user research

Remember, if you create a set of guidelines for your company or organisation, they won’t replace industry recognised global standard’s like W3C’s WCAG 2.1. When it comes time to measure the compliance of your website, you’ll need to do so against these standards.

Although accessibility guidelines get criticised for being overly technical, there is a need for this. Building accessible products is technical and requires a lot of expertise. Following standards ensures people with different access needs and people who use different assistive technologies are able to use your products, which in turn mitigates the risk of a lawsuit.

Creating more usable guidelines that your team can use throughout the product development cycle will empower designers, developers, and content writers to design more inclusively by giving them the knowledge and tools that are most relevant to their roles. As a result, you’ll have fewer surprises and remedial work after conducting your next accessibility test or audit.

Finally, it goes without saying that guidelines and standards don’t replace user-centred design methods. Involving participants, designers, and consultants with disabilities from the beginning of your project will be the best way to ensure you build accessible products. After all, your users don’t experience guidelines, they experience interfaces and services.

Many thanks to everyone who helped me find examples, submitted examples, and proofread this article for me.

--

--

UX / User researcher based in London, UK. Researching accessibility and inclusion. Work in financial services.