Creating habits to cultivate the mindset and go from theory to practice
It may seem difficult to build a culture of accessibility when that is not the focus of a company or product. There is a myth that accessibility is expensive, demands resources and, above all, time. But what if I tell you it’s possible? Let’s start at the heart of the projects: the design team. Find out how to get started and gradually contribute to making a difference in digital products.
Talk to the team to bring accessibility professionals to promote talks and workshops
Before any practice, it is necessary to raise awareness. Introductory and theoretical content will be useful at the beginning of this contact of employees with accessibility. Creating this mindset into the company is the first step.
Create personas based on people with disabilities
In Brazil there is more than 17 million people with disabilities, according to the Brazilian Institute of Geography and Statistics. In addition, PWDs are the most diverse group there is: we have women, black people, LGBTQIAP+, elderly, rich, poor, I mean, all types! So, don’t exclude this vast group from your personas. In this way, we contribute to a greater diversity of public being considered from the beginning of the project.
Don’t let the team forget about “alternative” contexts in use case discussions
When using a certain feature, how will a visually impaired person interact with it? Are the instructions for use clear? Will people be able to understand, see and interact, regardless of where, how and with which device they are using? These and other points must be raised when describing use cases, considering any and all alternative scenarios. In this way, it is easier to propose an experience that meets the greatest number of people.
Institutionalize an accessibility committee for decision-making
It is natural that with a more active routine in the search for reaching WCAG AA and AAA levels, more contextual questions will arise that will not be possible to be resolved only by looking for answers on the internet. In this case, it is good to have a committee or group with selected people — who have more interest and availability to debate the issue — and who are dedicated to delving into an atypical scenario in depth to study it and reach a solution. This group may be responsible for deciding which paths to follow when there are doubts from other teams and forwarding solutions to be tested with users.
Add an accessibility approval step when creating components for the Design System
Let’s eliminate the problem of generating inaccessible legacy once and for all? Take advantage of the stage of building a Design System to officialize good practices for the use of components, as well as ensuring that they are passing WCAG criteria, such as color contrast and minimum touch area. See how Shopify’s accessibility is documented by the end of the page.
Score accessibility improvements in critiques rituals
We know that not all designers may be interested in delving into the topic and we may not have much control over that. One way to help them and also help the product is to remind them of good practices and point out improvements in the critique rituals, where we analyze layouts in order to detect usability problems and ensure the best possible quality. Accessibility can — and should — be remembered in these moments
Create a documentation template for developers
In the same way that we document interactions and functionality, it is necessary to indicate the expected behavior of each component aiming accessibility. This practice is great in the long run as over time developers will get used to some recurrences and will be able to develop faster and more effectively. Indicate each element that will have focus, as well as the navigation order of elements by keyboard, etc.
Don’t forget to evaluate accessibility in design reviews
Regardless of whether there is a Q.A. specialist or just a checklist made by the designer himself, add all the accessibility improvement points and take it to the developers. If it is necessary to prioritize, I suggest doing it based on WCAG, that is: prioritize changes from A, after AA and finally from AAA. In addition, many checklists had been made in order to help designers through this process, like the A11y Project Checklist.
Include people with disabilities in usability testing
Who better to validate our hypotheses than the users themselves? Include people with disabilities in test groups to validate functionality and ensure — at least as much as possible — that your product is on the path to being more accessible and inclusive.
Don’t forget to also consider older people, if they use your product, and contexts of situational and temporary disabilities, such as: noisy places, poor internet connection and so on.
Promote online tools and disability simulation extensions to designers
There are several tools that help us to have a direction, although they are not final decision factors. These tools can be Chrome extensions, websites, editing software plugins, and so on. Several of them simulate dyslexia, glaucoma, color blindness, etc. An interesting experience is to apply one of these “filters” and try to use the devices in this way for a while, feeling what it’s like to be in these conditions on a daily basis. Here are some examples:
Last but not least, be flexible
We know that we won’t always have a team that embraces the cause or we simply won’t have time to get all the details right, and that’s okay. The most important thing is to have strategy and focus: if you feel that the project time is short, prioritize some fronts and create an action plan. Which could be, for example:
- Initially meet WCAG A criteria. Then work towards AA, and further on, AAA.
- Prioritize by deficiencies: in a first version make as much accessible for blind people as possible, then for keyboard navigation and so on.
It’s not ideal, but it’s a start. And over time, it is possible to test with users and raise positive feedbacks to bring as an argument to the team leader. The important is not to give up.