Hands-on With ARIA: Homepage Elements and Standard Navigation | How To

Looking to make your website more accessible? Want to be the first in line as new online interfaces come to market? Look no further than .


This set of standards maintained by the W3C (World Wide Web Consortium) gives you the best of both worlds by adding a number of attributes that allow HTML to be extended in meaningful ways. Here, we’ll walk through what ARIA is, see how it can benefit an informational website, and go through a use case step by step with code examples. Let’s get started!

ARIA Basics

ARIA (or sometimes WAI-ARIA) is the acronym for a set of accessibility standards, called the Web Accessibility Initiative–Accessible Rich Internet Applications. You can check out more about the foundations of ARIA in my previous article, but let’s go over some of its pillars now.

  • HTML

    Site Accessibility: Getting Started With ARIA

    Kyle Speaker

Defining Non-Traditional Relationships

A majority of websites are built using HTML, which primarily relates to each other in a hierarchical fashion through parent-child relationships. This structure is great for defining content, but falls short when it comes to defining user interfaces. For example, in many sites and web applications, an area of content is controlled by buttons within a sibling element—the siblings have the same parent element, but in HTML they don’t have a direct relationship with each other. Because of this, it becomes difficult to define which User Interface (UI)  control which pieces of content when using assistive technologies.

This carries through to newer interfaces as well. For example, if you are trying to navigate a website through a smart device, it becomes difficult when element changes are not visible.

ARIA allows you to tie HTML elements together using additional attributes to represent these types of controls.

Non-Rigid Element Classification

Another shortcoming of HTML is its inability to separate structure from intent.

For example, you may want to make an image element into a clickable button. However, HTML still largely defines that image as only an image, and everything beyond that happens elsewhere.

With ARIA, intent can be separated out from an element, allowing for images to be marked as buttons or a link to be defined as a tooltip. This gives more control to the developer concerning the UI, creating more clearly set relationships.

Creating Landmark Areas

Beyond marking elements within the UI, ARIA also gives access to the role attribute—used to define areas of a page. For example, you can mark your main menu as and your article’s content area as main content. This makes it easier for users to move throughout the important areas of your site, and can prevent confusion for those with uncommon or complex site layouts.

Use Case: Small Business

To get some experience adding ARIA to a site, we’re going to take a wireframe of a site that might be used by a small business and implement our attributes step by step.

Example Page Wireframe
The page wireframe we’ll be marking up

For the sake of clarity, the code we’ll be working with is stripped down, with CSS classes and any functionality from a CMS removed.

The first thing we’ll want to do is break up our wireframe into parts to make adding in ARIA simpler overall. In the picture below, you’ll see that I’ve chosen to break the site down into five main parts: 

  • navigation
  • content
  • sidebar
  • contact forms
  • specialized UI elements

In our case, it looks like this:

Wireframe broken into sections
The sections we’ll be working with

When breaking your site down into areas like this, we’re looking for two things. The first is for major elements that can be defined by an ARIA landmark: banner, navigation, main, complementary, content info, search, and form. These represent the necessary parts of our site, and anything unnecessary for utilizing it won’t be marked as a landmark (e.g. advertisements).

The second thing to look for is specific elements that need to be clarified with ARIA. In most cases, this is pretty simple (such as marking an image as an image), but for some UI elements, it can get a bit tricky.

Once we know what areas need to have ARIA implemented, we can start to move through them systematically. Let’s get started with the site’s navigation.

Navigation

In our example, you’ll notice that we have a few types of navigation. The first is a menu as seen on most sites, listing some pages for the site. Directly below is a smaller menu that holds options for users.

We want to mark these with the role="navigation" attribute so that they can easily be picked out as the site’s menus. This leads to the question: should they be grouped together into a single navigation landmark, or marked as two separate landmarks?

To answer this question in your own projects, you can typically ask yourself two questions:

  1. Is the intent for these menus different? In our example, the top menu navigates the site’s pillar pages, while the smaller menu focuses on things that a logged-in user might need. These intents are different, so it makes sense to separate them.

  2. Are the menus within the same parent element? I know this seems counterintuitive since ARIA is designed to help us overcome these types of relationship restrictions, but in this case it is less about what is possible and more about what is right for the user. Having a single menu defined, but with half of it in one location and the other half elsewhere, makes navigation more difficult.

For our case, we are going to treat our navigations as two separate landmarks. So we’ll make some changes to the code. To start with, we have just our basic HTML:

Now, we’ll annotate it with some landmarks.

The next step in defining these landmarks is to give the user a hint as to what the intent of each menu is. If we leave them both as navigation without any further information, it just makes things more difficult to interpret. So let’s add meaningful labels to them using the aria-label attribute:

Beyond that, we’ll want to add additional role markup to our menu to let users know that this is a menu, and mark each link within as a menu item:

Content Area

Now on to the content area. Here, we’ll be marking the container that holds the entirety of our main content with role=”main”. Again, for comparison, here’s our starter code. 

And here’s what it looks like after we add the "main" landmark.

Within that content, we’ll go on to find any element that has an intent that doesn’t match its HTML definition.

First, we’ll take care of the image acting as a button by adding the "button" role:

This link that activates a modal is a bit trickier, because it depends on what is in the modal itself. For us, we’re going to say it’s a tooltip:

Within our main content, we also have a search form. This has an extra layer of complexity to it, in that it’s a search form using HTML elements, and it also qualifies as a search box landmark. We would mark it up like this:

Advertisements

You might also like More from author

Comments are closed.