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

Re: WCAG-ISSUE-23 (DavidMacD): We should consider a new "Failure to provide role=presentation on a layout table"

From: Ramón Corominas <rcorominas@technosite.es>
Date: Mon, 02 Jun 2014 11:28:29 +0200
Message-ID: <538C43BD.3000307@technosite.es>
To: faulkner.steve@gmail.com
CC: Wilco Fiers <w.fiers@accessibility.nl>, Web Content Accessibility Guidelines Working Group <w3c-wai-gl@w3.org>
Hi Steve and all,

> Suggest the success criterion would be 1.3.1 Info and Relationships.*

I agree, provided that the table is really identified as such, which is 
noy always the case. If this happens, I would mark the table as failing 
SC 1.3.1 and CR #4, since it is a use of the technology that is not 
accessibility supported.

> I also ask ramon and sailesh to provide data on the claims that layout 
> tables are ignored by screen readers.

Is testing with real AT enough? The following table, which also containt 
nested tables, is completely ignored by JAWS 14 + Firefox / IE 8 and 
Safari + VoiceOver (at least). They don't announce any table, they don't 
find any table; if you try to navigate tables, they say "no tables found":

<tr><td colspan="2"><h1>My page</h1></td></tr>
   <h2>My article</h2>
   <p>This is my article</p>
   <h2>My sidebar</h2>
   <p>This is my sidebar</p>
<tr><td colspan="2"><p>&copy; My Website 2014</p></td></tr>

Thus, I would say that -at least in this case- the layout table is a way 
of using technology that is "accessibility supported", that is, it "has 
been tested for interoperability with users' assistive technology". 
Maybe it is ugly, but it is supported.

That said, I've already stated that layout tables are a bad idea, but 
including a failure for tables that do not fail is IMO another bad idea. 
You can include strong recommendations or whatever, but failures should 
be reserved for things that always fail. For those cases where layout 
tables are not accessibility supported, it's fine to mark them as 
failing the SC and provide solutions, but for those that are not a 
barrier, telling developers that they must dedicate resources to solve a 
"no-barrier" issue is, IMHO, a very bad idea.

Adding 'role="presentation"' to layout tables sounds "easy", but it is 
something that cannot be easily automated. Authors would probably have 
to manually add it or to create their own heuristics to apply the 
attribute only to layout tables, which is not simple.

Indeed, it would be better to suggest that tables are changed to divs 
using display: table and so on, which is a better solution. If we 
consider a failure due to "not including role='presentation'" it would 
be even better to say: "Failure of SC 1.3.1 due to using tables for 
layout". Period. If someone has to create the heuristics to find the 
layout tables and apply the role="presentation", it is also feasible to 
recommend substituting <table> by <div class="table"> and so on.

Received on Monday, 2 June 2014 09:30:01 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:07:56 UTC