- From: Jared Smith <jared@webaim.org>
- Date: Tue, 3 Jun 2014 10:15:34 -0600
- To: David MacDonald <david100@sympatico.ca>, Steve Faulkner <sfaulkner@paciellogroup.com>, WCAG <w3c-wai-gl@w3.org>
- Cc: "rcorominas@technosite.es" <rcorominas@technosite.es>
To avoid future confusion, my e-mail is jared@webaim.org, not jared@webaim.com as included in this thread. As Detlev noted, if the reading order is incorrect, then we would flag it as a 1.3.2 (Sequence) failure. If a layout table is being identified by AT as a data table due to incorrect usage of <caption> or <th> markup, then we would certainly identify this because it impacts accessibility. Our recommendation would be to not use this relational markup rather than simply adding role="presentation" to negate it. If the layout tables are used and there is no visual structure or relationships then I think it a stretch to consider this a 1.3.1 failure. It seems many are interpreting this success criterion in reverse. Normative 1.3.1 requires that *presentational* structure and relationships be programmatically determined. It does NOT require that the underlying semantic structure used result in some matching presentational structure or relationship. WCAG does not require proper underlying markup to meet the success criteria so long as that markup does not violate 4.1.1 or 4.1.2 (or result in some other success criterion failure). With that said, using a <th> in a layout table could maybe be a 4.1.2 failure because its role is not correct. I suppose one could argue the same for <td>, though using it in a layout table has no impact on end user accessibility (excepting the situation in the next paragraph). If a layout table is being identified by a screen reader as a data table because the screen reader heuristics incorrectly assume it is one, then this is a screen reader deficiency, not a WCAG failure. An advisory technique that recommends role="presentation" would help address this issue. I did write something several years ago about JAWS incorrectly interpreting layout tables as data tables - http://webaim.org/blog/jaws-ate-my-tables/ I'm not sure if the values presented there are still accurate. It has been quite some time since I encountered a data table incorrectly identified as a layout table. I do, however, frequently encounter properly marked-up data tables that screen readers (particularly VoiceOver) do not read properly. It seems we'd have a bigger influence exerting pressure there than by adding failures or techniques for the sake of semantic purity when it has almost no end user impact. Jared On Tue, Jun 3, 2014 at 8:50 AM, David MacDonald <david100@sympatico.ca> wrote: > I've closed the issue due to insufficient support for an explicit failure. > > On a separate note, I would like comments from Steve, Leonié, Alestair, > Ramón, Sailesh, Jared etc. > > Say, you are evaluating a public facing site with a layout table mising > role=presentation which is announced as a data table in JAWS, VO, NVDA and > in the API. Do you > > (1) flag a best practice and suggest they add role=presentation knowing > that many companies filter out best practices when entering things into the > remediation cue, or > (2) flag it as a failure of 1.3.1 given that the information is not data, > but presented as such. Or > (3) pass it > > > Cheers, > > David MacDonald > > > > CanAdapt Solutions Inc. > > Tel: 613.235.4902 > > LinkedIn > > www.Can-Adapt.com > > > > Adapting the web to all users > > Including those with disabilities > > If you are not the intended recipient, please review our privacy policy > > > On Tue, Jun 3, 2014 at 5:03 AM, Ramón Corominas <rcorominas@technosite.es> > wrote: >> >> @Loretta: I agree that a sufficient technique is a better approach. >> >> @Steve: adding role="presentation" to a <table> element does not change >> the table markup, so it would be still a misuse of the spec, so in reality >> the <table> should be changed to <div> with classes and so on. >> >> In any case, my main concern is that the addition of role="presentation" >> is not as easy as it sounds... >> >> Imagine that we have a web tool for an intranet that was created using >> layout tables, and that was originally tested for conformance with the >> specific set of OS, browser and AT defined by the organization. In this >> closed environment, layout tables are properly ignored (even if this is done >> through "desperate attemps" of the AT to ignore them). IMO, the fact is that >> they are "supported". The tool contains also normal data tables, properly >> marked with <caption>, <th> and so on, so it has both layout tables and data >> tables mixed together in the same page. >> >> In this scenario, adding a role="presentation" only to layout tables is >> not trivial, and the task cannot be easily automated. indeed, the automated >> process would need to re-create the same desperate heuristics that the AT is >> already performing, so the effort to "technically conform" could be huge >> while the practical benefit for the users would be null. >> >> >> I would also like to know what are the conditions that a failure must >> meet, it seems that there are different opinions. In any case, from my >> experience many developers and evaluators consider failures as "normative >> rules" that always prevent conformance, but my understanding is that they >> should be treated as informative only. Therefore, they should be considered >> under accessibility support in the specific usage context, especially when >> we are monitoring an existing website that was marked as "valid" prior to >> the existence of the Failure. >> >> Regards, >> Ramón. >> >> >> >> >
Received on Tuesday, 3 June 2014 16:16:06 UTC