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

Andrew wrote:
Is testing with real AT enough? 

To me, no, and in reality it is only "helpful" to determine the status of how various products handle rendering of specific content elements.  The underlying issue has to be to me if the page was coded in such a way that the information is provided for At use.  Not if one or another AT actually does use it appropriately.  For that matter some browsers don't support various content types so don't make it available to the AT and hence to the end-user with AT--but a developer has no control over that unless we are asking for a tied down AT/IT environment determination only for a snapshot in time.  Six months later with new versions of browser and AT product results may vary, so the results are limited by environment.  A baseline of correct coding is the essential evaluation criteria to me because all else can change around that, but a developer, the guy on the hook for making stuff meet success criteria, is responsible for the code, and can meet requirements if they focus on that aspect primarily.  



-----Original Message-----
From: Andrew Kirkpatrick [mailto:akirkpat@adobe.com] 
Sent: Monday, June 02, 2014 9:20 AM
To: rcorominas@technosite.es; faulkner.steve@gmail.com
Cc: Wilco Fiers; Web Content Accessibility Guidelines Working Group
Subject: RE: WCAG-ISSUE-23 (DavidMacD): We should consider a new "Failure to provide role=presentation on a layout table"

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":

Ramon,
I tried your table (https://awkawk.github.io/layout_table.html) with JAWS 15/FF and got the following speech when reading line-by-line:

Layout Table Example - Mozilla Firefox
Layout Table Example

heading level 1 Layout Table Example

table with 2 columns and 3 rows
heading level 1 My page

table with 1 columns and 1 rows nesting level 1
heading level 2 My article

This is my article
table end nesting level 1

table with 1 columns and 1 rows nesting level 1
heading level 2 My sidebar

This is my sidebar
table end nesting level 1

© My Website 2014

That said, I like the concept of requiring a way to programmatically and positively identify layout tables.  In the past there have been suggestions that layout tables should be marked with summary="" (I am in no way advocating for this now, just to be clear!) and even now we are talking about different heuristics to identify layout tables.  It seems that the big issue is that assistive technologies could implement the idea that Jon Avila suggested (essentially "no TH = layout table") and the result would probably be very good for not treating layout tables as tables, but I suspect that it would also be disliked as it would also make tables that are incorrectly coded today but correctly regarded as data tables less accessible for the screen reader users.

But I also go back to the questions about what does this do to the set of pages with currently conformant tables and what is the real impact on screen reader users.  As layout tables are less ubiquitious now and with HTML5 requiring role=presentation on layout tables, is this actually less of a problem now?  Would this be a technique that is addressing an old but diminishing problem?

I don't know the answers to all of these questions, but I'm sure that we'll be talking about it more...

AWK

Received on Monday, 2 June 2014 13:30:22 UTC