Conditional reveal aria-controls attribute added with JS

[adamsilver]

Currently, the aria-controls attribute is added during JS initialisation.

My thinking is that the attribute should be in the HTML regardless.

This way when a screen reader user focuses the radio button (or checkbox) they will be able to move to the controlled panel using additional shortcuts.

[kr8n3r]

related: https://developer.paciellogroup.com/blog/2018/06/short-note-on-progressive-aria/

But when ARIA is hard-coded into HTML it can have unintended consequences if/when the JavaScript fails to deliver the expected functionality.

[joshueoconnor]

+1 to @adamsilver

Actually AFAIK, the use of these kinds of ARIA attributes/properties is not JavaScript dependent at all but on support within the user agent (whether browser or AT). The points that Leonie makes on the blog post above are where JS is used as the delivery mechanism for 'some useful ARIA thing that makes something more accessible' - which is of course, important.

[NickColley]

https://www.w3.org/WAI/PF/aria-1.1/states_and_properties#aria-controls

Identifies the element (or elements) whose contents or presence are controlled by the current element.

We use aria-controls on these elements to enhance aria-expanded, which is not an allowed attribute for checkboxes and radio buttons.

So I think really it's perhaps a bit of a stretch to use aria-controls in a scenario where the content is static.

For pragmatic reasons adding this the to markup when we're considering removing aria-controls and aria-expanded would mean we'd have to make a breaking change in the future.

Finally, assistive technologies have limited support for this attribute when used on these elements.

So with all this in mind I'll close this out for now but if something changes and we do not decide to remove these attributes then we can reconsider this.

Thank you for raising. :)