Re: a suggestion for Personalization Semantics

Failure techniques are not the only way to fail WCAG. They are just common
ways that the working group recognizes collectively and agree on... the way
to fail WCAG is to not meet an SC.

As someone who was on nearly every call for 8 years and involved in almost
every decision I can without reservation say that the reason WCAG is
technology agnostic is so it can last a long time and remain relevant. It's
approach was intended to apply on to ways to meet WCAG and also ways to
fails it.

The SC clearly states what it states for a reason. Now if a member wants to
propose a consensus position that says "WCAG can never apply to new content
on the web and changing conditions of technology" they are free to do so...
and to see how it flies... but lack of consensus to add a failure technique
does not amount to consensus on anything.

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, Jan 12, 2018 at 11:27 AM, John Foliot <john.foliot@deque.com> wrote:

> The issue is this: adding a new Failure Technique to an existing SC that
> now is requiring something that was not required in the 2.0 Rec is
> effectively re-writing the Success Criteria.
>
> And while yes, Techniques (both Failure and Success) are non-normative, we
> have a small but significant issue: the non-normative Understanding
> Techniques for WCAG Success Criteria
> <https://www.w3.org/TR/2016/NOTE-UNDERSTANDING-WCAG20-20161007/understanding-techniques.html> *specifically
> states*:
>
> Content that has a *failure* does not meet WCAG success criteria, unless
> an alternate version is provided without the failure.
>
> Since Techniques are non-normative, and are all collected in one location,
> we do not have "2.0 Techniques" and separate but different "2.1
> Techniques", we simply have "Techniques", all in one big bucket. If the WG
> wants to change that, then the next required step would be to create that
> distinction (but then... does that further make Techniques 'normative'?)
>
> So retroactively adding a new Failure Technique that extends an existing
> SC to require 'more' to the collection of existing techniques for SC 1.3.1,
> effectively means that any and all documents that claim WCAG 2.0
> conformance today that do not use landmark notation will suddenly become
> non-conformant with the publishing of that non-normative yet strangely
> "quasi-normative" Technique, due to the advisory text I have quoted. (And,
> in fact, it is my personal belief that is exactly what David ultimately
> wants, as he has previously publicly stated that one of his clients will
> not add landmark regions unless it is specifically required by WCAG 2.0
> normatively or via a Failure Technique.)
>
> It is for this reason that WG members such as myself, James
> Nurthen/Oracle, and Alex Li/Microsoft strongly opposed further pursuit of
> this initiative. If we all feel that the presence of landmark elements or
> roles is important enough to be required, then make it an actual
> requirement; don't try and "back-door" it into the current Spec via a
> Technique on the most ambiguous of all of our 2.0 Success Criteria (1.3.1).
>
> JF
>
> On Fri, Jan 12, 2018 at 9:41 AM, Léonie Watson <tink@tink.uk> wrote:
>
>> The techniques are informative not normative. So at best they are a
>> recommendation from the WG on how to interpret a particular SC, they do not
>> make something mandatory, or prohibit its use in meeting the SC in question.
>>
>>
>>
>>
>> On 12/01/2018 15:11, David MacDonald wrote:
>>
>>>  >This Working Group has attempted to tackle this in the past, and the
>>> W3C consensus position is that WCAG 2.0 does not mandate their use.
>>>
>>> My understanding is that the consensus was "not to take the action to
>>> add a failure technique because of some members would not consent to adding
>>> it ... that is not the same as saying we took an action to have "consensus
>>> to not mandate their use",  ...  I don't provide my consensus to that
>>> proposal which has never been proposed.
>>>
>>> Not having consensus on one thing does not mean we have consensus on
>>> another.
>>>
>>> Cheers,
>>> David MacDonald
>>>
>>> *Can**Adapt**Solutions Inc.*
>>>
>>> Tel:  613.235.4902
>>>
>>> LinkedIn
>>> <http://www.linkedin.com/in/davidmacdonald100>
>>>
>>> twitter.com/davidmacd <http://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, Jan 12, 2018 at 9:52 AM, Alastair Campbell <
>>> acampbell@nomensa.com <mailto:acampbell@nomensa.com>> wrote:
>>>
>>>     JF wrote:____
>>>
>>>     >we cannot retroactively say that they are *REQUIRED*, nor can we
>>>     fail content that does not use either form of landmark
>>>     determination. ____
>>>
>>>     __ __
>>>
>>>     I agreed that In WCAG 2.0 we couldn’t add it, but why can’t we
>>>     simple add a failure for that in 2.1?____
>>>
>>>     __ __
>>>
>>>     It would be similar in concept to F91:____
>>>
>>>     https://www.w3.org/TR/WCAG-TECHS/failures.html#F91
>>>     <https://www.w3.org/TR/WCAG-TECHS/failures.html#F91> ____
>>>
>>>     __ __
>>>
>>>     (I.e. lacking markup that the content implies visually, the point of
>>>     1.3.1.)____
>>>
>>>     __ __
>>>
>>>     Why would we need a new (very-overlapping) SC for that?____
>>>
>>>     __ __
>>>
>>>     Create the new failure doc, link to up from 1.3.1 material… job
>>>     done?____
>>>
>>>     __ __
>>>
>>>     -Alastair____
>>>
>>>     __ __
>>>
>>>
>>>
>> --
>> @LeonieWatson @tink@toot.cafe tink.uk carpe diem
>>
>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com
>
> Advancing the mission of digital accessibility and inclusion
>