E-mail List Archives

Search E-mail List Archives for

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

From: Bryan Garaventa
Date: Mon, Aug 20 2012 10:32AM
Subject: improved select boxes - still accessible
No previous message | Next message →

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" < = EMAIL ADDRESS REMOVED = >
To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
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" < = EMAIL ADDRESS REMOVED = >
>> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
>> 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" < = EMAIL ADDRESS REMOVED = >
>>>> To: < = EMAIL ADDRESS REMOVED = >
>>>> 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

From: Bryan Garaventa
Date: Mon, Aug 20 2012 11:30AM
Subject: Re: improved select boxes - still accessible
← Previous message | Next message →

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

----- Original Message -----
From: "Jonathan Avila" < = EMAIL ADDRESS REMOVED = >
To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >; "Marc Haunschild"
< = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >; "WebAIM Discussion List"
< = EMAIL ADDRESS REMOVED = >
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: = EMAIL ADDRESS REMOVED = ]
> Sent: Monday, August 20, 2012 12:32 PM
> To: Marc Haunschild; = EMAIL ADDRESS REMOVED = ; 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" < = EMAIL ADDRESS REMOVED = >
> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
> 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" < = EMAIL ADDRESS REMOVED = >
>>> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
>>> 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" < = EMAIL ADDRESS REMOVED = >
>>>>> To: < = EMAIL ADDRESS REMOVED = >
>>>>> 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

From: Morin, Gary (NIH/OD) [E]
Date: Mon, Aug 20 2012 12:36PM
Subject: Re: improved select boxes - still accessible
← Previous message | Next message →

Thanks, Bryan, for bringing this up - Dragon (and speech recognition software, in general). I can honestly say that I've never gotten a drop-down menu to work with DNS. Radio buttons and Check boxes work just fine for me, but not drop-down menus. I can land on the list, and often it even opens up. But actually scrolling down and selecting my choice - not a happening thing. If anyone can instruct me on what I'm doing wrong, I'd sure appreciate it!

Gary


-----Original Message-----
From: Bryan Garaventa [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Monday, August 20, 2012 1:31 PM
To: Jonathan Avila; Marc Haunschild; = EMAIL ADDRESS REMOVED = ; WebAIM Discussion List
Subject: Re: [WebAIM] 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" < = EMAIL ADDRESS REMOVED = >
To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >; "Marc Haunschild"
< = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >; "WebAIM Discussion List"
< = EMAIL ADDRESS REMOVED = >
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: = EMAIL ADDRESS REMOVED = ]
> Sent: Monday, August 20, 2012 12:32 PM
> To: Marc Haunschild; = EMAIL ADDRESS REMOVED = ; 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" < = EMAIL ADDRESS REMOVED = >
> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
> 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" < = EMAIL ADDRESS REMOVED = >
>>> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
>>> 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" < = EMAIL ADDRESS REMOVED = >
>>>>> To: < = EMAIL ADDRESS REMOVED = >
>>>>> 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

From: Bryan Garaventa
Date: Mon, Aug 20 2012 1:51PM
Subject: Re: improved select boxes - still accessible
← Previous message | Next message →

I've been experimenting with this a bit, and found that the following syntax
appears to work well.

<ul role="listbox" aria-label="Label Text" id="l" tabindex="0"
aria-activedescendant="o1">
<li role="option" aria-selected="true" aria-posinset="1" aria-setsize="3"
id="o1">
Option One
</li>
<li role="option" aria-selected="false" aria-posinset="2" aria-setsize="3"
id="o2">
Option Two
</li>
<li role="option" aria-selected="false" aria-posinset="3" aria-setsize="3"
id="o3">
Option Three
</li>
</ul>

If aria-selected is not included, JAWS won't recognize a selected item in
the list when arrowing down the page using Firefox, and will only announce
'list', but with no indication of what is selected. So if present, this
would need to be toggled from true to false accordingly on all option nodes
via scripting.

