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
>
>
>
> *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 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 <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 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 <http://www.w3.org/html/wg/drafts/html/master/>
>>
>>
>>
>> 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.
>>  >
>>  >
>>
>>  >
>>  >
>>
>>
>>
>>
>>
>>
>>
>
>