Clarify setSize and posinSet calculation for radios - #2919

✅ Deploy Preview for wai-aria ready!

Name	Link
🔨 Latest commit	f53b776
🔍 Latest deploy log	https://app.netlify.com/projects/wai-aria/deploys/6acd4a163632f42d43ae04d5
😎 Deploy Preview	https://deploy-preview-2919--wai-aria.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

To edit notification comments on pull requests, go to your Netlify project configuration.

🚀 Deployed on https://deploy-preview-2919--wai-aria.netlify.app

Maybe also take a look at: w3c/html-aam#598 (comment)

The ARIA Working Group just discussed HTML-AAM: Clarify setSize and posinSet calculation for radios.

ping @scottaohara @HaTheo @front-endian for review :)

agree with the content of the changes.

arguably, since this now calls out the name attribute, there should be a new mapping table for the name attribute in relation to input type=radio that this updated mapping table could link to. The mapping tables would then cross link to each other.

there's this name attribute mapping table that generically mentions all input elements - but that's clearly not right that name is not mapped in regard to type=radio. so that'd unfortunately need to be modified to "input (except for type=radio lol)" or similar text...

(the separation of all the name attributes mostly by element type is clearly not very useful since they all mention "not mapped"... consolidating those could be another issue/PR, so then there could be a mapping table for all the not mapped name use cases, and then separate mapping tables for just the instances where name does something meaningful for accessibility).

Thanks @scottaohara and @HaTheo! I've update the spec by adding a "name" mapping and removed a bunch of prose in favor of pointing to it. I also added changes to Core-AAM... I realized the mapping is a little more complicate than redirecting to aria-setsize and aria-posinset, because the native/implicit mappings are different than aria-setsize and aria-posinset for macOS, and I think for UIA as well.

Actually, Theo, maybe you would know if Core-AAM is incorrect for posinset and setsize... it says to map them to AriaProperties.posinset and AriaProperties.setsize but in Chrome at least it looks like they are mapped to the properties PositionInSet and SizeOfSet. Actually, I could add the UIA aamtest test to test this...

Yes, I am not sure I have an authoritative answer but @douggeoffray or @benbeaudry might know the history here. What is stated here in the spec and mapping for aria properties in UIA and in the Core-AAM doesn't align with what I thought we did which was map to the native properties when they exist. I wonder if there is some particular history here I am missing or if things are dated, it's a good callout.

For those unfamiliar with the history(likely not anyone in the conversation): In UI Automation(UIA) the accessibility mapping API in Windows, Microsoft added a table that would allow them to expose all of the properties and every time a property was added so the solution was to add a ARIA table which can accept all ARIA properties. This allows AT to have a pure/updated understanding the ARIA properties in the case that it was not in UIA without Microsoft having to update UIA everytime, in many cases using the available native UIA property is preferred(what chrome is doing), but also in those cases they are cross-referenced in this case in particular UIA chose to not map ARIA's PosInSet and SetSize to UIA's native posinset and sizeofset both in this table in the UIA spec and also in the Core-AAM spec meaning that if browsers were to follow this the aria properties would be known would be in UIA's ARIA mapping table. Though it seems that at least Chromium browsers are not in spec and are mapping to UIA's posinset and sizeofset which is what I would expect intuitively but not what should be done according to the UIA Specification or Core-AAM.