Consider codifying an ARIA API review expectations section to reduce authoring tedium

[cookiecrook]

Consider codifying an ARIA API review expectations section? We do this informally with code review, but no reviewers internalize all the potential implications. What if we documented the important areas in a list or other review process?

e.g. for every new ARIA feature proposal

• has it been considered how it will be used in practice with common JavaScript framework patterns?
• has it been considered how it will work with emerging tech (for example Web Components/Shadow DOM led to frozen element arrays for IDREFS attrs)
• Is the new feature proposal more rigid than it needs to be?

Once codified, we could use those to re-review existing ARIA features to consider whether they meet these expectations. If not, which requirements can be relaxed or which alternative features might be considered to resolve the authoring tedium?

This came out of the OpenUI/ARIA Joint meeting on 2022-04-28, where Chris Hall asked, (paraphrased) ~"Does the ARIA WG acknowledge that some of structural limitations make it tedious to implement in frameworks?"

One example given was that ARIA radios must be contained in and ARIA radio group, where the same is not true for HTML <input type="radio"> ... My half baked proposal in the call was that we might relax the "group" containment requirement (radio group/tabgroup etc) if we had an ad hoc group UID (but not necessarily tied to an actual DOM element), similar to the way the name attribute is used on <input type="radio">

[scottaohara]

simply linking the example and the issue i had previously filed to help with the same example - https://github.com/w3c/aria/issues/1721