WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Using aria-describedby as aria-controls hack

for

From: Robert Fentress
Date: Nov 21, 2014 2:43PM

I like the label suggestion, Birkir, as it is probably more robust.
However, I think one thing to consider in your example is that you
wouldn't want to include aria-controls *and* the label text. If, for
instance, the user accessed the button on JAWS/Firefox, they would
have read to them both the JAWS message *and* the label text, which
would be confusing.

This raises a larger issue. Ideally, you would want to do feature
detection to determine if a screen reader/browser supported a
particular property and provide the shim conditionally. That way, you
could still use the "proper" semantics on browsers that support it.
There isn't any way to do this now, that I'm aware of.

Best,
Rob

On Fri, Nov 21, 2014 at 2:05 PM, Birkir R. Gunnarsson
< <EMAIL REMOVED> > wrote:
> 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.
> > > --
Robert Fentress
Senior Accessibility Solutions Designer
540.231.1255

Technology-enhanced Learning & Online Strategies
Assistive Technologies
1180 Torgersen Hall
620 Drillfield Drive (0434)
Blacksburg, Virginia 24061