W3C home > Mailing lists > Public > public-aria@w3.org > March 2016

ARIA and communicating dynamic content updates

From: Birkir Gunnarsson <birkir.gunnarsson@deque.com>
Date: Thu, 10 Mar 2016 13:45:48 -0500
To: "'ARIA Working Group'" <public-aria@w3.org>
Message-ID: <007801d17afd$1124e440$336eacc0$@deque.com>


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.


(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

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


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.






Received on Thursday, 10 March 2016 18:46:17 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:23:20 UTC