Also, in JAWS12 in IE, the presence of aria-label to set a field title on
the container element appears to hijack speech output, in that only the
label is announced every time the arrow keys are used to select a new list
item. This doesn't occur when setting focus to a DOM node directly however,
such as the LI tags.

There is also a bug in JAWS 12 and 13 regarding dynamically added listbox
controls, which renders them invisible in Firefox.

E.G

function genList(id){
document.getElementById(id).innerHTML = "<ul role="listbox"><li
role="option">One</li><li role="option">Two</li></ul>";
return false;
}

<a href="#" onclick="return genList('listId');"> Gen List </a>
<div id="listId"></div>


----- Original Message -----
From: "Jonathan Avila" < = EMAIL ADDRESS REMOVED = >
To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >; "Marc Haunschild"
< = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >; "WebAIM Discussion List"
< = EMAIL ADDRESS REMOVED = >
Sent: Monday, August 20, 2012 10:43 AM
Subject: 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: = EMAIL ADDRESS REMOVED = ]
> Sent: Monday, August 20, 2012 1:31 PM
> To: Jonathan Avila; Marc Haunschild; = EMAIL ADDRESS REMOVED = ; 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" < = EMAIL ADDRESS REMOVED = >
> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >; "Marc Haunschild"
> < = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >; "WebAIM Discussion List"
> < = EMAIL ADDRESS REMOVED = >
> 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: = EMAIL ADDRESS REMOVED = ]
>> Sent: Monday, August 20, 2012 12:32 PM
>> To: Marc Haunschild; = EMAIL ADDRESS REMOVED = ; 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" < = EMAIL ADDRESS REMOVED = >
>> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
>> 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" < = EMAIL ADDRESS REMOVED = >
>>>> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
>>>> 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" < = EMAIL ADDRESS REMOVED = >
>>>>>> To: < = EMAIL ADDRESS REMOVED = >
>>>>>> 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
>

From: Bryan Garaventa
Date: Mon, Aug 20 2012 2:14PM
Subject: Re: improved select boxes - still accessible
← Previous message | Next message →

Can you do me a favor? If you go to the following demo using Dragon
http://whatsock.com/modules/aria_sortable_listbox_module/demo.htm

Can you use voice commands to tab to the Sort button, which is a standard
button and should be actionable saying 'press enter'.

The list should then be generated dynamically, and focus set on the first
option. So from there you could say the following:

'press up' or 'press down' will navigate up and down the list
'press home' or 'press end' will jump to the start or end
'press space' will toggle an item to grab or drop
'press enter' will save the changes and rerender the list

I'm totally blind, so this is difficult for me to confirm. I'm curious if
this will work though.



----- Original Message -----
From: "Morin, Gary (NIH/OD) [E]" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >; "Jonathan
Avila" < = EMAIL ADDRESS REMOVED = >; "Marc Haunschild" < = EMAIL ADDRESS REMOVED = >;
< = EMAIL ADDRESS REMOVED = >
Cc: < = EMAIL ADDRESS REMOVED = >
Sent: Monday, August 20, 2012 11:36 AM
Subject: RE: [WebAIM] improved select boxes - still accessible


Thanks, Bryan, for bringing this up - Dragon (and speech recognition
software, in general). I can honestly say that I've never gotten a
drop-down menu to work with DNS. Radio buttons and Check boxes work just
fine for me, but not drop-down menus. I can land on the list, and often it
even opens up. But actually scrolling down and selecting my choice - not a
happening thing. If anyone can instruct me on what I'm doing wrong, I'd
sure appreciate it!

Gary


