Using WAI-ARIA landmark roles to increase accessibility

One of the most neglected aspects of the web is accessibility, unless you are part of a group dedicated to this subject. As web designers and web developers, we rarely think about handicapped users accessing the web and using our websites or apps with screen readers and other assistive technologies. We actually think first about supporting legacy browsers rather than increasing the accessibility of our products.

In this chapter, we're going to touch on what WAI-ARIA landmark roles are and how they can be easily implemented in our markup, enhancing the semantics of our documents to provide those users with assistive technology a better and pleasant experience when they navigate our websites/apps with their keyboards on any modern browser.

Note

WAI-ARIA stands for Web Accessibility Initiative – Accessible Rich Internet Applications.

WAI-ARIA landmark roles

WAI-ARIA landmark roles can also be referred to as ARIA roles, so that's the term we're going to use.

An ARIA role looks like this when implemented in an HTML5 element:

<header role="banner">

There are really multiple ARIA roles at our disposal, but in this book we're going to focus on the ones that are easier to implement and that will enhance the accessibility of our websites/apps efficiently.

The banner role

Here are a few important points to remember:

This role is usually applied to the top <header> of the page.
The header region contains the most prominent heading or title of a page.
Usually, the content that has role="banner" appears constantly across the site rather than in a single specific page.
Only one role="banner" is allowed per page/document.

Consider the following example:

<header class="masthead" role="banner">
    <div class="logo">Mastering RWD with HTML5 &amp; CSS3</div>
    <div class="search" role="search">
      <form>
         <label>Search:
            <input type="text" class="field">
            <button>Search Now!</button>
         </label>
      </form>
    </div>
</header>

The navigation role

Here are a few important points to remember:

This role is usually applied to the <nav> element, but it can also be applied to other containers such as <div> or <ul>.
It describes a group of navigational elements/links. These links can be either to navigate the site or the page they appear on.
There can be more than one role="navigation" per page.

Consider the following example where the role is applied to the main <nav> element:

<nav class="main-nav" role="navigation">
    <ul class="nav-container">
      <li><a href="#">Link 1</a></li>
      <li><a href="#">Link 2</a></li>
      <li><a href="#">Link 3</a></li>
      <li><a href="#">Link 4</a></li>
    </ul>
</nav>

Consider the following example where the role is applied to the <ul> element of the footer navigation:

<footer class="main-footer" role="contentinfo">
    <p>Copyright &copy;</p>
    <ul class="nav-container" role="navigation">
      <li><a href="#">Footer Link 1</a></li>
      <li><a href="#">Footer Link 2</a></li>
      <li><a href="#">Footer Link 3</a></li>
      <li><a href="#">Footer Link 4</a></li>
      <li><a href="#">Footer Link 5</a></li>
    </ul>
</footer>

There is no particular preference as to which element we add the navigation role to. It's the same if we add it to the <nav> element or the <ul> element.

The main role

Here are a few important points to remember:

This role is usually applied to the <main> element of the page.
The container of the main/central subject of the page should be marked with this role.
Only one role="main" is allowed per page/document.

Consider the following example:

<body>
    <main class="main-container" role="main">Content goes here
    </main>
</body>

The contentinfo role

Here are a few important points to remember:

This role is usually applied to the main <footer> element of the page.
This is the section that contains information about the document/site/app.
If the section contains, for example, a copyright link, footnotes, links to privacy statement, or terms and conditions, it's a good candidate for role="contentinfo".
Only one role="contentinfo" is allowed per page/document.

Consider the following example:

<footer class="main-footer" role="contentinfo">
    <p>Copyright &copy;</p>
    <ul class="nav-container" role="navigation">
      <li><a href="#">Footer Link 1</a></li>
      <li><a href="#">Footer Link 2</a></li>
      <li><a href="#">Footer Link 3</a></li>
      <li><a href="#">Footer Link 4</a></li>
      <li><a href="#">Footer Link 5</a></li>
    </ul>
</footer>

The search role

Here are a few important points to remember:

This role is usually applied to the <form> element that belongs to the search feature of the page/app.
If the search form is wrapped inside a <div> element, this role can also be applied to that <div> element. If this is the case, then there's no need to add it to the child <form> element.
There can be more than one role="search" per page as long as the control is an actual search feature. For example, using the role="search" on a contact form is incorrect and unsemantic.

Consider the following example where the role is applied to the site's search <form> element:

<div class="search">
    <form role="search">
      <label>Search:
         <input type="text" class="field">
         <button>Search Now!</button>
      </label>
    </form>
</div>

The form role

Here are a few important points to remember:

This role is usually applied to a <div> element that contains some type of form, except the main search form of the site/app, for example, contact forms, registration forms, payment forms, and so on.
It should not be applied to the actual <form> element, because this element already has default role semantics that assist technology support.

Consider the following example:

<div class="contact-form" role="form">
    <header>
      <h2>Have Questions About HTML5?</h2>
    </header>
    <form>
      <div class="flex-container">
         <label class="label-col">Name: <input type="text" class="field name" id="name" required></label>
         <label class="label-col">Email: <input type="email" class="field email" id="email" required></label>
      </div>
      <label for="comments">Comments:</label>
      <textarea class="comments" id="comments" cols="50" required></textarea>
      <button>Send Question!</button>
    </form>
