Re: improved select boxes - still accessible

Will this work for Dragon usage as well, such as saying down to activate a 
keypress?

----- Original Message ----- 
From: "Jonathan Avila" <jon.avila@ssbbartgroup.com>
To: "Bryan Garaventa" <bryan.garaventa@whatsock.com>; "Marc Haunschild" 
<mh@zadi.de>; <w3c-wai-ig@w3.org>; "WebAIM Discussion List" 
<webaim-forum@list.webaim.org>
Sent: Monday, August 20, 2012 10:17 AM
Subject: RE: improved select boxes - still accessible


> [Bryan wrote]
> The only way to make a control such as this keyboard accessible, is to use
> tabindex=0 on each div tag when it's selected, and to either remove 
> tabindex
> or set it to '-1' for every div that is not currently highlighted, then 
> set
> focus to each such div programmatically using the .focus() method every 
> time
> the arrow keys are pressed.
>
> Bryan, they may be able set tabIndex=0 on the parent div and then use
> aria-activedescendant to indicate the active descendant of the widget.
>
> Jonathan
>
> -----Original Message-----
> From: Bryan Garaventa [mailto:bryan.garaventa@whatsock.com]
> Sent: Monday, August 20, 2012 12:32 PM
> To: Marc Haunschild; w3c-wai-ig@w3.org; WebAIM Discussion List
> Subject: Re: improved select boxes - still accessible
>
> I agree, this is somewhat confusing. I'm including the W3C and WebAim list
> on this because I think this is an important issue to bring up to the
> community.
>
> Here is the tag structure for each of the select items in the sample you
> referenced:
>
> <LI class="select2-results-dept-1 select2-result select2-result-selectable
> select2-highlighted" jQuery17108271382708004837="227"><DIV
> class=select2-result-label><SPAN
> class=select2-match></SPAN>Hawaii</DIV></LI>
>
> The only thing that is happening when the arrow keys are used to navigate
> the select options, is that the class 'highlighted' is being toggled.
> Nothing else is occurring.
>
> The only way to make a control such as this keyboard accessible, is to use
> tabindex=0 on each div tag when it's selected, and to either remove 
> tabindex
> or set it to '-1' for every div that is not currently highlighted, then 
> set
> focus to each such div programmatically using the .focus() method every 
> time
> the arrow keys are pressed.
>
> Only then will the addition of ARIA actually work correctly. CSS cannot be
> used for this purpose.
>
> Google has also done something similar at
> https://groups.google.com/forum/?fromgroups#!overview
>
> Where, after logging in with your Google account login, you will find 6 
> ARIA
> tree controls in the heading navigation.
>
> If you press Insert+F5 using JAWS, you can see them listed there in the 
> Form
> Field list dialog.
>
> All of these controls include ARIA to make them accessible, and every 
> single
> one of them is completely inaccessible for screen reader users, because 
> none
> of them are keyboard accessible.
>
> This is why I've been saying that these concepts are critical for 
> developers
> to understand.
>
> Otherwise, such inaccessible controls will continue to be propagated 
> across
> the web with the assumption that ARIA will make them accessible, even when
> it won't.
>
> ----- Original Message -----
> From: "Marc Haunschild" <mh@zadi.de>
> To: "Bryan Garaventa" <bryan.garaventa@whatsock.com>
> Sent: Monday, August 20, 2012 1:26 AM
> Subject: Re: improved select boxes - still accessible
>
>
>> Obviously there is something I do not understand: the visual change made
>> by the CSS happens when the Element gets focus
>>
>> The selector is :focus
>>
>> And I CAN navigate with the arrow keys?!?
>>
>> We still talk about select 2 at http://ivaynberg.github.com/select2/, do
>> we?
>>
>>
>>
>> Am 17.08.2012 20:03, schrieb Bryan Garaventa:
>>> Hi, I understand your point.
>>>
>>> It's not a matter of the select action actually, but rather, the
>>> programmatic functionality.
>>>
>>> The problem that I've been seeing a lot lately, is a widespread
>>> assumption that the use of ARIA will make something accessible.
>>>
>>> This is not actually true; ARIA will enhance accessibility for a control
>>> that is already accessible, but it can't make something that is not
>>> accessible, accessible.
>>>
>>> For example, in the case of the select controls,
>>>
>>> However, literal keyboard focus is not being set on the various list
>>> options when the keyboard is used to navigate between each select item.
>>> You can see this by disabling CSS in your browser, then try to set focus
>>> on the link that activates the drop down, activate it, then try using 
>>> the
>>> arrow keys to see where focus is set.
>>>
>>> You will see that focus is not actually being moved between the various
>>> options, making this control impossible to function from the keyboard,
>>> and impossible to make a selection in the same manner as when you use 
>>> the
>>> mouse to click a select item like "West Virginia". If you refrain from
>>> using the mouse, it won't work.
>>>
>>> I've seen this before, where CSS is used to make something appear to be
>>> happening, but in actuality, nothing is. This causes many problems,
>>> because nothing that occurs in CSS for simulating the movement of focus
>>> is accessible from the keyboard, and the use of ARIA in cases such as
>>> these, only changes the feedback of an inaccessible control for screen
>>> reader users, but doesn't make it any more accessible.
>>>
>>>
>>>
>>> ----- Original Message ----- From: "Marc Haunschild" <mh@zadi.de>
>>> To: "Bryan Garaventa" <bryan.garaventa@whatsock.com>
>>> Sent: Friday, August 17, 2012 2:28 AM
>>> Subject: Re: improved select boxes - still accessible
>>>
>>>
>>>> Hi Bryan,
>>>>
>>>> thanks for your answer - as far as I understood, hitting return (or
>>>> clicking an item) does not do anything, because using this example does
>>>> not trigger any action. It just shows how to select items, but nothing
>>>> is sent. ;-)
>>>>
>>>> Marc
>>>>
>>>>
>>>>
>>>> Am 16.08.2012 08:27, schrieb Bryan Garaventa:
>>>>> If this is helpful, I've updated the ARIA Listbox Generator, 
>>>>> documented
>>>>> at
>>>>> http://lnkd.in/CKfG9x
>>>>>
>>>>> The ARIA Listbox Generator automates the process of rendering keyboard
>>>>> and screen reader accessible listbox controls, which are instantiated
>>>>> as independent Listbox objects.
>>>>>
>>>>> These Listbox objects support current selection tracking, callbacks,
>>>>> dynamic addition and deletion of new option elements, dynamic getting
>>>>> and setting, keyboard accessible sortability, and multiselect.
>>>>>
>>>>> ----- Original Message ----- From: "Marc Haunschild" <mh@zadi.de>
>>>>> To: <w3c-wai-ig@w3.org>
>>>>> Sent: Wednesday, August 15, 2012 10:46 PM
>>>>> Subject: improved select boxes - still accessible
>>>>>
>>>>>
>>>>>> Hi everyone,
>>>>>>
>>>>>> I found two really interesting javaScript upgrades for select boxes. 
>>>>>> I
>>>>>> want to use them, but I wonder if they are accessible in jaws and
>>>>>> other screenreader software.
>>>>>>
>>>>>> Also I would like to get some general feedback. Is it confusing to
>>>>>> interact with these modified boxes? Or do you think the improvements
>>>>>> are helpful?
>>>>>>
>>>>>> I am grateful for any response!
>>>>>>
>>>>>> Thanks for your help!
>>>>>>
>>>>>> Marc

Received on Monday, 20 August 2012 17:31:38 UTC