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

It sounds like there is much confusion around Ramon's questions.

>From what I understand he is using properly marked up tables but trying to
get screen readers to announce the labels for form fields within the table
cells.  Screen readers do NOT announced table header cells as field
labels.  Thus he is planning on using aria-labelledby.  This is a good
approach but as others have mentioned it doesn’t provide a fallback.
Thus, the use of label elements in addition is required.  As assistive
technologies do NOT support multiple label elements for one field like
they do aria-labelledby -- so an off-screen CSS label has been suggested
that would contain both the column and row names.     There is also some
concern that this would provide double speaking with assistive technology.
My quick tests have indicated that JAWS 12, 13, and the latest NVDA do not
announce the label with an aria-labelledby is also present.  If you
weren't sure you could also add an aria-hidden to the off-screen text to
try and prevent ARIA aware screen readers from using that.

Because other assistive technology such as Window-Eyes and Dragon do not
support ARIA yet - fallback methods are very important unless you are in a
particular environment where AT and configuration can be guaranteed.

Best Regards,

Jonathan

-----Original Message-----
From: Ramón Corominas [mailto:listas@ramoncorominas.com]
Sent: Thursday, March 22, 2012 10:28 AM
To: George Zamfir
Cc: WAI Interest Group
Subject: 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-t
> opic/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 16:25:02 UTC