</div>

The complementary role

Here are a few important points to remember:

This role is usually applied to an <aside> element.
It should be used on a region that contains supporting content; if separated from the content, it can still make sense on its own. This is pretty much the description of the <aside> element.
There can be more than one role="complementary" per page.

Consider the following example:

<aside class="side-content" role="complementary">
    <h2>What Does "Semantic HTML" Mean?</h2>
    <p>Semantic markup basically means that we use HTML tags to describe what a specific piece of content is.</p>
</aside>

Note

WAI-ARIA roles explained

If you're curious about the list of ARIA roles, you can visit the Web Platform website where the explanations are simple and very easy to understand: https://specs.webplatform.org/html-aria/webspecs/master/#docconformance

Important meta tags to consider for RWD

There are many ways web designers and developers use meta tags, but those extensive explanations are outside the scope of this book, so we're going to focus on the bits and pieces that are relevant and work as intended for RWD. 

The following meta tags are very important for our responsive site/app. These meta tags are not just for HTML5 pages, they will work with any version of HTML.

Let's get started.

The viewport meta tag

The viewport meta tag is the most important meta tag for RWD. It was introduced by Apple in their mobile Safari browser. Now, other mobile browsers support it as well. Oddly enough, this meta tag is not part of any web standards of any kind, yet it is mandatory if we want our responsive sites/apps to display correctly on small screens.

The recommended syntax of this meta tag is as follows:

<meta name="viewport" content="width=device-width, initial-scale=1">

Here are a few important points to remember:

The name="viewport" directive describes the type of meta tag.
The content="width=device-width, initial-scale=1" directive does several things:
- The width property defines the size of the viewport meta tag. We can also use specific pixel widths, for example, width=960.
- The device-width value is the width of the screen at 100 percent zoom in CSS pixels.
- The initial-scale value defines the zoom level the page should be shown at when it's first loaded. 1 equals 100 percent zoom and 1.5 equals 150 percent zoom.
With this syntax, users will be able to zoom in if they want to. This is a UX best practice.

Note

This book strongly discourages the use of the following viewport properties: maximum-scale=1 and user-scalable=no. By using these viewport properties, we deny the users the ability to zoom in our website/app. We never know when zooming may be important for anyone, so it's best to steer away from including those viewport properties.

To help websites that are not responsive (yet) display a bit better on small screens, add the specific pixel width the site was built at. For example, if a website is as wide as 960px, add this viewport meta tag to it:

<meta name="viewport" content="width=960">

If you're interested in reading in more detail about the viewport meta tag, MDN explains it very well: https://developer.mozilla.org/en/docs/Mozilla/Mobile/Viewport_meta_tag.

The X-UA-Compatible meta tag

The X-UA-Compatible meta tag targets only Internet Explorer and its Compatibility View feature. As we all know, Microsoft introduced Compatibility View in IE8.

The recommended syntax of this meta tag looks like this:

<meta http-equiv="X-UA-Compatible" content="IE=edge">

Here are a few important points to remember:

The http-equiv="X-UA-Compatible" directive tells IE that a certain rendering engine needs to be used to render a page.
The content="IE=edge" directive tells IE that it should use its latest rendering HTML and JavaScript engines.
Using this meta tag to trigger IE's latest HTML and JavaScript engines is very good, because the latest version of IE always has the latest security updates and support for many more features.

Tip

There's no need to use the chrome=1 value anymore, since Chrome Frame was retired in February 2014.

Note

Google Chrome Frame was a plugin for old versions of IE. When installed, it would replace certain modules within IE, such as rendering and JavaScript engines, thus improving the user experience. In other words, it was like installing a small version of Google Chrome on top of IE.

The charset meta tag

The charset meta tag tells the browser which character set to use to interpret the content. Some say it isn't that important to include because the server itself sends the character set to the browsers via HTTP headers anyway. But it's always a good measure to include it in our pages as well.

If charset is not declared in the HTML and the server doesn't send the character set to the browser, it's likely that some special characters may display incorrectly.

The recommended syntax of this meta tag in HTML5 is like this:

<meta charset="utf-8">

Here are a few important points to remember:

This meta tag was created exclusively for HTML5 documents. The main benefit is that there's less code to write.

For HTML 4 and XHTML, you should use the following syntax:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

Another common value is ISO-8859-1, but UTF-8 is more widely used because there is a better chance of the browser interpreting the content correctly.
Note
UTF-8 stands for Unicode Transformation Format-8.

Previous Chapter

The

Next Chapter

A full HTML5 example page with ARIA roles and meta tags

Table of Contents for Mastering Responsive Web Design

Using WAI-ARIA landmark roles to increase accessibility

Note

WAI-ARIA landmark roles

The banner role

The navigation role

The main role

The contentinfo role

The search role

The form role

The complementary role

Note

Important meta tags to consider for RWD

The viewport meta tag

Note

The X-UA-Compatible meta tag

Tip

Note

The charset meta tag

Note

Table of Contents for
Mastering Responsive Web Design