RE: University of Illinois automated tool WCAG failures

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

 

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.

 

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?

 

​​​​​

 

 

 

* katie *

 

Katie Haritos-Shea 
Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)

 

Cell: 703-371-5545 |  <mailto:ryladog@gmail.com> ryladog@gmail.com | Oakton, VA |  <http://www.linkedin.com/in/katieharitosshea/> LinkedIn Profile | Office: 703-371-5545 |  <https://twitter.com/Ryladog> @ryladog

 

From: John Foliot [mailto:john.foliot@deque.com] 
Sent: Friday, July 8, 2016 10:57 AM
To: 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

 

​​

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, WCAG explicitly states <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> Describe the affirmative condition of the passing content")

 

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