Team process and role-based accessibility

Contents

• Introduction
• Accessible by default
• Time and budget
• Think about the entire journey
• Using 3rd-party services
• WCAG AA is the baseline, not the aim
• Team responsibility
• Embedding accessibility in team processes
• Dealing with accessibility debt
• Wrap-up

Introduction

Accessibility is a complex thing and it involves all aspects of a product's lifecycle from the initial idea, to design, development, testing and maintenance. It also needs support to be implemented cohesively and robustly.

Without a process to work to we become too reliant on the goodwill of individuals and when these individuals leave accessibility knowledge and practice leaves with them. Processes mean the entire team is brought along and accessibility becomes part of everyone's job.

Accessible by default

We should not see accessibility as an add-on or a nice-to-have, it should be just part of how we work, whether that is during kick-off discussions, during a discovery phase or during a build. We should never see accessibility as something we can deprioritise or leave until later.

Time and budget

Accessibility in a project will add some additional time (and budget), but it will result in a much better product.

Make sure you allow time for your team to get up to speed and learn as they go. Think about avenues for help for the team - is there an in-house an accessibility team they can run things past for example? Think about setting up some process right at the start of the project (see Definiions of Ready and Done below).

The most important thing is don’t wait - it is never too early to start thinking aout accessibility and including users in your discovery phase.

Finally, make sure you schedule time both to prepare and undertake accessibility audits (especially if your team is in the Public Sector).

Think about the entire journey

Accessibility doesn’t start and end with the code we put on a screen. The user has to get to the product in the first place - how do they do that? Is it through a social channel, an email, a print campaign or something else? Are we looking at the whole journey and making sure it is as accessible as possible?

It’s no good if the online product is accessible if the social media posts are not.

Also think about the off-ramps from the product. Are contact mechanisms capable of supporting all the users - is there a range of contact options to allow users to choose the one which might suit them best? How about 3rd party integrations such as help-desks? If a user needs to raise a support ticket can they use the platform provided to follow it up?

An example of poor ancillary communication methods is a case against DWP where it was found they had discriminated against a blind user by not providing communication in an accessible format.

Then think about any support staff, are the systems they work with accessible? How about how the user logs into the product? Are those authentication methods accessible?

Using 3rd party services

If you are embedding or paying for 3rd party services then the responsibility for their accessibility comes down to your product. Do some investigation before signing up to any 3rd party services and where possible ensure accessibility is covered in any contracts.

Claims of WCAG compliance is one metric but it is often cited with no real data to back it up so treat such claims with caution if there is no evidence or demonstration of processes. Look for the ability to request fixes to bring in compliance where it is lacking. This expectation of the level of support should be covered in any contract.

WCAG AA is the baseline, not the aim

There is often a confusion that WCAG AA compliance should be the aim of a product. Unfortunately this would leave a lot of users behind as the WCAG criteria are not all-encompassing. There are lots of ways a product can be WCAG compliant but place barriers in front of their users.

Because of this we should view WCAG AA compliance as only the baseline for accessibility. We should always aim beyond this, leaning on testing with actual users, assistive technology and devices to bring a holistic approach to accessibility. If a user is having problems with a product, pointing to your WCAG compliance statement is not going to help them.

Just working to passing WCAG rather than true accessibility means we are just doing the bare minimum to make something just accessible. That's not enough.

Read more about WCAG, guidelines and legalities.

Team responsibility

Everyone, regardless of their team role, can contribute to making a product more accessible. We should never leave it to one person on the team to always be pushing for accessibility. Having one person with sole responsibility means others aren’t contributing their own valuable experience and makes it too easy for pushback. It also means the team never upskills. Reliance on a single person will mean they will quickly get overwhelmed and burn out as they try to fix issues caused by the rest of the team.

The only way forward is for everyone to take responsibility for their area. Look at drawing up a RACI matrix to show who is responsible for what at each stage of the project.

Example RACI matrix

This example shows that each role is responsible for their own section and shows how responsibility for accessibility moves through the team along with the work. Notice also that previously responsible team members still need to be consulted so that solutions are correctly implemented.

