W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2018

Re: a suggestion for Personalization Semantics

From: Michael Cooper <cooper@w3.org>
Date: Fri, 12 Jan 2018 12:35:39 -0500
To: Alastair Campbell <acampbell@nomensa.com>, John Foliot <john.foliot@deque.com>, LĂ©onie Watson <tink@tink.uk>
Cc: "W3c-Wai-Gl-Request@W3. Org" <w3c-wai-gl@w3.org>
Message-ID: <4a9e4322-2a53-3691-ebdd-c8390c1080a6@w3.org>
On 12/01/2018 11:51 AM, Alastair Campbell wrote:
>
> JF 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.
>
> AC: It is not re-writing the SC at all, it taking into account changes 
> in other specs (i.e. ARIA & HTML) that were not available when 2.0 
> came out.
>
> And more importantly, it is doing so in 2.1, so does not affect 2.0 
> conformance.
>
> > 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.
>
> AC: Then *we need a mechanism to separate techniques and failures that 
> apply from 2.1 onwards*.
>
> MichaelC, is that possible?
>
At the moment WCAG 2.0 and WCAG 2.1 are using separate systems, so the 
set of techniques associated with 2.0 can be different from the set of 
techniques associated with SC inherited from 2.0 in 2.1.

If it's a requirement, we can ensure that remains possible as the 
systems evolve. However, I don't recommend we map techniques differently 
for an SC that has the same wording in two different versions of the 
guidelines. It will introduce lots of confusion to say a given technique 
is allowable for conformance to one version of the guidelines but not 
the other, if the SC wording is identical between them.

I do emphasize the point that techniques are kept separate from the 
guidelines, and updated more frequently, specifically so we can respond 
to technology change. It is perfectly reasonable to add or remove 
sufficient or failure techniques as technology changes, independent of 
what we're doing for new SC in new guidelines. Yes, that affects what we 
describe for conformance, but it's always been intended that that 
happen. Sites with a conformance claim dated before we made such a 
change would presumably not be suddenly considered to have an invalid 
claim - but if they update the date of the conformance claim, they 
should probably address the needs of new technologies at that time.

Also keep in mind that Understanding and Techniques are not normative. 
They express what we think is the best conformance to the guidelines at 
a given moment in time. But we're not changing the meaning of the SC, 
just the interpretation of what it means to present-day technology. 
Other organizations have the right to make different interpretations. We 
should not be held back from providing our best available advice on the 
basis of concerns about impact on legacy conformance claims.

Michael
>
> That is my main point: separation of techniques and failures for 2.1 
> onwards is critical to maintaining the SCs and reducing the complexity 
> of SC text, the rest of this email is less important.
>
> > If we all feel that the presence of landmark elements or roles is 
> important enough to be required, then make it an actual requirement
>
> AC: But that is impossible, it would fail our SC requirements to not 
> over-lap with other SC.
>
> You are then setting up a dynamic where SCs have to be perfect 
> first-time, and cannot change as the technology changes, which is the 
> opposite of the aim of technology-agnostic SCs.
>
> Some of the push-back against the link/input context SC was saying 
> that it should reference an external spec so things can be added / 
> changed later. (Which would be preferable, if not possible in that case.)
>
> Now that things have changed since WCAG 2.0, we should be able to add 
> techniques AND failures in 2.1 for new technologies, for old and new SC.
>
> Cheers,
>
> -Alastair
>
Received on Friday, 12 January 2018 17:35:43 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:21 UTC