Repository navigation
mappings for type attribute on <ol>? #91
Description
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!
Activity
joanmarie commentedon May 24, 2017
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 commentedon May 31, 2017
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
typeattribute. That is, thetypeattribute 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
typeattribute determines the range of values for the list marker?joanmarie commentedon Jun 1, 2017
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....
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 commentedon Jun 14, 2017
I would wrote in IA2/ATK case something like "Exposed as a bullet character it defines in the accessible text via text interface"
jasonkiss commentedon Jul 26, 2017
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 commentedon Aug 2, 2017
thumb up from me!
boggydigital commentedon Aug 8, 2017
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 commentedon Aug 9, 2017
Thanks all.
I've updated all the mappings for
typeonol: 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 commentedon Aug 17, 2017
@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!
some clean up of @type / issue #91
jasonkiss commentedon Dec 18, 2017
Closing. Mappings updated accordingly in 8ac13bc last August. Minor tweaks in ceb3984.