RE: University of Illinois automated tool WCAG failures

John,

>I don't think this is a question of my not respecting David, it is about having a fundamental disagreement about how we move forward, which I have attempted to outline clearly, calmly, and professionally. It is not my intention (nor was it ever) to attack David personally, and I am troubled that you see it that way.

​​​​​Here is how it *appears* to me.....when David suggested a new Failure Technique that (BTW, once discussed) did NOT require Landmarks, you lambasted the idea, and suggested that WCAG should focus on Sufficient techniques instead of Failures.....then when he brings ideas for some place to start with some new Sufficient techniques (from Jon's FAE tool rules - a very good idea I might add).....you seem to want to teach him about WCAG 2, quoting some of the very text that he himself may have written....

I am suggesting that many, including myself, would appreciate it if you spent more time, on this list, offering suggested text for those Sufficient techniques you would like to see - than criticizing what other bring forward (unless it is to politely suggest improved wording). 

You have so very much good to offer John, but the verbal gymnastics, lack of respect and showmanship is exhausting - and, is less than helpful. 

Most importantly, I am afraid your posture may deters others from wanting to contribute. 

Please, I am asking you, just try to be more thoughtful and respectful of others and their experiences - when offering your suggestions.

* katie *
 
Katie Haritos-Shea 
Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)
 
Cell: 703-371-5545 | ryladog@gmail.com | Oakton, VA | LinkedIn Profile | Office: 703-371-5545 | @ryladog


-----Original Message-----
From: John Foliot [mailto:john.foliot@deque.com] 
Sent: Friday, July 8, 2016 2:49 PM
To: 'Katie Haritos-Shea GMAIL' <ryladog@gmail.com>; 'Gregg Vanderheiden' <gregg@raisingthefloor.org>
Cc: 'David MacDonald' <david100@sympatico.ca>; 'GLWAI Guidelines WG org' <w3c-wai-gl@w3.org>; 'Jon Gunderson' <jongund@illinois.edu>
Subject: RE: University of Illinois automated tool WCAG failures

Katie Haritos-Shea GMAIL wrote:
>
> I have to say I cringe at the thought of someone quoting the requirements, text, and what is normative and not normative, of WCAG 2, to David MacDonald……I’ll just have to hope one was shooting for trying to teach a broader audience…..I would like to think however that that broader audience would not include the WCAG WG itself…..
>
> Perhaps this ‘teaching’ of WCAG 2 is better suited for places outside this WG. Reminders are one thing, teaching is another…..

Hi Katie,

I'm sorry if you think reminding this list about the status of Techniques may not be in scope, however I will note that currently there are 85 members in this WG (https://www.w3.org/WAI/GL/participants.html), even if we traditionally only hear from a small sub-set of that group on a regular basis. I personally have had at least one member of this WG say to me directly that they traditionally lurk on this list as they are attempting to learn more, and so I think that taking the opportunity to revisit what some members of this WG may consider 'obvious' is not a bad thing in and of itself. I also prefaced my comments with the statement "... I am also struggling with terminology here", and so I leave open the possibility that there is nothing but a communication issue here. 

Maybe David could explain what he means on that page when it says "Required"?


>
> Respectful discussions though, in my mind, are awesome, and hopefully what we are all about! Suggestions for different/better text is always welcome when one is critiquing what someone else had taken the time to provide.

I don't think this is a question of my not respecting David, it is about having a fundamental disagreement about how we move forward, which I have attempted to outline clearly, calmly, and professionally. It is not my intention (nor was it ever) to attack David personally, and I am troubled that you see it that way.

You noted below that we had a previous issue with some actors not clearly understanding the difference between normative Success Criteria language and non-normative Techniques, to the point where, as you state, "... We only clarified more specifically the fact that they were not required in WCAG documentation, just a few years ago – based on the problems that arose from places making them required." For this reason, *I* cringe when we appear to be returning to talking about Techniques and "Required" in the same sentence; doubly so when the shared document suggests that some things are "HTML4 Techniques: Recommended"(column) and "HTML5 and ARIA Techniques: Required"(column).  No Techniques are "Required" - a point, by your own admission, this WG had to previously clarify "...because of the problems that arose".


