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 4:37PM

Rob

I definitely see what you are saying.
But since there is a very strong anti-assistive technology detection
centiment out there, I think such a feature detection will not be
possible.
After all, that would really be a lot more complex and unreliable than
the vendors just upgrading their product in the first place to take
advantage of the semantic relationships offered through ARIA-compliant
code.

So, yes, for Jaws users with Firefox this would be overly verbose. But
it might greatly benefit a lot of other users.
It is a tricky situation, and one would always have to see the actual
page in question to make a more educated or informed suggestions.
Nevertheless, these are fun little brain teasers and I like to see the
real world problems.



On 11/21/14, Robert Fentress < <EMAIL REMOVED> > wrote:
> 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
> > > >


--
Work hard. Have fun. Make history.