- From: David MacDonald <david100@sympatico.ca>
- Date: Mon, 2 Jun 2014 10:19:51 -0400
- To: Loretta Guarino Reid <lorettaguarino@google.com>
- CC: "Hoffman, Allen" <allen.hoffman@hq.dhs.gov>, Web Content Accessibility Guidelines Working Group <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: <BAY179-W76B8EAEF3CAC11E869D94EFE200@phx.gbl>
Hi Loretta
It is as I say " ... my understanding of the WCAG historical decision process for a Failure technique." I'd be glad for you, Michael, Gregg, Wendy, Cynthia, and Ben to chime in... it might be an important piece of corporate history.
Date: Mon, 2 Jun 2014 07:10:45 -0700
From: lorettaguarino@google.com
To: david100@sympatico.ca
CC: allen.hoffman@hq.dhs.gov; w3c-wai-gl@w3.org; faulkner.steve@gmail.com; w.fiers@accessibility.nl; acampbell@nomensa.com; lwatson@paciellogroup.com
Subject: Re: WCAG-ISSUE-23 (DavidMacD): We should consider a new "Failure to provide role=presentation on a layout table"
David, where did this list come from? I can't say that it perfectly matches my recollection (not that my memory is infallible).
On Mon, Jun 2, 2014 at 6:41 AM, David MacDonald <david100@sympatico.ca> wrote:
>The
question I have from reading the informal list of criteria is where is
the simple criteria that it actually is a failure of the specific
guideline?
The name of the proposed failure is "Failure of SC 1.3.1. ..."
Although I'd love to take credit for the list, for better or worse, it is my understanding of the WCAG historical decision process for a Failure technique. For testability each failure has a test procedure. We've worked hard to make every test procedure clear and understandable even though most cannot be automated. There is a fair amount of documentation about what WCAG means by testable. The new Evaluation Methodology attempts to bring greater clarity to the weird and wonderful world of conformance, we're always looking for contributors.
Cheers,
David MacDonald
CanAdapt Solutions Inc.
Tel: 613.235.4902
LinkedIn
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
On Mon, Jun 2, 2014 at 9:02 AM, Hoffman, Allen <allen.hoffman@hq.dhs.gov> wrote:
This is just me speaking, but to me we need simple, clear and unambiguous objectives for creation of, review of, and
distribution of things like failure conditions.
I am not intending to be critical of your list David, but they don’t seem to fit that description well to me.
Maybe I’m not reading and processing well this morning, if so forgive my slowness this time.
The question I have from reading the informal list of criteria is where is the simple criteria that it actually is a failure of the specific guideline?
In my opinion that should be the absolute and overriding criterion.
Whether some nebulous group feels this is a problem or not, or if current “today at time of writing” AT product implemented access solution to use correctly coded information, should not be a criteria for creating a failure condition.
I thing I do understand accessibility supported, and you can easily fail to meet success criteria if you use techniques which simply are not accessibility supported in the sense that no AT can get to the information, in more than a custom configuration,
but for something as forceful as “this is a failure to meet success criteria”, we need clear rationale for failing beyond product specificity or “feeling” that a problem exists.
This stuff is important for the people involved in development, testing, and acceptance, and any and all ambiguity creates confusion, multi-interpretations, and at the end of the day detracts from consistently making forward progress across the board
so people with disabilities have increased access.
I know I’m always on this same topic, but it is very important to me and I work on this every day.
I know ambiguity creates problems for folks, slows the wheels of progress, and at the end of the day can greatly
dealy accessibility for end-users with disabilities.
I love sufficient techniques and failures, but want to ensure we create them clearly without ambiguity or unneeded complexity.
I don’t even know what my opinion on this specific failure idea is yet but the discussion seems to be straying in to that area of which AT might or might not implement support for correctly coded content, and to me as long as it is coded and AT can use
it, it can’t be a failure period. I don’t care if JAWS, windows eyes, or NVDA, or HAL supports a coding solution, if
its there they should support it, and most likely will in the short term at their schedule and per their customer request.
Could be nobody cares and they won’t implement support for it—one AT vendor I won’t name held out on Java
AccessBridge support for years.
From: David
MacDonald [mailto:david100@sympatico.ca]
Sent: Monday, June 02, 2014 8:39 AM
To: Hoffman, Allen; Web Content Accessibility Guidelines Working Group
Cc: 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"
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
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
On Mon, Jun 2, 2014 at 7:51 AM, Hoffman, Allen <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]
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
On 2 June 2014 08:39, Wilco Fiers <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]
Verzonden: zondag 1
juni 2014 17:03
Aan: Web Content Accessibility Guidelines Working Group;
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> 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>
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+tracker@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:20:22 UTC