-----Original Message-----
From: Bryan Garaventa [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Monday, August 20, 2012 1:31 PM
To: Jonathan Avila; Marc Haunschild; = EMAIL ADDRESS REMOVED = ; WebAIM Discussion
List
Subject: Re: [WebAIM] 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" < = EMAIL ADDRESS REMOVED = >
To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >; "Marc Haunschild"
< = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >; "WebAIM Discussion List"
< = EMAIL ADDRESS REMOVED = >
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: = EMAIL ADDRESS REMOVED = ]
> Sent: Monday, August 20, 2012 12:32 PM
> To: Marc Haunschild; = EMAIL ADDRESS REMOVED = ; 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" < = EMAIL ADDRESS REMOVED = >
> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
> 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" < = EMAIL ADDRESS REMOVED = >
>>> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
>>> 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" < = EMAIL ADDRESS REMOVED = >
>>>>> To: < = EMAIL ADDRESS REMOVED = >
>>>>> 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

From: deborah.kaplan@suberic.net
Date: Mon, Aug 20 2012 2:20PM
Subject: Re: improved select boxes - still accessible
← Previous message | Next message →

I could not get this to work with NaturallySpeaking. (and unlike
Gary, I can get drop-down menus to work with DNS; I have had
luck with the "expand list" command. Gary, have you tried that?)

-Deborah

On Mon, 20 Aug 2012, Bryan Garaventa wrote:

> Can you do me a favor? If you go to the following demo using Dragon
> http://whatsock.com/modules/aria_sortable_listbox_module/demo.htm
>
> Can you use voice commands to tab to the Sort button, which is a standard
> button and should be actionable saying 'press enter'.
>
> The list should then be generated dynamically, and focus set on the first
> option. So from there you could say the following:
>
> 'press up' or 'press down' will navigate up and down the list
> 'press home' or 'press end' will jump to the start or end
> 'press space' will toggle an item to grab or drop
> 'press enter' will save the changes and rerender the list
>
> I'm totally blind, so this is difficult for me to confirm. I'm curious if
> this will work though.
>
>
>
> ----- Original Message -----
> From: "Morin, Gary (NIH/OD) [E]" < = EMAIL ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >; "Jonathan
> Avila" < = EMAIL ADDRESS REMOVED = >; "Marc Haunschild" < = EMAIL ADDRESS REMOVED = >;
> < = EMAIL ADDRESS REMOVED = >
> Cc: < = EMAIL ADDRESS REMOVED = >
> Sent: Monday, August 20, 2012 11:36 AM
> Subject: RE: [WebAIM] improved select boxes - still accessible
>
>
> Thanks, Bryan, for bringing this up - Dragon (and speech recognition
> software, in general). I can honestly say that I've never gotten a
> drop-down menu to work with DNS. Radio buttons and Check boxes work just
> fine for me, but not drop-down menus. I can land on the list, and often it
> even opens up. But actually scrolling down and selecting my choice - not a
> happening thing. If anyone can instruct me on what I'm doing wrong, I'd
> sure appreciate it!
>
> Gary
>
>
> -----Original Message-----
> From: Bryan Garaventa [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Monday, August 20, 2012 1:31 PM
> To: Jonathan Avila; Marc Haunschild; = EMAIL ADDRESS REMOVED = ; WebAIM Discussion
> List
> Subject: Re: [WebAIM] 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" < = EMAIL ADDRESS REMOVED = >
> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >; "Marc Haunschild"
> < = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >; "WebAIM Discussion List"
> < = EMAIL ADDRESS REMOVED = >
> 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: = EMAIL ADDRESS REMOVED = ]
>> Sent: Monday, August 20, 2012 12:32 PM
>> To: Marc Haunschild; = EMAIL ADDRESS REMOVED = ; 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" < = EMAIL ADDRESS REMOVED = >
>> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
>> 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" < = EMAIL ADDRESS REMOVED = >
>>>> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
>>>> 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" < = EMAIL ADDRESS REMOVED = >
>>>>>> To: < = EMAIL ADDRESS REMOVED = >
>>>>>> 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
>
>
> > > >

From: Bryan Garaventa
Date: Mon, Aug 20 2012 2:33PM
Subject: Re: improved select boxes - still accessible
← Previous message | Next message →

Hmm, I'll revisit the ARIA for this.

