Add "May not have accessible object" preamble for UIA div and span

[carmacleod]

Add preamble mentioned in w3c/aria#699 (comment) by @melanierichards:

HTML-AAM probably needs the "May not have an accessible object if has no semantic meaning. Otherwise..." preamble [for div] for us [UIA] too...

[carmacleod]

(assigning to me)

[carmacleod]

Reading again, I see that @melanierichards' comment in w3c/aria#699 (comment) also applies to span:

In Edge/UIA we map <div> and <span> to ControlType: Group, only if it is semantically interesting (tabindex for example). Otherwise, child nodes, such as text nodes, are placed into the accessibility tree. HTML-AAM probably needs the "May not have an accessible object if has no semantic meaning. Otherwise..." preamble for us too...

[scottaohara]

Thanks for getting this going @carmacleod

think this will be related to the local draft I have started for 151

[carmacleod]

Hi, @scottaohara . I had just discovered #151 a few minutes ago, and I have been trying to figure out what the mappings are for span if it is "semantically interesting" (i.e. if it has tabindex, etc).
@joanmarie says ATK maps to ATK_ROLE_STATIC.
UIA seems to map to Control Type: Group.
Not sure what MSAA/IA2 map to.

Anyhow, just wondering if the same div-preamble would be useful for span as well. Something like:

WAI-ARIA	No corresponding role
MSAA + IAccessible2	May not have an accessible object if has no semantic meaning. Otherwise, ROLE_SYSTEM_GROUPING ??
UIA	May not have an accessible object if has no semantic meaning. Otherwise, Control Type: Group
ATK	May not have an accessible object if has no semantic meaning. Otherwise, ATK_ROLE_STATIC
AX	AXRole: AXGroup, AXSubrole: (nil), AXRoleDescription: "group"

[joanmarie]

In the case of ATK, we would want to preserve the existing role (ATK_ROLE_SECTION) for divs which are exposed.

[carmacleod]

Hi @joanmarie . The table entry for ATK div would stay the same, i.e. it would still say the following:

May not have an accessible object if has no semantic meaning. Otherwise,
Role: ATK_ROLE_SECTION
Interfaces: AtkText; AtkHypertext

It's the entry for span that would change from "Not mapped" to:

May not have an accessible object if has no semantic meaning. Otherwise,
Role: ATK_ROLE_STATIC

Is that ok? Would you want the text interface(s) for span as well?

[scottaohara]

I was going down the route of adding "ATK_ROLE_STATIC (if mapped)" but I'm fine with what you're proposing for now:

May not have an accessible object if has no semantic meaning. Otherwise,
Role: ATK_ROLE_STATIC

Per 151, that preamble would need to be added to other elements that this change would apply to. but i'll take care of that to close that issue

[carmacleod]

I leave this in your capable hands. :)
Feel free to either merge or close #192.

[joanmarie]

The thing is, it's not just semantic meaning that can cause an element to need to be exposed in the accessibility tree. If an author puts a tabindex on a span, that's sufficient to require an accessible object. But I would argue there's no semantic meaning associated with that span.

If anything, I would update the text for div to be more in line with what I propose for span and friends. For instance, Gecko has historically (and probably still does, though to a lesser extent) include div instances with no specific semantic meaning in the accessibility tree. Also one can wind up with div-like objects when an accessibility object is created as a result of an anonymous block. In these cases we need to know what role to apply because the object is "mapped" (though otherwise meaningless).

[joanmarie]

It's the entry for span that would change from "Not mapped" to:

May not have an accessible object if has no semantic meaning. Otherwise,
Role: ATK_ROLE_STATIC

Is that ok? Would you want the text interface(s) for span as well?

Regarding the language above, I personally would prefer the language I stated, but like you I'll leave it up to @scottaohara.

Regarding the interfaces: Any element which exposes text needs to implement AtkText. Any element which has children needs to also implement AtkHypertext.

[carmacleod]

Ok, although my thinking was that adding tabindex (or any other event handling) gave the element "semantic meaning"... because now it's an "interactive thing". Similarly, I figured that the target of a relation attribute could be considered to have semantics, because it's "the thing that gives the description", or "the thing that is owned", etc. (And so on, for the other global aria attributes).

The problem I have with "(if mapped)" is that it makes me wonder: "Why wouldn't it be mapped?"
It makes me feel like the spec is "too fuzzy". :)

Can we use "(if mapped)", but link it to some useful definition?

The definition of "Not Mapped" in HTML-AAM is not useful enough because it doesn't tell the whole story:

"Not mapped" (Not Applicable) means the element does not need to be exposed via an accessibility API. This is usually because the element is not displayed as part of the user interface.

There is no definition for "Not Mapped/If Mapped" (for roles) in Core-AAM any more...

So can we link to the not-yet-reworded section "Including Elements in the Accessibility Tree" currently in the ARIA spec (although @jnurthen mentioned it might belong back in Core-AAM... 😄 ).

[joanmarie]

The problem I have with "(if mapped)" is that it makes me wonder: "Why wouldn't it be mapped?"
It makes me feel like the spec is "too fuzzy". :)

That's fair. :) But the answer to "why it's mapped" might NOT be "because some spec says it needs to be mapped as a result of X or Y" or "because it has semantic meaning" or "because it's focusable." Instead, the answer might be something like "Because it's too big a change to remove it, and there's not a spec statement prescribing that we MUST exclude it, so whatever. It's in the tree." (Admittedly, I paraphrase a tad. But not all that much....)

Yes, it would be nice to have all accessibility trees be the same regardless of user agent and regardless of accessibility API. Good luck making that happen. ;)

So.... We need something which boils down to "if, for whatever reason, you're going to include this in your accessibility tree, here's the platform role to use so that ATs know what the heck it is." I thought "if mapped" covered that.

[carmacleod]

@scottaohara @joanmarie

I'm fine with having " (if mapped)" appended to the platform role for all span-ish and div-ish elements (and remove the preamble); ... so @scottaohara can finish #151. :)

However, I'd like to add a new bullet to the HTML AAM Element Role Mappings Notes, right after the bullet about "Not mapped". Something like:

• "(if mapped)" means the element may not need to be exposed via an accessibility API. This may be because the element is not interactive, or has no semantic meaning. User agents may decide to map these elements for reasons of performance, space optimization, or simplicity.

(@joanie is that last sentence about right?)

@scottaohara I can open a separate issue for the new bullet if you prefer.

[joanmarie]

@carmacleod What's an example of "space optimization"?

Also, your proposed definition of "if mapped" seems to emphasize the exclusion and not give enough emphasis on inclusion.

What about tweaking it to something like:

• "If mapped" means the element is conditionally exposed in the accessibility tree. User agents MUST map the element if it is interactive or has semantic meaning. User agents MAY also include this element in the accessibility tree for implementation-specific reasons.

[carmacleod]

@joanmarie

• "If mapped" means the element is conditionally exposed in the accessibility tree. User agents MUST map the element if it is interactive or has semantic meaning. User agents MAY also include this element in the accessibility tree for implementation-specific reasons.

I like it - it's perfect. Thank-you! It even nudges the user agents along towards a semblance of mapping parity with the normative MUST in there.

(for "space optimization", I was thinking along the lines of optimizing memory use, i.e. if the a11y tree got too big, that could affect performance. However, your phrase "implementation-specific reasons" covers all of that stuff - nice!).

[carmacleod]

Closing this issue as it has been completely superseded by #151.