RE: ARIA and communicating dynamic content updates

Use https://www.w3.org/TR/wai-aria/complete#aria-controls.

Best Regards
Stefan

From: Birkir Gunnarsson [mailto:birkir.gunnarsson@deque.com]
Sent: Donnerstag, 10. März 2016 19:46
To: 'ARIA Working Group' <public-aria@w3.org>
Subject: ARIA and communicating dynamic content updates

Greetings

Recently I have been dealing with a number of dynamic forms where selecting a radiobutton or checking a checkbox reveals additional content.
I have been asked numerous times how to make that information available to screen readers.
When the content contains focusable elements, and when it is placed in focus order after its triggering element, one may claim additional markup is not necessarily needed.
http://a11yideas.com/testcode/checkboxContent_before.html
(though it would still provide better screen reader user experience to know when the activation of a control triggers display of content).

But when the new content is text only screen reader users can easily miss it, if they are operating in forms mode.
Sighted users are made aware of it, it appears on the screen.

Aria-describedby is one solution, but it only works for short and simple texts without structure. Also aria-describedby does not indicate whether the element is visible on the page or not.
aria-controls is part of a solution, but it is not specific enough, and is only available to screen reader users when the content is visible on-screen.
I have been recommending a combination of aria-controls and live regions, but it feels very "hacky".

Re-enter aria-expanded
We recommend use of aria-expanded in patterns such as our accordion pattern to indicate to users that element controls the display of page content and to indicate whether such content is visible (aria-expanded="true") or not (aria-expanded="false").
In the accordion pattern it is recommended that we place the aria-expanded attribute on the triggering element to indicate the availability and display status of dynamic content, and aria-controls to show the exact element relationship (unless the displayed content is inline with the triggering element). This is relatively easy to code and gives screen readers a very clear picture of what is happening on the page.
It seems logical to allow the same combination of attributes on other elements that, when triggered, cause dynamic content to appear on a webpage.

All checkboxes and radiobuttons can be checked, but only a minority trigger display of additional content when checked.
The checked/aria-checked property alone is not enough to communicate that information.

If aria-expanded is not a viable solution for this, do we need an additional ARIA attribute to account for this situation, something along the lines of aria-hascontent or aria-displayscontent?
This is an increasingly common real-world situation, and I think ARIA should have an answer for that.

Thanks
-Birkir