Recently, as part of my research for a presentation about web accessibility for non-specialized teams, I asked around about how people were applying the HTML
role attribute in their day-to-day web practice.
Their answers didn’t surprise me. Many expressed chagrin at their apparent ignorance, admitting they copied and pasted examples a lot. Some had a passing familiarity with a few prevalent roles, but sensed beyond that a gaping chasm of things they didn’t know. The prevailing tone was guilt. It’s not that people don’t care about accessibility, it’s that the topic can feel overwhelming among all the other priorities we have.
I’ve noticed a lack of easily-Googled, applied documentation for certain technologies or practices. On one end, we have specs, sometimes exhaustive. On the other end, we have a smattering of implemented examples. Synthesized documentation can be thin on the ground.
I can’t change the world, but I can add some analytical documentation about something specific: my nutshell-in-a-nutshell view of landmark roles in WAI–ARIA, as I understand them, and as it translates to more easily adding website accessibility to your daily workflow.
The Accessible Rich Internet Applications (ARIA) suite from the W3C’s Web Accessibility Initiative (WAI) is one piece of the web accessibility puzzle. Now, the first rule of ARIA usage is—I am not making this up—we do not use ARIA (unless we need to). Before you set out to use it, you should already have a solid authoring craft: careful, semantic treatment of content; proper use of attributes and textual alternates; sensitivity to contrast and font sizes. Support for accessibility leads to well-crafted HTML and vice versa.
How ARIA fits in#section2
Applied ARIA in HTML is a combination of two things: roles and
aria-prefixed attributes. Roles identify an element’s purpose, and attributes describe things about it (properties) and what it’s up to (states).
ARIA is a gap-filler for HTML semantics. It allows you to be declarative beyond what HTML elements and attributes currently provide, and lets you be explicit about the relationships and meanings of elements on your page. It also provides a mechanism to attach semantic meaning when authors, by perversity or necessity, use non-standard elements to represent other things (e.g. using a
The ARIA specification provides a standardized way for browsers and assistive technologies to evaluate HTML documents for people who access and use the web in different ways. There’s a lot to know about ARIA, and we don’t have all day, so today I’m going to focus on one important topic: landmark roles.
Landmark roles for daily use#section3
The HTML element attribute
role is the piece of the ARIA iceberg most often visible above the waterline, and the chunk of ARIA most immediately recognizable to web builders.
<div role="main"> (or even
<main role="main">) may be familiar to some of us.
main is one of a set of eight defined ARIA landmark roles. All defined roles express an element’s purpose, but landmark roles serve as key milestones, allowing AT (assistive technology) to map the lay of the land of an HTML document. This is why they’re a great set of roles to start with. Landmark roles make navigation between areas of your page more efficient for different kinds of users. They help convey basic semantic intent and can serve as hooks and helpers for other technologies (or even humans reading your source).
Here are some landmark roles that can be used on practically every HTML page you write:
main: The main content of a document.
banner: The main header or masthead of a page; typically assigned to a header element.
navigation: A collection of links for navigation. A common usage is
contentinfo: A collection of metadata, copyright information and the like. Commonly applied as
Those other landmark roles#section4
There are two further straightforward landmark roles you might be interested in:
complementary—a chunk of content that supports
main but remains autonomous, and
search—an element containing your site’s search interface.
application landmark role should be used with care, so read up first if you want to use it.
form is also a landmark role, but arguably redundant if you use it on a form element (doesn’t
<form role="form"> seem repetitive?).
When are roles redundant?#section5
Here’s where it gets foggy. I’m arguing that
<form role="form"> is redundant and yet suggesting
<main role="main"> (or maybe
<div role="main">) is good practice. What gives?
Roles are semantic extenders. One of the things they do is provide training wheels for semantic elements that don’t exist or haven’t been adopted fully by all browsers.
It’s safe to anticipate that all major browsers know what a form element is—its role is implicit in the element itself. This is less reliable, however, with the
main element. Presently, Chrome and Firefox require
<role="main"> on an element to make the semantic role available to assistive technology and IE is all,
main? Never heard of it. So we
role on until broad adoption.
Though I lean slightly toward not using
<form role="form">, there are varying and vigorous views on this (and other aspects of ARIA). Don’t take my opinion as fact.
Where to next?#section6
I talked about documentation being thin on the ground. That’s not untrue, but it gives short shrift to some fabulous efforts. There are some killer resources, like a11yproject.com’s accessibility checklist. That’s exactly the kind of applied reference web generalists need. Analytical documentation targeted at web implementors isn’t completely absent, although there seems to be a scarcity of it compared to other topics.
There is far more to ARIA and accessibility. While landmark roles are a great place to start, your growing understanding may lead you to other kinds of roles (there are four categories, of which landmark is one) and to
aria-*prefixed state and property attributes.
What I’ve talked about here only begins to scratch the surface. But even if all you do is commit to using some of the ARIA landmark roles in your HTML, I am a happy person.
12 Reader Comments
it’s only IE that does not expose main as a landmark (that is in the works though), In Chrome, Firefox and Safari it worked from day one of implementation (a few years back now). Most screen readers work around IE’s lack of support. As a consequence the advice/requirments for addition of default implicit roles to HTML elelements is changing. This will filter through to conformance checkers such as the W3C Nu markup checker which will in future issue a warning if role=main is used on the main element (for example). In addition an important rule of thumb for landmark use it to ensure that all content is a descendent of a landmark container.
Thanks for the link to the A11y project. I work in ebook production for an academic publisher, so accessibility for readers with assistive technology is important to us. I’m always looking for ways to improve the usefulness of our ebooks. We do use WAI-ARIA in our files, and I keep having to remind our conversion vendors about the need for good semantic structure. I’m color blind myself, so I’m aware of how even simple choices can potentially affect usability for large numbers of people.
Nice article. Simple to implement and high on usefulness, thanks.
Oh! My! I was going by the information on main on http://www.html5accessibility.com/ — “Firefox and Chrome: implements as role=main”. The way I read it was: “You have to use `role=’main’` for it to be exposed to FF and Chrome.” I’m betting this is incorrect! Can you shed some light? Thanks for the great info overall!
with a role=main in Accessibility APIs. This test data provides a more granular level of detail about accessibility semantics implementation support for a bunch of HTML elements in the 4 major browsers (note that many of bugs listed have since been fixed, particularly in chrome).
What it means is that Firefox and Chrome have already hooked up the semantics for role=main (Safari too). They expose
Not a correction nor even clarification, but from experience helping others I think three of the landmark roles warrant a tiny bit more detail.
The landmark roles
contentinfoshould only appear once per page. This is specified in ARIA 1.0 and ARIA 1.1.
How it impacts assistive technology users when more than one is used I cannot say as I am not a regular AT user.
I don’t think it’s an issue of how it impacts AT users (as I am one myself). It’s a matter of thinking through what main, banner, and contentinfo are for. Would you have more than one footer on a page? Would you really have more than one main area since . . . main pretty much implies one main? It’s a valuable clarification, Adrian; it’s just that it doesn’t have much to do with impact and very much to do with logic and common sense.
I would quibble with the notion in this article that there isn’t much documentation. On the contrary, there’s a lot of documentation, test data, and blog posts. The problem is that, as stated, (and it is true in my experience) that most folks want accessibility to be basically a simple checklist. And I always find it noteworthy that people want that from accessibility, but (at least based upon what I read), it’s demanded less so from the usability field. That’s worth considering because I believe deeply that the two very much go hand-in-hand.
The bottom line is that people are not learning accessibility i.e. it’s not commonly included in code examples, people don’t learn it in their education, etc.; whereas I think most folks do at least get a taste of usability.
Thanks for the article; every little bit helps.
Great article Lyza.
It’s a shame that more devs don’t have a basic understanding of semantics – i.e. why use a
Thank you for the information, Liza! I want to make my site more accessible to everyone, and the w3c documentation is quite dry to read and hard to find straightforward information.
As the internet becomes more part of everyone’s lives, web designers and site owners should care more about have at least basic accessibility on their sites. It’s a shame that IE is still lagging behind support for this technology.
Thanks very much to you all for great article and comments.
18F published their guides for the US Government. Very good stuff:
Great article. This is by far one of the most concise explanation of landmark roles I have found.
information about css and html code that is very helpful for me who is studying deeper .. keep working , thanks to quality article , if you need information about more try visiting Daftar Harga Sepeda Fixie
Got something to say?
We have turned off comments, but you can see what folks had to say before we did so.
More from ALA
Personalization Pyramid: A Framework for Designing with User Data
Mobile-First CSS: Is It Time for a Rethink?
Designers, (Re)define Success First
Breaking Out of the Box
How to Sell UX Research with Two Simple Questions