(In reply to Jason Kiss from comment #0)
> Some of the ARIA roles do not have explicit a11y api roles listed for them.
> The UIA column is especially lacking control types for certain ARIA roles.
> Is this by design?

AFAIK, for the ARIA roles you cite, there are no corresponding AAPI roles in some of the AAPIs.  Consequently, another mechanism is used to communicate the role information: the xml-roles object attribute in the case of IA2 and ATK/AT-SPI, and the AriaRole property in UIA.

AAPI ROLE values or control types could be used for those AAPIs (and likely something is assigned when the accessible is actually built by the user agent), but it would be relatively generic, as you suggested.  The important information in these cases is communicated by other means.  This is not a reflection of the draft state of the document.  In fact, the current UAIG 1.0 Recommendation has the same mappings (http://www.w3.org/TR/wai-aria-implementation/#mapping_role_table).

However, I'm cc'ing various AAPI experts for their opinion.

Some urls for reference:
banner:
http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#role-map-banner

navigation:
http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#role-map-navigation

complementary:
http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#role-map-complementary

contentinfo:
http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#role-map-contentinfo

article:
http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#role-map-article

form:
http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#role-map-form

Thanks, Joseph. 

To the degree that the roles in question don't have specific corresponding roles in the AAPIs, but are (always?) associated with an accessible object in the a11y tree, is it reasonable to give them the relevant generic grouping or section role in the AAPI?

Or is it better to leave this to the host language mapping guides? For example, the HTML-AAM will map the nav element to ROLE_SYSTEM_GROUPING, ROLE_SECTION and the Group control type, and otherwise refer to Core-AAM for mappings related to the implicit navigation role. 

Just trying to make sure the mapping documents work together well, and consistently leverage Core-AAM in the most efficient and appropriate manner.

(In reply to Jason Kiss from comment #2)
> Thanks, Joseph. 
> 
> To the degree that the roles in question don't have specific corresponding
> roles in the AAPIs, but are (always?) associated with an accessible object
> in the a11y tree, is it reasonable to give them the relevant generic
> grouping or section role in the AAPI?

An accessible object is always created for these roles.  There has to be an accessible since the IA2 or ATK 'xml-role' object attribute is a property of the accessible object so created.  Likewise, the AriaRole property used in UIA.

I don't know about "reasonable", but it isn't very informative.  A motivation for different aria roles is to make semantic distinctions.  If different aria roles are mapped to the same generic AAPI role, say ROLE_SYSTEM_GROUPING, then an AT can't tell the difference between them, based on that alone.

For example, here are two accessibles, using IA2:

Accessible #1: {
  role: ROLE_SYSTEM_GROUPING,
  name: "foo",
  description: "",
  states:  FOCUSABLE, STATE_SYSTEM_COLLAPSED, ..."
  relationships: [ ... ],
  objectProps : {
    xml-roles: "banner",
    ...
  },
  ... 
}

Accessible #2: {
  role: ROLE_SYSTEM_GROUPING,
  name: "bar",
  description: "",
  states:  FOCUSABLE, STATE_SYSTEM_COLLAPSED, ..."
  relationships: [ ... ],
  objectProps : {
    xml-roles: "navigation",
    ...
  },
  ... 
}

In terms of roles, the difference is given by the xml-roles object attribute, not the AAPI role, and *that* property tells you one is a banner, and the other is navigation. Since the AAPI role values don't make the distinction, they are pretty much irrelevant, in this case.

> 
> Or is it better to leave this to the host language mapping guides? For
> example, the HTML-AAM will map the nav element to ROLE_SYSTEM_GROUPING,
> ROLE_SECTION and the Group control type, and otherwise refer to Core-AAM for
> mappings related to the implicit navigation role.

To the extent that the <nav> element and the aria "navigation" role have equivalent role semantics, then, IMO, use the Core-AAM mapping entry of "navigation" for the basis of the <nav> AAPI mappings.  In fact, if they are role-equivalent, then the role mappings should be identical.

> 
> Just trying to make sure the mapping documents work together well, and
> consistently leverage Core-AAM in the most efficient and appropriate manner.

Sure.  Hope this clarifies.

While the generic AAPI role might be irrelevant for distinguishing the ARIA semantic, an AAPI role needs to be set nonetheless for the accessible, right? 

Shouldn't the Core-AAM indicate a preferred AAPI role, even if that role is generic?

I'm thinking that at least the HTML-AAM should expressly indicate the preferred AAPI role in all cases, even if the role is generic. And if that AAPI role mapping isn't declared in the Core-AAM, then the HTML-AAM can't simply point to it with a "Use WAI-ARIA mapping", but will need to declare the AAPI role for the HTML element and then also point to the Core-AAM for the ARIA-related mapping, or just duplicate the Core-AAM mapping in the HTML-AAM, neither of which are ideal.

An issue is how ATs determine when to use the alternate mechanism for acquiring the role.  That is, in most cases, an AT uses the AAPI's "getRole()" accessor to obtain the accessible's role.  But, in the cases that Jason has raised, that doesn't work, and the AT has to make a second call to get the actual role information from another property of the accessible.

The question is:  how does the AT know to do that?  What tells the AT that getRole() in insufficient, in these cases?

There might be an argument that using generic AAPI roles here is detrimental, since they are legitimate roles.  How does the AT distinguish between a real generic vs. one that triggers a second call to get the alternative role information?

Or, the indicator might be the generic role itself using the rule, "if the AAPI role is generic, check the alternate role for more information."

Whatever the rule is, the Core-AAM should say something about it.

AFKAICT, this isn't an problem when using ATK/AT-SPI nor AXAPI, only with IA2 and UIA.

Cynthia and Alex:  any insights here?

For UIA, these should be mapped to the group control type with a localized control type that matches the aria role.

(In reply to Cynthia Shelly from comment #6)
> For UIA, these should be mapped to the group control type with a localized
> control type that matches the aria role.

Thanks Cynthia.

Using role='navigation' as an example, the current entry for UIA is [1]:

"Expose as text string in AriaRole".

Based on your comments, how is this for the new text?

"
- Expose as text string 'navigation' in AriaRole.
- Group control type with a localized control type based on the AriaRole.
"

[1] http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#role-map-navigation

Is it confirmed that:

1. for each accessible object in both IA2 and ATK, some kind of formal AAPI role, even if generic, needs to be set, and 

2. for each accessible object in UIA, the Group control type with an appropriate localized control type needs to be set?

It would be great to have this sorted and clarified in Core-AAM as it's hard to finalise the mappings in HTML-AAM (and presumably other AAMs) without knowing to what degree it can leverage the Core-AAM mappings.

While ATK has the quasi-generic ROLE_LANDMARK for ARIA landmarks where the  distinction between them is made via the xml-roles object attribute, there is at least one other ARIA role, i.e. definition, for which there is no explicit ATK role indicated [1]. Should it take ROLE_STATIC in addition to the object attribute?

From my review, the following ARIA role is lacking explicit AAPI roles or control types for MSAA+UIA Express, MSAA+IA2, UIA, and ATK:

-definition

The following ARIA roles are lacking explicit AAPI roles or control types for MSAA+UIA Express, MSAA+IA2, and UIA:

-banner
-complementary
-contentinfo
-main
-navigation
-search
-timer

The following ARIA roles are lacking explicit AAPI roles or control types for MSAA+UIA Express and/or UIA:

-article
-form
-math
-note

And the following ARIA role is lacking an explicit AAPI role for MSAA+IA2:

-log


[1] http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#role-map-definition

(In reply to Jason Kiss from comment #8)
> Is it confirmed that:
> 
> 1. for each accessible object in both IA2 and ATK, some kind of formal AAPI
> role, even if generic, needs to be set, and 

One of the things we discovered during the AAPI meeting 30-Jun-2015 was that when one of these aria roles are used with HTML, FF uses the element for the AAPI role.  For example, <p role="banner"> is exposed as IA2_ROLE_PARAGRAPH and xml-roles: "banner".  A paragraph role is not generic.

I checked this on GNOME/Linux, and FF is exposing ROLE_PARAGRAPH for ATK/AT-SPI as well.  In this case, FF is not following the Core-AAM mappings for role="banner", since the core ATK/AT-SPI mapping is ROLE_LANDMARK.  It is following the HTML-AAM mapping for the <p> element, though (http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-p).

There may be a rationale for this.  Alex, can you clarify?

> 
> 2. for each accessible object in UIA, the Group control type with an
> appropriate localized control type needs to be set?

That is Cynthia's stance for these roles when used with generic elements, like <div>. See comment 6.  But, she may agree with FF's approach of using the element for the AAPI role when it is more specific.  That is, <p role="banner"> might be exposed as control type Text, with an AriaRole of "banner", not a generic control type.

I treat xml-roles as a list of extra roles the accessible may have. In a practice it is single role. In case of HTML element it can be either landmark role or ARIA role if ARIA role is more specific. So I assume AT has to check both GetRole() and xml-roles.

(In reply to alexander surkov from comment #10)


Thanks Alex.  But, I don't understand:
> In case of HTML element it can be either landmark role or ARIA role if ARIA
> role is more specific.

Take this example:  <p role="banner">.  The HTML element has an ARIA landmark role that is more specific than just a paragraph.  Nonetheless, FF exposes it as (ATK):  ROLE_PARAGRAPH/xml-roles:banner.

Why isn't it ROLE_LANDMARK/xml-roles:banner?  That is how FF exposes <div role="banner">.

What is the rationale?

(In reply to Joseph Scheuhammer from comment #11)
> (In reply to alexander surkov from comment #10)
> 
> 
> Thanks Alex.  But, I don't understand:
> > In case of HTML element it can be either landmark role or ARIA role if ARIA
> > role is more specific.
> 
> Take this example:  <p role="banner">.  The HTML element has an ARIA
> landmark role that is more specific than just a paragraph.  Nonetheless, FF
> exposes it as (ATK):  ROLE_PARAGRAPH/xml-roles:banner.
> 
> Why isn't it ROLE_LANDMARK/xml-roles:banner?  That is how FF exposes <div
> role="banner">.
> 
> What is the rationale?

I am wondering the same thing. If the author says "this is a banner", telling the AT that it's a paragraph doesn't seem like the right thing to do.

I'm also wondering what info is needed from me (i.e. for the needinfo request).

there's no landmark role afaik but after all landmark role can be applied to any element and it doesn't override its native semantics, so for example if you have <table role="banner"> then it's still a table, and AT wants to know that.

<div role="banner"> is exposed as ROLE_SECTION, just a generic role.

(In reply to alexander surkov from comment #13)
> there's no landmark role afaik ...

There is in ATK/AT-SPI, since 2.12.  

> ... <div role="banner"> is exposed as ROLE_SECTION, just a generic role.

Right, my bad.  I thought I had tested that, but it turns out I was going by what the Core-AAM says.

I also tested <span role="banner"> to see what the native semantics were there.  The result was ROLE_TEXT/xml-roles:banner.

(In reply to Joanmarie Diggs from comment #12)
> I'm also wondering what info is needed from me (i.e. for the needinfo
> request).

Joanmarie, I think I was just looking for your input on the best ATK role for definition.

As far as the needinfo from Cynthia, I think it was for input on the UIA mappings for:

-banner
-complementary
-contentinfo
-main
-navigation
-search
-timer
-article
-form
-math
-note

As a summary, here is my understanding thus far, at least for ARIA landmark roles:

UIA exposes the ARIA role value in the AriaRole property, and exposes a group control type with a localized control type based on the AriaRole.  I think this is easily added to Core-AAM.

For MSAA+IA2 and ATK/AT-SPI, use the element itself for the ROLE property, but expose the ARIA role in the xml-roles property.  I don't think this belongs in the Core-AAM; rather, it's part of the HTML-AAM.  The reason being that it may or may not apply for SVG.  I'm adding Rich to the cc list, since he is the SVG-AAM editorm, and may have some insights.

Needed:  rules for the other non-landmark roles that Jason listed in comment 8 and comment 15.

(In reply to Cynthia Shelly from comment #6)
> For UIA, these should be mapped to the group control type with a localized
> control type that matches the aria role.

Based on the above, and the issues Cynthia raised in tracker, I've modified the UIA mappings for application, banner, complementary, contentinfo, main, search, navigation, article, definition, log, math, and note.  Most of these are landmarks; some are not, but were noted in the issues.

The general pattern is, using role="application" as an example:

* Control type/role is Pane.
* Localized Control Type is application.

The commit on github is here:
https://github.com/w3c/aria/commit/cc4ae422060d78e309be846d13e17043e56c5ea8

The changes were taken from Cynthia's notes in ISSUE-723 through ISSUE-734:
https://www.w3.org/WAI/PF/Group/track/issues/723
https://www.w3.org/WAI/PF/Group/track/issues/724
https://www.w3.org/WAI/PF/Group/track/issues/725
https://www.w3.org/WAI/PF/Group/track/issues/726
https://www.w3.org/WAI/PF/Group/track/issues/727
https://www.w3.org/WAI/PF/Group/track/issues/728
https://www.w3.org/WAI/PF/Group/track/issues/729
https://www.w3.org/WAI/PF/Group/track/issues/730
https://www.w3.org/WAI/PF/Group/track/issues/731
https://www.w3.org/WAI/PF/Group/track/issues/732
https://www.w3.org/WAI/PF/Group/track/issues/733
https://www.w3.org/WAI/PF/Group/track/issues/734

Believe this is dealt with through subsequent work in the UAIG TF.