Even if something may seem common sense to you, you will be surprised at how many things you overlook during your design phase. And when it comes to A11y principles, your product will probably not pass the basic A level of accessibility. In order to help you and your team know how you stand, it is important to conduct accessibility reviews.
When should you do an Accessiblity review?
It’s crucial to keep accessibility in mind from the earliest stages of design and development to create an app or a website that is accessible and suitable for everyone. If accessibility concerns are addressed at some later stages, it is significantly more difficult to fix them.
But, it is advisable to periodically review the product’s accessibility to catch possible issues that occurred during the development phase.
The best way to start is when you first start designing your product. While designing, you can simultaneously check and keep in mind all the principles and guidelines.
Align with other team members or use annotations in your design file to communicate certain A11y levels that require syncing with the rest of the team.
For certain parts that can only be reviewed after the product is implemented, you must align with the QA and Development team to test it out. Usually, QA should be responsible for reviewing voice-overs, touch target areas, font scaling, etc.
If you didn’t design your product by following the A11y principles, you would need to ask your project managers to provide you with time for this review. It will probably take 2-3 days for you to review your design. However, that depends on the scale of the product.
The best time to include this is when you are in the phase of offering suggestions and improvements* to your product.
Lastly, if you start getting complaints that your product can not be used in certain conditions, that will be your red alarm to start reviewing and implementing A11y principles.
How to conduct an Accessiblity review?
Go over our four chapters to learn about Perceivable, Operable, Understandable, and Robust principles. For each category guideline, see an example in order to understand its purpose. Plan out the review strategically by choosing the way that best suits your needs. Strategic ways to divide the review are per platforms, per A11y categories, per app’s main navigation and hierarchy. You can review your design file or the implemented product. Use plugins & tools to check specific A11y points. Use the checklist template to note down the A11y status of your designs. (P.S. It will be a useful type of documentation for project managers and product owners, too.)
Don’t feel overwhelmed. Review the parts in your domain and the power to do so. The product you are helping to create should be a mutual responsibility between the whole project team. So, covering A11y should be a shared responsibility between the client, content provider, development team, product owner, project manager, software tester, product strategist, data analyst, and you, the designer. > Align with QA (software testers) on performing certain parts of the review. QA should test the implemented product and check how the app or site is usable with voice-over, touch target areas, dynamic font scaling, etc.
Educate and include your content providers in building a more accessible product. You will need their help for video & audio transcripts, content (alt text) descriptions, wording, and overall communication inside your product.
A11y as a shared responsibility
As we mentioned, being A11y-compliant should be the responsibility of the whole project team. But this only works if the whole team is aligned on the A11y issue. There will be a requirement for syncs and alignments.
- Content providers, usually “the client”, need to be aware of their responsibilities: providing you with content descriptions and transcripts for any video/audio content.
- Copywriters, UX designers, or any dedicated team member shaping the product’s communication must be aware of the Understandable principle and use wording and product communication in alignment with those guidelines.
- The QA team needs to include A11y points when testing out the product implementation.
- The Development team will handle correct label ID implementation, the correct order of elements, touch-target areas, etc.
- Designers should be aware of all the A11y principles listed in this guide, but not all of them will be in their domain to address. Therefore, alignment with the rest of the project team will be required on certain parts.
- Project managers & product owners need to plan out A11y as a part of the acceptance criteria and include A11y reviews as a part of the product’s timeline.
- Data analysts should provide the project team with information on how the app is used.
If A11y is included in the earliest stages of the product design and development, it will not require significant scheduling.
What after the review?
Share your findings with the project team. (Use the checklist template) Let your product owner create an Accessibility epic and user stories based on the provided documentation. The product owner should create separate user stories for design-related and development-related issues. After improvements are implemented, QA should test it out by following the A11y accessibility criteria.
Check our A11y Review checklist template! Duplicate it in Figma and track how accessible your app is.
