E-mail List Archives
Thread: Using aria-selected=true on any HTML element?
Number of posts in this thread: 13 (In chronological order)
From: Paul J. Adam
Date: Tue, Aug 21 2012 1:36PM
Subject: Using aria-selected=true on any HTML element?
No previous message | Next message →
The WAI-ARIA spec states that the aria-selected state is only used in roles gridcell, option, row, and tab. <http://www.w3.org/TR/wai-aria/states_and_properties#aria-selected>;
Is it bad to use aria-selected=true on a HTML widget with a selected state that does not fall into one of these roles? Like a list item or link?
If aria selected should not be used on links or list items then how would you communicate state to a screen reader? Visually hidden text? Title attribute?
Adding aria-selected to a HTML element does cause VoiceOver to speak the text "selected" even if it's not one of the supported roles.
Thoughts?
Paul J. Adam
Accessibility Evangelist
Deque Systems
= EMAIL ADDRESS REMOVED =
www.PaulJAdam.com
@pauljadam on Twitter
From: Steve Faulkner
Date: Tue, Aug 21 2012 1:59PM
Subject: Re: Using aria-selected=true on any HTML element?
← Previous message | Next message →
hi Paul,
>> Adding aria-selected to a HTML element does cause VoiceOver to speak the text "selected" even if it's not one of the supported roles.
this may work for voiceover but may well not work for other AT will check
this related thread on WAI-xtech may be of interest:
http://lists.w3.org/Archives/Public/wai-xtech/2012Jul/0006.html
regards
SteveF
On 21 August 2012 20:36, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
> The WAI-ARIA spec states that the aria-selected state is only used in roles gridcell, option, row, and tab. <http://www.w3.org/TR/wai-aria/states_and_properties#aria-selected>;
>
> Is it bad to use aria-selected=true on a HTML widget with a selected state that does not fall into one of these roles? Like a list item or link?
>
> If aria selected should not be used on links or list items then how would you communicate state to a screen reader? Visually hidden text? Title attribute?
>
> Adding aria-selected to a HTML element does cause VoiceOver to speak the text "selected" even if it's not one of the supported roles.
>
> Thoughts?
>
> Paul J. Adam
> Accessibility Evangelist
> Deque Systems
> = EMAIL ADDRESS REMOVED =
> www.PaulJAdam.com
> @pauljadam on Twitter
>
> > > --
with regards
Steve Faulkner
Technical Director - TPG
www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
From: Paul J. Adam
Date: Tue, Aug 21 2012 4:17PM
Subject: Re: Using aria-selected=true on any HTML element?
← Previous message | Next message →
Hey Steve, thanks for the reply. I do agree with your linked suggestion to allow aria-selected state on any focusable element. It also would be great if any of the ARIA states could be applied to focusable elements.
I made a quick test case with three aria- states applied to links, list items, and buttons. No support with JAWS. NVDA only supports on IE latest. Expanded has better support than selected and pressed does not have any support other than JAWS saying it's a toggle button.
<http://pauljadam.com/demos/aria/aria-selected.html>;
So is it unwise to recommend aria to convey state of JavaScript widgets if it has support only in certain browsers & AT?
Instead should I recommend conveying state with visually hidden text? Or title attributes? Or placing the state as an alt attribute in an image if present in the widget?
Can you say that a widget is not accessible if it only relies on aria states?
Paul J. Adam
Accessibility Evangelist
Deque Systems
= EMAIL ADDRESS REMOVED =
www.PaulJAdam.com
@pauljadam on Twitter
On Aug 21, 2012, at 2:59 PM, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:
> hi Paul,
>
>>> Adding aria-selected to a HTML element does cause VoiceOver to speak the text "selected" even if it's not one of the supported roles.
>
> this may work for voiceover but may well not work for other AT will check
>
> this related thread on WAI-xtech may be of interest:
> http://lists.w3.org/Archives/Public/wai-xtech/2012Jul/0006.html
>
>
> regards
> SteveF
>
> On 21 August 2012 20:36, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>> The WAI-ARIA spec states that the aria-selected state is only used in roles gridcell, option, row, and tab. <http://www.w3.org/TR/wai-aria/states_and_properties#aria-selected>;
>>
>> Is it bad to use aria-selected=true on a HTML widget with a selected state that does not fall into one of these roles? Like a list item or link?
>>
>> If aria selected should not be used on links or list items then how would you communicate state to a screen reader? Visually hidden text? Title attribute?
>>
>> Adding aria-selected to a HTML element does cause VoiceOver to speak the text "selected" even if it's not one of the supported roles.
>>
>> Thoughts?
>>
>> Paul J. Adam
>> Accessibility Evangelist
>> Deque Systems
>> = EMAIL ADDRESS REMOVED =
>> www.PaulJAdam.com
>> @pauljadam on Twitter
>>
>> >> >> >
>
>
> --
> with regards
>
> Steve Faulkner
> Technical Director - TPG
>
> www.paciellogroup.com | www.HTML5accessibility.com |
> www.twitter.com/stevefaulkner
> HTML5: Techniques for providing useful text alternatives -
> dev.w3.org/html5/alt-techniques/
> Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
> > >
From: Brendan McKeon
Date: Tue, Aug 21 2012 10:07PM
Subject: Re: Using aria-selected=true on any HTML element?
← Previous message | Next message →
I'm wondering if there's also an issue with UI terminology... The term
casual English term 'selected' can have different meanings depending on
context; and aria-selected is appropriate for only one of those. For
example, "selected text" is a different concept than "selected items"; the
phrase "select a link" or "select the main menu item" really refers to
activation or perhaps focus. Similarly, the phrase "list item" could refer
to either a (usually) non-interactive bulleted LI tag, or an interactive
selectable item in a list box, which is an OPTION tag within a SELECT.
Aria-select is generally reserved for the purpose of indicating that one
element, among several similar siblings, is in such a state that it
represents the current value of the overall container control. So you can
have a selected list item within a listbox; the selected tab within a tab
control, and so on. That's really the key meaning behind the aria-selected
attribute; it's not simply a way to cause the screenreader to read out the
text "selected", it's implying more about the structure and context of the
element also.
I'm wondering if you could give more details about your UI examples, to see
if they match this model, or if there's really something else going on. Do
these cases feature a parent container, for example? Does clicking on or
moving focus to the element in question select it, or cause something else
to happen? Are they single-select or multiple-select? Do the items remain
selected when focus is moved to a different control?
Note that by default, LI and OPTION tags are associated with ARIA roles
listitem and option respectively. When those are in turn exposed through
accessibility APIs, both end up with the same role as "listitem", but other
properties will indicate to the user that the former is read-only or
non-interactive, while the latter is a forms-style selectable or interactive
UI component. So if you have some LI tags that you've marked up and attached
javascript to in order to make them behave like listbox elements, then
role=option would be appropriate to indicate this (would also need an
appropriate role on the container element also), and then aria-selected
would be fine.
Brendan.
From: Brendan McKeon
Date: Tue, Aug 21 2012 11:07PM
Subject: Re: Using aria-selected=true on any HTML element?
← Previous message | Next message →
Scratch that, been doing too much stuff with listboxes today, so everything
I see is a listbox... you're talking about a breadcrumb bar, or page
navigation menu or tabs or something similar here?
These would seem to be a good match for tabs, but that doesn't work out well
in practice. Bryan Garaventa has an article outlining the problems with this
at the following link, and suggests offscreen text as best option for now:
http://www.linkedin.com/groups/Why-you-should-not-use-4512178.S.134719297
Brendan.
From: Elle
Date: Wed, Aug 22 2012 5:54AM
Subject: Re: Using aria-selected=true on any HTML element?
← Previous message | Next message →
Paul:
We often use visually hidden text to convey state for most JavaScript
widgets, because neither title attributes nor ARIA are a guarantee that
every AT user will get that information.
Hope that helps,
Elle
On Tue, Aug 21, 2012 at 6:17 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
> Hey Steve, thanks for the reply. I do agree with your linked suggestion to
> allow aria-selected state on any focusable element. It also would be great
> if any of the ARIA states could be applied to focusable elements.
>
> I made a quick test case with three aria- states applied to links, list
> items, and buttons. No support with JAWS. NVDA only supports on IE latest.
> Expanded has better support than selected and pressed does not have any
> support other than JAWS saying it's a toggle button.
>
> <http://pauljadam.com/demos/aria/aria-selected.html>;
>
> So is it unwise to recommend aria to convey state of JavaScript widgets if
> it has support only in certain browsers & AT?
>
> Instead should I recommend conveying state with visually hidden text? Or
> title attributes? Or placing the state as an alt attribute in an image if
> present in the widget?
>
> Can you say that a widget is not accessible if it only relies on aria
> states?
>
> Paul J. Adam
> Accessibility Evangelist
> Deque Systems
> = EMAIL ADDRESS REMOVED =
> www.PaulJAdam.com
> @pauljadam on Twitter
>
> On Aug 21, 2012, at 2:59 PM, Steve Faulkner < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > hi Paul,
> >
> >>> Adding aria-selected to a HTML element does cause VoiceOver to speak
> the text "selected" even if it's not one of the supported roles.
> >
> > this may work for voiceover but may well not work for other AT will check
> >
> > this related thread on WAI-xtech may be of interest:
> > http://lists.w3.org/Archives/Public/wai-xtech/2012Jul/0006.html
> >
> >
> > regards
> > SteveF
> >
> > On 21 August 2012 20:36, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
> >> The WAI-ARIA spec states that the aria-selected state is only used in
> roles gridcell, option, row, and tab. <
> http://www.w3.org/TR/wai-aria/states_and_properties#aria-selected>;
> >>
> >> Is it bad to use aria-selected=true on a HTML widget with a selected
> state that does not fall into one of these roles? Like a list item or link?
> >>
> >> If aria selected should not be used on links or list items then how
> would you communicate state to a screen reader? Visually hidden text? Title
> attribute?
> >>
> >> Adding aria-selected to a HTML element does cause VoiceOver to speak
> the text "selected" even if it's not one of the supported roles.
> >>
> >> Thoughts?
> >>
> >> Paul J. Adam
> >> Accessibility Evangelist
> >> Deque Systems
> >> = EMAIL ADDRESS REMOVED =
> >> www.PaulJAdam.com
> >> @pauljadam on Twitter
> >>
> >> > >> > >> > >
> >
> >
> > --
> > with regards
> >
> > Steve Faulkner
> > Technical Director - TPG
> >
> > www.paciellogroup.com | www.HTML5accessibility.com |
> > www.twitter.com/stevefaulkner
> > HTML5: Techniques for providing useful text alternatives -
> > dev.w3.org/html5/alt-techniques/
> > Web Accessibility Toolbar -
> www.paciellogroup.com/resources/wat-ie-about.html
> > > > > > >
> > > >
--
If you want to build a ship, don't drum up the people to gather wood,
divide the work, and give orders. Instead, teach them to yearn for the vast
and endless sea.
- Antoine De Saint-Exupéry, The Little Prince
From: Paul J. Adam
Date: Wed, Aug 22 2012 9:55AM
Subject: Re: Using aria-selected=true on any HTML element?
← Previous message | Next message →
Thank you Elle and Brendan for the feedback! Most of these JS widgets I'm talking about are loading in new content or filtering content using AJAX. I could assign role=tab to most of them and that would increase the AT/Browser support, but it still won't work in all 5 combinations I'm testing.
I reworked my test case to add role=tab, title attributes, and visually hidden text. <http://pauljadam.com/demos/aria/aria-selected.html>;
Titles are not read automatically in VoiceOver or JAWS. ARIA expanded has great support but aria-selected does not.
My dilemma is: why should I recommend using aria-expanded to convey state even though it has great support in all 5 combinations when aria-selected does not?
It would likely be confusing to recommend developers to use aria-expanded for expanded state but use visually hidden text for selected state.
I'd really love to use aria states for everything because they make so much sense to me semantically but I guess that's just not possible.
It looks like using the old school visually hidden text is the only way to convey all possible states to all possible AT/browser combinations.
Paul J. Adam
Accessibility Evangelist
Deque Systems
= EMAIL ADDRESS REMOVED =
www.PaulJAdam.com
@pauljadam on Twitter
On Aug 22, 2012, at 6:54 AM, Elle < = EMAIL ADDRESS REMOVED = > wrote:
> Paul:
>
> We often use visually hidden text to convey state for most JavaScript
> widgets, because neither title attributes nor ARIA are a guarantee that
> every AT user will get that information.
>
>
> Hope that helps,
> Elle
>
>
>
>
> On Tue, Aug 21, 2012 at 6:17 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Hey Steve, thanks for the reply. I do agree with your linked suggestion to
>> allow aria-selected state on any focusable element. It also would be great
>> if any of the ARIA states could be applied to focusable elements.
>>
>> I made a quick test case with three aria- states applied to links, list
>> items, and buttons. No support with JAWS. NVDA only supports on IE latest.
>> Expanded has better support than selected and pressed does not have any
>> support other than JAWS saying it's a toggle button.
>>
>> <http://pauljadam.com/demos/aria/aria-selected.html>;
>>
>> So is it unwise to recommend aria to convey state of JavaScript widgets if
>> it has support only in certain browsers & AT?
>>
>> Instead should I recommend conveying state with visually hidden text? Or
>> title attributes? Or placing the state as an alt attribute in an image if
>> present in the widget?
>>
>> Can you say that a widget is not accessible if it only relies on aria
>> states?
>>
>> Paul J. Adam
>> Accessibility Evangelist
>> Deque Systems
>> = EMAIL ADDRESS REMOVED =
>> www.PaulJAdam.com
>> @pauljadam on Twitter
>>
>> On Aug 21, 2012, at 2:59 PM, Steve Faulkner < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>>> hi Paul,
>>>
>>>>> Adding aria-selected to a HTML element does cause VoiceOver to speak
>> the text "selected" even if it's not one of the supported roles.
>>>
>>> this may work for voiceover but may well not work for other AT will check
>>>
>>> this related thread on WAI-xtech may be of interest:
>>> http://lists.w3.org/Archives/Public/wai-xtech/2012Jul/0006.html
>>>
>>>
>>> regards
>>> SteveF
>>>
>>> On 21 August 2012 20:36, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>>>> The WAI-ARIA spec states that the aria-selected state is only used in
>> roles gridcell, option, row, and tab. <
>> http://www.w3.org/TR/wai-aria/states_and_properties#aria-selected>;
>>>>
>>>> Is it bad to use aria-selected=true on a HTML widget with a selected
>> state that does not fall into one of these roles? Like a list item or link?
>>>>
>>>> If aria selected should not be used on links or list items then how
>> would you communicate state to a screen reader? Visually hidden text? Title
>> attribute?
>>>>
>>>> Adding aria-selected to a HTML element does cause VoiceOver to speak
>> the text "selected" even if it's not one of the supported roles.
>>>>
>>>> Thoughts?
>>>>
>>>> Paul J. Adam
>>>> Accessibility Evangelist
>>>> Deque Systems
>>>> = EMAIL ADDRESS REMOVED =
>>>> www.PaulJAdam.com
>>>> @pauljadam on Twitter
>>>>
>>>> >>>> >>>> >>>
>>>
>>>
>>> --
>>> with regards
>>>
>>> Steve Faulkner
>>> Technical Director - TPG
>>>
>>> www.paciellogroup.com | www.HTML5accessibility.com |
>>> www.twitter.com/stevefaulkner
>>> HTML5: Techniques for providing useful text alternatives -
>>> dev.w3.org/html5/alt-techniques/
>>> Web Accessibility Toolbar -
>> www.paciellogroup.com/resources/wat-ie-about.html
>>> >>> >>> >>
>> >> >> >>
>
>
>
> --
> If you want to build a ship, don't drum up the people to gather wood,
> divide the work, and give orders. Instead, teach them to yearn for the vast
> and endless sea.
> - Antoine De Saint-Exupéry, The Little Prince
> > >
From: Bryan Garaventa
Date: Wed, Aug 22 2012 10:24AM
Subject: Re: Using aria-selected=true on any HTML element?
← Previous message | Next message →
One thing about role=tab, which I described in the article Brendan
mentioned, is that if you are using JAWS13 and IE, and you arrow to a point
just before the ARIA tabs, then press Tab, it will manually activate the
link and navigate to a page that doesn't exist.
Pressing Alt+Leftarrow after doing this will then say that the focused tab
is now selected, which will occur even when there is no aria-selected
attribute present in the markup.
I'm seeing this in IE8, but it will likely do the same in 9.
----- Original Message -----
From: "Paul J. Adam" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Wednesday, August 22, 2012 8:55 AM
Subject: Re: [WebAIM] Using aria-selected=true on any HTML element?
Thank you Elle and Brendan for the feedback! Most of these JS widgets I'm
talking about are loading in new content or filtering content using AJAX. I
could assign role=tab to most of them and that would increase the AT/Browser
support, but it still won't work in all 5 combinations I'm testing.
I reworked my test case to add role=tab, title attributes, and visually
hidden text. <http://pauljadam.com/demos/aria/aria-selected.html>;
Titles are not read automatically in VoiceOver or JAWS. ARIA expanded has
great support but aria-selected does not.
My dilemma is: why should I recommend using aria-expanded to convey state
even though it has great support in all 5 combinations when aria-selected
does not?
It would likely be confusing to recommend developers to use aria-expanded
for expanded state but use visually hidden text for selected state.
I'd really love to use aria states for everything because they make so much
sense to me semantically but I guess that's just not possible.
It looks like using the old school visually hidden text is the only way to
convey all possible states to all possible AT/browser combinations.
Paul J. Adam
Accessibility Evangelist
Deque Systems
= EMAIL ADDRESS REMOVED =
www.PaulJAdam.com
@pauljadam on Twitter
On Aug 22, 2012, at 6:54 AM, Elle < = EMAIL ADDRESS REMOVED = > wrote:
> Paul:
>
> We often use visually hidden text to convey state for most JavaScript
> widgets, because neither title attributes nor ARIA are a guarantee that
> every AT user will get that information.
>
>
> Hope that helps,
> Elle
>
>
>
>
> On Tue, Aug 21, 2012 at 6:17 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Hey Steve, thanks for the reply. I do agree with your linked suggestion
>> to
>> allow aria-selected state on any focusable element. It also would be
>> great
>> if any of the ARIA states could be applied to focusable elements.
>>
>> I made a quick test case with three aria- states applied to links, list
>> items, and buttons. No support with JAWS. NVDA only supports on IE
>> latest.
>> Expanded has better support than selected and pressed does not have any
>> support other than JAWS saying it's a toggle button.
>>
>> <http://pauljadam.com/demos/aria/aria-selected.html>;
>>
>> So is it unwise to recommend aria to convey state of JavaScript widgets
>> if
>> it has support only in certain browsers & AT?
>>
>> Instead should I recommend conveying state with visually hidden text? Or
>> title attributes? Or placing the state as an alt attribute in an image if
>> present in the widget?
>>
>> Can you say that a widget is not accessible if it only relies on aria
>> states?
>>
>> Paul J. Adam
>> Accessibility Evangelist
>> Deque Systems
>> = EMAIL ADDRESS REMOVED =
>> www.PaulJAdam.com
>> @pauljadam on Twitter
>>
>> On Aug 21, 2012, at 2:59 PM, Steve Faulkner < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>>> hi Paul,
>>>
>>>>> Adding aria-selected to a HTML element does cause VoiceOver to speak
>> the text "selected" even if it's not one of the supported roles.
>>>
>>> this may work for voiceover but may well not work for other AT will
>>> check
>>>
>>> this related thread on WAI-xtech may be of interest:
>>> http://lists.w3.org/Archives/Public/wai-xtech/2012Jul/0006.html
>>>
>>>
>>> regards
>>> SteveF
>>>
>>> On 21 August 2012 20:36, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>>>> The WAI-ARIA spec states that the aria-selected state is only used in
>> roles gridcell, option, row, and tab. <
>> http://www.w3.org/TR/wai-aria/states_and_properties#aria-selected>;
>>>>
>>>> Is it bad to use aria-selected=true on a HTML widget with a selected
>> state that does not fall into one of these roles? Like a list item or
>> link?
>>>>
>>>> If aria selected should not be used on links or list items then how
>> would you communicate state to a screen reader? Visually hidden text?
>> Title
>> attribute?
>>>>
>>>> Adding aria-selected to a HTML element does cause VoiceOver to speak
>> the text "selected" even if it's not one of the supported roles.
>>>>
>>>> Thoughts?
>>>>
>>>> Paul J. Adam
>>>> Accessibility Evangelist
>>>> Deque Systems
>>>> = EMAIL ADDRESS REMOVED =
>>>> www.PaulJAdam.com
>>>> @pauljadam on Twitter
>>>>
>>>> >>>> >>>> >>>
>>>
>>>
>>> --
>>> with regards
>>>
>>> Steve Faulkner
>>> Technical Director - TPG
>>>
>>> www.paciellogroup.com | www.HTML5accessibility.com |
>>> www.twitter.com/stevefaulkner
>>> HTML5: Techniques for providing useful text alternatives -
>>> dev.w3.org/html5/alt-techniques/
>>> Web Accessibility Toolbar -
>> www.paciellogroup.com/resources/wat-ie-about.html
>>> >>> >>> >>
>> >> >> >>
>
>
>
> --
> If you want to build a ship, don't drum up the people to gather wood,
> divide the work, and give orders. Instead, teach them to yearn for the
> vast
> and endless sea.
> - Antoine De Saint-Exupéry, The Little Prince
> > >
From: Paul J. Adam
Date: Wed, Aug 22 2012 10:38AM
Subject: Re: Using aria-selected=true on any HTML element?
← Previous message | Next message →
Hey Bryan, yes I did see that problem in my test case where JAWS and IE kept sending me to the link's URL. It popped up a crash error as well but did not really crash.
Paul J. Adam
Accessibility Evangelist
Deque Systems
= EMAIL ADDRESS REMOVED =
www.PaulJAdam.com
@pauljadam on Twitter
On Aug 22, 2012, at 11:24 AM, "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = > wrote:
> One thing about role=tab, which I described in the article Brendan
> mentioned, is that if you are using JAWS13 and IE, and you arrow to a point
> just before the ARIA tabs, then press Tab, it will manually activate the
> link and navigate to a page that doesn't exist.
>
> Pressing Alt+Leftarrow after doing this will then say that the focused tab
> is now selected, which will occur even when there is no aria-selected
> attribute present in the markup.
>
> I'm seeing this in IE8, but it will likely do the same in 9.
>
> ----- Original Message -----
> From: "Paul J. Adam" < = EMAIL ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> Sent: Wednesday, August 22, 2012 8:55 AM
> Subject: Re: [WebAIM] Using aria-selected=true on any HTML element?
>
>
> Thank you Elle and Brendan for the feedback! Most of these JS widgets I'm
> talking about are loading in new content or filtering content using AJAX. I
> could assign role=tab to most of them and that would increase the AT/Browser
> support, but it still won't work in all 5 combinations I'm testing.
>
> I reworked my test case to add role=tab, title attributes, and visually
> hidden text. <http://pauljadam.com/demos/aria/aria-selected.html>;
>
> Titles are not read automatically in VoiceOver or JAWS. ARIA expanded has
> great support but aria-selected does not.
>
> My dilemma is: why should I recommend using aria-expanded to convey state
> even though it has great support in all 5 combinations when aria-selected
> does not?
>
> It would likely be confusing to recommend developers to use aria-expanded
> for expanded state but use visually hidden text for selected state.
>
> I'd really love to use aria states for everything because they make so much
> sense to me semantically but I guess that's just not possible.
>
> It looks like using the old school visually hidden text is the only way to
> convey all possible states to all possible AT/browser combinations.
>
> Paul J. Adam
> Accessibility Evangelist
> Deque Systems
> = EMAIL ADDRESS REMOVED =
> www.PaulJAdam.com
> @pauljadam on Twitter
>
> On Aug 22, 2012, at 6:54 AM, Elle < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Paul:
>>
>> We often use visually hidden text to convey state for most JavaScript
>> widgets, because neither title attributes nor ARIA are a guarantee that
>> every AT user will get that information.
>>
>>
>> Hope that helps,
>> Elle
>>
>>
>>
>>
>> On Tue, Aug 21, 2012 at 6:17 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> Hey Steve, thanks for the reply. I do agree with your linked suggestion
>>> to
>>> allow aria-selected state on any focusable element. It also would be
>>> great
>>> if any of the ARIA states could be applied to focusable elements.
>>>
>>> I made a quick test case with three aria- states applied to links, list
>>> items, and buttons. No support with JAWS. NVDA only supports on IE
>>> latest.
>>> Expanded has better support than selected and pressed does not have any
>>> support other than JAWS saying it's a toggle button.
>>>
>>> <http://pauljadam.com/demos/aria/aria-selected.html>;
>>>
>>> So is it unwise to recommend aria to convey state of JavaScript widgets
>>> if
>>> it has support only in certain browsers & AT?
>>>
>>> Instead should I recommend conveying state with visually hidden text? Or
>>> title attributes? Or placing the state as an alt attribute in an image if
>>> present in the widget?
>>>
>>> Can you say that a widget is not accessible if it only relies on aria
>>> states?
>>>
>>> Paul J. Adam
>>> Accessibility Evangelist
>>> Deque Systems
>>> = EMAIL ADDRESS REMOVED =
>>> www.PaulJAdam.com
>>> @pauljadam on Twitter
>>>
>>> On Aug 21, 2012, at 2:59 PM, Steve Faulkner < = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>>
>>>> hi Paul,
>>>>
>>>>>> Adding aria-selected to a HTML element does cause VoiceOver to speak
>>> the text "selected" even if it's not one of the supported roles.
>>>>
>>>> this may work for voiceover but may well not work for other AT will
>>>> check
>>>>
>>>> this related thread on WAI-xtech may be of interest:
>>>> http://lists.w3.org/Archives/Public/wai-xtech/2012Jul/0006.html
>>>>
>>>>
>>>> regards
>>>> SteveF
>>>>
>>>> On 21 August 2012 20:36, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>>>>> The WAI-ARIA spec states that the aria-selected state is only used in
>>> roles gridcell, option, row, and tab. <
>>> http://www.w3.org/TR/wai-aria/states_and_properties#aria-selected>;
>>>>>
>>>>> Is it bad to use aria-selected=true on a HTML widget with a selected
>>> state that does not fall into one of these roles? Like a list item or
>>> link?
>>>>>
>>>>> If aria selected should not be used on links or list items then how
>>> would you communicate state to a screen reader? Visually hidden text?
>>> Title
>>> attribute?
>>>>>
>>>>> Adding aria-selected to a HTML element does cause VoiceOver to speak
>>> the text "selected" even if it's not one of the supported roles.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Paul J. Adam
>>>>> Accessibility Evangelist
>>>>> Deque Systems
>>>>> = EMAIL ADDRESS REMOVED =
>>>>> www.PaulJAdam.com
>>>>> @pauljadam on Twitter
>>>>>
>>>>> >>>>> >>>>> >>>>
>>>>
>>>>
>>>> --
>>>> with regards
>>>>
>>>> Steve Faulkner
>>>> Technical Director - TPG
>>>>
>>>> www.paciellogroup.com | www.HTML5accessibility.com |
>>>> www.twitter.com/stevefaulkner
>>>> HTML5: Techniques for providing useful text alternatives -
>>>> dev.w3.org/html5/alt-techniques/
>>>> Web Accessibility Toolbar -
>>> www.paciellogroup.com/resources/wat-ie-about.html
>>>> >>>> >>>> >>>
>>> >>> >>> >>>
>>
>>
>>
>> --
>> If you want to build a ship, don't drum up the people to gather wood,
>> divide the work, and give orders. Instead, teach them to yearn for the
>> vast
>> and endless sea.
>> - Antoine De Saint-Exupéry, The Little Prince
>> >> >> >
> > > >
> > >
From: Benjamin Hawkes-Lewis
Date: Wed, Aug 29 2012 1:39AM
Subject: Re: Using aria-selected=true on any HTML element?
← Previous message | Next message →
On Tue, Aug 21, 2012 at 8:36 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
> The WAI-ARIA spec states that the aria-selected state is only used in roles gridcell, option, row, and tab. <http://www.w3.org/TR/wai-aria/states_and_properties#aria-selected>;
>
> Is it bad to use aria-selected=true on a HTML widget with a selected state that does not fall into one of these roles? Like a list item or link?
>
> If aria selected should not be used on links or list items then how would you communicate state to a screen reader? Visually hidden text? Title attribute?
What sort of selection are you talking about here, that would apply to
links or list items?
--
Benjamin Hawkes-Lewis
From: Paul J. Adam
Date: Wed, Aug 29 2012 8:58AM
Subject: Re: Using aria-selected=true on any HTML element?
← Previous message | Next message →
I guess most of the HTML elements with selected state could have a role=tab, but they don't always look like tabs. Basically what I'm referring to is that many times I see custom user interface components that are designed visually to have selected and unselected states. The developer may code these on top of a normal link or list item or a div, whatever CSS and JavaScript allows them to do. So my quandary was how do I communicate that state to screen readers. Do I use ARIA with weak support or go back to old school visually hidden text. Visually hidden text is the only bulletproof solution.
Paul J. Adam
Accessibility Evangelist
Deque Systems
= EMAIL ADDRESS REMOVED =
www.PaulJAdam.com
@pauljadam on Twitter
On Aug 29, 2012, at 2:39 AM, Benjamin Hawkes-Lewis < = EMAIL ADDRESS REMOVED = > wrote:
> On Tue, Aug 21, 2012 at 8:36 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>> The WAI-ARIA spec states that the aria-selected state is only used in roles gridcell, option, row, and tab. <http://www.w3.org/TR/wai-aria/states_and_properties#aria-selected>;
>>
>> Is it bad to use aria-selected=true on a HTML widget with a selected state that does not fall into one of these roles? Like a list item or link?
>>
>> If aria selected should not be used on links or list items then how would you communicate state to a screen reader? Visually hidden text? Title attribute?
>
> What sort of selection are you talking about here, that would apply to
> links or list items?
>
> --
> Benjamin Hawkes-Lewis
> > >
From: Gunderson, Jon R
Date: Wed, Aug 29 2012 9:26AM
Subject: Re: Using aria-selected=true on any HTML element?
← Previous message | Next message →
Are the elements basically being used to show the state of content that can be selectively hidden or visible?
If so use aria-expanded property and aria-controls.
http://oaa-accessibility.org/example/21/
http://oaa-accessibility.org/example/22/
From: Paul J. Adam
Date: Wed, Aug 29 2012 9:38AM
Subject: Re: Using aria-selected=true on any HTML element?
← Previous message | No next message
Thanks for those examples. 21 does not work with VoiceOver, 22 does work though. aria-expanded has pretty good support, just not on all the browsers/AT so I still can't really recommend it.
Paul J. Adam
Accessibility Evangelist
Deque Systems
= EMAIL ADDRESS REMOVED =
www.PaulJAdam.com
@pauljadam on Twitter
On Aug 29, 2012, at 10:26 AM, "Gunderson, Jon R" < = EMAIL ADDRESS REMOVED = > wrote:
> Are the elements basically being used to show the state of content that can be selectively hidden or visible?
>
> If so use aria-expanded property and aria-controls.
>
> http://oaa-accessibility.org/example/21/
>
> http://oaa-accessibility.org/example/22/
>
>
>
>
>