ARIA Rich Internet Application Suite
Let’s start with some basics. So, ARIA basically stands for Accessible Rich Internet Applications. It is “something” we do to make a website more accessible to users with a variety of users. It is also called WAI-ARIA. The WAI stands for Web Accessibility Initiative. It is more correct to use WAI-ARIA to acknowledge its origins in WAI.
Okay, this sounds boring so I’ll just go back to tagging my friends in memes.
Well, hold on! It only gets better from here. Let’s break down the paragraph above and analyse it. Ever wondered how would you make your website usable for people with physical disabilities? Or even for users in general? As developers, we usually tend to be content by our websites, apps etc. being accessible through keyboards, mouse, touchscreens etc. leaving behind users who might not interact and access things like a “typical” user. Specifically, users who might have impairment/disabilities which might be temporary or permanent. How about we make our next website accessible to literally anyone. Interested? Let’s explore that “something” mentioned in the first paragraph, together.
TL;DR:
· Get deep into accessibility and how it applies to web development.
· Learn to use basic accessible techniques in a website.
· Explore some features and specifications in HTML to make it accessible.
PS: The examples I have used are compiled/simplified from various sources like Github, W3C, Google developers, Mozilla etc. The sources will be mentioned accordingly for those interested in reading further.
All right let’s jump right in.
Accessibility:
Consider filling a form in a website through our desktop browsers. Let’s say we have two columns containing multiple fields. It isn’t much difficult to traverse through the fields because of the large screen. All the fields are easy to read and easy to scroll. Imagine opening the same form from a mobile device, things start to get a little trickier now. If the form isn’t responsive then traveling through the fields in the two columns gets difficult in a small screen. We would need to zoom in and zoom out every time we want to fill a field. This is a problem of accessibility.
When we say a website is accessible, we broadly mean that the site’s content is available to everyone and its functionality can be operated by literally anyone. Think about a person with some form of visual impairment but not total blindness. Maybe the person is suffering from a concussion which makes him unable to distinguish between similar colors. To make websites accessible to him/her, one such solution would be to use high contrast mode to provide make contents presentable with clarity to that person. Okay, how about people with total blindness? To solve their problems, we need to know how they consume the internet and access websites on a daily basis.
Assistive Technologies:
This is kind of a loose term, as, technology itself is meant to assist ourselves in whatever way needed. To get a clear understanding of the term we take the analogy of crutches that aids mobility to a person having a fractured leg. It is in a way an assistive technology for that person.
Okay, so how does assistive technology apply in web and mobile? Let’s take the example of voice assistants, one of the technologies that make us go hands-free on our devices especially during the time when we are unable to use our hands to do that task (e.g.: making a call). Another example is making use of on-screen readers to navigate through a website. It might not be very common to a typical user but to a person without vision, for example, this is one of the primary media they use to browse through a website. The concept of ARIA basically enables us to control how the screen reader navigates our website and apply functionalities to them. This works on the concept of semantics in a website. Let’s take a closer look at this in the next section.
Semantics and Accessibility Tree:
Time for a demo! Have a look at this website. It is an example taken from the Google developers site and it best simulates how a website may be perceived by a user with a vision impairment. Click on the enable ChromeVox Lite button to enable the experience and navigate the site using the buttons at the bottom. Notice how the screen reader tells you some information about each interface element. We expect a well-designed reader to tell you all, or at least most, of the following information about the elements it encounters.
· The element’s role or type, if it is specified (it should be).
· The element’s name, if it has one (it should).
· The element’s value, if it has one (it may or may not).
· The element’s state, e.g., whether it is enabled or disabled (if applicable).
The screen reader is able to construct this alternate UI because the native elements contain built-in accessibility metadata. Just like the browsers are able to read HTML and CSS to build a visual interface for the user, the screen reader uses the metadata in the DOM nodes to construct an accessible version, something like the following-
Let’s focus on screen readers more closely for the time being. Imagine a hypothetical situation in which we are creating a website for the screen reader users only. We would, then, not require any kind of visual UI because nothing will be visible to the users. Instead, we would create something like an API which will give the information needed for the screen readers to create a page structure which would something look this-
The same thing happens in our browsers when we enable screen readers. This tree is called Accessibility Tree. How does a browser understand the hierarchy of a website from the DOMs? The native HTML tags have an implicit semantic meaning which specifies the specific roles, description, name etc. of that tag. For e.g.: a button has a property of it being clickable so the browser understands this property and swipes its magic wand to put it in the correct place in the accessibility tree. However, in reality, we have many elements which we make functional by using our own CSS or JavaScript like giving an anchor tag a style of a button and making it link to some other page. In this case, the screen reader would not know that it is acting as a button and would go ahead and classify it as an anchor tag unless we explicitly define it. Enter ARIA!
ARIA Semantics:
Hi, I am ARIA! I am here to solve problems of the browsers not able to recognise custom elements for accessibility. I also enable customisation of various native elements and I can be used to override the native functionality of the native elements. Read below to see how I can be utilised to provide required and accurate functionalities for each element for screen readers. However, I can’t change anything visual on the DOM. I am only employed to work for accessibility.
There you go. ARIA explained by herself. Now to understand and utilise the full functionality of ARIA would require us to go through the whole spec. Here we will only look at few examples that would help us understand their usage and make us realise its potential.
The following code snippet shows list item acting as a checkbox.
<li tabindex="0" class="checkbox" checked>
Receive promotional offers
</li>This can be seen easily in a DOM but a screen reader will not be able to identify it correctly. Here’s the above code using ARIA.
<li tabindex="0" class="checkbox" role="checkbox" checked aria-checked="true">
Receive promotional offers
</li>As you can see there are a whole lot of things ARIA can do by augmenting the native HTML semantics or adding particular information just for the assistive technologies API. Take a look a the picture below. It is a small collection of values only for the role attribute of ARIA.
I would end it here as it has become an overwhelmingly long article. In general, however, the spec is very dense; a more approachable place to start is the ARIA Authoring Practices document, which explores best practices for using the available ARIA roles and properties.
ARIA also offers landmark roles that extend the options available in HTML5. See the Landmark Roles Design Patterns spec for more information.
Happy coding for assistive technologies! :)