Can you point me to an ARIA listbox implementation that does work using
voice activation?

----- Original Message -----
From: < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Monday, August 20, 2012 1:20 PM
Subject: Re: [WebAIM] improved select boxes - still accessible


>I could not get this to work with NaturallySpeaking. (and unlike
> Gary, I can get drop-down menus to work with DNS; I have had
> luck with the "expand list" command. Gary, have you tried that?)
>
> -Deborah
>
> On Mon, 20 Aug 2012, Bryan Garaventa wrote:
>
>> Can you do me a favor? If you go to the following demo using Dragon
>> http://whatsock.com/modules/aria_sortable_listbox_module/demo.htm
>>
>> Can you use voice commands to tab to the Sort button, which is a standard
>> button and should be actionable saying 'press enter'.
>>
>> The list should then be generated dynamically, and focus set on the first
>> option. So from there you could say the following:
>>
>> 'press up' or 'press down' will navigate up and down the list
>> 'press home' or 'press end' will jump to the start or end
>> 'press space' will toggle an item to grab or drop
>> 'press enter' will save the changes and rerender the list
>>
>> I'm totally blind, so this is difficult for me to confirm. I'm curious if
>> this will work though.
>>
>>
>>
>> ----- Original Message -----
>> From: "Morin, Gary (NIH/OD) [E]" < = EMAIL ADDRESS REMOVED = >
>> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >; "Jonathan
>> Avila" < = EMAIL ADDRESS REMOVED = >; "Marc Haunschild" < = EMAIL ADDRESS REMOVED = >;
>> < = EMAIL ADDRESS REMOVED = >
>> Cc: < = EMAIL ADDRESS REMOVED = >
>> Sent: Monday, August 20, 2012 11:36 AM
>> Subject: RE: [WebAIM] improved select boxes - still accessible
>>
>>
>> Thanks, Bryan, for bringing this up - Dragon (and speech recognition
>> software, in general). I can honestly say that I've never gotten a
>> drop-down menu to work with DNS. Radio buttons and Check boxes work just
>> fine for me, but not drop-down menus. I can land on the list, and often
>> it
>> even opens up. But actually scrolling down and selecting my choice - not
>> a
>> happening thing. If anyone can instruct me on what I'm doing wrong, I'd
>> sure appreciate it!
>>
>> Gary
>>
>>
>> -----Original Message-----
>> From: Bryan Garaventa [mailto: = EMAIL ADDRESS REMOVED = ]
>> Sent: Monday, August 20, 2012 1:31 PM
>> To: Jonathan Avila; Marc Haunschild; = EMAIL ADDRESS REMOVED = ; WebAIM Discussion
>> List
>> Subject: Re: [WebAIM] 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" < = EMAIL ADDRESS REMOVED = >
>> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >; "Marc Haunschild"
>> < = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >; "WebAIM Discussion List"
>> < = EMAIL ADDRESS REMOVED = >
>> 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: = EMAIL ADDRESS REMOVED = ]
>>> Sent: Monday, August 20, 2012 12:32 PM
>>> To: Marc Haunschild; = EMAIL ADDRESS REMOVED = ; 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" < = EMAIL ADDRESS REMOVED = >
>>> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
>>> 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" < = EMAIL ADDRESS REMOVED = >
>>>>> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
>>>>> 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" < = EMAIL ADDRESS REMOVED = >
>>>>>>> To: < = EMAIL ADDRESS REMOVED = >
>>>>>>> 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
>>
>>
>> >> >> >>
>
> > >

From: Bryan Garaventa
Date: Mon, Aug 20 2012 2:47PM
Subject: Re: improved select boxes - still accessible
← Previous message | Next message →

One obvious thing, do you know if speech activation software triggers only
the keypress event, or does it support keydown as well?

----- Original Message -----
From: < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Monday, August 20, 2012 1:20 PM
Subject: Re: [WebAIM] improved select boxes - still accessible


