Day 49 of 100DaysOfSpec, 3.2.7 WAI-ARIA, contd.

I am reading and taking notes on the HTML specifications for 100 days as part of #The100DayProject. Read the initial intent/backstory. I am a Microsoft employee but all opinions, comments, etc on this site are my own. I do not speak on behalf of my employer, and thus no comments should be taken as representative of Microsoft's official opinion of the spec. Subsections not listed below were read without comment.

Currently reading in 3.2.7 WAI-ARIA

3.2.7.4 Implicit ARIA Semantics

This handy table shows what ARIA semantics are implied on particular elements. Unlike the table in yesterday’s reading, these semantics can be overridden, with some restrictions.

Interesting tidbits:

• You can have the “button” role on a hyperlink (a tag), even though common wisdom is “buttons should be buttons”. Live update: the spec actually points out this specific weirdness following the Implicit ARIA Semantics table.
• Likewise, you can put the “main” role on an article, even though there is a main element.

These first two bullets I’ve listed here underline the impression to me that—like web dev as a whole—accessibility can be a muddy endeavor, a practice of choosing the most sensible-seeming option among all possible solutions that arise. I also wonder if this ability to role-swap between elements is around to help devs who may be locked into using particular elements for whatever reason, but who want to report those elements as something semantically different to screen readers, etc.

• There are no restrictions as to which role you can put on an img tag, as long as it doesn’t have an empty alt tag. W I L D.
• Pretty cool how you can get granular about an element’s semantics with ARIA. For example, you can set an ol or ul element’s role to “radiogroup”, for a list of radios (a pretty common way of marking up that pattern). Though, the W3C accessibility tutorials mark up radio lists using a fieldset/legend pattern with semantically-beige divs wrapping input-label pairs.

3.2.7.5 Allowed ARIA roles, states and properties

This non-normative (UAs are not beholden to conform to this section, at least not in this spec) table lists ARIA properties you are required to and able to use with elements of a particular ARIA role. It includes some global states and properties that can be used in conjunction with any ARIA role.

This table would be great to scan for someone just learning what the different roles are, as it has short descriptions of each ARIA role. There’s some interesting stuff in here you might be inclined to misuse if you just looked for an ARIA role with the correct-sounding name (been there, done that). For example, the description of the complementary role: “A supporting section of the document, designed to be complementary to the main content at a similar level in the DOM hierarchy, but remains meaningful when separated from the main content.”

Also interesting:

• The grid role allows you to tell screen readers that a set of ambiguous divs is laid out like a table and contains tabular information. “Why not just use a table?” is a whole other, angsty conversation.
• The group role seems like a curious little thing I’d like to research more. Definition: “A set of user interface objects which are not intended to be included in a page summary or table of contents by assistive technologies.”