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

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


David MacDonald

*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn <>

*  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 <>

> @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 14:50:38 UTC