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

David,
I'll revise that a bit: Difficult to be very categorical without
reference to the content and context.
If the layout table simply contains form controls  (2 col table for
instance), I'd not call it as a failure.
If it were a 2 col table with a link in every cell, I'd say using list
mark up to group related links is the better approach and it will not
fail.
But sometimes there are larger tables with nested tables within and
perhaps blank rows / columns. SR readers may end up navigating this to
make sense out of it. I'd call this a failure and encourage them to
use role=presentation. I'd also check for reading order issues.
Thanks,
Sailesh


On 6/3/14, 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
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902
>
> LinkedIn <http://www.linkedin.com/in/davidmacdonald100>
>
> 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
> <http://www.davidmacd.com/disclaimer.html>
>
>
> 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 15:55:33 UTC