Day 17: ARIA Authoring Practices

Published on 16 Dec 2018

• journal
• was
• aria

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.

• Read (browsed) through the WAI-ARIA Authoring Practices 1.1

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:

1. A role is a promise, so you better couple expected keyboard functionality with that role
2. 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.

Concerning 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.

• WAI-ARIA screen reader compatibility (PowerMapper)