E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 4 (In chronological order)

From: Hugh B. Ristić
Date: Fri, Nov 21 2014 9:15AM
Subject: Using aria-describedby as aria-controls hack
No previous message | Next message →

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

From: Birkir R. Gunnarsson
Date: Fri, Nov 21 2014 12:05PM
Subject: Re: Using aria-describedby as aria-controls hack
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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.

From: Robert Fentress
Date: Fri, Nov 21 2014 2:43PM
Subject: Re: Using aria-describedby as aria-controls hack
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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

From: Birkir R. Gunnarsson
Date: Fri, Nov 21 2014 4:37PM
Subject: Re: Using aria-describedby as aria-controls hack
← Previous message | No next message

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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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.