WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Using aria-describedby as aria-controls hack

for

From: Birkir R. Gunnarsson
Date: Nov 21, 2014 12:05PM

Hi

I would rather implement this as a tooltip (aria-describedby pointing
to the helptext is inserted when user puts focus on the element and
removed when user moves focus away from it.
This is info the users will only need in interactive mode, so tying it
to the onFocus/onBlur would give them that info if they need it rather
than tie it statically to the text at all times.
Of course you could also just move the user focus to the content if
user activates the button.

If you still want to go with the latter, you wouldn't need
aria-describedby, just add additional off-screen text to the label
<button id="addinfo" aria-controls="myinfopanel">Add information <span
id="visually hidden text">press ctrl-shift-4 to jump straight to the
information</span></button>
Keep in mind that a keyboard only user may want this convenience as
well so making this a visible tooltip might benefit a larger group of
users.

Usually expandable/collapsible sections (accordions) are implemented
so that the control that toggles it is inline to that content.
tabs are a different matter, and the ARIA authoring guide in fact
recommends hotkeys for moving between the visible tabpanel and the
tabs, so you are on the right track there.

Please make sure to file issues with NVDA (their issue tracker is
public and developers are very responsive), Apple
( <EMAIL REMOVED> ) and, if required, browser manufacturers.
It takes a lot of energy , and is intensely annoying, but if we do not
complain to the right people we will not get the solutions we want.
I feel your pain, and I will try to follow my own example and file
issues myself.
Cheers



On 11/21/14, Hugh B. Ristić < <EMAIL REMOVED> > wrote:
> Dear Knowledgable People,
>
> I would like to use the *aria-controls* property to provide an affordance
> for users accessing a page with a screen reader to be able to optionally
> set focus to a controlled element in response to the user initiating a
> keyboard command. My understanding, based on this article on Juicy Studio
> (
> http://juicystudio.com/article/aria-controls-lack-support.php) and personal
> experimentation, is that the only browser/screen reader combination that
> supports this currently is Firefox/JAWS, which announces "Press JAWS key +
> ALT + M to move to controlled element". Of course, this is a real pain,
> since this would be incredibly useful functionality for today's rich
> internet applications, if it were better supported.
>
> My question is if it would be appropriate to create a shim of sorts to
> approximate this behavior using JavaScript and *aria-describedby*, since
> this property is better supported. Basically the pattern would be as
> follows:
>
> - An attribute, *data-aria-controls*, with its value set to the ID of
> the controlled element, would be attached to a control in the HTML.
> - On page load, a script would apply the *aria-describedby* property to
> any controls that had the *data-aria-controls *attribute, with the value
> of the property set to the ID of an element that contained the string,
> "Press CTRL + CMD + ALT + M to move to controlled element"
> - With focus on a control element, pressing the key command would shift
> focus to the controlled element.
> - You could provide the screen reader user the ability to turn off the
> *aria-describedby* cues if they wanted, once they got familiar with the
> application.
>
> I hate to use a hack like this, but with such limited support and such a
> pressing need, it seems like it might work as a solution. Once screen
> reader support reached the needed threshold, one could simply modify the
> code library to ditch the *aria-describedby* hack and, instead have it
> replace any instances of *data-aria-controls* with *aria-controls*.
>
> What do you think?
>
> -Hugh
> > > >


--
Work hard. Have fun. Make history.