RE: aria-label usage in table cells

Ø  neither does keyboard focus even with tabindex 0 reveal title attributes
(and probably shouldn’t on static text?). That said, while being aware of
such drawbacks, we can only do so much.



I’ve found that when you put JAWS in JAWSKey+Z mode in IE it often will
announced title attributes on tables and other elements that it wouldn’t if
you didn’t press insert+z.  This type of non-standard behavior can be very
confusing and I’ve seen organizations try to claim compliance around
methods that require screen reader users to use this mode.



<div title="this is read with insert+z " tabindex="0"> this is read without
insert+z </div>



Jonathan



*From:* Devarshi Pant [mailto:devarshipant@gmail.com]
*Sent:* Monday, June 23, 2014 3:01 PM
*To:* Ramón Corominas
*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"
>so regardless of the title attribute being advisory, is the page compliant
when a certain user group cannot access that information, however much
degree of usability it may provide?
"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?"
> We are applying titles only on data cells, but they only help mouse
users. A screen reader (JAWS 13) would not read title attributes on static
<TD>s, neither does keyboard focus even with tabindex 0 reveal title
attributes (and probably shouldn’t on static text?). That said, while being
aware of such drawbacks, we can only do so much.
-Devarshi



On Fri, Jun 20, 2014 at 3:46 PM, Ramón Corominas <listas@ramoncorominas.com>
wrote:

"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