Resolve "ARIA required context role" survey comments

[maryjom]

Rule: ARIA required context role
Survey results
Survey discussions: 7 January meeting.
Reference to Issue 499 introducing this as a new rule.

Comments from survey:

Detlev Fischer

• I struggle understanding Passed example 6 and Failed example 4 but I trust they are alright :)'
• The stated patchy support of aria-owns makes me wonder how useful this rule will currently be in practice.

Kathy Eng

• Should the ARIA spec be cited as an accessibility requirement?
• Please provide further explanation of Background: The definition of owned by used in this rule is different from the definition of "owned element" in WAI-ARIA.
• why was it necessary to create a definition?
• Seems like the WAI-ARIA "owned element" definition is broader (any DOM descendant), so failing the narrower definition of this rule would not necessarily fail 1.3.1.
• Owned Element: An 'owned element' is any DOM descendant of the element, any element specified as a child via aria-owns, or any DOM descendant of the owned child.

Mary Jo Mueller

• Does the inconsistency in the definition of "owned element" with the ARIA spec cause concern? This is a normative definition in the ARIA spec. It would be better if the scope is to be narrowed, that would be stated in the applicability, not as a new definition.

[JAWS-test]

Example 5 seems unfortunate to me, since it contains a non-valid nesting of navigation within list. This has nothing to do with the rule itself, but should at least be mentioned

[Jym77]

Updated in act-rules/act-rules.github.io#1554

The main concern seems to be about the "owned by" definition. Since it is actually fairly easy (at least ours), I've directly inlined it and replaced by "[is] a child in the accessibility tree". That should remove the confusion with the ARIA definition.

Note that the ARIA definition is itself under discussion (w3c/aria#748) and may end up close to what we do (direct children only, not further descendants) which is the reason why we chose to stray away in the start.

As for the other comments:

• @detlevhfischer the examples with Shadow DOM are always a bit hard to read 😅 The easiest way might be to open the example in a new tab (e.g. https://act-rules.github.io/testcases/ff89c9/b86943f7a563dbd10ea493ce437ae7ea9a572119.html) and then use the devtools/inspector to look at the DOM, most browser have an option to show both the shadow tree and the accessibility tree. Here are screenshots of the Passed and Failed example showing the list items as children or not of the list (sorry for only screenshooting, actual copy/paste from devtools is a bit tricky sometimes)

• @kengdoj we can't map to ARIA requirements due to the discrepancy around the definition of "owned by".

<div role="list">
  <div aria-label="foo">
    <div role="listitem">Item 1</div>
    <div role="listitem">Item 2</div>
  </div>
</div>

This is currently allowed by ARIA: the listitem are "owned by" the list (because "owned by" consider any ancestor). But this fails the rule: the listitem are not children of th list.
Since we can fail the rule without "failing" ARIA, we can't have a mapping…
This is typically the kind of case we want to catch (the list is not announced correctly), and the reason why the definition of "owned by" in ARIA is a bit flaky and under discussion…

• @JAWS-test I think that example is OK-ish. This is correct HTML (roles are ignored). This is correct ARIA and AT experience (the aria-owns attribute skips over the intermediate element). It is not clear that the navigation role is forbidden inside a list (because the definition of "required owned elements" is even more flaky than the definition of "owned by", and their interaction makes things even worse… see also Clarify "required owned element" aria#1033)