RE: aria-label usage in table cells

Examples are always helpful!  However, birthdate is one that leaves ambiguity.  Day/Month/Year is most often presented as Month/Day/Year in the US, so the accessible labels would impart additional instruction.

Terry Lynn Sales
Architecture and Engineering
Section 508 SME
Cargo Systems Program Directorate/OIT
U.S. Customs and Border Protection
Desk - 571-468-5271    
B'Berry - 703-945-2777

 
NOTICE:  The Contracting Officer is the sole individual that is authorized to make changes to the contract.  The contents of this email are not intended to change the existing scope of the contract.  If the Contractor considers any part of this communication to constitute a change in scope, the Contractor shall notify the Contracting Officer in accordance with FAR Clause 52.243-7, Notification of Changes.

-----Original Message-----
From: Ramón Corominas [mailto:listas@ramoncorominas.com] 
Sent: Friday, June 20, 2014 3:47 PM
To: Devarshi Pant
Cc: SALES, TERRY LYNN; Sailesh Panchang; WAI Interest Group
Subject: Re: aria-label usage in table cells

"Advisory" in this context means "not required to understand the content, but might add some degree of usability". That is, you cannot rely on the title attribute to convey important information. If I understood well your case, you are giving this information in the table headers, so you are not relying on @title, isn't it?

Regarding the use of @title when you cannot use a label, it refers only to form controls. In this case, when a form control has no associated label, the @title is mapped to the accName property in the accessibility API, so it is read by the screen reader exactly the same as the label. 
It could also used by voice recognition software, and of course presented to mouse users.

For keyboard-only sighted users it would certainly not work, but remember that the technique is intented only for situations where a visible label is present, thus allowing the sighted user to identify the field (or components of the field). For example, imagine that you have a "birthdate" label (probably within a <legend>) above three separate <select> fields (day, month, year). For design reasons you might not be able to use visible "day", "month" and "year" labels, but the "birthdate" is assumed to be enough for sighted users.

Regards,
Ramón.

Devarshi wrote:

> I am with you on comparable access, but who is at fault here -- 
> developer, browser, business, or spec? Isn't the title attribute 
> supposed to be exposed to sighted keyboard only users?  Spec says 
> "This attribute offers advisory information about the element for 
> which it is set."
> 
> A case in point, and it may be extended to large data tables where 
> column / row headers are not visible to all user groups - H65: Using 
> the title attribute to identify form controls when the label element 
> cannot be used (http://www.w3.org/TR/WCAG20-TECHS/H65) - Question: can 
> a project team using standard code claim compliance because the title 
> attribute serves screen reader and mouse users and possibly other user 
> groups , but not sighted keyboard only users? Would it be advisable to 
> fail that page even though the team used standard code (or at least tried)?
> -Devarshi

Received on Monday, 23 June 2014 19:21:31 UTC