W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2012

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

From: Roger Hudson <rhudson@usability.com.au>
Date: Fri, 23 Mar 2012 06:59:16 +1100
To: "'Michael Gower'" <michael.gower@ca.ibm.com>, "'Steve Faulkner'" <faulkner.steve@gmail.com>
Cc: 'Ramón Corominas' <listas@ramoncorominas.com>, "'WAI Interest Group'" <w3c-wai-ig@w3.org>, "'Diane V Margaretos'" <dianevm@us.ibm.com>, "'David Best'" <davebest@ca.ibm.com>
Message-ID: <001b01cd0866$44d70100$ce850300$@com.au>
For form inputs inside a data table (e.g. for indicating number of items to
be ordered), I have used the input title attribute rather than a hidden
explicitly associated label to indicate the purpose of the input. This seems
to work fine with an accessibly marked up data table. As you read the table
with a  screen reader the col and row THs can be associated with the cell
containing the input. And, when you move from input to input filling in the
form elements, the title attribute is presented. Of course, the title
attribute has to be meaningful.



From: Michael Gower [mailto:michael.gower@ca.ibm.com] 
Sent: Friday, 23 March 2012 4:10 AM
To: Steve Faulkner
Cc: Ramón Corominas; WAI Interest Group; Diane V Margaretos; David Best
Subject: Re: Using aria-labelledby instead of <label> element


We have recently used both techniques to give remediation advice to a client
with something very similar where radio buttons were located in each cell.
Both aria-labelledby and the use of title appear to function fine with
keyboard and screen reader. We recommended using the aria technique unless
backward compatibility was an issue. One point of consideration is whether
your "data table" is really a data table in this context, or if it is
actually a presentation table that is using the col and row headers as
labels. That may seem like a fine distinction, but housing inputs in a data
table can potentially affect the behaviour of some assistive technologies. 

Michael Gower
i b m  i n t e r a c t i v e
1803 Douglas Street
Victoria, BC  V8T 5C3
voice: (250) 220-1146
cel:     (250) 661-0098
sms:    2506610098@txt.bellmobility.ca
fax:     (250) 220-8034 

From:        Steve Faulkner <faulkner.steve@gmail.com> 
To:        Ramón Corominas <listas@ramoncorominas.com> 
Cc:        WAI Interest Group <w3c-wai-ig@w3.org> 
Date:        03/22/2012 09:47 AM 
Subject:        Re: Using aria-labelledby instead of <label> element 


Another possibility is to use the title attribute on the inputs to provide
the label.

for example:


On 22 March 2012 11:22, Ramón Corominas <listas@ramoncorominas.com> wrote: 
Hi all,

We are developing a tool to manage different fields related to many records
in a dataset. The information is presented as a data table to show and edit
the values of each record, so the column headers act as labels for each
field, and row headers identify each record. For example, imagine that you
have a chess shop:

Columns: Piece, color, material, unit price
Rows: King, Queen, Rook, Knight, Bishop, Pawn

Thus, we need to construct the "label" for each field combining both row and
column headers "Queen color", "Knight unit price", etc. We have tested
aria-labelledby to do this, and it seems to work fine with all the screen
readers and platforms that we have tested (JAWS & NVDA w/ IE & FF, VoiceOver
w/ Safari). We have also seen that this technique has been submitted to the
WCAG WG [1]. However, I cannot find it in the Techniques document, so I
don't know if there is a reason to avoiding it.

What do you think? Would it be acceptable to use aria-labelledby as the only
way to label a form control?

Thanks in advance,

[1] Associating multiple labels with a form control using ARIA-LABELLEDBY

with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com <http://www.paciellogroup.com/>  |
www.HTML5accessibility.com <http://www.html5accessibility.com/>  |
HTML5: Techniques for providing useful text alternatives -
Web Accessibility Toolbar -
Received on Thursday, 22 March 2012 20:01:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:36:39 UTC