Why accessibility for everyone actually affects—well, everyone.
If you have ever planned a website you might have heard about accessibility before. You might have even noted “accessible system” as a requirement, and by doing so you have checked it off a list? We have often experienced how accessibility was marked with a low priority. And yes, we have heard the argument “Blind people are not our target group” more than once. No joke.
It’s about time to clarify a few things. On one hand, visual impairment is just one aspect of accessibility. We will name some other aspects in this article. On the other hand, any person can be temporarily handicapped. More people than you should initially think will benefit from accessible web pages. Some of them are definitely part of your target group as well.
Accessibility means that a web page or more exactly the information provided by a web page is accessible for everyone, independently from physical or cognitive limitations or limitations of the currently used device.
In terms of web accessibility, most people think about blind people first. Which is not wrong because that is indeed a not too small group. For example there are about 4,7 mio people who are blind or have a severe visual impairment in the USA (according to the World Health Organization, in 2002). Poor accessibility will block their access to information or goods. Not to forget that voice assistants are conquering the housholds. You should really make sure that your website is ready for voice interaction.
Another widespread impairment is the inability to see certain colors. About 8 % of the male population can’t distinguish the colors red and green. Also there are some devices like e-book readers which can be used to view web pages but only have a gray-scale display. Even if you do not have any visual impairment: Did you ever try to view a photo in your smartphone in bright sunlight? – Exactly.
Impairments are often not permanent. Anybody who has ever tried to use a mouse with the non-primary hand knows how difficult that can be. In situations like this it is very helpful when a website can be fully operated using the keyboard.
With aging the eyesight decrases. We then benefit from a possibility to enlarge the text on a web page using keyboard shortcuts of the browser. But on many web pages this will cause distortions and overlappings in the design of the web page, often making the page unusable.
Cognitive impairments are not only related to mental capabilities. Distractions caused by the environment can also be the reason. Have you ever tried to read a complex text with many abbreviations or technical terms while using public transport? Distraction is one of the most common and most overlooked impairments faced by the users of websites. Often websites are designed in a way which assumes that the users’ focus is 100 % on the current page and everything they have just read is fully present in their minds.
The goal of accessibility is to make sure that all information provided by a web page can be perceived by as many people as possible and that the web page can be used with all suitable devices. In a way, making a web page responsive (the layout adapts to the screen size of the device) is already an accessibility enhancement.
There are several so-called assistive technologies which enable people with severe impairments to use a computer. The most prominent example are screenreaders which convert the content of the screen into speech. But there is large number of other assistive technologies like screen magnifiers for enlarging parts of the content or special input devices allowing to operate a computer by eye movement or breath modulation.
All common operating systems provide interfaces which can be used by applications to provide information for these assistive technologies. Most web applications lack this information. To fill this gap, the W3C has developed the Accessible Rich Internet Applications Standard (ARIA). ARIA defines additional attributes for HTML which can be used to provide this information. As an example, ARIA attributes are used to make a modal dialog controllable for a screen reader.
The good news: There are standards
What are the requirements for an accessible web page? The most important guidelines are the Web Content Accessibility Guidelines (WCAG) published by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C). (Did you notice how the abbreviations and technical terms disturb the flow of reading?) The WCAG are using four principles to define several guidelines and success criteria for accessible web pages:
As a supplement to the WCAG, the W3C publishes two additional documents:
- Understanding WCAG 2.1 provides detailed explanations of the success criteria of the WCAG.
- Techniques for WCAG 2.1 describes several possible techniques for implementing the success criteria of the WCAG.
The European Union’s directive 2016/2102 makes accessiblity obligatory for all websites of public institutions. It further recommends a harmonisation of the regional directives.
Now who is responsible for creating accessible websites?
To create truly accessible websites it requires work from any role participating in the creation of a website. Here are some examples of what the different roles should care for:
- Structure content hierarchically with according headline formats
- Write captions and descriptive alternative text for images
- Write meaningful link text (instead of “read more”)
- Explain abbreviations and technical terms in easy words
- Build semantially correct tables (e. g. replace first line bold typesetting with semantic table heading cells)
- Identify language changes for foreign words (e. g. use the attribute lang=“fr” for a French pronounciation of “Bon appétit”)
- Use images with sufficient contrast and avoid text graphics (unless you add alternative text for these, see above)
- Create a flexible (responsive) layout that allows upscaling of text and images
- Choose colors/color contrasts responsibly and test them
- Prefer well readable fonts over fancy looking ones
- Plan and test the design for different devices
- Design hiarchichal headlines (after asking the editors) in a fashion that will not result in abuse for the sake of tastes
Content management system
- Correctly identify page language according to content translations [TO DO: add to German part]
- Create a base page structure with semantically correct HTML
- Allow adding/editing of alternative text, captions, per-word language identification in all text fields (maybe even enforce certain attributes)
- Offer accessible interactive elements (e. g. buttons as buttons, not as lookalike links, take special care for date fields with calendar widgets) [TO DO: add calendar hint to German part]
- Allow for the creation of truly accessible forms
(implementation and/or indidual coding for the specific project)
- Design extensions in a fashion to follow accessibility standards
- Adjust user interface elements to a system-wide UI standard (e. g. re-use the CMS’s default objects instead of hard-coding your own, this way you’ll benefit from future system-wide enhancements)
- Push your quality assurance colleague/department to test accessibility as well
Customer/product owner/quality assurance
- Clearly state that accessibility has a high priority and be prepared to maybe pay a little more for that (it will pay off)
- Build up own competence, hire consultants
- Have websites professionally tested, not just professionally built
You will see: Accessibility will pay off. Less complaints, less dropouts, less support costs. And maybe you will notice with a smile that in fact blind people are a part of your target audience.
Perspectives in a nutshell
WAI has issued a number of short videos, giving insight in different perspectives of accessibility. This is a compilation (of course, a transcript is available).
By the way, you are very welcome to contribute transcripts (subtitles) in further languages.