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

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. 

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.

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. 

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. 

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. 

So I think it is much more complicated than I think has been considered.  

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. 

What were the original delays referred to?  And how long were they?

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?  

(I do wonder if we could change it from XML to HTML but it would probably mean a lot of complicated reprogramming). 

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