WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Using aria-selected=true on any HTML element?

for

From: Bryan Garaventa
Date: Aug 22, 2012 10:24AM

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 REMOVED> >
To: "WebAIM Discussion List" < <EMAIL 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 REMOVED>
www.PaulJAdam.com
@pauljadam on Twitter

On Aug 22, 2012, at 6:54 AM, Elle < <EMAIL 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 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 REMOVED>
>> www.PaulJAdam.com
>> @pauljadam on Twitter
>>
>> On Aug 21, 2012, at 2:59 PM, Steve Faulkner < <EMAIL 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 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 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
> > >