Re: WCAG 2.2 - tightened requirements approach

On 01/07/2019 12:22, Wilco Fiers wrote:
[...]

> The world has been building tools for WCAG 2 for 11 years. For WCAG 2.1 
> we've all had to figure out how we're going to add success criteria. 
> Most tools have this capability at this point. Deprecating something 
> just means removing it, that should be fairly straight forward for 
> anyone. Changing an SC however is a far more substantial change. For 
> Deque, it would likely require architectural changes to several of our 
> products. I imagine it's the same thing for others. It's something I'd 
> like to avoid if we can.

HTML is a specification that has seen both deprecation and element 
definition evolution over it's 25+ year history, and which has numerous 
conformance tools associated with it, so it's a useful thing to look at 
in this context. The HTML design principles include a priority of 
constituencies [1] that says:

"In case of conflict, consider users over authors over implementors over 
specifiers over theoretical purity. In other words costs or difficulties 
to the user should be given more weight than costs to authors; which in 
turn should be given more weight than costs to implementors; which 
should be given more weight than costs to authors of the spec itself, 
which should be given more weight than those proposing changes for 
theoretical reasons alone."

This seems like good advice for WCAG too.

The risk with making 2.2 more complex than it needs to be, is that 
authors find it harder to implement things in accessible ways, and users 
are worse off because of it.

The challenge for organisations that create conformance checkers, is 
that you create tools that help individuals check accessibility more 
easily. By definition, you take on some of the hard work so that others 
don't have to.

Léonie.
[1] https://www.w3.org/TR/html-design-principles/#priority-of-constituencies



  --
@TetraLogical TetraLogical.com

Received on Monday, 1 July 2019 11:47:40 UTC