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

Hold on, because you said quite a few things:

   1. *...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*
   The pre-requisite (which I probably didn't make very clear) was that
   both values - for <label> and aria-labelledby= - are exactly the same. Is
   this something that can't be done? BTW, *if you want your labels hidden
   then use **aria-label=** on the <input> field rather **aria-labelledby= *
   *on some text. See *
   http://www.w3.org/TR/wai-aria/states_and_properties#aria-labelledby*.*
   2. *...table must be still a table visually, so the labels must be
   hidden *
   Yes, and you can have visually hidden labels. I successfully used this
   method to "hide" content off-screen -
   http://yaccessibilityblog.com/library/css-clip-hidden-content.html
   3. *...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. *
   How did you test this? Table headers are not read if you only use the
   cursor keys to read cells. But SR users have table-specific keystrokes that
   they use to read table headers (assuming they're coded correctly)
   pertaining to a cell -  http://webaim.org/resources/shortcuts/jaws#moving
   Charles mentioned the same thing.

Overall, I would go with *aria-label=* and a hidden <label>.

With regards to supporting different browsers / ATs / OSs - certainly there
isn't one answer to rule them all and I definitely can't give you an
arbitrary answer. But, I'd start with the users'; What are the most used
browsers (and versions) & OSs? Then work your way down. In my environment
(banking) we support internal (employees) & external (customers) and we
know for example that IEx is the lowest common denominator.

If you rely on an ARIA-only solution users who don't have ARIA support are
completely left out. Though you can mitigate some of the risk with good
table (i.e. users won't read the label directly but can read the respective
cell information). However, with the solution above for non-ARIA
combinations at least users will at least have a minimal experience (they
get to read the <label> and rely on table headers).


Cheers,
George


On Thu, Mar 22, 2012 at 10:27 AM, Ramón Corominas <listas@ramoncorominas.com
> wrote:

> 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<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
>>
>
>