- From: Devarshi Pant <devarshipant@gmail.com>
- Date: Mon, 23 Jun 2014 16:16:56 -0400
- 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>
- Message-ID: <CAJGQbjuvi-88t-WO9T3BJvoVCF3WfXV-xq3skxeJTA0AEAGRGw@mail.gmail.com>
"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