- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Tue, 3 Jun 2014 11:22:49 -0400
- To: David MacDonald <david100@sympatico.ca>
- Cc: "rcorominas@technosite.es" <rcorominas@technosite.es>, WCAG <w3c-wai-gl@w3.org>, Jared Smth <jared@webaim.com>
David, Good question. I'd encourage them to use role="presentation" on such tables that are likely to be exposed to SRs as tables. And yes I'll mark it as a failure; but I'll not suggest that all existing layout tables need that role. Going forward, I'll advise they should integrate this into their processes so that all layout tables do have role="presentation" to remove ambiguity. Regards, Sailesh 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:23:16 UTC