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

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>
>>>
>>
>>
>