When I first worked on the accessibility topic some years ago, I had a basic idea what “A11y” (short for Accessibility) stands for, but within 2 days, a customer message reaching my inbox titled: “I cannot access my system anymore because I forgot my password”. At least, you can learn from this what Accessibility is NOT.
In a software context, “Accessibility”, “Design for All”, “Universal Design” and “E-Inclusion” all describe the same thing. Users who have difficulties using software need to be supported in the best possible way, with a definition of “difficulties” ranging from not being able to use an input device (e.g. keyboard, mouse, or touchscreen) to not being able to recognize what’s on a screen due to colorblindness or low vision.
Let’s have a deeper look at accessibility from a LEGAL, TECHNOLOGY, and VISUAL DESIGN perspective.
Within the last years, LEGAL regulations in the area of accessibility have been established in many countries, mostly derived from the W3C / WCAG [Web Content Accessibility Guidelines] standard. In the U.S., for example, “section 508” (of the U.S. rehabilitation act) is seen as an economical driver to enforce accessibility, requesting each software vendor who wants to sell software to the U.S. government to disclose the accessibility status of the offered software in a document called “VPAT” (voluntary product accessibility template).
From a TECHNICAL perspective it is vital that the software can interoperate with both platform-specific and generic mechanisms to support the end-user when applying specific settings (such as colors or text sizes) and when assistive technologies are used (such as screen readers, braille keyboards or specific input devices, including voice input). In HTML-based environments, for example, this means that HTML and CSS is strictly W3C compliant according to WCAG2 and especially that custom elements are correctly tagged according to the WAI-ARIA standard. With that, most of the interoperability with assistive technologies and also responsiveness when it comes to adjusting text sizes and so forth is taken care of.
Most software comes with a finely balanced VISUAL DESIGN that gives the product a unique look (as with consumer products) or that is brand conform, to be coherent with other products from the same company (for example with enterprise software products). In either case, end-users with low vision, colorblindness etc. might need (or might just prefer) to change colors, fonts, or text sizes. Unless the underlying UI technology does not allow arbitrary visual changes at the operating system level as mentioned above, capabilities to define alternate themes need to be provided. Using style sheets is one good way to deal with these requirements.
Finally, here is a quick and dirty way to test the accessibility:
- … test your desktop software with only a keyboard attached (no mouse or touchpad)
- … apply the high contrast settings of the device or select a high contrast style sheet and see if you can still use the software
- … use a leading screen reader (desktop) or turn on the voice-over options and try to work with the software
So, please feel encouraged to DESIGN FOR ALL. This will result in better software for everybody, not just users with disabilities.