Re: Using aria-labelledby instead of <label> element

Not so easy...

The main problem is that screen readers do not use aria-labelledby the 
way you think. JAWS, for example, reads only de <label>, so it only 
contains part of the information. In addition, the table must be still a 
table visually, so the labels must be hidden. In addition, the table 
headers are also not read by JAWS (it only reads the label), and this is 
a component that is not easy to construct as a "static" piece of HTML.

In any case, and regarding the combinations you mention... What number 
of combinations should we take into account to consider a development 
"accessibility supported"? How many versions? and how old?

I know that this is a difficult question. Some people consider that they 
have to test with IE 7+ and JAWS 8+, others consider IE8+ and JAWS 10+, 
and of course we have also Firefox and Chrome, or VoiceOver with Safari 
or Firefox or Chrome... And we have even Opera, or Linux with Orca and 
Konqueror... Which of these users should be discriminated against?

I know that there must be a balance between development effort and real 
accessibility outcomes, but where should we put that limit?

Regards and thanks!
Ramón.

George re-wrote:

> Gmail sent an awesome blank email, seems it's an issue 
> <http://groups.google.com/a/googleproductforums.com/forum/#!category-topic/gmail/composing-and-sending-messages/VYpXeK5EkGE>; 
> and of course I didn't copy the message before sending. So, here it is 
> again in a much shorter form unfortunately.
> 
> I don't believe ARIA to be enough and I wouldn't rely on ARIA alone to 
> save the day. In true progressive enhancement the stack looks like this: 
> HTML-CSS-JavaScript-ARIA. Your solution seems to start with the end of 
> the stack - ARIA. There are browser / assistive technology (AT) 
> combinations, take IE7 & JAWS 9, where an ARIA-only solution fails 
> miserably.
> 
> I was in your shoes recently so here's what I did: 
> 
>     * if it's a data table it should marked-up with a <table> (semantics)
>     * not ARIA-dependent but used it to enhance the experience
> 
> Now, unless I misunderstood something, your data is in one of 2 states: 
> *show* and *edit* - this is an important point and again I can relate to 
> this as I was in a similar situation (with financial data)!
> 
>    1. Start with marking-up the data as a <table> with proper <th> for
>       columns and / or rows and use the /scope=/ attribute. This will be
>       sufficient for the *show* state as screen reader (SR) users can
>       get around the static data with regular table-specific keystrokes.
>       Also it's a minimal fallback (but fallback nonetheless) for
>       the *edit* state.
>    2. For the *edit *state use both <label> and /aria-labelledby= /with
>       the same value (which you can construct dynamically). For browser
>       / AT combinations that support ARIA /aria-labelledby=/ will
>       overwrite the <label> and for combinations that do not support
>       ARIA you have the <label> fallback; plus the semantic table as
>       another fallback
> 
> Hope this helps (and it's not an empty email). If you have any further 
> questions, please ask away.
> 
> Thank you,
> George

Received on Thursday, 22 March 2012 14:25:58 UTC