Team guide, Accessibility swarms

Accessibility swarms are one of the practices that help us meet the BBC Mobile Accessibility Guidelines. Assistive technology testing forms part of this practice, along with other accessibliity checks. We do this in a swarm format because accessibility is a team responsibility.

This practice also:

• Helps everyone better understand accessibility
• Increases engagement with accessibility
• Increases accessibility knowledge throughout the team
• Improves the user experience for our users

Accessibility swarms take place on all new front-end code, this means any change to HTML, CSS or front-end JavaScript code.

Who should take part?

If it's a new component or feature, hold a team accessibility swarm:

• Include 4 to 6 people
• You don’t need to have worked on the component or feature
• All disciplines can join in. The testing steps enable anyone, in any role, to use any of the supported assistive technology for the first time
• Ideally a mixture of roles should take part, such as business analyst, designer, engineer etc.
• If you don't have a large team, why not invite people from another team to take part. And you can return the favour for them another time

If it's a small change, carry out a developer accessibility swarm:

• You don’t need 4 to 6 people
• 2 engineers can work through the swarm checklist alone
• You only need to check what’s relevant. For example, if you have only changed a colour, then you only need to check what’s relevant to this. Such as colour contrast and colour blindness. Not sure what's relevant, ask

Back to page contents

Planning for swarms

The level of accessibility swarm, team or developer, should be defined up front and documented as a requirement before the development phase.

Back to page contents

When should a swarm take place?

• Before the work moves from development to test
• When HTML, CSS & front-end JavaScript is code complete
• After code review and UX review have taken place
• Some developer testing with some assistive technology should already have taken place

Back to page contents

How long will a swarm take?

• Some swarms will be shorter, some longer
• Allow 2 hours
• It will depend on the size and complexity of the component, and experience of the swarmers

Back to page contents

How to carry out a swarm

Before the swarm starts, prepare a document to make a note of any issues. Also ensure you'll have all the equipment you need:

• Android device with Talkback
• iPhone
• Mac laptop
• Windows laptop with supported assistive technology installed
• Headphones with microphone, to use with Dragon NaturallySpeaking on Windows e.g. Jabra headset

At the start of the swarm:

• Brief the swarmers. Is there something that you need to look out for that might not be obvious? Such as some visually hidden text
• Get into pairs, technical role with non-technical role, such as designer and engineer. We all have different skills and can help each other along

During the swarm:

• Work through the swarm checklist, with each pair looking at different items from the checklist
• Test with all supported assistive technology following the testing steps
• Make notes of any issues
• Prioritise bugs

After the swarm:

• Create tickets to fix the issues you aren't going to address as part of the current pull request
• Include information on how to replicate the issue and the bug priority level

Back to page contents

Moving to the test phase

• Swarms take place before work moves from development to test. On a rare occasion, if the swarm checklist was not completed fully, fill in the gaps to ensure there is complete testing coverage
• If the code hasn’t changed since the swarm, you do not need to repeat what was carried out during the swarm

Back to page contents

Top tips

• Be proactive, any discipline can request and start a swarm
• Work at component level rather than page level
• The more swarms you do, the more familiar and faster you will get
• Always follow the testing steps
• Not sure? Ask an accessibility champion

Back to top