>I could not get this to work with NaturallySpeaking. (and unlike
> Gary, I can get drop-down menus to work with DNS; I have had
> luck with the "expand list" command. Gary, have you tried that?)
>
> -Deborah
>
> On Mon, 20 Aug 2012, Bryan Garaventa wrote:
>
>> Can you do me a favor? If you go to the following demo using Dragon
>> http://whatsock.com/modules/aria_sortable_listbox_module/demo.htm
>>
>> Can you use voice commands to tab to the Sort button, which is a standard
>> button and should be actionable saying 'press enter'.
>>
>> The list should then be generated dynamically, and focus set on the first
>> option. So from there you could say the following:
>>
>> 'press up' or 'press down' will navigate up and down the list
>> 'press home' or 'press end' will jump to the start or end
>> 'press space' will toggle an item to grab or drop
>> 'press enter' will save the changes and rerender the list
>>
>> I'm totally blind, so this is difficult for me to confirm. I'm curious if
>> this will work though.
>>
>>
>>
>> ----- Original Message -----
>> From: "Morin, Gary (NIH/OD) [E]" < = EMAIL ADDRESS REMOVED = >
>> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >; "Jonathan
>> Avila" < = EMAIL ADDRESS REMOVED = >; "Marc Haunschild" < = EMAIL ADDRESS REMOVED = >;
>> < = EMAIL ADDRESS REMOVED = >
>> Cc: < = EMAIL ADDRESS REMOVED = >
>> Sent: Monday, August 20, 2012 11:36 AM
>> Subject: RE: [WebAIM] improved select boxes - still accessible
>>
>>
>> Thanks, Bryan, for bringing this up - Dragon (and speech recognition
>> software, in general). I can honestly say that I've never gotten a
>> drop-down menu to work with DNS. Radio buttons and Check boxes work just
>> fine for me, but not drop-down menus. I can land on the list, and often
>> it
>> even opens up. But actually scrolling down and selecting my choice - not
>> a
>> happening thing. If anyone can instruct me on what I'm doing wrong, I'd
>> sure appreciate it!
>>
>> Gary
>>
>>
>> -----Original Message-----
>> From: Bryan Garaventa [mailto: = EMAIL ADDRESS REMOVED = ]
>> Sent: Monday, August 20, 2012 1:31 PM
>> To: Jonathan Avila; Marc Haunschild; = EMAIL ADDRESS REMOVED = ; WebAIM Discussion
>> List
>> Subject: Re: [WebAIM] 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" < = EMAIL ADDRESS REMOVED = >
>> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >; "Marc Haunschild"
>> < = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >; "WebAIM Discussion List"
>> < = EMAIL ADDRESS REMOVED = >
>> 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: = EMAIL ADDRESS REMOVED = ]
>>> Sent: Monday, August 20, 2012 12:32 PM
>>> To: Marc Haunschild; = EMAIL ADDRESS REMOVED = ; 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" < = EMAIL ADDRESS REMOVED = >
>>> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
>>> 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" < = EMAIL ADDRESS REMOVED = >
>>>>> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
>>>>> 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" < = EMAIL ADDRESS REMOVED = >
>>>>>>> To: < = EMAIL ADDRESS REMOVED = >
>>>>>>> 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
>>
>>
>> >> >> >>
>
> > >

From: Bryan Garaventa
Date: Mon, Aug 20 2012 8:44PM
Subject: Re: improved select boxes - still accessible
← Previous message | No next message

Hi,
I'm curious why certain standard event types and focus redirection isn't
working correctly in voice navigation software, so I've created an obstacle
course of sorts, available at
http://whatsock.com/obstacle/demo.htm

There are two event sections, keyDown and keyUp, since special characters
are not supported using keyPress.

The obstacle course consists of several different element types, standard
links and buttons, and non-standard ARIA links and buttons.

If it's possible to set focus on the Start button, then activate the down
arrow via 'press down', and to make it through all of these element types to
the End button, then the event handling and focus redirection is working
properly.

