Day 17: ARIA Authoring Practices
Today I quickly went through the ARIA Authoring Practices 1.1, a W3C Working Group Note included in the ARIA suite of documentation. Though I found the WAI-ARIA 1.1 spec a bit hard to retain, this additional "note" helped me see some real-life application of the ARIA spec. It's definitely something I'd recommend web developers bookmark when needing to refer to common pattern examples, use of landmark regions, and a how-to for developing a keyboard interface. It's an informative resource best tapped into for specific information, rather than a document read from top to bottom.
Things I accomplishedPermalink for "Things I accomplished"
- Read (browsed) through the WAI-ARIA Authoring Practices 1.1
What I learned todayPermalink for "What I learned today"
There are a couple principles behind why using ARIA can be a challenge, and why sometimes it is better to not use ARIA rather than write bad ARIA:
- A role is a promise, so you better couple expected keyboard functionality with that role
- ARIA can both cloak and enhance, so use this power cautiously
This guide does not provide help on mobile and touch support. Apparently, ARIA is not consistently supported in mobile browsers. On that note, if you notice my resource mentioned at the end of this post, ARIA isn't consistently supported across screen readers (it's only 70% reliable!), and varies even more depending on the browser the screen reader is paired with.
role="presentation", this role is ignored, if one of the following is true:
- the element it is applied to is focusable (links or inputs)
- the element it is applied to contains any of the 21 global states and properties.
Must-read resourcePermalink for "Must-read resource"
- WAI-ARIA screen reader compatibility (PowerMapper)