Re: improved select boxes - still accessible

Hi Brendan,

thanks a lot for your answer!

You asked me, why I did not test it myself? I have to admit, that I find it very difficult to test screenreader use cases myself - I am not able to use them without watching the site myself - it ist just to strange for me, to see nothing at all.

On the other hand, when I use a screenreader AND watch at a page, I tend to cheat, what means I betray myself. :-)

I think I am really doing well in testing web pages accessibility - except screenreader access. So time after time, when I try to add a rather basical technique to my standard toolbox, I need some advice of people, doing these things better than me... ;-)

On the other hand I made some tests (browser support on desktop and mobile) and discussed these techniques with some colleagues (e.g. efficient use within our development environment) and so on.

So I ask the public not for everything I found in the web, just because I don't like to test it myself. ;-)

Nevertheless in this particular case I obviously have not done enough research myself. The missing ARIA is obvious and I should have seen this myself. So I understand, why you ar asking me this question. ;-)

Your answer is a big help, anyway! Thanks again.

Marc


----- Ursprüngliche Mail -----
> Von: "Brendan McKeon" <brendan_mckeon@hotmail.com>
> An: "Marc Haunschild" <mh@zadi.de>, w3c-wai-ig@w3.org
> Gesendet: Donnerstag, 16. August 2012 10:20:34
> Betreff: 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.

Received on Thursday, 16 August 2012 09:17:46 UTC