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: Gunderson, Jon R <jongund@illinois.edu>
Date: Mon, 2 Jun 2014 14:55:27 +0000
To: David MacDonald <david100@sympatico.ca>
CC: "Hoffman, Allen" <allen.hoffman@hq.dhs.gov>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>, Steve Faulkner <faulkner.steve@gmail.com>, Wilco Fiers <w.fiers@accessibility.nl>, Alastair Campbell <acampbell@nomensa.com>, Léonie Watson <lwatson@paciellogroup.com>
Message-ID: <46739F12637CC94E82F75FF874E4A14736390CAA@CITESMBX6.ad.uillinois.edu>
I believe it is also important to support web standards.

So there is now a defined way (e.g. through the ARIA spec) to identify a table being used for layout using role="presentation" on the table elements.

If we want people to use the engineered solution it has to promoted as technique to satisfy WCAG SC 1.3.1 and/or 1.3.2.

If web designs start using role="presentation" on table elements correctly, AT vendors will start to support it.

Jon

From: CAE-Vanderhe [mailto:gregg@raisingthefloor.org]
Sent: Monday, June 02, 2014 9:46 AM
To: David MacDonald
Cc: Hoffman, Allen; GLWAI Guidelines WG org; Steve Faulkner; Wilco Fiers; Alastair Campbell; Léonie Watson
Subject: Re: WCAG-ISSUE-23 (DavidMacD): We should consider a new "Failure to provide role=presentation on a layout table"

Good idea to revisit or refresh what failures are

My thoughts on this



Documented FAILURES in the WCAG techniques document

  *   the WCAG failures are NOT a list of all ways to fail
  *   they are only  COMMON ONES
  *   they should only be CERTAIN ones.   (that is - they shouldn't be listed unless they are ALWAYS failures
  *   since AT someday could be strong enough to read pages just from the pixels  (someday a long time from now) - all failures are in some way failures only because AT isn't strong enough.   So we can't eliminate failures due to AT from being failures

     *   that having been said, something that is due to a bug or shortcoming or only some AT should not make the Failure list.
     *   they WOULD be failures if there is NO AT support  (because that is required)
     *   but if it is ambiguous or temporary or only some AT - then it may or may not fail but should NOT be listed in our FAILURES

  *   WCAG documented Failures - should be

     *   COMMON
     *   CONSISTENT  (always failures)
     *   ENDURING  (not something that can/might be solved soon)
     *   SERIOUS   (has genuine impact on users )


this is my take on this - to spur the discussion - and not anything official

Gregg








On Jun 2, 2014, at 7:39 AM, David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>> wrote:


Perhaps this is a good time to explore and review what we are trying to do with failures, and with WCAG in general. It seems with each new crop of members it is a good time to revisit our goals. It is difficult to articulate a perfect algorithm of when we create a failure technique. Here is my understanding from way back of some of the conditions that would bring us to introduce a failure technique.
1) Is it a common problem that disproportionally affects people with disabilities?
2) Is it a problem that technology has now solved but that authors are still not doing?
3) Are AT repair techniques non-uniform, or patchy?
4) Is there momentum, general consensus, and desire among those in the disability community to see it fixed
5) Is is easy to fix OR is impact on the authoring community such that industry can live with the requirements
I think if the answer is yes to all of these, then a failure could/should be considered. I'm interested to other's thoughts. We can achieve nothing as a group unless we find consensus.

I agree with Ramon, that failures are stronger than techniques and need to be more rigorous in their application. On the other hand those of us who have been working with developers for a long time generally understand that little gets done until a failure is articulated, it's just human nature. So it's with all these balanced considerations that I suggest we introduce some sort of a failure of 1.3.1 for missing role="presentation" layout tables.

Cheers,
David MacDonald


CanAdapt Solutions Inc.
Tel:  613.235.4902
LinkedIn<http://www.linkedin.com/in/davidmacdonald100>
www.Can-Adapt.com<http://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 Mon, Jun 2, 2014 at 7:51 AM, Hoffman, Allen <allen.hoffman@hq.dhs.gov<mailto:allen.hoffman@hq.dhs.gov>> wrote:
Some screen readers "can" ignore layout tables when presenting the information, but they don't really ignore them they simply don't enable cell coordinate-type navigation commands explicitly as they do in what they feel are data tables.  In reality layout tables would be improved with some mechanism that programmatically associates specific information as needed by the layout, however, I'm not aware of such a mechanism presently.

I'm still not a subscriber to a strategy of creating a failure condition based on specific assistive technology current development status.  If the information is available but not utilized by assistive technologies presently it is not the responsibility of the developer to take further steps, unless the developer wants to specifically code something for particular AT environments.  Adding on nice usability stuff is great, but frankly if we can just get ourselves to the accessible point we'll be darned proud of ourselves.

How would such AT-status conditions be maintained?  Who would validate when one product now supports the lack of access and then determines the change to the failure condition?  It's a maintenance nightmare.