• A = Accountable (the person ultimately accountable for the task)
• R = Responsible (the person doing the task)
• C = Consulted (people who should be involved in decisions)
• I = Informed (people to keep in the loop)

Embedding accessibility in team processes

“Accessibility lives in people, processes and tools”

Derek Featherstone

Our aim should be to have accessibility embedded in the team processes so everyone knows their role and no one person is taking on all the accessibility work and responsibility.

Treat accessibility issues as bugs

This means we treat accessibility issues as what they are - bugs, not features. Any other situation where users are having barriers placed in front of them by the code or design would be jumped on, but for some reason if it is an accessiblity concern it tends to get put way down on the backlog.

Having the accessibility-issues-as-bugs mindset will push us more to fixing any accessibility issues in the current ticket within that ticket’s timeframe rather than spinning off another ticket to fix it later.

Real-world testing

Where possible we should be including people with assistive needs in all stages of our product design and development. This goes hand-in-hand with real device testing to ensure what we are producing both satisfies the needs of the user and the abilities of the technology they use.

How users have their assistive technology or adaptations configured can impact on how they interact with the product, so getting this insight early on is key to developing a truly accessible product. Try to work in regular user testing throughout the project.

Consider accessibility in every ticket

Sometimes accessibility will obviously not apply, but if we get into the habit of at least thinking of how accessibility might play into a ticket then we go a long way to catching issues before we write any code, and that is where the savings really come. See Definition of Ready below for more on this.

Implement robust testing

Good accessibility testing means multiple stages and types of tests.

Testing should begin at the design phase and follow through all the way to go-live and beyond. The person responsible for delivering the content, design or code is ultimately responsible for ensuring this testing is done and what is delivered is accessible.

Designs in particular need to consider how different groups of users will perform the required tasks and how the design will adapt to different user preferences such as font size. Questioning designs before they are passed onto the development team is an important aspect of this. All this information needs to be communicated to the development team .

• manually triggered automated testing on design documents, during code development, code reviews and QA testing
• automated testing as a pipeline tool for continual baseline assurance
• manual testing to catch issues automated tooling cannot, again at all stages of development. This can range from simple keyboard tests to more complex assistive technology testing.

Testing is something which team members need to be aware of and then know how to conduct so there is a bit of a learning curve. Like many skills this will become easier with continual application.

Some tests such as screen-reader checks will require more effort but a few simple commands can cover most of the requirements.

Read more about testing strategies

Add automation but don’t rely on it

Automated tests in accessibility are useful but should not be relied on to take care of your accessibility concerns for you. Automated tests can only check against specific criteria and a lot of accessibility depends on context and wider aspects of relationships and information conveyed by the page as well as different states.

Because automated tests do not have the contextual awareness needed to check effectively they are often cited as only being able to find around 30-40% of issues.

However this does not mean that automated tests are not useful. They should be seen as a baseline - a zero failure in automated tests is an easy benchmark but should be seen as the minimum start-point.

Automated testing in a pipeline can be very useful in flagging any issues creeping in, it will allow you to see when things are getting worse, but also when things are getting better. If the team has access to this data it can be just the mental boost they need.

Manual testing will be required to take us beyond that and into true accessible products.

Definition of Ready

When looking at work which needs to be brought in to a sprint, take some time to look at how accessibility requirements might be addressed.

Be really specific when asking questions - for example “How will someone using speech recognition access the information on this page and navigate successfully?”

Annotating designs in Figma or Mural can help convey important information about desired page markup (such as relationships between content, heading hierarchy, non-visual copy, or use of ARIA) to developers and will help inform questions before the work is started.

Some questions to ask:

• how will this work on smaller viewports?
• does the content have the appropriate reading level, are we using language which can cause issues such as metaphors?
• what is the heading hierarchy - does it follow the visual hierarchy?
• will someone who cannot see the screen still get the information and the relationships between the content?
• do all the interactive elements have focus indicators?
• do non-decorative images have meaningful alt text copy written?
• are all the different error messages considered and are they helping the user fix the issue they are facing?
• do visually-identical links have hidden contextual copy to make them unique for screen-reader users?
• are interactive elements without visual labels given meaningful accessible names so they can be addressed by speech-recognition users and understood by screen-reader users?
• does this journey require users to remember details from previous pages?
• is there a need for the user to do work which we could do for them?
• are we making any assumptions? For example are we assuming how a screen-reader would work with this component or have we actually tested it?
• be prepared to take a ticket back to the design phase if accessibility issues are raised. It is better to have an accessible design to work from rather than build an inaccessible one and have to retro-fit accessibility later.

Think about each user group, for example:

• screen-magnification users
• screen-reader users
• switch users
• keyboard-only users
• speech-recognition users
• users with reduced dexterity
• English as a second language
• users with memory impairments
• user who find dealing with numbers difficult
• users with cognitive difference such as ADHD, ADD, dyslexia
• colour-blind users
• users with vision impairments

Depending on the specific work a set of accessibility requirements can be drawn up. For example:

As a sighted keyboard-only user

In order for me to successfully navigate the page

I need interactive elements to show a clear focus indicator

Definition of Done / PR ready

Issues found after the code has been merged will normally become the responsibility of another ticket in the backlog, rather than be fixed at point of causation. It is only by finding and fixing issues as they are created that accessibility will be seen as an integral part of development practices.

The desired outcome here is to effectively add a release gate so we are not introducing accessibility issues to the codebase which will need to be picked up later at a greater cost.

Any accessibility failures should be found and fixed before a PR is raised, but the code review should also look at potential accessibility issues which have been missed.

When looking at the outcomes of a piece of work, specifically when it is a code ticket there are some tests we can do to ensure the work is accessible, beyond what has been raised as part of the Definition of Ready. These checks should be done both by the ticket-holder but also by the code-reviewer.

1. View the page being worked on in the browser. It is often eye-opening how often this simple check can be overlooked. Whenever work is done on a page which is rendered to the user the page should be viewed to verify the output.
   • If the changes are complex also verify how the page renders in different browsers and devices.
2. HTML validation - while this may not always expose an accessibility issue it is an easy check
3. Check no issues are raised by automated tools (such as Axe or Wave plugins).
4. If using a pattern library, verify the page follows the guidance - these often have a lot of advice around how to code up specific examples and are not just for designers.
5. Check all hidden copy (including those added using aria and alt attributes) are correctly rendering (no-one likes exposed message keys) and translated where applicable.
6. Finally, manually test the page. This is the most important aspect when it comes to accessibility as so much in the published specs is not supported in assistive technology or cannot be checked with automated tooling.

Dealing with accessibility debt

It is often the case that accessibility only gets raised as an issue part-way through a build, or even at the end after launch. Whilst it will now cost more in time and budget to fix any issues found it is still important to tackle any potential accessibility debt.

First you should put in place some processes to avoid technical debt from increasing any more:

• set up automated checks in the pipeline if possible to help give some baseline metrics and show if the debt is getting larger (and help with a morale boost when you start to reduce it).
• use the steps outlined elsewhere in this article to embed accessibility in the team processes and limit the number of new accessibility issues being introduced

Then you need to know how big of an issue you may be looking at:

• find out what you don’t know - use a full accessibilty review of the product to find out what issues you have
• make sure issues from this review are recorded on the backlog with an epic so progress can be tracked

Work through the issues which you find:

• triage the issues and prioritise them
• set some realistic timescales for fixes
• add firebreaks into feature build timelines to allow the team to fix accessibility issues
• document the current state and keep track of progress to keep the team and stakeholders informed and motivated

Wrap-up

It may not be perfect immediately. Accessibility is tough and some aspects may seem simple but have hidden complexities. You will likely make mistakes.

Take it one step at a time, it’s easy to get overwhelmed. Processes help keep everyone on the same page and provide structures of support.

Just make it better today than it was yesterday.