TextPath and TSpan need platform-specific mappiings

[joanmarie]

TextPath and TSpan should be mapped as ATK_ROLE_STATIC. The current mapping to group role means they will wind up exposed as ATK_ROLE_PANEL.

This was originally filed against ARIA (i.e. before the Great Repo Split of 2017): w3c/aria#133

[joanmarie]

Regarding the needs implementer input label:

As an ATK implementor (I did the SVG AAM implementation in WebKit a couple of years ago) and as the maintainer of the GNU/Linux screen reader, I trust you don't need further input from me.

If you need input for other platforms, perhaps pinging them to comment on this issue would be helpful?

[AmeliaBR]

@joanmarie Yes, the input required is for the other platforms. But at the time I posted it, I was mostly focused on cleaning things up quickly for the republished WD.

Maybe @melanierichards and @cookiecrook could take a look (or suggest someone else who could)?

See the spec for more details.

The question is basically: what's the appropriate platform API role for a formatted text span that needs to be exposed as an accessible object with name/description?

[joanmarie]

@asurkov could you please provide input w.r.t. IA2? Thanks!

[melanierichards]

Thanks for the ping @AmeliaBR and @joanmarie, Control Type: Group (how we map the group role) would still be the most sensible mapping for textPath and tspan in UIA.

[asurkov]

@joanmarie, IA2_ROLE_TEXT_FRAME looks appropriate for tpath element. However, I'm not sure whether tspan element should have accessible object, because it looks quite close to HTML:span element, used for text styling, which should be expressed by text attributes. The latter is also valid for ATK case I would say.

[joanmarie]

@asurkov The mapping tables describe what should happen if the object is included in the accessibility tree. So if the object is excluded from the tree, it wouldn't get mapped. When it should/shouldn't be included in the accessibility tree is (I believe) stated in the spec. If not, it should be.

As with span, if it were used for styling and, say, made focusable, that span/tspan would need to be in the accessibility tree of course. And it would need a role which makes sense. :)

[asurkov]

oh, if there's no requirement to make it having an accessible object, then it's fine. So if it has to have an accessible object for some reason, for example, it is focusable, then IA2_ROLE_TEXT_FRAME should work.

[AmeliaBR]

Thanks for the recommendations, all. To summarize the recommended roles:

• MSAA/IA2: IA2_ROLE_TEXT_FRAME
• UIA: Group
• ATK: ATK_ROLE_STATIC
• AX: Probably AXGroup, pending confirmation from someone who works with the API, but that seems to be used for almost all inline HTML elements

As Joanie said, these roles are only used if the element has been given an explicit name or description, or is focusable. By default the elements are not exposed as separate accessible objects.

One question, for @melanierichards: Why Group and not Text? Text is recommended in HTML-AAM for some formatted-span elements that are directly exposed in UIA, like <mark> and <q>, as well as for SVG <text> (which would be a parent to tspan/textpath if they are both exposed).

[joanmarie]

Ping? The spec still has what I feel are incorrect mappings.

Related aside: I'm working on the Chromium implementation at the moment.

[joanmarie]

Right now, Chromium is exposing these (and also non-link a) in the same was as does a div and (included) span, namely using its internal "generic-container" role. While that's not 100% consistent with what is described here, it IS consistent with what I state in the opening report, namely: These things should NOT be mapped the same as an ARIA group role.

Now that ARIA has the generic role for role parity with div and span, I think the thing to do is update SVG-AAM to make that the mapping rather than have platform-specific mappings. Then the Core-AAM can be where we deal with how badly we want to distinguish inline generics from block generics on a platform-by-platform basis.