graphics-aria role mappings needed as precursor to svg-aam role mappings

[cookiecrook]

I noticed tonight that the SVG-AAM role mappings are dependent on the Graphics-ARIA spec (3 roles) that may require some discussion with the ARIA WG and Graphic-ARIA Spec editors.

I'll draft a PR to help illustrate the editorial questions I have.

[cookiecrook]

@AmeliaBR @jnurthen @spectranaut @aleventhal @cyns

There's a difference between WebKit and Chromium on on the internal computedrole for this three-role test from the ARIA Graphics module. As we hope to automate the testing of SVG-AAM for this accessibility investigation project, resolving this discrepancy is a prerequisite.

Chromium vends the browser internal computedrole as the literal role strings from the extension spec: graphics-document, graphics-object, and graphics-symbol.

WebKit vends the browser internal computedrole of the WAI-ARIA core superclass roles: document, group, and image.

Regardless of the internals, the platform mappings are identical, so until now, this difference between the engines has been an implementation detail. Either is "correct."

To move forward with WPT testability of SVG-AAM and DPUB-AAM, I think the options are:

1. Leave it unspecified. (Testability suffers but there is no user impact.)
2. Define in ARIA that the computedrole of extension specs should match the literal concrete role name (Chromium behavior here)
3. Define in ARIA that the computedrole of extension specs should match the superclass core role (WebKit behavior here)
4. Some other option I haven't considered.

Thoughts?

[cookiecrook]

@benbeaudry fyi

[cookiecrook]

This issue and PR blocked on the following:

• Define computedrole for graphics-* roles w3c/graphics-aam#7
• Add computedrole column w3c/graphics-aam#9

[cookiecrook]

Moving ahead with landing the linked PR because it's unblocked now that the ARIA group made a decision.

• graphics-aria roles tests wpt#39437