Accessibility can cater to a wide range of disabilities: visual, auditory, physical, speech, cognitive, language, learning and neurological. So, how is your application’s accessibility?
For example, have you ever asked yourself how the UX is for visually impaired people using your application? How would they navigate it? What would their user experience be? Might we need to create an ad-hoc navigation mode? Are our applications 'responsive' to them?
Blind people use screen readers to read and interpret the code labels, and navigate with the keyboard since they do not use the mouse. We don't have to make a new application for them; we just have to ensure our code can be understood by the screen readers. Then we improve/adapt it with functionalities for this type of user—those who (unfortunately) aren’t always taken into account when designing and developing applications.
If the code of your application is well labeled and can be navigated using only the keyboard (without a mouse), we could say that your application is quite ‘responsive’ to users with disabilities. If your application is programmed according to the 'good programmer's manual,' you would be ahead of many, since the screen reader will understand it to a great extent. But this does not usually happen in a real application and especially if it has certain time, maintenance and patches have been put in place to resolve urgent production incidents.
In our day to day, we know that applications work (almost) as well when we fill them with patches and code shortcuts to finish faster, but this is not the case if your ‘user’ is a screen reader. A screen reader is not going to know how to interpret disorderly code.
Things generally considered good practices but not essential for our application to work, become necessary here.
The good news: we won’t have to do anything extravagant to adapt our application. We do not have to make new ad-hoc applications, as the screen readers do the complicated computing and ‘translate’ our code to serve people with disabilities. But, yes, we must comply with programming standards so that those readers can understand us.
Let's get down to business.
Luckily, we have a clear, concise and standard list of W3C requirements that you can find in the Web Content Accessibility Guidelines (WCAG), version 2.1. Furthermore, this list includes a guide for each requirement with examples and guidelines to solve each case. It does not include how to diagnose your tool, but we will get to that later.
It may seem overwhelming at first glance, so we’ll break it down little by little.
The first thing is to see that the requirements are grouped into functional sections, but they are also cataloged at 3 different levels, and this is where we will focus first:
Examples: the application's business flows are logical and understandable, the forms to be filled in by the user are self-explanatory, the videos have subtitles ...
Examples: general labeling (both visible and non-visible, so that screen readers can read it): images, icons, headers, sub-headers ..., color contrast, consistency in the UX, error handling ... and keyboard navigation (without mouse).
Examples: texts and general use suitable for the secondary level, adapted and inclusive language for all audiences, adequate waiting or session times, sign language in the videos...
The A-AA-AAA levels correspond to the three certification levels. Here we have the first high-level decision to make, since it involves a budget: do we need to be certified? If the answer is yes, at which level?
Beyond the obvious reason that an accessible application benefits more people, the reasons for becoming certified may include:
To be practical, and not stop at this point to wait for a decision, what we can do— and in fact we did in our case—is to establish the AA level as a target, since it is a reasonable level to adapt our application to.
At the end of the day, if the eventual goal is to get certified, everything you have done to work toward the AA level is time and effort well spent toward a future specialized audit.
With this information, we may already be able to face a list of incidents and start correcting them, but as you may already be guessing, the main challenge here is getting that list of incidents. Who has the criteria to make a diagnosis of the application and prepare the list of incidents that we must to correct?
Unless there is an expert on the subject, it is unlikely there is a developer or tester on your team with specific training to test the application from the WCAG requirements point of view.
So aside from the obvious answer, like a specialized external audit, we are going to find a great ally: the Web Accessibility Evaluation tool (WAE tool).
As you can see, the list is huge, so we will filter it in three concepts:
The selected WAE tool will be our tester. It will prepare the list of incidents, test our fixes and is the one that is going to give us enough guarantees that our application reaches the AA level.
The most important point that the WAE tool does not reach, or at least not completely, is keyboard navigation, but we do have the ability to verify that our entire application is accessible by keyboard and that all the functionality it is executable without a mouse.
Now we have all the pieces.
Once this work is done, to advance further or become certified, you would need a specialized and accredited supplier to print a certification. In any case, you would be in a good position to face an audit with guarantees and, most importantly, your application would ALREADY be accessible to EVERYONE.
As always, leave a comment if you have questions or suggestions, and subscribe to our blog below!