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

Thanks, I'll look into the visual markers.

The reason why I call them matrices, is because like an algorithm, they are meant to be reviewed from left to right top to bottom, and if followed, it's just supposed to make sense. To be honest though, as with the spec, I can't make anybody actually read anything, that's up to the eyeballs of the person in control of them.

I know what you mean about the Required column having aria-valuemax, aria-valuemin, and aria-valuenow listed there instead of in the Optional column. This is another point of ambiguity for me; which I hope to get feedback about.

For example, what is the point of an ARIA Slider, Scrollbar, or Progressbar if none of these attributes are required? They won't work accessibly without them.


From: Fred Esch [mailto:fesch@us.ibm.com]
Sent: Tuesday, June 16, 2015 6:23 AM
To: Bryan Garaventa
Subject: Re: The ARIA Role Conformance Matrices, and issues with the ARIA 1.1 spec


Bryan,

A problem with tables is, a developer has to read the Implementation Notes in order to understand the proper use of some aria attributes like aria-label and aria-labeled by. When I was going through the tables I did not read the Implementation Notes, rather I looked at the required attributes and optional attributes columns. I imagine many developers won't read the implementation notes without a visible cue. I would suggest that you put a highly visible footnote mark (ie fat red asterisk) on aria-label and aria-labeledby in the required attributes/optional attributes columns and at the beginning of the paragraph (in the implementation notes) where you explain proper usage of the aria attributes.

I also see things that are under the required attribute column (ie aria-valuemin), but when I read the spec, I see SHOULD in the spec not MUST..
Regards,

Fred Esch
Accessibility, Watson Innovations
AARB Complex Visualization Working Group Chair
W3C SVG Accessibility Task Force
[IBM Watson]

[Fred]



[Inactive hide details for Bryan Garaventa ---06/15/2015 08:39:00 PM---Hello, I wished to pass this along. I've built the follow]Bryan Garaventa ---06/15/2015 08:39:00 PM---Hello, I wished to pass this along. I've built the following resource at

From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>
To: "'W3C WAI Protocols & Formats'" <public-pfwg@w3.org<mailto:public-pfwg@w3.org>>
Date: 06/15/2015 08:39 PM
Subject: 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