Re: University of Illinois automated tool WCAG failures

ps... a short link for the long link  to the wiki article (which drops on
the mail archives) is here:
*http://tinyurl.com/ht2nnlx <http://tinyurl.com/ht2nnlx>*
There is no mention of any technique being required.

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

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 Fri, Jul 8, 2016 at 2:49 PM, John Foliot <john.foliot@deque.com> wrote:

> 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
>
>
>
>