DEV Community

Cover image for ARIA/Accessibility - A Beginner's Guide
AK DevCraft
AK DevCraft Subscriber

Posted on • Updated on

ARIA/Accessibility - A Beginner's Guide

Introduction

What is WAI-ARIA and why we need it?
It stands for Web Accessibility Initiative - Accessible Rich Internet Applications, more commonly known as ARIA. As per MDN Web Doc, ARIA is a set of attributes that define ways to make web content and web applications (HTML, JavaScript) more accessible to people with disabilities.

Internet is a place that is open for all and should be accessible to everyone, hence web application, even a simple HTML page needs to be built in a way that could be used by everyone, even people with some challenges.

ARIA doesn't interfere with DOM and neither impacts the visual appearance, it just enriches the web content making content within reach for all.

If correct HTML5 tags are used, then half work is already done, as HTML5 brings the semantic that is understood by browsers and screen readers. For example, using an anchor element with a role as a button to submit a form instead of using a button element is not an ideal practice.

//This is NOT ideal
<a role="button">Submit</a>
//This is ideal
<button>Submit</button>
Enter fullscreen mode Exit fullscreen mode

Again, same for using div with a role as a heading instead of using h1 element, when h1 is designed for heading.

//This is NOT ideal
<div role="heading" aria-level="1">This is a heading</div>
//This is ideal
<h1>This is a heading</h1>
Enter fullscreen mode Exit fullscreen mode

ARIA defines semantics that can be applied to HTML elements, with these divided into roles, and states and properties that are supported by a role. For the complete list of roles, and state and properties visit here.

Let's see an example:

1. Table

<div role="table" aria-label="Table for city to state mapping">
  <div role="rowgroup">
     <div role="row">
       <span role="columnheader" aria-sort="none">City</span>
       <span role="columnheader" aria-sort="none">State</span>
     </div>
   </div>
   <div role="rowgroup">
    <div role="row">
       <span role="cell">Chicago</span>
       <span role="cell">Illinois</span>
    </div>
    <div role="row">
      <span role="cell">Norwalk</span>
      <span role="cell">Connecticut</span>
    </div>
  </div>
</div> 
Enter fullscreen mode Exit fullscreen mode

To create an ARIA table, add role="table" to the container element. Within that container, each row has a role="row" set and contains child cells. Each cell has a role of either columnheader, rowheader, or cell. Rows can be children of the table or within a rowgroup.

ARIA is a vast topic that can't be wrapped up in a single blog, however, hopefully, this is enough to get you started with it. There are a lot of resources available, but I generally refer to MDN docs, which provides precise explanation. I have mentioned few references at the end of this article. But, before I end this article, wanted to walk you through few common mistakes.

Common Mistakes:

1. Overriding default roles

The button element has default characteristics that should not be overridden with anything else.

<button role="heading">submit</button>
Enter fullscreen mode Exit fullscreen mode

2. Adding redundant roles

The button tag already has the implicit role for the element, why to explicitly declare it again.

<button role="button">submit</button>
Enter fullscreen mode Exit fullscreen mode

If you have reached here, then I did a satisfactory effort to keep you reading. Please be kind to leave any comments or ask for any corrections. Happy Coding!

References:

Top comments (3)

Collapse
 
grahamthedev profile image
GrahamTheDev

Great except for your very last example, unfortunately you made a mistake (I thought that was funny given it was a common mistakes section ๐Ÿคฃ).

You should (almost) never make a <h1>, <p> etc. focusable.

Screen readers have loads of ways that a person can access information on a page. For example one of those is the ability to jump between headings with the keys 1-6, so they do not need to be able to focus them, the screen reader handles all of that.

If you make headings focusable it causes two issues.

The first is for keyboard users (not using a screen reader), you are introducing unnecessary tab stops into the page which can make navigation annoying or (if you really over do it) nearly impossible.

The second is that for screen reader users it may (depending on settings) announce that an item is focusable, meaning people using a screen reader will think it may be interactive, or worse it may actually announce "clickable" as it is expected that if you can focus something it is interactive.

As I said other than that, a great article โค๐Ÿฆ„

Collapse
 
akdevcraft profile image
AK DevCraft

Thanks for your comment and explanation๐Ÿ˜€, Iโ€™ll take that out

Collapse
 
grahamthedev profile image
GrahamTheDev

No problem, I enjoyed the article and you highlighted the use of semantic HTML as the number one priority beautifully, so I was always going to enjoy the article once I saw that ๐Ÿ˜‹