Which properties drawn from ARIA should apply to virtual AccessibleNode

[cookiecrook]

@alice asked that I list each ARIA attribute as an exercise to determine how it should (if it should) be conveyed on virtual AccessibleNodes.

Note 1: This issue bears no relevance to ARIA property reflection on Element. String reflection of ARIA attributes (e.g. Element.arialabelledBy) seems to be relatively uncontroversial and could be specified by HTML or the ARIA. This issue is about how some of those concepts need to be adopted directly (e.g. String label) or modified (e.g. Array labelElements) to work in a non-markup based API like AOM properties on AccessibleNode.

Note 2: Ideally I'd like this issue to avoid the syntax debate of where these properties land. It may not end up as Element.accessibleNode.label, but I think we all agree that there needs to be a property bag somewhere. Let's debate that syntax on the other existing Issue trackers.

Sections of properties will follow as comments.

[cookiecrook]

Keep as-is

• autocomplete
• busy (busy has utility outside the context of live regions)
• checked
• colspan
• current
• disabled
• errormessage (rename or work into error/announcement API?)
• expanded
• hidden
• invalid
• keyshortcuts
• label
• level
• modal
• multiline (rename?)
• multiselectable
• orientation
• placeholder
• pressed
• readonly
• required
• role (Note: equiv to @ role not @ aria-* like the others)
• roledescription
• rowspan
• selected
• sort
• valuetext (rename?)

[cookiecrook]

Consider keeping but with a better name in AOM. Values (including valuetext) might also be combined into a better accessible value API

• valuemax -> max
• valuemin -> min
• valuenow -> value?
• haspopup -> ???

[cookiecrook]

Any deprecated properties should not be included. Currently that list is:

• dropeffect
• grabbed

[cookiecrook]

relationship attrs should use object reference arrays

• activedescendant -> Node focusProxy? (needs a better name)
• controls -> Array controlsEements[] (also needs a better name b/c people think of form controls)
• describedby -> Array descriptionElements[]
• details -> Array descriptionElements[]
• labelledby -> Array labelElements[]
• owns -> Array ownedElements[]
• flowto -> (if not deprecated) either simple Array (relatedElements?) or Dictionary-like Object indicating navigational relevance

[cookiecrook]

live regions should be superseded by a better announcement API

• atomic
• live
• relevant

[cookiecrook]

collections should be superseded by better data provider API as a native Web Platform API or a non-declarative accessibility-specific JavaScript API

• colcount
• colindex
• rowcount
• rowindex
• setsize
• posinset

[minorninth]

It'd be nice to not have "hidden" on virtual AccessibleNodes, it'd be better to just not include those nodes in the tree, right?

I think we really need colindex, rowindex, etc. for something like a spreadsheet. I don't think we should exclude them just because we'd ALSO like to have a better data provider API. Note that so far everything we're proposing in AOM could be implemented without needing new AT support, that would be an exception.

[cookiecrook]

@minorninth wrote:

It'd be nice to not have "hidden" on virtual AccessibleNodes, it'd be better to just not include those nodes in the tree, right?

If you wanted to temporarily mark a node tree as hidden, then bring it back, it's easier to use .hidden than to tear down the tree and rebuild it. For example, a carousel usually only displays one view at a time. Why force the author to create and destroy those nodes every time the visible representation slides in and out of view?

I think we really need colindex, rowindex, etc. for something like a spreadsheet. I don't think we should exclude them just because we'd ALSO like to have a better data provider API. Note that so far everything we're proposing in AOM could be implemented without needing new AT support, that would be an exception.

My main objection to this is that the ARIA collection-related attrs (rowindex, posinset, etc.) are currently insufficient to create a minimally accessible spreadsheet application. For example, a screen reader user on mobile has no way to scroll a grid or even to navigate to a cell that is out of view. Why should we reimplement a declarative markup-based API in JavaScript unless it already provided sufficient support for a minimally passable experience? Since it doesn't and we'll need to augment it anyway, let's not limit the new API to the declarative form required by ARIA.

For the smaller collections/grids you mentioned on the call (e.g. a 3x3 Tic Tac Toe game), these properties are not necessary. If the full accessible tree is available in the DOM or the virtual AOM tree, the user agent can compute position, set size, etc.

[cookiecrook]

Note: I moved busy from the "live regions" section to the "as-is" section after recalling it had utility outside the context of live regions.

[asurkov]

1. I see the point of having hidden but the property should be defined, for example, whether it affects on a whole subtree or an element only, whether its value can be overridden in a subtree or not. Personally I'm good if it had behavior of display:none.

2. It feels weird with me that the tendency is to put all properties into a single interface. That makes me worry that one day we will have thousands of props on each element, and most of them have nothing in common with an element's semantics. Are there drawbacks of taking the DOM approach, i.e have a hierarchy of interfaces?

[SiTaggart]

Note that so far everything we're proposing in AOM could be implemented without needing new AT support

I think this is super important.

My main objection to this is that the ARIA collection-related attrs (rowindex, posinset, etc.) are currently insufficient to create a minimally accessible spreadsheet application.

I think this point is valid, but also maybe takes it to an extreme where you maybe discounting valid usage somewhere inbetween simple grids and spreadsheets. It's fairly reasonable to want to virtualise a large collection in a list or grid, where the full accessibility tree isn't available from what's in the DOM.

Unless I'm understanding incorrectly, we can have collections in the thousands or tens of thousands that we won't want to render entirely, but would like to communicate size or position in the collection to AT. Having collection attrs in AOM would be extremely beneficial in doing so.

[cookiecrook]

@SiTaggart wrote:

Unless I'm understanding incorrectly, we can have collections in the thousands or tens of thousands that we won't want to render entirely, but would like to communicate size or position in the collection to AT. Having collection attrs in AOM would be extremely beneficial in doing so.

I absolutely agree that having a way to achieve that solution makes sense in AOM. And, if the ARIA collection attrs (setsize, posinset, etc.) actually solved that problem, I'd be less reluctant to duplicate them in AOM. As it stands, duplicating them would only serve to make a second web API that also does not work.

[caridy]

@cookiecrook @alice @minorninth do you have any preference on where to discuss the naming, type, default-value, etc for the new ARIA property reflection and names? We will like to help with that part of the spec now that the direction seems to be well defined.