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: "Describe the affirmative condition of the passing content
<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