mappings for type attribute on <ol>?

[jasonkiss]

I'm guessing it's not mapped directly to the a11y apis, and AT determine the list marker value via CSS? I don't know, so checking before filling in the recently added entry for ol@type in the attribute mapping table.

ping @stevefaulkner, @asurkov, @joanmarie, @boggydigital, @cookiecrook. Thanks!

[joanmarie]

The list marker's textual content is exposed in ATK/AT-SPI2 (and I assume IA2) through the accessible text interface on the list item with which the marker is associated.

In the case of AX API, there is a separate accessible object for the list marker which exposes the rendered content. I would have to double check to know which accessible property holds the value, but my guess is AXValue.

[jasonkiss]

Thanks, @joanmarie. Yes, in both those cases the list marker's value or content is exposed (and yes, it's AXValue on AXListMarker for AX API), but isn't what is being exposed there the result of a calculation based on what is specified in the type attribute. That is, the type attribute is not exposed as such, but determines what kind of values will be exposed for the list marker?

Perhaps then the answer is "Not mapped" in all cases, and we include a comment in the comment column to the effect that the value of the type attribute determines the range of values for the list marker?

[joanmarie]

but isn't what is being exposed there the result of a calculation based on what is specified in the type attribute. That is, the type attribute is not exposed as such, but determines what kind of values will be exposed for the list marker?

Yes, though indirectly (at least in the case of WebKit). The implementation's rendering code has already done the work to figure out and render the list item marker, so the implementation's accessibility code should be able to just grab and expose the value from the rendered marker. That's what happens in WebKit. And I'd think that all engines would do this (why reinvent the wheel and also risk the displayed text not jiving with the accessible text?). But I just remembered a Gecko bug which suggests Gecko's accessibility code might be doing otherwise -- a bug they might be able to fix by just grabbing and exposing the value from the rendered marker. But I digress....

Perhaps then the answer is "Not mapped" in all cases, and we include a comment in the comment column to the effect that the value of the type attribute determines the range of values for the list marker?

I would not object (strongly) to that. However, assuming I am understanding you correctly, that does then leave implementors without guidance regarding how to expose the value for a given platform. And platforms do have expectations/requirements regarding how the value is exposed (is there a dedicated accessible for the marker or not? what attribute and/or interface exposes the rendered value?).

My small objection is that, at least for the ARIA/Core AAM, "not mapped" is equivalent to "not exposed to ATs". And that's arguably not true. Moreover, depending on the rendering engine and accessibility API, exposure doesn't necessarily happen for free. For instance, in the case of ATK, implementors not only need to prune the list item marker from the accessibility tree and expose the content of the rendered list item marker via the accessible text of the associated list item, they also need to remember to do things like adjust the offsets (e.g. for caret-moved events, text-selection events, etc.) for the accessible list item rather than just taking the offsets unmodified from the list item renderer.

[asurkov]

I would wrote in IA2/ATK case something like "Exposed as a bullet character it defines in the accessible text via text interface"

[jasonkiss]

Thanks @joanmarie for that very helpful explanation. Taking a steer from what you note and @asurkov's response above, is it unreasonable to do something like the following?

MSAA+IA2

Defines the list item marker, which has no accessible object, but is exposed as content in the accessible text of the associated list item.
Interfaces: IAccessibleText2

UIA

TBD

ATK

Defines the list item marker, which has no accessible object, but is exposed as content in the accessible text of the associated list item.
Interfaces: ATKText

AXAPI

Defines the list item marker, which is exposed as content in AXValue, and rendered as an accessible object:
AXRole: AXLlistMarker
AXSubrole: (nil)
AXRoleDescription: list marker

Comments

Some platforms, e.g. IA2 and ATK, do not expose an accessible object for the list item marker, whether it is not created in the first place, or pruned from the accessibility tree after the fact. Instead, they expose the list item marker as part of the associated list item's accessible text. In these cases, implementors need to consider such things as adjusting the offsets (e.g. for caret-moved events, text-selection events, etc.) for the updated list item text that now also contains the list item marker as content, rather than just taking the offsets unmodified from the list item renderer.

[asurkov]

thumb up from me!

[boggydigital]

In Edge's UIA implementation I believe we're consistent with other implementers, so I would recommend the following text for UIA:

Defines the list item marker, which has no accessible object, but is exposed as content in the accessible text of the associated list item.
Control Pattern: TextPattern

It doesn't seem the other entries were submitted yet - so please let me know if I should submit UIA entry.

[jasonkiss]

Thanks all.

I've updated all the mappings for type on ol: 8ac13bc

@boggydigital, note that for UIA I went with just "Text" for the control pattern instead of "TextPattern". Does that make sense? Or should it even be "TextRange"?

[boggydigital]

@jasonkiss You're right. Inside the team we use "TextPattern" term so much it's practically tattooed on my brain. Control Pattern: Text is the correct way to refer to it. TextRange is more specific and not applicable here. Thank you!

[jasonkiss]

Closing. Mappings updated accordingly in 8ac13bc last August. Minor tweaks in ceb3984.