Re: Recommendation to move WCAG Techniques out of TR, concerned about Failure Techniques loosing authority

Oh, and one chaser to this explanation - I want to emphasize that the 
wording in the proposed WCAG WG charter does not obligate us to change 
how we publish Techniques. It is carefully worded to *allow* us to 
change, but also allow us to keep things the same. I do agree we need 
further discussion before making any major changes like this. But 
because we have already identified problems with the current status quo, 
we do not want to be prohibited by our charter from making changes either.

So I hope everyone understands that accepting the charter as proposed 
does not force us into a particular decision with our resources. And I 
hope everyone can see the value in building flexibility on that into the 
charter, since we have to close the rechartering process up now, so that 
we can continue the discussion on our publications without undue 
constraints.

Michael

On 22/05/2015 9:43 AM, Michael Cooper wrote:
> Hi Gregg - some background information:
>
> On 20/05/2015 11:14 AM, Gregg Vanderheiden wrote:
>> Hmmm
>>
>> I see lots of problems in trying to do this —  and I’m still not sure 
>> I understand what the problems of the current system are.
>>
>> RE Problems
>>
>> The techniques are linked to WCAG (which can’t be changed) so that is 
>> a problem.
> The techniques link *to* WCAG. But that's no problem, if we move them 
> somewhere else, they can still link to WCAG.
>
> There are only two links *from* WCAG to the techniques, basically 
> saying "look here". The individual techniques are not linked from 
> WCAG. The proposal is not to stop publishing a document at the URI 
> referred from WCAG (http://www.w3.org/TR/WCAG20-TECHS/). Instead, the 
> proposal is to turn that into more of an index (which is what the 
> cover page is now anyways), and the links in the index would point to 
> individual techniques that are elsewhere. The user experience of 
> accessing techniques by following links from WCAG would be basically 
> unchanged, just the URI when they finally get there would be different.
>
> The Understanding document does link profligately to the Techniques. 
> The proposal is to continue to publish Understanding more or less as 
> it is now, twice per year. When that resource is updated, URIs to 
> techniques can be updated, so again we wouldn't lose any paths.
>>
>> But even if you can reach in and change the links there — the 
>> techniques also crosslink to many other documents — and not just 
>> search engines.  These will all break everywhere.  And many of these 
>> documents cannot be changed because they are publications and 
>> archival in nature.   Breaking all the literature in the field that 
>> points to the techniques is not something that should be done except 
>> if not possible to avoid.
> The proposal would not result in broken links, nor in changes to old 
> documents. All of our techniques publications are published to dated 
> URIs, and we would not change those. The latest dated URI is also the 
> same as the "latest version" URI, http://www.w3.org/TR/WCAG20-TECHS/. 
> When we update a publication of Techniques, the links at that would 
> automatically update, while old links in dated versions would be the 
> same (and would not break, because we're not removing their targets). 
> It's also been the practice that if we do remove a technique, we put a 
> redirect at the dated version URI (at publication time) so old links 
> don't break, and we would keep that practice. We would not be 
> attempting to change or remove old content.
>>
>> One COULD wire up the server to cause all references to TR to forward 
>> to another location but
>>
>>   * I think this might violate practice
>>   * and if going to TR takes you to a document- I think that document
>>     needs to follow TR rules no matter where it is stored.
>>
> We won't forward old TR references.
>
> TR pages certainly can point to resources outside of TR, that is 
> completely normal. Often they are non-W3C resources, and often they 
> are W3C resources that are not in TR. I don't know of any constraints 
> here. Normative references would be a constraint, but the Techniques 
> are non-normative so we don't run into that.
>>
>> Finally,  the “500 pages” are all part of a doc to which you can make 
>> a single change,  and then “push a button” and it will rebuild all 
>> the pages and links between all the docs automatically.   This is 
>> complicated if there is an error but then that should be fixed anyway.
> It's not too complicated from a "push the button" perspective to 
> publish 500 pages. But as things stand right now, if we add or change 
> one technique and want it to be available immediately, we have to 
> publish the entire 500-page suite just for that one change. If we 
> wanted to update techniques weekly (a worthy goal though we probably 
> won't reach it quickly) we'd have to publish 500 pages 50 times per 
> year. I don't know if this is really a problem for the W3C servers. 
> But I do know having so many copies of nearly but not quite identical 
> content is very hard to manage. It's been a problem for years that 
> people stumble onto old techniques at date URIs and challenge us on 
> them only for us to respond "we fixed that years ago, you were looking 
> at an old URI". These dated URIs get indexed by search engines and 
> often trump the "latest version" URIs that are the ones we actually 
> want people to find. Moving the substance of techniques off of TR 
> solves these problems, by allowing us to have a stable URI that gives 
> us the flexibility to manage changes (via redirects) etc.
>
> Another major reason to move the substance of techniques off of TR is 
> the constraints on style. W3C Technical Reports have rigid style 
> rules, for good reasons. But as we have been looking into the 
> usefulness of our resources to the public, we have been finding that 
> people have problems with structure and style that can't be changed 
> for TR resources. We would be better able to serve our stakeholders if 
> we move this content off of TR where not only can we update it more 
> frequently, we can present it better.
>
> And again, the basic document "Techniques for WCAG 2.0" would not 
> disappear from TR, nor even cease to be updated. It would simply 
> change to a set of pointers to external resources. It would probably 
> also have basic introduction and other content more appropriate to the 
> "spec-like" nature of TR publications (even Notes that are not 
> specifications).
>>
>> If you change the process— you will need to build all new mechanisms 
>> to crosslink all the docs each time you add a technique etc.  - and 
>> to forward all links from WCAG  — and from all other docs  - and….
>> And again I’m not sure that if you keep the TR links alive (which you 
>> will need to to not break everything) I think the TR publishing rules 
>> would still have to apply even if you put the doc in another filespace.
> This isn't a problem. The cross references are managed by variables 
> that are easily updated in the build tool. There might be some work on 
> the tool to accommodate publishing both the index to TR and the 
> techniques content somewhere else, but I don't think that's a big project.
>>
>> So I think it is much more complicated than I think has been considered.
> I hope the above shows that it has been considered, and I don't think 
> it's overly complicated. I apologize that we didn't convey in our 
> initial proposals that we had thought through those issues.
>>
>> And I still don’t understand what  “delays” and “overhead” are that 
>> are so important or large that we are considering such complications 
>> to avoid?   There are certainly no barriers I know of to publishing 
>> new versions each month if one would like to.
> There are no barriers to that. But as explained above, I think it has 
> side effects that we are finding increasingly problematic.
>>
>> What were the original delays referred to?  And how long were they?
> We've had instances in the past where someone submitted a technique 
> and it did not become an official publication of the WG for 2 years. 
> We've sped up the process but still have measured that it can easily 
> be the case that it takes 8 months for a new technique to become 
> official, even if it is approved by the Working Group in the first 
> week of that 8-month cycle.
>>
>> And what are the complications that would be worse than having to 
>> maintain all of the cross-links by hand and undoing the other 
>> problems introduced in the change?
> We would not need to maintain the cross-links by hand, that would be 
> automated as it is now.
>
> In a worst case scenario we could always go back to publishing 
> techniques to TR as we do now. The "off-TR" version could have 
> permanent redirects set up, allowable since they aren't TR resources. 
> So I don't think we irreparably break anything.
>
> The main consequences of *not* making this sort of change are:
>
>   * WCAG WG continues to be perceived as slow as our TR publication
>     process introduces months of delay in publishing a techniques;
>   * Or in an effort to avoid that, we end up with many more versions
>     of very similar content floating around on TR with a lot of
>     difficulty in making sure people are using the right one;
>   * We don't have the ability to make structure and style changes to
>     better meet the needs our stakeholders have expressed to us;
>   * We continue to have to deal with jurisdictions that treat
>     techniques as normative because they're published to TR, even
>     though we clearly and repeatedly say they're not normative. Moving
>     off TR and removing some of the TR style imprimatur should help
>     clarify their non-normative status.
>
>>
>> (I do wonder if we could change it from XML to HTML but it would 
>> probably mean a lot of complicated reprogramming).
> That is a goal as a separate project. I've been wanting to do it for a 
> good year-and-a-half and it may be one of the important things to 
> focus on this year. Yes it would mean a lot of complicated 
> reprogramming - but once done, we would have resources that are much 
> easier for outsiders to contribute to.
>
> Michael
>>
>> Thanks
>>
>> /gregg/
>>
>> ----------------------------------
>> Gregg Vanderheiden
>> gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>
>>
>>
>>
>>
>>> On May 20, 2015, at 8:50 AM, Andrew Kirkpatrick <akirkpat@adobe.com 
>>> <mailto:akirkpat@adobe.com>> wrote:
>>>
>>> And one of the more mechanical reason is that the collection of 
>>> techniques documents is huge.  Over 500 pages, and there is no need 
>>> to replicate every one of those pages when only a few are changed. 
>>>  This actually creates more problems now in that people regularly 
>>> land on the incorrect version of a technique because of search 
>>> engines finding an older version, and then they follow links to 
>>> other older versions of related information within the collection.
>>>
>>> There would be a transition time but in not too long people and 
>>> search engines would find the individual techniques in the same 
>>> predictable location.  We would still have the same issue with the 
>>> top pages of the techniques that would be in TR space, but if that 
>>> happened then people would get back on track as soon as they 
>>> followed a link to an individual technique.
>>>
>>> AWK
>>>
>>> -----Original Message-----
>>> From: Joshue O Connor [mailto:joshue.oconnor@cfit.ie]
>>> Sent: Wednesday, May 20, 2015 2:22 AM
>>> To: Gregg Vanderheiden
>>> Cc: David MacDonald; GLWAI Guidelines WG org
>>> Subject: Re: Recommendation to move WCAG Techniques out of TR, 
>>> concerned about Failure Techniques loosing authority
>>>
>>> Gregg Vanderheiden wrote:
>>>> Techniques are Notes - so they can be amended at any time.  [...]
>>>
>>> In practice having them in TR space has often meant overhead/delays etc.
>>>
>>>> Can you  explain the logic of moving them more?
>>>
>>> It's really about moving to a lighter adaptive model where techs can 
>>> be updated and kept fresh - so currently this is our thinking on the 
>>> best way to do this.
>>>
>>> Josh
>>>
>>>> gregg
>>>>
>>>> ----------------------------------
>>>> Gregg Vanderheiden
>>>> gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>
>>>>
>>>>
>>>>
>>>>
>>>>> On May 19, 2015, at 1:17 PM, David MacDonald<david100@sympatico.ca 
>>>>> <mailto:david100@sympatico.ca>>  wrote:
>>>>>
>>>>> There is a discussion in today's meeting about possibly amending 
>>>>> technique authoring process to possibly move the Techniques  out 
>>>>> of TR space going forward to speed up the cycle.
>>>>>
>>>>> This is in the new Charter proposal.
>>>>> http://www.w3.org/2015/04/draft-wcag-charter<http://www.w3.org/2015/0
>>>>> 4/draft-wcag-charter>
>>>>>
>>>>> Section 2 Deliverables
>>>>>
>>>>> "Understanding WCAG 
>>>>> 2.0<http://www.w3.org/TR/UNDERSTANDING-WCAG20/>, to be published 
>>>>> as a W3C Working Group Note or as a curated resource of the 
>>>>> Working Group. Understanding WCAG 2.0 explains the intent of each 
>>>>> Success Criterion and links to known sufficient techniques, both 
>>>>> general and technology-specific;"
>>>>>
>>>>> The proposal in the charter allows the group to go either way, so 
>>>>> the discussion is not a show stopper for the Charter.
>>>>>
>>>>> However, there is a discussion that the weight and authority of 
>>>>> failures might be affected by this, and there may be legal 
>>>>> implications in environments that look to the common failures as 
>>>>> evidence in court.
>>>>>
>>>>> I would be interested in a fairly wide discussion of this, which 
>>>>> includes prior WCAG member and affected jurisdictions... I think 
>>>>> there are court cases all over the world that cite a WCAG failure 
>>>>> technique violations as an authoritative indication that a web 
>>>>> site (page) doesn't meet WCAG requirements.
>>>>>
>>>>> Similarly, there may be some circumstances of web masters are 
>>>>> defending their claims that they met WCAG by citing a WCAG technique.
>>>>>
>>>>> Cheers,
>>>>> David MacDonald
>>>>>
>>>>> CanAdapt Solutions Inc.
>>>>> Tel:  613.235.4902
>>>>> LinkedIn<http://www.linkedin.com/in/davidmacdonald100>
>>>>> www.Can-Adapt.com 
>>>>> <http://www.Can-Adapt.com><http://www.can-adapt.com/>
>>>>>
>>>>>   Adapting the web to all users
>>>>>             Including those with disabilities
>>>>>
>>>>> If you are not the intended recipient, please review our privacy
>>>>> policy<http://www.davidmacd.com/disclaimer.html>
>>>>
>>>
>>>
>>
>