Re: improved select boxes - still accessible

To clarify one thing, check where focus is being set when the arrow keys are 
being used to navigate. I'm seeing this on the body node, so it looks like 
CSS is being used to scroll menu items. Either way, none of the select 
element option nodes include dynamically updated tabindex values, which 
would be required to make it work properly using ARIA.

----- Original Message ----- 
From: "Bryan Garaventa" <bryan.garaventa@whatsock.com>
To: "Brendan McKeon" <brendan_mckeon@hotmail.com>; "'Marc Haunschild'" 
<mh@zadi.de>; <w3c-wai-ig@w3.org>
Sent: Thursday, August 16, 2012 9:28 AM
Subject: Re: improved select boxes - still accessible


> I've taken a look as well, and there is more going on that ARIA would not 
> be able to resolve.
>
> In the basic example where Alaska is converted into a link, if you try 
> navigating to it using JAWS in IE, pressing Enter on it does nothing.
>
> Also, when the drop down is rendered, all of these list items appear at 
> the bottom of the page in the DOM, and none of the select option items are 
> keyboard accessible. E.G, you can't activate the drop down, and you can't 
> use the arrow keys to make a selection, and you can't press Enter to make 
> a selection.
>
> Adding ARIA will not solve any of these issues, since ARIA will only 
> change the feedback that screen reader users hear when interacting with a 
> control. If the control is not keyboard accessible to begin with, it won't 
> work.
>
> I wrote an article about this at
> http://lnkd.in/jYnkZq
> if it's helpful. These are important concepts for all developers to be 
> aware of.
>
> Also, when adding ARIA to an interactive control, if focus is not 
> dynamically placed on the correct DOM nodes, the addition of ARIA will not 
> matter, since it will still be inaccessible to screen reader users.
>
> To see how a listbox should act from the keyboard, I have a demo of this 
> at
> http://whatsock.com/modules/aria_sortable_listbox_module/demo.htm
> When the Sort button is activated, it generates an accessible listbox 
> control, which can then be navigated from the keyboard with or without a 
> screen reader.
>
> ----- Original Message ----- 
> From: "Brendan McKeon" <brendan_mckeon@hotmail.com>
> To: "'Marc Haunschild'" <mh@zadi.de>; <w3c-wai-ig@w3.org>
> Sent: Thursday, August 16, 2012 1:20 AM
> Subject: RE: improved select boxes - still accessible
>
>
> Hi Marc,
>
> A quick look at these in Chrome's DOM inspector shows that neither are 
> using ARIA attributes at all, so can't be considered accessible from a 
> screenreader point of view.
>
> Both seem to build some of their custom combos from A elements (and also 
> assorted SPAN and LI elements); but since there's no ARIA roles (or any of 
> the other attributes that would be required to build an accesible select 
> equivalent), NVDA reads them out as links.
>
> At a first glance, keyboard support in both cases is reasonably good; 
> keyboard seems to work as expected, esc dismisses the drop-downs as 
> expected; this is one bright spot - it used to be the case that custom 
> HTML controls didn't even get that right and were essentially mouse-only!
>
> But for now, they can't be considered screenreader accessible in their 
> current form due to the lack of ARIA support. If the authors added the 
> appropriate support, however, then they could be made accessible ( - at 
> least assuming that a user is using a suitably current browser and 
> screenreader combination).
>
> --
>
> Marc, I now have a question for you: I'm curious as to why you asked on 
> this list about if these are accessible, instead of testing them out for 
> yourself. Perhaps you don't have access to JAWS? If that's the case, then 
> for web pages at least, the free NVDA screenreader has pretty much the 
> same capabilities, so makes for a good alternative to test or experiment 
> with. Or are you just not yet familiar with how to evaluate a control for 
> accessibility? I'm wondering what are the resources a web content author 
> would need to have in order to be able to make this determination 
> themselves.
>
> Cheers,
>
> Brendan.
>
> --
> Brendan McKeon | brendan_mckeon@hotmail.com
>
>
> -----Original Message-----
> From: Marc Haunschild [mailto:mh@zadi.de]
> Sent: Thursday, August 16, 2012 12:45 AM
> To: w3c-wai-ig@w3.org
> Subject: Fwd: SV: improved select boxes - still accessible
>
>
> Of course you guys are right. Here are the missing links
>
> http://ivaynberg.github.com/select2/
> http://harvesthq.github.com/chosen/
>
> So sorry!
>
> ----- Ursprüngliche Mail -----
> Von: "Morten Tollefsen" <morten@medialt.no>
> An: "Marc Haunschild" <mh@zadi.de>
> Gesendet: Donnerstag, 16. August 2012 08:44:10
> Betreff: SV: improved select boxes - still accessible
>
> Hi!
>
> Perhaps you forgot a link in the message below?
>
> - Morten
>
> -----Opprinnelig melding-----
> Fra: Marc Haunschild [mailto:mh@zadi.de]
> Sendt: 16. august 2012 08:01
> Til: w3c-wai-ig@w3.org
> Emne: 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 Thursday, 16 August 2012 16:44:12 UTC