RE: Coming to a decision on 2.2

+1 to this.

 

I have a long and ramble-y JF email in my Drafts folder which explains my concerns around this in more detail, but in summary I see the current thinking around something like ‘SC 1.4.3-LV’ versus ‘SC 1.4.3-Mobile’, versus ‘SC 1.4.3-COGA’ (for example) as being quite onerous to manage, especially for entities that seek to conform to more than one user-group’s needs. I also find that using this kind of pattern (SC #.#.# - [affected user group]) as being divisive and fosters a “ghettoization” of both WCAG and the individual Success Criteria, as this is more of a “forking” of WCAG rather than building upon existing Success Criteria that would benefit all users. 

 

JF

 

From: Léonie Watson [mailto:tink@tink.uk] 
Sent: Monday, February 22, 2016 10:59 AM
To: 'Joshue O Connor' <josh@interaccess.ie>; 'Andrew Kirkpatrick' <akirkpat@adobe.com>
Cc: 'WCAG' <w3c-wai-gl@w3.org>
Subject: RE: Coming to a decision on 2.2

 

On 18 Feb 2016, at 22:59, Andrew Kirkpatrick <akirkpat@adobe.com <mailto:akirkpat@adobe.com> > wrote:

"We need some suggestions.  The WCAG’ers on the call believe that the 3rd bullet isn’t quite right and we don’t have agreement on the alternatives.  We want to clearly convey that the extensions may alter the text of a success criteria, but that in doing so a web page that passes the version of the success criteria in the extension must also pass the version of the success criteria in WCAG 2.0."

 

This is (to me) one of the critical problems with the extensions model. We can't change WCAG 2.0 itself (it's a Recc), but the extensions model means we are hamstrung in terms of what can be changed.

 

If a Tf determines that an existing 2.0 criterion should be improved, it makes more sense to make the modification within WCAG itself. Evolving WCAG so it continues to be a single set of guidelines removes the enormous potential for confusion that the extensions model promises.

 

I'm not suggesting that the work mode change, only that the way we package the resulting guidance changes. Instead of fragmented extensions, we create point releases of WCAG that incorporate both new criteria and modified existing criteria produced by each extension TF.

 

The scope of each point release would need clearly defining to avoid scope creep. WCAG 2.1 might be restricted only to the new/modified guidance for cognitive for example, but no amendments to WCAG outside of that.

 

If conformance with an extension cannot put conformance with 2.0 at risk, it effectively makes the extensions optional. We know what optional means to accessibility… Level AAA criteria are almost never considered because Level AA is the policy/legal standard in almost every jurisdiction.

 

I realise that the current charter restricts what can be done in the short term [1]. The charter does however raise the possibility of WCAG being rechartered before the 2018 deadline in light of the closure of the UAAG and ATAG WGs. I wanted to put these ideas out there for discussion before we reach that point.

 

 

Léonie.

[1] https://www.w3.org/2015/09/wcag-charter 

 

-- 

@LeonieWatson tink.uk Carpe diem