6. To ARIA or not to ARIA?
5 Rules of ARIA (according to )Notes on Using ARIA in HTML
7. First Rule of ARIA use
If you can use a native HTML5 element 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.
8. Second Rule of ARIA use
Do not change native semantics, unless you really have to .
10. Third Rule of ARIA use
All interactive ARIA controls must be usable with the keyboard.
11. Example
“ If using role=button the element must be able to receive focus and a
user must be able to activate the action associated with the element
using both the enter (on WIN OS) or return (MAC OS) and the space
key.
12. Fourth Rule of ARIA use
Do not use role="presentation" or aria-hidden="true" on a
visible focusable element.
13. Fifth Rule of ARIA use
All interactive elements must have an accessible name.
19. JAWS
“ When you focus an element with the attribute included, JAWS will
announce, “press the JAWS key plus Alt and M to move to the
controlled element.” Verbose and clumsy.
Then again, I’m not sure how else you’d go about supporting it.
But, that’s not the only problem. How in the hell do I move back? And,
even if I could, how would that be communicated and how long should
the option to move back remain active? No wonder the other screen
reader vendors are giving this a wide berth.
21. But there is more!
<button
aria-controls="elem1 elem2 elem3 elem4"
>
open / close
</button>
22. What to do?
“Same-page links to move users from one part of the
interface to another
Landmark roles to encapsulate major areas of the interface’s
functionality
Expandable areas that come immediately after their aria-
expanded controllers in the source (and in focus order)