[ROLE PARITY] Determine why these elements with ARIA roles have customized mappings for some platforms

[joanmarie]

The following elements are already mapped in the HTML AAM to an ARIA role, but at least one platform's mapping is NOT "Use WAI-ARIA mapping."

Assumption: If at least one platform feels the ARIA role is not right for their needs, it may suggest we want a new role. Then again, it might not. For instance, if the HTML AAM mapping corresponds to what is now in the Core AAM, the element in question would not belong in this group, but instead in the group of elements found in #694.

We need to triage these further to figure out if the customized mappings are truly different, and for those that are if that justifies a new role.

• aside: complementary (belongs in [ROLE PARITY] Verify we do NOT need new roles for these elements which already have roles #694)
• footer (scoped to body element): contentinfo (belongs in [ROLE PARITY] Verify we do NOT need new roles for these elements which already have roles #694)
• header (scoped to body element): banner (belongs in [ROLE PARITY] Verify we do NOT need new roles for these elements which already have roles #694)
• input (type=email, no suggestions source element): textbox (belongs in [ROLE PARITY] Determine which of these elements with existing ARIA role mappings require a new role #696)
• input (type=telephone, no suggestions source element): textbox (belongs in [ROLE PARITY] Determine which of these elements with existing ARIA role mappings require a new role #696)
• input (type=url, no suggestions source element): textbox (belongs in [ROLE PARITY] Determine which of these elements with existing ARIA role mappings require a new role #696)
• input (type=email,search,telephone,textbox,url, suggestion source element): combobox (belongs in [ROLE PARITY] Determine which of these elements with existing ARIA role mappings require a new role #696)
• output: status (belongs in [ROLE PARITY] Verify we do NOT need new roles for these elements which already have roles #694)
• thead: rowgroup (belongs in [ROLE PARITY] Determine which of these elements with existing ARIA role mappings require a new role #696)
• tr: row (belongs in [ROLE PARITY] Verify we do NOT need new roles for these elements which already have roles #694)

[joanmarie]

I assigned this one to myself to do the additional triage described.

[cookiecrook]

It may be that this is an implementation detail that does not need addressing.

One of the purposes of role parity is automated spec testability. As long as the engine returns the correct WAI-ARIA role to the JavaScript test context (WebDriver, etc.), it may not harm the test status if an engine also special-cases a mapping into a specific API. That can be verified as an individual manual or other non-WPT test.

To be clear, I am not saying we don't need additional roles. I am only stating that <one browser's mapping decision> does not in and of itself necessitate a new role. It could mean a new role, or a note in the AAM, or it may just be an implementation bug.

[joanmarie]

@cookiecrook: Understood. What I am hoping I shall find in quite a few cases is that what's explicitly in the HTML AAM is no different from what's in the Core AAM, in which case the mappings are not any different. But since I don't know if that's what I'll find, and because I want to get input on all the other groups, I filed this issue and assigned it to myself. Depending on what I find, I plan to move the roles listed here into one of the groups from the other issues.

[joanmarie]

Having triaged the landmark roles, I believe they belong in issue #694. I have updated the opening report here to reflect that. See w3c/html-aam#119.

[joanmarie]

Having triaged the input types, the platform unique mappings are just to expose the type of the input. Because the mappings on all platforms are otherwise to use the WAI-ARIA role, I moved the input items to #696 because while there is a role, it's not a one-to-one mapping. Therefore, they need further triage to determine if the existing roles are sufficient parity.

[joanmarie]

The last two, tr and thead have been triaged:

• UIA generally doesn't map tr. That's a platform preference. The remaining platforms do use the ARIA role mapping (row). Because there is a one-to-one correspondence between the element and the ARIA role, it belongs in [ROLE PARITY] Verify we do NOT need new roles for these elements which already have roles #694. I've added it (along with the landmark roles) as a comment [ROLE PARITY] Verify we do NOT need new roles for these elements which already have roles #694 (comment) because @cookiecrook had already given his +1 to the opening report.
• thead is a similar case insofar as all platforms but UIA use the ARIA role (rowgroup). UIA maps it as a header. While this is another platform preference, thead, tbody, and tfoot all map to rowgroup. Because there is not a one-to-one correspondence, it belongs in [ROLE PARITY] Determine which of these elements with existing ARIA role mappings require a new role #696 for further triage. I've added it to the opening report of that issue.

Having completed the triage and moved the elements in question to the issues where they (IMHO) belong, I'm closing this issue.