#586: ARIA 1.2

Visit on Github.

Opened Dec 14, 2020

HIQaH! QaH! TAG!

I'm requesting a TAG review of ARIA 1.2.

Provides an ontology of roles, states, and properties that define accessible user interface elements and can be used to improve the accessibility and interoperability of web content and applications. These semantics are designed to allow an author to properly convey user interface behaviors and structural information to assistive technologies in document-level markup.

Further details:

  • I have reviewed the TAG's API Design Principles
  • Relevant time constraints or deadlines: ready for CR as soon as horizontal review complete
  • The group where the work on this specification is currently being done:
  • The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): W3C / ARIA
  • Major unresolved issues with or opposition to this specification: N/A
  • This work is being funded by: N/A

You should also know that...

This project was discussed with the TAG at TPAC 2016. The outcome was that ARIA 1.2 should focus on HTML parity. This version does so (though incomplete, further work in future versions).

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

CAREFULLY READ AND DELETE CONTENT BELOW THIS LINE BEFORE SUBMITTING

Please preview the issue and check that the links work before submitting.

In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document. We would prefer fully public documents though, since we work in the open.

¹ We require an explainer to give the relevant context for the spec review, even if the spec has some background information. For background, see our explanation of how to write a good explainer. We recommend the explainer to be in Markdown.

² A Security and Privacy questionnaire helps us understand potential security and privacy issues and mitigations for your design, and can save us asking redundant questions. See https://www.w3.org/TR/security-privacy-questionnaire/.

Discussions

2021-01-Kronos

Minutes

Rossen: Took a look at the explainer, but it wasn't very helpful.

... Looked at the spec, focusing on section B.2 - "substantive changes from ARIA 1.1".

... spinbutton changes look good. rowheader, also looks good, group as child of listbox should have always existed so that's good.

... "paragraph" role ... seems weird, I guess you could use it on a flexbox?

Alice: I think that's mostly about reaching parity with HTML.

Rossen: ... aria-expanded for menuitem, makes sense for sub-menus.

... aria-errormessage has some normative usage changes. A little confusing, multiple negations...

Alice: It's forbidding you from having an aria-errormessage when something is explicitly marked as valid using aria-invalid=false, because that's an inconsistent experience.

Rossen: Makes sense.

Alice: What about the IDL changes?

Rossen: looking..

... Are they following our suggested naming conventions? Looks like it.

Alice: There was some discussion at that point about whether some of those attributes should reflect to something other than DOMString..

Rossen: Right, some of these are numbers... For example https://www.w3.org/TR/2019/WD-wai-aria-1.2-20191218/#aria-valuemax is defined as a number by ARIA but reflected as a DomString.

Alice: There's an open issue about this.

Rossen: We should check the WebIDL part once it's in a more mature state. The rest of the additions seem fairly straightforward.

... Leaving a comment and proposing close.