The ARIA Role Conformance Matrices, and issues with the ARIA 1.1 spec

Hello,

I wished to pass this along. I've built the following resource at

http://whatsock.com/training/matrices

called The ARIA Role Conformance Matrices, which is an open source project that maps to ARIA 1.1.



The problem that I've been noticing, is that the spec is often overly vague, and the APG is often overly granular, so that it's very difficult for developers to understand why something is supposed to work, and specifically how accessibility fits into the roles and attributes being used; especially when certain roles are shared between widgets.



The role matrices bridge the gap between the spec (which defines all possible roles and supporting attributes) and the APG (which provides granular detail about specific widget constructs), by mapping all requisite child relationships and required versus optional attributes plus general implementation notes; irrespective of the markup being used.



It should therefore be possible to understand everything that is needed to implement a particular role or widget by viewing one role matrix, which then links to the relevant areas that apply directly to it within the spec.



This also makes it possible for people to perform logic testing against the 1.1 spec, by comparing what a role matrix reveals about requisite roles plus attributes and behaviors, and what the spec actually says, in order to identify where the spec is wrong or inaccurate or overly vague. E.G if it's not clear how to do the same thing by reading the spec alone, then developers won't be able to understand it either.



I would like this to be as accurate as possible before I mention this publically next week, so please let me know if you notice any issues with the mappings.



I do have a question about the Treegrid mappings, which in reading the spec, don't make much sense to me. You can see this at

http://whatsock.com/training/matrices/#treegrid



I wrote this as clearly as I understand it, but aspects of it don't seem to match the spec because the spec is exceedingly vague about this implementation. For example, an ARIA Tree includes a Group role to group child treeitems, however there appears to be no mechanism for doing this in a Treegrid. Is Rowgroup supposed to be used for this? If yes, it would be analogous to adding multiple tbody elements within a table. However if this is allowed, how are nested expandable Rows handled? E.G, nesting tbody elements? That doesn't make sense. Also, it's important to note that a Treegrid control is treated more as an ARIA Tree and not as an ARIA Grid by ATs like screen readers. This means that all table navigation commands for viewing the Grid aspect of the Treegrid are lost.



So my question is, what changes do I need to make in order to bring the Treegrid matrix into line with the intended functionality of this control type?



As I was building this, I also discovered all of the following 1.1 spec issues, which I would like to officially file as bugs. I plan on entering these into the bug tracker, but the spec says that the deadline for filing bugs is June 16, and I won't have time to enter all of these by EOD tomorrow.



Live Regions: http://whatsock.com/training/matrices/#live-region-roles

Spec text: http://www.w3.org/TR/wai-aria-1.1/#aria-relevant

Within the role descriptions of Alert, Log, and Status, it is implied that implicit attributes such as aria-relevant can be used to override default role behaviors, but this is directly contradicted by the text

"aria-relevant is an optional attribute of live regions. This is a suggestion to assistive technologies, but assistive technologies are not required to present changes of all the relevant types."

Thus ensuring that no ATs will treat the handling of live regions equally.



Combobox: http://whatsock.com/training/matrices/#combobox

Spec text: http://www.w3.org/TR/wai-aria-1.1/#combobox

The spec states the following:

"Authors SHOULD associate the combobox textfield with its listbox using aria-owns."

This doesn't makes sense though if the Accessibility Tree is meant to be rearranged based on the usage of aria-owns, which would be a good thing, because elements of Input+type="text" cannot support child elements in a DOM hierarchy.

I'd like to propose changing this to aria-controls instead, because this technically makes more sense anyway. If I'm misunderstanding the association or Accessibility Tree mappings for this, please let me know.



aria-activedescendant spec text: http://www.w3.org/TR/wai-aria-1.1/#aria-activedescendant

The spec states:

"Authors MAY use the aria-activedescendant attribute on the focused descendant of a composite widget; for example, on a textbox descendant of a combo box."

This is confusing, and makes it sound like the following is valid: <div role="combobox"><input type="text"></div>

Which it isn't; I've seen people doing this and siting this line as the reason why. It never works though.

Also, in many places (aria-activedescendant being one) within the Inherits Into Roles section, "select" is listed, though it's not a valid role that is supposed to be used anywhere.



Grid: http://whatsock.com/training/matrices/#grid

Spec text: http://www.w3.org/TR/wai-aria-1.1/#grid

It's confusing that Grid and Treegrid are referenced together, because the two act very different within ATs like screen readers, but this seems to imply that they should work the same? It's just very difficult to know what goes where and how it is supposed to work from the spec text alone.



Row spec text: http://www.w3.org/TR/wai-aria-1.1/#row

The spec text states that it supports aria-colindex, which doesn't make sense on Row, and does not list aria-rowspan as being supported, though it should.



Columnheader spec text: http://www.w3.org/TR/wai-aria-1.1/#columnheader

Rowheader spec text: http://www.w3.org/TR/wai-aria-1.1/#rowheader

Gridcell spec text: http://www.w3.org/TR/wai-aria-1.1/#gridcell

The supported attributes for all of these indicates aria-rowindex and aria-rowspan, which doesn't make sense on individual cells.



Menu: http://whatsock.com/training/matrices/#menu

Menuitem spec text: http://www.w3.org/TR/wai-aria-1.1/#menuitem

Menuitemcheckbox spec text: http://www.w3.org/TR/wai-aria-1.1/#menuitemcheckbox

Menuitemradio spec text: http://www.w3.org/TR/wai-aria-1.1/#menuitemradio

The spec for all three doesn't list aria-posinset and aria-setsize as supported attributes.



Menuitemradio spec text: http://www.w3.org/TR/wai-aria-1.1/#menuitemradio

The spec doesn't indicate that the "mixed" value of aria-checked shouldn't be used on Menuitemradio, because this state wouldn't make sense for a Radio of any type.



Radiogroup: http://whatsock.com/training/matrices/#radiogroup

Radio spec text: http://www.w3.org/TR/wai-aria-1.1/#radio

The spec doesn't indicate that the "mixed" value of aria-checked shouldn't be used on Radio, because this state wouldn't make sense for a Radio of any type.



Tablist: http://whatsock.com/training/matrices/#tablist

Tab spec text: http://www.w3.org/TR/wai-aria-1.1/#tab

The spec states:

"For a multi-selectable tablist, authors SHOULD ensure each visible tabpanel has its aria-expanded attribute set to true, and that the remaining hidden tabpanel elements have their aria-expanded attributes set to false."

This is incorrect, the role="tab" element should include aria-expanded, not role="tabpanel", because it is the Tab that ATs are interfacing with, not the hidden Tabpanel.



I'll work on getting these filed into the bug tracker as soon as possible.



Regarding the Role Matrices, I wrote them for the W3C, so you are welcome to do whatever you wish with the tables. The source is on GitHub at

https://github.com/accdc/aria-matrices



Please let me know if you notice any issues and I'll get them fixed as quickly as possible.



All the best,

Bryan