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

Thanks Micheal, I do.

 

 

 

* katie *

 

Katie Haritos-Shea 
Senior Accessibility SME (WCAG/Section 508/ADA/AODA)

 

Cell: 703-371-5545 |  <mailto:ryladog@gmail.com> ryladog@gmail.com | Oakton, VA |  <http://www.linkedin.com/in/katieharitosshea/> LinkedIn Profile | Office: 703-371-5545

 

From: Michael Cooper [mailto:cooper@w3.org] 
Sent: Friday, May 22, 2015 9:55 AM
To: Gregg Vanderheiden; Andrew Kirkpatrick
Cc: Joshue O Connor; David MacDonald; GLWAI Guidelines WG org; Judy Brewer
Subject: 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>