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
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 div as button).
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
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 <nav role=“navigation”>.contentinfo: A collection of metadata, copyright information and the like. Commonly applied as <footer role=“contentinfo”>.
Those other landmark roles
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.
The 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?
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?
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.
via planetweb
0 commentaires:
Enregistrer un commentaire