User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
I'm reading the W3 WCAG quick reference guide located here
It has the option of selecting items to display for WAI ARIA WCAG compliance -- is WAI-ARIA required for WCAG compliance or not? It's not clear to me.
It's my first time building a site to meet WCAG level AA compliance and need to make sure it's done properly :)
No.
The requirements (i.e., Guidelines) are only in this document:
Web Content Accessibility Guidelines (WCAG) 2.0
W3C Recommendation 11 December 2008
Guidelines are usually technology-neutral and abstract, so they don’t apply only to HTML, but to Web content in general. Therefore, requiring WAI-ARIA attributes would make no sense.
However, to comply with the Guidelines, you can (but don’t have to!) use the Techniques for WCAG 2.0. It might be the case that certain Techniques rely on WAI-ARIA attributes. But, again, this is not normative: there are typically several applicable Techniques for a Guideline, and probably most of the time you might use a solution that is not described in a Technique at all.
So when you have to follow a Guideline, and a corresponding Technique describes a solution using WAI-ARIA, you don’t necessarily have to use it: Another Technique (not using WAI-ARIA) or an undocumented solution can possibly fulfil the Guideline, too. Of course, your specific restrictions might not allow for alternative solutions in all cases, so it can happen that a solution with WAI-ARIA is the only possible solution for you.
I know this is already answered, but since it was referenced from another question I figured I'd paste this info here as well for more recent readers. It supplements the answer above.
If you are using proper semantic and structural HTML, you probably won't need ARIA. For those cases where you have to use the wrong element (such as a broken library or framework), then you may have to but that is not the way to start.
As always, context is key and blanket statements do not always apply.
If it is helpful, there are three (five) "rules" of ARIA use (they are suggestions, but you should treat them as rules for best effect):
First rule of ARIA use: If you can use a native HTML element [HTML51] or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
Second rule of ARIA use: Do not change native semantics, unless you really have to.
Third rule of ARIA use: All interactive ARIA controls must be usable with the keyboard.
Fourth rule of ARIA use: Do not use role="presentation" or aria-hidden="true" on a visible focusable element. Using either of these on a visible focusable element will result in some users focusing on 'nothing'.
Fifth rule of ARIA use: All interactive elements must have an accessible name. An interactive element only has an accessible name when its Accessibility API accessible name (or equivalent) property has a value.