Accessibility challenges would be a more descriptive designation for such situations and guidance, and such would be a moving target.



From: Steve Faulkner [mailto:faulkner.steve@gmail.com<mailto:faulkner.steve@gmail.com>]
Sent: Monday, June 02, 2014 4:08 AM
To: Wilco Fiers
Cc: 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"


Suggest the success criterion would be 1.3.1 Info and Relationships.
I also ask ramon and sailesh to provide data on the claims that layout tables are ignored by screen readers. I understand that some SR's use heuristics to try to determine whether a table is being used for layout or not, but these mechanisms are fallible. Anecdotally in my day to day work I encounter usage of layout tables the semantics of which are (incorrectly) announced by SR's. It should also be noted that regardless of the AT behaviour, the roles/properties of layout tables are always exposed in accessibility APIs whenever they are used. role=presentation provides an unambiguous indicator (and depending on the browser) actually removes the semantics from the accessibility tree.


--

Regards

SteveF
HTML 5.1<http://www.w3.org/html/wg/drafts/html/master/>

On 2 June 2014 08:39, Wilco Fiers <w.fiers@accessibility.nl<mailto:w.fiers@accessibility.nl>> wrote:
Hi everyone,
I think Sailesh and Ramón make an excellent point. Under which success criterion would you say this is a failure? Perhaps I'm mistaken, but it does not seem like any of the success criteria currently require this. It would therefore seem that adding this failure technique would broaden the scope of a success criterion beyond what it was initially designed for. And considering that WCAG 2.0 is normative and the techniques are not, I don't think that's something techniques should do.

Regards,
Wilco

________________________________________
Van: Sailesh Panchang [spanchang02@yahoo.com<mailto:spanchang02@yahoo.com>]
Verzonden: zondag 1 juni 2014 17:03
Aan: Web Content Accessibility Guidelines Working Group; rcorominas@technosite.es<mailto:rcorominas@technosite.es>
Onderwerp: Re: WCAG-ISSUE-23 (DavidMacD): We should consider a new "Failure  to  provide role=presentation on a layout table"

I second Ramón : not having role=presentation on layout tables cannot be a failure.
Sure ARIA / HTML5 may permit  one to explicitly mark layout tables with the role but it cannot be 'required'.
In several cases, it may be redundant and create extra work for developers. Consider:
A table with a single column or row or even a table  with 2 rowslike:
<table><tr><td colspan=2">Some content</td></tr>
<tr><td>something 1</td><td>Something 2</td></tr>
</table>
Consider the content that is up there but will fail WCAG2 because this role is not set on the layout tables.
The role will certainly help AT when used on a 2x2 type layout table that is most likely interpreted as a data table.
Regards,
Sailesh

--------------------------------------------
On Sun, 6/1/14, Ramón Corominas <rcorominas@technosite.es<mailto:rcorominas@technosite.es>> wrote:

 Subject: Re: WCAG-ISSUE-23 (DavidMacD): We should consider a new "Failure  to  provide role=presentation on a layout table"
 To: "Web Content Accessibility Guidelines Working Group" <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
 Date: Sunday, June 1, 2014, 8:05 AM

 Hello all,

 Although I agree that layout
 tables are evil and should die, I cannot
 see this as a WCAG failure. Simple layout
 tables (no <th>, no <caption>,
 no @summary) are usually ignored by most screen
 readers, even if they
 don't have the
 role="presentation", and behavior does not change

 whenadding it. Therefore, I cannot find a
 justification to include a
 failure that
 would force developers to add a role that has no practical

 effect on accessibility.

 Regards,
 Ramón.

 Steve
 noted:

 > Note: HTML5
 requires role=presentation on layout tables
 >
 > " If a table is
 to be used for layout it MUST be marked with the
 > attribute role="presentation"
 for a user agent to properly represent the
 > table to an assistive technology and to
 properly convey the intent of
 > the
 author to tools that wish to extract tabular data from the
 document."
 >
 >
 http://www.w3.org/html/wg/drafts/html/master/tabular-data.html#the-table-element
 > --
 > On 1 June 2014
 10:14, Web Content Accessibility Guidelines Working Group

 > Issue Tracker <sysbot+tracker@w3.org<mailto:sysbot%2Btracker@w3.org>
 <mailto:sysbot+tracker@w3.org<mailto:sysbot%2Btracker@w3.org>>>
 wrote:
 >
 >
    WCAG-ISSUE-23 (DavidMacD): We should consider
 a new "Failure to
 >
    provide role=presentation on a layout
 table"
 >
 >
    http://www.w3.org/WAI/GL/track/issues/23
 >
 >
    Raised by: David MacDonald
 >     On product:
 >
 >     We
 should consider a new "Failure to provide
 role=presentation on a
 >
    layout table." In the old days there were
 many wars about whether to
 >
    allow layout tables. wai aria has now solved
 the issue pretty well
 >
    and we should consider requiring it now on
 layout tables.
 >
 >

 >
 >
Received on Monday, 2 June 2014 14:57:06 UTC

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