Re: a suggestion for Personalization Semantics

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?

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