How does one define an accessible application? Or the other way round; how do I guarantee that my application is accessible?
There might never be 100% accessibility for any application and the questions above are equally difficult to answer. But standards to the rescue. There are guidelines to check for accessibility criteria.
WCAG – Web Content Accessibility Guidelines
By today the Web Content Accessibility Guidelines exist in version 2.2. They consist of a long list of criteria to meet when an application is meant to be approved for accessibility. The criteria are sorted into four topics. Perceivable, Operable, Understandable, and Robust.
Perceivable
Within a perceivable application, all the content, information and functionality can be perceived by everybody. Despite having bad eyesight or being blind.
To be perceivable means to clearly structure informations and present them in text form, as well as being mindful when using colors and contrast. Because even the state of an active link counts as perceivable information.
Operable
An application is operable when all the information and functionality is available regardless the method of input. There are keyboards, joysticks, sipp-and-puff-devices and touchscreens. Representative for all these possibilities is the total operability via keyboard.
It is recommended to learn the basic short keys to navigate and use inputs. Gestures and touch are not forbidden in accessible applications but keyboard accessible alternatives must exist.
Understandable
An application counts as understandable when texts are semantically clear, easy to read and without typos, but also when the functionality of buttons is obvious. Or which content hides behind links, images, or icons. What happens, when a particular button is clicked?
Obvious to some but other users might need additional labels or explanations.
Robust
A robust application can run on as many different devices as possible. Despite size, resolution, and orientation. Responsive design is key, but it is also important to maintain a useable layout when text size or gaps between words are changed.
Tools
Every week the number of accessibility tools grows. Keep in mind that they are just that: tools. The outcome has yet to be understood and interpreted. Also tools can never predict 100% accessibility.
Nonetheless tools are a good starting point to get a feeling for the own applications accessibility. It even comes with neat numbers and stats to be improved.
Lighthouse
Lighthouse is a browser extension that runs in all chromium based browsers. It scans the page for “accessibility” and lists findings and potential for optimization.
WAVE
The Web Accessibility Evaluation Tool takes the pages URL to analyze it. WAVE lists positive finding, failures and even warnings.
This tool only works for applications that are available via URL from the internet (so not suitable for local development).
Quick Check
Humans are better than machines (in this case). Best would be to have some test users with disabilities to test the page, but for a first glance it is possible to technically emulate some of the most common barriers.
- The developer tools may switch a page to black and white to emulate missing color vision.
- With Strg +/- oder by tweaking the system settings, the application can be zoomed in and out (at least try for 200% Zoom).
- It is not enough for an application to look and feel perfect on a desktop (where they are created) but also on mobile devices. This includes portrait and landscape mode.
- All functionalities must be available via keyboard only. So without gestures, touch, or mouse.
- If you feel brave, try a screenreader. Is all the content correctly read to you? Are there invisible elements that should not be read?
Combining these tools and a manual easy check one does not gain an official WCAG audit. This serves as a first glance at how accessible your very own application is.
Leave a Reply