Which ARIA synonym role should computedrole return?

[cookiecrook]

Which ARIA synonym role should computedrole return?

WebKit and Chromium differ on this new synonym role test:
https://github.com/web-platform-tests/wpt/pull/38941/files

I think, and the Draft PR test asserts, that the primary role names should be none and image... I think the secondary synonyms (presentation and img) should be supported as input, but not returned by computedrole.

(Details results linked from table header.)

role/synonym	WebKit	Chromium
none/presentation	✅none (Was: presentation until (bug 224617)	✅none
image/img	✅image	❌generic / ❓img (bug 1428763)

If the WG confirms this assertion, the WPT test will result in 1 bug each for WebKit and Chromium. Maybe 2 for Chrome if it's not already tracking the missing image role.

We'd also need something in the ARIA spec… pointing the synonym at its primary, or a table defining the computedrole for each role in the spec.

See also:

• Need a decision on what the computedrole should return on extension specs aria#1887

[spectranaut]

We discussed this in today's working group meeting: https://www.w3.org/2023/03/16-aria-minutes.html#t05

@scottaohara and I agreed, because this is an implementation detail, it belongs in the aams. Many html elements will need this "computed role" mapping as well.

In the meeting, we did not discuss which mapping to choose for these synonyms, but in my opinion, as it is an implementation detail, the choice can be arbitrary. I'll explore adding these mappings it to the specification and suggested computed roles in the role image / role presentational case.

[cookiecrook]

@scottaohara and @spectranaut agreed

I assume this means you agreed none and image should be the primary roles over their respective synonyms, since that's what the PR reflects.

because this is an implementation detail, it belongs in the AAMs.

I'm not certain I understand this. "implementation detail" usually means "it doesn't matter, and shouldn't be in a spec." which seems contradictory to your agreement that it should be.

Also, I don't follow the logic of why this should be in Core-AAM instead of the ARIA spec. Can you clarify?

[scottaohara]

we were agreeing that it made sense this would be spec'd in the AAMs because then the various specs could link to core aam for what the computed role should be. For instance, HTML elements in HTML AAM could benefit from a computed role as well - particularly for elements like summary which don't neatly map to a single ARIA role, and instead are being announced as a "summary", "button", "disclosure triangle". Similarly, were thinking that for things like dpub ARIA, where there's the role in the spec, but the computed role may be what the dpub role is extending off from.

in other words, if the exposed roles / mappings are largely covered in core aam, then why not also specify the computed role there to keep the number of specs needing to be linked to (which i know the ship is sailed on this one) to a minimum.

but to your immediate question, I at least agree that yes, none and image should be the primary roles.

[cookiecrook]

Overall I agree, but the reason I thought there should be something in the spec is that there should never be a time when a peer synonym should be exposed. E.g an extension spec should not be able to say graphics-symbol should return a computed role of img even though the spec defines image as the primary. However, an extension spec AAM could define that graphics-symbol return a computed role of graphics-symbol even if it's treated like a synonym of image (e.g. AXImage) at the platform Accessibility API level.

[scottaohara]

I thought there should be something in the spec is that there should never be a time when a peer synonym should be exposed.

yah, i agree with that as well.

[cookiecrook]

Also see:

• Need a decision on what the computedrole should return on extension specs aria#1887