>
> Some countries, not understanding that Techniques were not required, chose to make them *required* by their state or country laws. Some places in Canada were some of those places (and maybe Italy?), as I recall. We only clarified more specifically the fact that they were not required in WCAG documentation, just a few years ago – based on the problems that arose from places making them required.
>
> Perhaps it is possible the *required* in this documentation came from that?

Perhaps, and if this is the case, getting that clarification is, I think, useful (but not currently present) - and again "... I am also struggling with terminology here."

Many individual countries & other organizations take WCAG and then apply their own 'personalization' to the standard: in Canada there is both the adoption of WCAG 2.0 into the federal "Common Look and Feel" requirements (with some specific exclusions: https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=23601#appB), and both the provinces of Ontario (AODA) and Quebec (SGQRI 008-01) have provincial standards that are based upon WCAG 2.0, but again with some modifications. 

If the context of David's "Required" is through any of those lenses then I think that should be clearly articulated - so yes, it is *possible*, but if so, let's say so, so that those who are not impacted by this are clear in their own minds as to what is or isn't Required per the W3C's WCAG 2.0 (or 2.1 / 2.next / "Silver"). I'll also note that David wrote:  "I did an analysis of all of the checks in the University of Illinois Functional Accessibility Evaluator (FAE) by Jon Gunderson, through the lens of WCAG 2.", and so on first read-through I don't think he was referencing anything but the W3C WCAG 2.0 Recommendation.

​​​​​However...

Under the heading "Take aways for David" he notes: "I would like to introduce the following new common failures to WCAG. - Failure of 1.3.1 due to not including main element or role="main" on the main content of an HTML page.", and a significant number of the other takeaways all appear related to "requiring" landmarks (either HTML5 elements or ARIA landmarks). We have had this discussion internally within this WG as recently as May (https://github.com/w3c/wcag/issues/173), where we discussed the role of landmarks in great length, and where I heard a broad consensus that we cannot (and should not) be mandating "techniques":

 "well you can't require headings (which are only but one possible technique) if there are other ways to achieve an acceptable outcome for the SC." - Patrick Lauke
 "But can we now fail a page today that has passed WCAG2 yesterday without landmarks? So for practical reasons, I hesitate to call it a failure." - Sailesh Panchang
 "since landmarks did not exist it is likely that the spirit was that regions of content did not need to be distinguished under 1.3.1." - Adam Solomon
 (source: all comments taken from https://github.com/w3c/wcag/issues/173) 

The GitHub discussion (and related emails and conference call discussions) coalesced around deferring this to WCAG.next ("Closing as a result of the May 24 discussion and adding the "WCAG.Next label" to ensure it doesn't get lost." - AWK), but there was opposition from more than just myself about making landmarks "required" at that time, especially when David suggested on one of our calls that it was "easy" to implement and "didn't take much time to do" - interpreted by myself and others on that call as David wanting to mandate landmarks going forward.

If it is the consensus of this WG to investigate whether or not we should mandate page landmarks as part of WCAG 2.1, then I would suggest we start by fleshing out some proposed SC language to discuss and evaluate - however I will continue to argue against mandating specific patterns. 

But if the intention is to somehow try to make landmarks "required" through the use of a Failure Technique then I would again suggest that this is a wrong approach - it was wrong for 2.0, and I will argue it is wrong for 2.1. as it continues to perpetuate the 'misunderstanding' that this WG "... clarified more specifically... just a few years" around Techniques.

If more Failure Techniques is a requirement for territorial or organizational interpretations of WCAG 2.x going forward, and David or others want to work on Techniques (Success or Failure) then that work is valuable, and worth supporting, as long as it is crystal clear to the larger Working Group and the consumers of those techniques documents that this does not mandate a specific pattern (a.k.a "You MUST use landmarks"), unless that is in fact the consensus and explicit recommendation of this Working Group, which would derive from a new Success Criteria (or modification of an existing SC).

Respectfully,

JF

*****

From: John Foliot [mailto:john.foliot@deque.com] 
Sent: Friday, July 8, 2016 10:57 AM
To: Gregg Vanderheiden <mailto:gregg@raisingthefloor.org>
Cc: David MacDonald <mailto:david100@sympatico.ca>; GLWAI Guidelines WG org <mailto:w3c-wai-gl@w3.org>; Jon Gunderson <mailto:jongund@illinois.edu>
Subject: Re: University of Illinois automated tool WCAG failures

​​
Hi David,

While I wholeheartedly agree with Gregg regarding alignment with 2.0. versus 2.1, I am also struggling with terminology here. Specifically, on your wiki page you note that "Techniques" are *required*. No, they aren't, and by my reading and understanding of WCAG 2.0, they never were. In fact, when it comes to Techniques, https://www.w3.org/TR/WCAG20/#intro-layers-guidance:

Sufficient and Advisory Techniques - For each of the guidelines and success criteria in the WCAG 2.0 document itself, the working group has also documented a wide variety of techniques. The techniques are informative and fall into two categories: those that are sufficient for meeting the success criteria and those that are advisory.

(Informative, not normative)

Techniques are ways of successfully accomplishing any given Requirement, but many of the existing SC have multiple Techniques for passing a SC - and any 1 of the collection of techniques for any given SC will meet the requirement, yet none of the existing techniques are "Required".

The way I see and understand WCAG, it is a list of functional outcomes that must be met to ensure accessibility. *HOW* the page author achieves the outcome is less important than the fact that they *HAVE* met the outcome. An easy example is that images must have an accessible name, and while the simplest and most common way of achieving that is to use the alt attribute, the functional requirement can also be met with any number of other techniques (https://www.w3.org/WAI/WCAG20/quickref/?showtechniques=111#qr-text-equiv-all) and in fact, that entire referenced section starts with the provision, "Sufficient Techniques - Note: Other techniques may also be sufficient if they meet the success criterion." 

Landmarks are another example (whether via HTML landmark elements or via aria-landmarks) and are, as you have noted, techniques that emerged after the publishing of WCAG 2.0. I have no issue suggesting that today either of those techniques is a Best Practice, but given that we could satisfy SC 2.4.1 *prior* to the emergence of either of those constructs, we cannot now say that you *FAIL* because you haven't used either of those techniques, and less than 5 minutes searching the web today could likely turn up examples where pages are functionally accessible without the use of either. The Requirement for successfully meeting 2.4.1 is that a *mechanism* is provided to bypass blocks (a.k.a. block-level navigation), not that landmarks MUST be provided. As such, a "Failure Technique" that somehow suggests a page does not conform to 2.4.1 because landmarks are not present is, to me, unacceptable and outside of the design of how WCAG was created, which was to establish the expected outcomes, and let the developers deliver to those outcomes. (As well, I recall, this Working Group discussed the "requirement" for landmarks at great length earlier this year, and I have a reasonable expectation that the WG's position on this topic won't change.)


You also note on the wiki page the following:

* Introduce new failure of WCAG 1.3.1 due to not programmatically associating a data table with a visual Tile or Label for that table. 

Outside of the fact that there are other ways of conveying information, structure and/or relationships of a table (<caption>, <details>, @aria-labelledby, and less so @aria-describedby, @summary), introducing a Failure Technique like this will not directly impact the normative text of WCAG 2.0, SC 1.3.1 which states:

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

...and so while ensuring a "Success" technique that illustrates those patterns for successfully meeting 1.3.1 is recognized as being valuable, I question the overall value of stating that a table without either fails 1.3.1, as that is simply not accurate nor true: other techniques exist. I am very concerned that we do not limit the creativity of designers or developers, nor emergent techniques or technologies that may come forward, and mandating specific development patterns is the first step down that slippery path.

Randomly looking at some of the other comments on your wiki, you note the following:

Image 3 Alt text must not include filename (and you note that it is "Required")

That might be an internal Univ of Illinois requirement, but it certainly isn't a normative requirement from WCAG, and I hope it never is. Based on this rule (as presented on the wiki page), what would you use as alt text for <img src="rose.jpg">? Reading that rule perhaps suggests that I cannot use alt="Photo of a rose" because the file name is rose (dot jpg). Or what if the image is being used in a Photoshop tutorial, and the appropriate alt text actually is <img src="rose.jpg" alt="Example of rose.jpg after applying a filter">? Demanding specific patterns is sometimes more harmful than helpful (and while it's possible the actual FAE text is more nuanced, this 'rule' none-the-less contradicts your own guidance on good Success Criteria: "http://davidmacd.com/blog/what-are-WCAG-success-criteria.html#p3")

Mandated patterns, and insisting on them to meet accessibility requirements, is the wrong way forward in my humble opinion, and I will continue to argue strenuously against heading in that direction, sorry.

JF

Received on Friday, 8 July 2016 19:34:25 UTC