RE: improved select boxes - still accessible

[Bryan wrote:]
Will this work for Dragon usage as well, such as saying down to activate a
keypress?

If the application properly responds to "press down" which sends the down
arrow keystrokes and then is set to watch the key press event for enter
"press enter" via Dragon on the proper element then it should work.  Other
dragon commands for example to open a list or select a list would likely
not work as the support for ARIA in Dragon is limited.

Jonathan



-----Original Message-----
From: Bryan Garaventa [mailto:bryan.garaventa@whatsock.com]
Sent: Monday, August 20, 2012 1:31 PM
To: Jonathan Avila; Marc Haunschild; w3c-wai-ig@w3.org; WebAIM Discussion
List
Subject: 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:44:09 UTC