Tri-State Checkbox Example: clarify usage of aria-controls

[jscholes]

Copying from w3c/aria#1352

In the Tri-State Checkbox Example, aria-controls is applied to the "All condiments" checkbox, with a value referencing all four IDs of the individual condiment two-state checkboxes. This is programmatically correct, but:

• aria-controls usage isn't mentioned anywhere within the Checkbox design pattern; and
• as covered in What to do about aria-controls aria#995, there is still no consensus about how aria-controls should be surfaced by assistive technology. Indeed, the previous surfacing by JAWS (now silenced by default) didn't take multiple IDREFs into account.

Given the above, should aria-controls usage be added to the "WAI-ARIA Roles, States, and Properties" section of the Checkbox design pattern? And for the purposes of ARIA-AT testing (ref: w3c/aria-at#322), my belief is that no assertions can be included as of the time of filing, because there is no meaningful understanding of how to surface the information.

[mcking65]

@jscholes commented:

Given the above, should aria-controls usage be added to the "WAI-ARIA Roles, States, and Properties" section of the Checkbox design pattern?

I don't think so. aria-controls does not inherently fit into the checkbox design pattern. If we added it there, we'd need to add aria-controls to the pattern for any role that supports it, e.g., button. Instead, we include it in a pattern where we think it should be part of the pattern, e.g., disclosure.

And for the purposes of ARIA-AT testing (ref: w3c/aria-at#322), my belief is that no assertions can be included as of the time of filing, because there is no meaningful understanding of how to surface the information.

Exactly right -- I don't think it is appropriate to make screen reader behavior assertions at this time, probably not even optional ones. We need to resolve w3c/aria#995 first.

[jscholes]

aria-controls does not inherently fit into the checkbox design pattern. If we added it there, we'd need to add aria-controls to the pattern for any role that supports it, e.g., button. Instead, we include it in a pattern where we think it should be part of the pattern, e.g., disclosure.

I'm worried that this creates inconsistencies between the pattern as described within the APG and the examples, potentially leaving web authors in some doubt about whether they should use certain attributes or not. However, I'm satisfied that for now, aria-controls isn't directly in scope for ARIA-AT testing which addresses my most pressing concern.