However, individuals who are visually impaired usually find these actions more difficult online when websites do not implement appropriate accessibility features. This article explores ways to make web applications more accessible to those who perhaps need it most.
What does “accessibility” mean?
Accessibility refers to the ability of a tool to be used by the widest possible audience including those with any type of disability. Examples include screen readers, braille displays, and devices adapted for people with reduced mobility. To include them, many strategies can be progressively adopted during different stages of development.
Accessible design
Begin in the UI/UX design stage by keeping style guides well-defined and consistent. Additionally, allow the user to easily customize properties from a settings panel. For example, a brightness/contrast setting will help people with reduced vision, color blindness, or light sensitivity but also those without disabilities deal with conditions such as sudden changes of light.
Always avoid using multiple design patterns such as forms with primary buttons that have different background colors or multiple texts with different font colors. Similarly, avoid components that exclusively interact with mouse events such as displaying additional information when it passes over an element. While visually striking, because they do not respond to keyboard events it makes it impossible for a blind person to interact, limiting their access.
Another factor that usually affects accessibility is the presentation of the text in a Web application. Using italic fonts, justified text, or even certain typefaces could create "rivers" in the content that can make it difficult and even confusing for those with dyslexia [1]. To avoid this problem, it would be appropriate to keep the text aligned to the left, avoid using decorations or shadows, and use sans-serif fonts instead of Serif [2]. In addition to these tips, The British Dyslexia Association (BDA) offers a style guide that could help you improve the content in your applications.
Accessible navigation
Navigation is one aspect where developers often fail, especially in single page applications. The main culprit is often the asynchronous loading of elements. Here’s an example:
Note there is a tabs pane which allows you to see a list of different items. When you open the page, by default, the first tab opens and the API is requested to load the elements. When you click on the next tab, the same thing happens, the only difference being the information displayed. The key point is the header, sidebar, and other sections remain unchanged.
The problem is that screen readers are not usually notified of such changes, which negatively affects people with blindness. Likewise, if the screen reader is focused on the lower part of the screen, they will never find out that the upper part has changed due to an asynchronous event [3].
To deal with this there are several strategies you can use including:
- Always change the document.title on each page transition, as it is the first thing the screen reader reads. If the title is not present or descriptive enough, navigation will be much more complicated.
- Once the content of the page has been loaded, make sure to put the main element of the page in focus. In this way, the user will know of the context change and not get stuck in the middle of a page without realizing it.
An example in React:
const MyPage = () => {
const mainElementRef = useRef(null);
useEffect(() => {
document.title = "About | Site Name";
/* Set focus to the content ref */
mainElementRef.current.focus();
}, []);
return (
<article></article>
tabIndex="-1" // more details at https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/tabindex
ref={mainElementRef}
>
Hello, here starts the new page
<main></main>
This is the main content, but what should be read first is the content of H1 so it must be focused.
);
};It’s also possible to communicate when a section’s content is modified asynchronously using ARIA live regions [4].
Is this all I need to know about accessibility?
No. Accessibility is in continuous development so the list of good and bad practices tends to be updated regularly. However, if you’re interested in the subject, simply start by thinking about how you can improve interaction of your users. In my personal experience, I’ve noticed many practices I used were not very accessible, so I changed them. I’ve even begun creating accessible forms that not only improve the interaction of people with disabilities but also those who find it easier to use just their keyboard.
How can I create accessible applications?
There are 2 great places to start learning and getting resources to build accessible web applications. The first one is the a11y project, a collaborative project where you will find resources, tools, and common tips to take your first steps on this process. Second place is the Web Content Accessibility Guidelines (WCAG) 2.0 document, that contains a huge list of recommendations, principles and test criteria that will lead you to build highly accessible web applications.
In addition, if you’re a React developer, I recommend using the plugin for ESLint.
Is it really that important my applications are accessible?
Yes. In 2018, the World Health Organization estimated there are more than 1 billion people with moderate to severe visual impairments (approx. 12% of the world population), of which 36 million are totally blind and the number is growing due to aging. [4]. Fortunately, many countries including Canada and the members of the European Union have created policies that make accessibility mandatory. [5] [6]. Creating accessible applications has not only become an admirable trend but, at some point, could represent a fairly significant competitive advantage. In my opinion, it should be included in every piece of custom software you build.
[2] https://dl.acm.org/doi/abs/10.1145/2513383.2513447
[3] https://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html
[4] https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Alert_Role
[4] https://www.who.int/news-room/fact-sheets/detail/blindness-and-visual-impairment
[5] https://ec.europa.eu/digital-single-market/en/web-accessibility