- From: Ramón Corominas <rcorominas@technosite.es>
- Date: Tue, 03 Jun 2014 18:52:42 +0200
- To: jared@webaim.org
- CC: David MacDonald <david100@sympatico.ca>, Steve Faulkner <sfaulkner@paciellogroup.com>, WCAG <w3c-wai-gl@w3.org>
David: 1) Layout tables that are ignored (no matter what the markup is): no failure, but a recommendation to add at least role="presentation", and also to avoid table markup completely, if possible/feasible. 2) Layout tables not ignored: depending on the content and the confusion that this might cause to the user, but usually I would mark it as a failure of SC 1.3.1 because the visual presentation does not imply that there is a table; let's say that the "clean" presentation is not being conveyed to the SR user. In any case, it depends on the complexity of the information being read by the SR. No failure of 4.1.2 because I understand it is intended for -interactive- UI components only. 3) Layout tables identified as data tables (for example, containing <th> or <caption>): failure of SC 1.3.1 due to conveying structure that is not present visually. 4) In any case, for layout tables I would check also SC 1.3.2 (sequence). No failure of 4.1.1 since it only says "nested according to the spec", and not "used according to the spec". 5) Data tables ignored or read as layout tables: I've never experienced this, but it would be a failure of SC 1.3.1. 6) Data tables that do not identify -some- headers: if they are properly marked, I would not flag them as failing, but I would probably warn about the issue and try to provide suggestions if something can be done to enhance reading. This can happen, for example, with certain data tables that could benefit from adding @scope or @id/@headers. Regards, Ramón. Jared wrote: > 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:54:16 UTC