Re: University of Illinois automated tool WCAG failures

> Specifically, on your wiki page you note that "Techniques" are *required*.

Hmmmm... Could you show me where the WIKI it says they are required? It
doesn't and it never did.
https://www.w3.org/WAI/GL/wiki/Failures_based_on_the_Functional_Accessibility_Evaluation_(FAE)_tool_from_the_University_of_Illinois

Now if you are quoting the analysis of the FAE tool which is not in the
WCAG group, outside the group domain, not on a wiki, it is simply a copy of
the FAE ruleset table with a column added for my comments about whether I
thought it was a candidate for WCAG.
Here is the original table http://fae20.cita.illinois.edu/rulesets/rc/

The table on my page of analysis is introduced appropriately, with a link
to the original. You would have to ask Jon about why the column with
"required" is in the table of tests, but I think his reasoning may be that
it is required for the test that he is running. My analysis has nothing to
do with that column and it appears to be a red herring argument to me.

There are about 100 checks in Jon's FAE tool and I'm suggesting we look at
about 25 of them which I've identified as candidates, because some might be
useful to our techniques document, and Jon appears to be open to including
them.


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 10:57 AM, John Foliot <john.foliot@deque.com> wrote:

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