Re: WCAG 2.2 - tightened requirements approach

Wilco wrote:

> We would deprecate SC 2.4.7 as it is superseded by this new SC.

Alastair wrote:

> Interesting, that would prevent overlap at least. Would you think the
previous SC should appear at all in the spec (with a deprecated warning
message), or just remove it entirely?

Katie wrote:


> I tend to feel that new requirements need a new identifier (SC # in this
case). This helps to avoid confusion for all involved. HTML usually adds a
new element or attribute for new requirement / feature / functionality.

+1 to Katie.

If the intent is to be building on top of prior WCAG versions, we also have
to accept that some organizations may find themselves somewhere *between *WCAG
2.1 and WCAG 2.2 conformance (which is all good, because they are still in
conformance with WCAG 2.0 "and growing"). I know *I'd* encourage an
organization to do that, as I am doing essentially that now with 2.1 (i.e.
"You don't *HAVE* to, but if you can now, all the better")

For this reason (and in light of the Project Silver 're-working' of our SC)
I'd favor adding a new SC and new SC number, but I'd avoid out-right
deprecation at this time: we instead could note that the new Success
Criteria supersedes SC 2.4.7.

JF





On Mon, Jul 1, 2019 at 9:12 AM Katie Haritos-Shea <ryladog@gmail.com> wrote:

> I tend to feel that new requirements need a new identifier (SC # in this
> case).
>
> This helps to avoid confusion for all involved. HTML usually adds a new
> element or attribute for new requirement / feature / functionality.
>
> On Mon, Jul 1, 2019, 7:48 AM Léonie Watson <lw@tetralogical.com> wrote:
>
>> 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
>>
>>

-- 
*​John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com