SVG-AAM: Corrections to platform mappings for ATK

[joanmarie]

1. text is currently mapped to as ATK_ROLE_PARAGRAPH. In ATK, generic text blocks should be mapped as ATK_ROLE_SECTION. (In HTML, <p> maps to ATK_ROLE_PARAGRAPH and <div> maps to ATK_ROLE_SECTION.)
2. tspan is currently mapped to the 'group' role mapping. In ATK, there are two roles which function like 'group': If the group is serving like a generic text container (i.e. like the <div> element in HTML) then ATK_ROLE_SECTION should be used. If instead the group is serving as a container of interactive widgets, then ATK_ROLE_PANEL should be used. HOWEVER, in both cases the element (and associated accessible object) is assumed to be a block element; not an inline element. Therefore, I think tspan should be mapped like <abbr> (and other inline elements which need accessible objects in order to expose an associated property), namely as ATK_ROLE_STATIC.

[richschwer]

Joanie, I changed the role to Section for . I have not changed tspan yet because it is simply used for styling. I looked at span in HTML and it is not mapped for ATK/ATSPI. It is used for styling. Should basically say it is not mapped? http://www.w3.org/TR/html-aam-1.0/

[richschwer]

sorry, changed the role text for atk to ATK_ROLE_SECTION

[klown]

@richschwer

Should basically say it [span] is not mapped? http://www.w3.org/TR/html-aam-1.0/

The core-aam has a general statement about this, where it uses SPAN as an example. The general principle is that an accessible object is created for a DOM element because the element has semantics in the form of an AAPI event, property, state, and/or relationship that needs to be exposed.

See the section "The Accessibility Tree and the DOM Tree (http://w3c.github.io/aria/core-aam/core-aam.html#intro_treetypes). The SPAN element is mentioned in the last sentence of that paragraph.

[joanmarie]

@richschwer: In addition to what @klown stated, see my comment in https://www.w3.org/Bugs/Public/show_bug.cgi?id=27391#c1:

Also, this might be worth a note:

• span - almost always not mapped. But if there is a need to expose it, e.g. <span onclick="foo()">clickable</span>, then it should be ATK_ROLE_STATIC.

[richschwer]

just because you have a click handler on something does not mean it has a meaningful semantic. A role of static text really seems more like a "throwing jello at the wall" solution. A tspan has to sit inside a section which is text. So, whether the tspan is there or not, it is still text. I don't see value in making it static text. The author would need to add aria semantics if it is meaningful.

[joanmarie]

If it has a click handler, there has to be an accessible object associated with it because without that, an AT cannot present the clickability to the user. Furthermore, and arguably more importantly, objects which have an onclick handler should implement the AtkAction interface so that an AT can use that interface to synthesize the click on behalf of the user. Thus the element (e.g. span) needs to have an accessible object in order for AtkAction to be implemented for it.

I agree that if the tspan is strictly for formatting, it should not be mapped. In other words, tspan is "almost always not mapped" (just like span). But if an author adds something to a tspan to make it interactive (e.g. a tabindex) we need an accessible object for it (e.g. to emit the accessible state-changed:focused events so a screen reader can present it when tabbed to). What if the author fails to add a role. We need to map it to some role. I would suggest ATK_ROLE_STATIC (ATK's generic, don't-speak-a-role role).

[joanmarie]

BTW and to be clear, ATK_ROLE_TEXT is not appropriate as described in https://developer.gnome.org/atk/stable/AtkObject.html#AtkRole:

ATK_ROLE_TEXT
An interactive widget that supports multiple lines of text and optionally accepts user input, but whose purpose is not to solicit user input. Thus ATK_ROLE_TEXT is appropriate for the text view in a plain text editor but inappropriate for an input field in a dialog box or web form. For widgets whose purpose is to solicit input from the user, see ATK_ROLE_ENTRY and ATK_ROLE_PASSWORD_TEXT. For generic objects which display a brief amount of textual information, see ATK_ROLE_STATIC.

[klown]

@joanmarie wrote:

If it has a click handler, there has to be an accessible object associated with it because ...

Another factor is that if a user clicks on a SPAN with a click handler, an accessible click event will be emitted by AT-SPI. That click event object has an "event source" property, which references the accessible object that is the source/target of the click. Hence, there has to be an accessible object in the accessibility tree that is the source of the event.

[joanmarie]

As long as we're chatting about this.... Would it make sense for textPath to be mapped in a similar fashion to tspan, both regarding when to map it and what role to map it to?

[fredesch]

SVG a11y TF discussed and want tspan treated like span (normally not in accessibility tree, group if something adds it to tree). Rich updated the SVG AAM.

[AmeliaBR]

To clarify: both tspan and textPath should by default not be mapped to an accessible object. However, either may be mapped, if the author has provided supplementary accessibility features, such as a description of the visual appearance of the text.

In that case, I think @joanmarie's recommendations for platform-specific mappings should be used. I'd love to have feedback about similar mappings for other APIs, too. Long term, I'd like to see proper ARIA roles for describing basic text-level semantics, but for now we can at least make sure that correct roles are used when they exist in the accessibility API.

For interactive elements, one would hope that the author would assign a widget role (such as button), but if not I agree that these "neutral" text roles would still seem to be the best guess. We will need to review the SVG-AAM rules for including/excluding objects to be sure they are consistent with creating an object in these cases.

[AmeliaBR]

Cleaning up old issues, but I don't think this one is entirely clean, so I can't close it just yet.

The SVG-AAM has been updated to match @joanmarie's first point in this issue (if <text> needs a mappable role, treat it as "section" not as "paragraph").

However, <textPath> and <tspan> still reference the generic CORE-AAM mappings for "group" (if the element is going to be exposed in the accessibility tree at all). Joanie, do you still think the best generic mapping for a text formatting element is "ATK_ROLE_STATIC"?

PS, repeating my comment from last year:

I'd love to have feedback about similar mappings for other APIs, too. Long term, I'd like to see proper ARIA roles for describing basic text-level semantics, but for now we can at least make sure that correct roles are used when they exist in the accessibility API.

[joanmarie]

However, and still reference the generic CORE-AAM mappings for "group" (if the element is going to be exposed in the accessibility tree at all). Joanie, do you still think the best generic mapping for a text formatting element is "ATK_ROLE_STATIC"?

Yes. These things do not strike me as being sections. Do they strike you as being sections?

[joanmarie]

Closing this as a duplicate of w3c/svg-aam/issues/2.