Why you need to know about WAI-ARIA for accessibility

Our team at User Vision have been passionate advocates of creating inclusively designed services & products for over 20 years, and have been working with many clients to improve the accessibility of their sites.

The Web Content Accessibility Guidelines (WCAG) 2.1 is the de facto standard for web accessibility that has 4 basic principles, which are necessary for anyone to access and use web content. These guidelines state that web content must be perceivable, operable understandable and robust for users with visual, auditory, physical or cognitive disabilities. In addition to the well-recognised WCAG guidelines is another useful set of guidelines from the W3C’s Web Accessibility Initiative called WAI Accessible Rich Internet Applications (or WAI-ARIA). As we outline below, these are especially relevant for sites that include dynamic content.  But first, it’s worth understanding why all these guidelines on accessibility are needed in the first place.

Why you should improve the accessibility of your digital channels

There are several reasons why you should have an accessible site. Firstly, and most importantly is that it’s the right thing to do. Having an accessible site provides equal access and equal opportunities to people with disabilities. It is extremely important to have an accessible site as 15% of adults who use the internet in the UK have a disability (according to the Office of National Statistics Internet Users UK:2019)(this will open in a new window). An accessible website is often the best way to engage with some disabled user groups. For instance, users with physical disabilities that find going to the supermarket by themselves unmanageable due to physical accessibility barriers in the outside world would prefer to shop online.

Furthermore, an accessible site is best practice for usability and inclusive design and improves search engine optimization (SEO).  It could even prevent a lawsuit. There is a legal rationale for accessibility in most countries.  For instance, in the UK, companies can be sued under the Equalities Act 2010 for failing to provide accessibility for their products or services.

Why WAI-ARIA?  The web is becoming more dynamic

While we’ve published several articles around the importance of the WCAG guidelines (see top 10 accessibility issues on public sector websites and new UK government accessibility rules articles), we have not mentioned the importance of the WAI-ARIA guidelines. Implementing WAI-ARIA attributes correctly can help disabled users understand the greater context of the content on the page, and help to achieve WCAG compliance. Inevitably for discussion on accessibility, we will have to refer to some coding syntax but the purpose and benefit of implementing WAI-ARIA should be clear. 

In modern development, single-page applications built using the Ajax (Asynchronous JavaScript and XML) technique and JavaScript have increasingly become standard practice. Applications like Gmail, Netflix and AirBnB are all single-page applications where a lot of information on the page stays the same and only a few pieces need to be updated at a time. In other words, the pages are very dynamic where the content of the page changes based on interactions from the user.  The URL of the page can stay the same even as a new full page is not being delivered to the user’s screen, but a different set of content. The load time of these applications is much faster than a traditional page load which is why companies have started to move towards this style of development.

Using JavaScript, developers can create complex and engaging features that we have all become familiar with, including Dynamic interactions (drag and drop, hide and show, open and shut etc), and widgets and components (modals, tabs, accordions, date pickers, sliders etc).

The downside to using JavaScript to build complex and dynamic interactions is that it can cause all sorts of problems for assistive technology users, particularly those who are unable to view the screen. These include: 

1. The content is largely inoperable using the keyboard alone - Many people, including those who are blind or who have low vision or hand tremors, rely on a keyboard (or keyboard alternate) to access components on the site. This would fail WCAG 2.1.1 Level A - Keyboard and WCAG 2.1.2 Level A - No Keyboard trap success criteria.
2. Updates are not announced to assistive technologies - Blind users need to be informed of changes happening on screen as they have no visual frame of reference and require up to date information in order to make informed decisions. This would fail WCAG 3.3.1 Level A - Error Identification and WCAG 4.1.3 Level AA - Status Messages success criteria.
3. Role and state of interactive elements are not announced to assistive technologies (e.g., the role of a checkbox and the information it relates to and its state, whether it’s checked or unchecked) - Screen reader users need to know the label on the element, the type element and the state of the element so they can make informed decisions on how to navigate the site. This would fail WCAG 4.1.2 Level A - Name, Role, Value success criteria.
4. Visual association between interactive elements and adjacent text is not announced programmatically to screen reader users - This visual association needs to be available programmatically for screen reader users who navigate the site by links and interactive elements (for ease and efficiency) so these users can understand the broader context of the process and the relationship between form controls and associated elements. This would fail WCAG 1.3.1 Level A - Information and Relationships and WCAG 2.4.6 Level AA - Headings and Labels success criteria.

