W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2014

Re: aria-label usage in table cells

From: Devarshi Pant <devarshipant@gmail.com>
Date: Mon, 23 Jun 2014 16:16:56 -0400
Message-ID: <CAJGQbjuvi-88t-WO9T3BJvoVCF3WfXV-xq3skxeJTA0AEAGRGw@mail.gmail.com>
To: Jonathan Avila <jon.avila@ssbbartgroup.com>
Cc: Ramón Corominas <listas@ramoncorominas.com>, "SALES, TERRY LYNN" <TERRYLYNN.SALES@cbp.dhs.gov>, Sailesh Panchang <sailesh.panchang@deque.com>, WAI Interest Group <w3c-wai-ig@w3.org>
"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."
> Interesting, so table navigation (or table layer keystrokes) wouldn't
work on these tables, and even if users could get to it, not knowing when
to change the mode in itself is a cause for concern.
"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."
> Agreed.


On Mon, Jun 23, 2014 at 3:30 PM, Jonathan Avila <jon.avila@ssbbartgroup.com>
wrote:

>  Ř  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
>
>
>
>
>
Received on Monday, 23 June 2014 20:17:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:51 UTC