Web Accessibility — Developing web with empathy
Even while developing web apps for years, we forget about one really important thing and that’s called Web Accessibility. It’s going to be our topic of discussion in this article. We’ll be learning what accessibility is, why is it important, how to develop well accessible web apps and in the end see an example.
What’s accessibility?
As per wiki,
Accessibility or A11y refers to the design of products, devices, services, or environments for people who experience disabilities.
Hence, by making web accessible means we are targeting a wide range of users by making our web app reachable to people with a plethora of disabilities. Here’s an excerpt from w3 website.
Web accessibility means that people with disabilities can use the Web. More specifically, Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. Web accessibility also benefits others, including older people with changing abilities due to ageing.
WCAG: The Web Content Accessibility Guidelines are part of a series of Web accessibility guidelines published by the Web Accessibility Initiative(WAI) of the World Wide Web Consortium (W3C).
WAI-ARIA: Web Accessibility Initiative — Accessible Rich Internet Applications is a technical specification published by the W3C that specifies how to increase the accessibility of web pages, in particular Dynamic Content and UI components developed with AJAX.
Why should I care?
We developers are in a habit of doing RAD (Rapid Application Development). Many a times we find ourselves in a scurry of finishing our projects in order to meed the deadlines using plush frameworks and tools out there. In this haste, we forget the notion of ARIA (Accessible Rich Internet Applications) and simply assume that my website is going to be used by people like me. This thought is really perilous for both you and your users. In fact, out of all the Front End developers I’ve met and interviewed, most of them don’t even know what ARIA or even accessibility is because no one bothers to learn about it. We treat it as an “additional” feature to our apps. I too used to think the same way ever since it hit me while using bootstrap in the good old days. Watching those “useless” aria-* and role attributes, frankly I used to delete them from my markup (*chuckle*). But learning their significance, I understand their importance now.
Understanding your users
One important step while creating ARIA is understanding the diversity of users. There are several people with different kind of disabilities like visual, motor, auditory, speech or cognitive impairments. The way they access your web apps is different. Most of them use Screen Readers, Braille device, eye tracking etc to access it. These impairments could be temporary or permanent. In fact, in our lifetime, we all experience the such situations in one way or the other like a temporary broken arm, blurry vision etc. So, if you develop web apps using proper web standards, it’ll become easier for all of your users to perceive your web content easily which otherwise is impossible.
How can I make my web apps Accessible?
Okay, enough of the theory now, lets learn how we can actually make ARIA apps. There are several steps involved.
Managing Focus: First and foremost, you need to make sure your app is capable to be browsed by using keyboard only. By keyboard I mean using tabs and focus. An element that is focusable is the one which is able to receive input from the user like a focused button could be clicked by hitting enter or an input field could receive text by simply typing the letters. So, for people with motor and visual impairments, those who are unable to or find it difficult to use the mouse might be solely dependent on using keyboard for accessing your app. Hence, managing focus in your app is a really important step towards making your web app accessible.
All native input elements like buttons, input form fields are by default focusable but the problem comes when most of the time you create custom elements or web components I should say in this current trend of creating web apps. I guess none of us like to see those hideous radio buttons or checkboxes, autocomplete boxes, file inputs etc. To counter that and maybe to meet the expectations of the UI/UX designer, we tend to create custom elements by ourselves and completely forget about managing focus in our component. In fact, there’s a wide range of components rubrics available on w3 website at https://www.w3.org/TR/wai-aria-practices-1.1/. One must go through them while creating a custom component.
Talking about focusing elements by using tab key to move the focus forward to the next element and shift + tab to move backward, we as developers must respect it to make sure it reaches the right element in the Accessibility tree. Imagine a visually impaired user using screen reader to narrate the next elements using tabbed focus, if the focus reaches an irrelevant info element like an icon or some adornment thing in your app, it can be perplexing. Hence, you might wanna provide some meaning response to the user while he presses tab on your app. A very nice example is available on our beloved site github.com.
On pressing tab after landing on github, you see a “Skip to Content” div which is hidden otherwise to facilitate navigating to the main content of the page right away.
This is one example, the main challenge comes when one has to fill in a form and you have created the form using custom elements. And if you haven’t taken care of focus management, the users might not be able to submit the information to your form. So, it’s very important to go through the w3 rubrics cited above while creating custom components. Here’s a codepen I created using the proper focus management for my custom tab component using a technique called Roving Focus. In this, you set the initial tabindex of all your sibling elements (tabs in our case) to -1 and then set only one of them as 0 to receive focus and this shifting it over in the list by listening to the arrow keys events.
Same way, if you’re creating a group of checkboxes or radio boxes you need to take immense care of focus and these keys events. One could encounter problems like keyboard traps as shown below.
So, in this example, I can’t move to the next ‘Date From’ element because the tab key is trapped as an event in the Search Terms input field. The good UX states there should be no such keyboard traps since it’s very blocking in nature, there should be some way developed to get out of this trap say by using escape key. Also, as per the WCAG guidelines section 2.1.2 keyboard trap should not be there.
The DOM order and tab order should be in sync
Setting the DOM order the latter way will confuse the users using screen readers. So, it’s an anti pattern to use such practice. In fact, your tabindex most of the time would be either 0 or -1.
Semantic HTML: Making use of HTML5 semantic tags can be really helpful here. Tags like <header>, <main>, <section>, <footer> helps the assistive technologies interpreting your web content easily. Also, using these semantic tags give a boost for SEO(Search Engine Optimisation). These tags are nothing but a <div role=””>, div with a role attribute set “banner” for <header>, “main” for <main>, “contentinfo” for <footer>. In fact, it used to be a way of writing semantic html in the period that predated HTML5.
ARIA Roles: ARIA roles define the type of element and suggest what purpose it serves.
<div role="alert">
Please upgrade to the latest version of your browser for the best experience.
</div>Specifying a role to an element helps the browser treat in its own way. For eg: If you add a role of button to a div, it’ll become focusable automatically to behave like a button.
For a full list of available roles and aria attributes in HTML5, see this lucid graph by w3 https://www.w3.org/TR/wai-aria/rdf_model.svg
ARIA Attributes: The ARIA attributes are used in conjunction to provide supportive information for the assistive technologies to determine. For eg: helping the screen reader speak out the state of your custom checkbox, you might wanna include aria-checked property as follows:
<span role="checkbox"
aria-checked="true"
tabindex="0"
id="myCheckbox">
</span>Also, you must handle the click event of this span to toggle the aria-checked state along with the visual change. This kind of aria attribute is state based attribute.
There exist another kind of aria attribute called property attributes like aria-label
<p aria-label=”author name”>Param Singh</p>For further reading about the classification of ARIA attributes and their uses, I suggest referring to https://www.w3.org/TR/wai-aria/states_and_properties
ARIA rules and Caveats
Use Semantic HTML where possible: Always prefer using <header> for your web app header section since they already have a role=”banner” set implicitly. Also, good from SEO perspective.
One Element — One Role: There should be only one role per one element.
Never change native semantic tag roles: We must never do something like this
<footer role="button">Using those unsung native tags: I’m talking about tags like blockqoute, cite, q
<blockquote cite="http://www.imdb.com/character/ch0000672/quotes">
<p>
You know the golden rule, don’t you boy? Those who have the gold make the rules.
</p>
<footer>
<a href="http://www.imdb.com/character/ch0000672/quotes">Crazy hunch-backed old guy in Aladdin</a>
</footer>
</blockquote>Using alt with images: We should always develop a habit of including alt attribute in our image tag, not only from ARIA perspective it’s right but also in case the image has failed to load, one could see some descriptive text in place of it which is in favour of Progressive Enhancement. And not to mention SEO, the crawlers and spiders look for such attributes helping them index your web content easily.
<img src="dog.jpg" alt="A golden labrador playing in the park"><figure aria-labelledby="operahouse_1" role="group">
<img src="operahousesteps.jpg" alt="The Sydney Opera House"/>
<figcaption id="operahouse_1">We saw the opera <cite>Barber of Seville</cite> here!</figcaption>
</figure>
Color & Contrast: Taking into account the visually impaired users, we should spend some time choosing the right palette for the theme of our web app. The primary and accent colors should have a good contrast ratio. We should avoid camouflaging coloured text over a div with the same color. Instead, one should follow the golden rule of KISS(Keep it Simple Stupid!). One of the prominent examples of this is Google.com in that it’s so user friendly because it’s really simple with a white background and simplified user interaction.
As per WCAG 2.0 level AA requires a contrast ratio of 4.5:1 for normal text and 3:1 for large text. Level AAA requires a contrast ratio of 7:1 for normal text and 4.5:1 for large text. Large text is defined as 14 point (typically 18.66px) and bold or larger, or 18 point (typically 24px) or larger.
Also, out touch targets like buttons, input fields must be large enough to receive user touch inputs. The optimum size of such touch targets should be around 48px.
Here’s an example of a little app I created with accessibility taken care of. https://restaurants-reviewer.herokuapp.com/
Conclusion
The one thing I love about web is that it makes any mundane information readily available. You just have to navigate to a web site. So, following this norm, making it reachable to every person becomes our responsibility as web developers. Remember one thing, developing accessible web apps is not only good for ARIA but also for SEO.
At last, all I would say is “Just be considerate!”
Thanks