Wow, that’s a lot of barriers for users with disabilities. How do you get around these issues? That’s where ARIA comes into play.

What is WAI-ARIA?

WAI-ARIA, (often shortened to ARIA) is a set of attributes you can add to HTML elements that define ways to make web content and applications accessible to users with disabilities who use assistive technologies. When accessibility issues cannot be managed with semantic HTML, ARIA can help bridge those gaps.

Using ARIA attributes correctly can:

• Achieve keyboard navigation and focus movement conventions
• Help with dynamic content and advanced user interface controls developed with HTML, JavaScript and related technologies.
• Provide a means of describing roles, states and properties for custom widgets so that they are recognisable and usable by assistive technology users.
• Provide a mechanism to ensure that users of assistive tech are aware of updates in the application

For best practices, see full W3C WAI-ARIA authoring practices(this will open in a new window).

How to use ARIA

When ARIA is implemented correctly, it can be a great way to make web content accessible to users with disabilities. On the other hand, if it is implemented badly, it can create further accessibility issues to users with disabilities.

ARIA attributes can often override the text content of native HTML5 elements. With this in mind, we strongly advice using ARIA attributes with caution.

The Basic Rules of ARIA are:

• ALWAYS use semantic HTML following the W3C standards
• ONLY use ARIA attributes if you can’t fix an accessibility issue using native HTML.
• DON’T re-purpose an element by adding ARIA role, state or property if you can use a native HTML element or attribute with the semantics and behaviour you require already built in

Remember:

1. All interactive ARIA controls must be usable with the keyboard using standard keystrokes
2. All interactive elements must have an accessible name
3. Do not use 'role=presentation' or 'aria-hidden=true' on a visible focusable element. Screen reader users will land on these focusable elements and nothing will be announced. 

When to use ARIA

Dynamic Content

For content that is updating automatically on the page, for instance, a status message, or error message, 'aria-live' regions can be applied to notify assistive technologies that a change has occurred on the page.

Depending on the context and importance of the dynamic content on screen, the information can be indicated by using ARIA live regions setting aria-live=‘assertive’, aria-live="polite" or role=“alert”.

Keyboard

Simple HTML components, such as forms, should have no issue working across a vast range of browsers. If you are coding such components, ensure you use semantic HTML following the W3C standards. 

If your team are creating more complex and dynamic interactions like hiding, showing and changing elements without a page refresh, you must ensure these elements are operable using a keyboard interface.

See best practices on developing a keyboard interface.(this will open in a new window)

Providing Role, State and Properties using Aria

Widget roles define interactive elements. When implanting widget roles, ONLY do so when native HTML is insufficient. For example, an `<img>` element will be announced as an ‘image’ by the screen reader, whereas a `<div>` or `<span>` element is meaningless to a screen reader and therefore it cannot identify or communicate what the object is or what it does.

States describe the dynamic properties of an object that may change in response to a user action or automated process. The state of a button on a form which is disabled until the user completes a form field can be done using `aria-disabled=”true”` attribute.

Properties describe the nature of an object or a data value associated with the object. Developers can extend HTML’s native semantics by defining properties that are not available in standard HTML.

For best practices see the article on using ARIA: Roles, states, and properties(this will open in a new window).

Programmatically associate text to form fields

To associate form fields with adjacent text programmatically, group the form fields to the question or adjacent text by implementing a `fieldset` and descriptive `legend`. This helps users understand why certain form fields have been grouped together and will help them work through the form more easily.  Use the `‘for’` and `‘id’` attributes on the label and input elements to make that connection.`aria-labelledby` and `aria-describedby` attributes are also a great way to provide further context to screen reader users.  

For guidance please refer to the Government Design System (GDS) design pattern on fieldsets(this will open in a new window) or this further tutorial information on accessible form fields(this will open in a new window).

Summary

In summary, when developing a site, always try and use native HTML elements with semantic behaviour already built in. If an accessibility issue persists when semantic HTML is not enough on its own, ARIA can provide additional context for assistive technology users, but always use with caution.

Furthermore, ensure that your developers and testers are familiar with assistive technologies so they can ensure that the name, role and value of interactive elements are communicated to all users. Test the site on multiple browsers, devices and assistive technologies to ensure a consistent and inclusive user experience to your customers. 

If you’d like to learn more about how User Vision can help you create an accessible experience for your users or find out about the training courses we offer for developers and designers, don’t hesitate to drop us an email.