If it gets stuck, at least it will be clear on which element and in which
section this is occurring.

At the end, there are two buttons, one with only a click handler, and a
second with only a keyPress event, to see which ones work by activating
'press enter' and 'press space'.

Screen reader users will notice that the keyPress button cannot actually be
pressed unless Forms Mode is activated, resulting from the lack of an
onClick.

If anyone out there is using voice navigation software, please let me know
how this works for you.

Sincerely,
Bryan Garaventa

----- Original Message -----
From: < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Monday, August 20, 2012 1:20 PM
Subject: Re: [WebAIM] improved select boxes - still accessible


>I could not get this to work with NaturallySpeaking. (and unlike
> Gary, I can get drop-down menus to work with DNS; I have had
> luck with the "expand list" command. Gary, have you tried that?)
>
> -Deborah
>
> On Mon, 20 Aug 2012, Bryan Garaventa wrote:
>
>> Can you do me a favor? If you go to the following demo using Dragon
>> http://whatsock.com/modules/aria_sortable_listbox_module/demo.htm
>>
>> Can you use voice commands to tab to the Sort button, which is a standard
>> button and should be actionable saying 'press enter'.
>>
>> The list should then be generated dynamically, and focus set on the first
>> option. So from there you could say the following:
>>
>> 'press up' or 'press down' will navigate up and down the list
>> 'press home' or 'press end' will jump to the start or end
>> 'press space' will toggle an item to grab or drop
>> 'press enter' will save the changes and rerender the list
>>
>> I'm totally blind, so this is difficult for me to confirm. I'm curious if
>> this will work though.
>>
>>
>>
>> ----- Original Message -----
>> From: "Morin, Gary (NIH/OD) [E]" < = EMAIL ADDRESS REMOVED = >
>> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >; "Jonathan
>> Avila" < = EMAIL ADDRESS REMOVED = >; "Marc Haunschild" < = EMAIL ADDRESS REMOVED = >;
>> < = EMAIL ADDRESS REMOVED = >
>> Cc: < = EMAIL ADDRESS REMOVED = >
>> Sent: Monday, August 20, 2012 11:36 AM
>> Subject: RE: [WebAIM] improved select boxes - still accessible
>>
>>
>> Thanks, Bryan, for bringing this up - Dragon (and speech recognition
>> software, in general). I can honestly say that I've never gotten a
>> drop-down menu to work with DNS. Radio buttons and Check boxes work just
>> fine for me, but not drop-down menus. I can land on the list, and often
>> it
>> even opens up. But actually scrolling down and selecting my choice - not
>> a
>> happening thing. If anyone can instruct me on what I'm doing wrong, I'd
>> sure appreciate it!
>>
>> Gary
>>
>>
>> -----Original Message-----
>> From: Bryan Garaventa [mailto: = EMAIL ADDRESS REMOVED = ]
>> Sent: Monday, August 20, 2012 1:31 PM
>> To: Jonathan Avila; Marc Haunschild; = EMAIL ADDRESS REMOVED = ; WebAIM Discussion
>> List
>> Subject: Re: [WebAIM] 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" < = EMAIL ADDRESS REMOVED = >
>> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >; "Marc Haunschild"
>> < = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >; "WebAIM Discussion List"
>> < = EMAIL ADDRESS REMOVED = >
>> 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: = EMAIL ADDRESS REMOVED = ]
>>> Sent: Monday, August 20, 2012 12:32 PM
>>> To: Marc Haunschild; = EMAIL ADDRESS REMOVED = ; 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" < = EMAIL ADDRESS REMOVED = >
>>> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
>>> 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" < = EMAIL ADDRESS REMOVED = >
>>>>> To: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
>>>>> 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" < = EMAIL ADDRESS REMOVED = >
>>>>>>> To: < = EMAIL ADDRESS REMOVED = >
>>>>>>> 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
>>
>>
>> >> >> >>
>
> > >