RE: the techniques document is hard to follow

I also find the techniques hard to follow, and my short-term memory is at least average.  I find it difficult to map the techniques to the SC they go with, and also with the principals and guidelines.  So, I find it difficult to understand what the technique is for, what problem it fixes, and how it fits into the whole.

There are a couple of things to address here:
1) Is this a usability issue or an accessibility issue?  That is, is this something that the guidelines should address?  I don't know the answer to this one, but I'd like to hear opinions.

2) How can we make our document set more usable?  I had similar problems when trying to understand and implement WCAG 1.0, and I don't think we have fixed them.   I have always thought that there needs to be an "all-in-one" document, with a structure something like this

Principal 1
    Guideline 1.1
        SC 1.1.1
            Understanding 1.1.1
            Technique
            Technique
            ...
            Technique
        SC 1.1.2
            Understanding 1.1.2
            Technique
            Technique
            ...
            Technique
    Guideline 1.2
        SC 1.2.1
            Understanding 1.2.1
            Technique
            Technique
            ...
            Technique

etc.

I know this can't be the normative document, because the techniques aren't normative.  But, can we generate a view like this?  Some techniques would appear under more than one SC, but I think that's ok.  An arrangement like this makes it easier to understand how the pieces fit together. It also makes it possible to print the standard and read it in the absence of hypertext.  The current arrangement means that in order to understand a guideline on paper, you have to flip around in 3 different documents -- not a simple task if you're trying to read it on the bus!

Another option would be to include the SC text above the description for each technique.  That would help somewhat in understanding what SC a technique applies to, though I don't think it solves the problem of getting a global understanding, and I'm quite sure it doesn't address the read-on-bus scenario.

Thoughts?


________________________________
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Lisa Seeman
Sent: Monday, May 15, 2006 9:21 PM
To: WCAG-WG
Subject: the techniques document is hard to follow


Folks
I am currently reviewing the techniques document, and I think you need to know that it is really hard for me to follow.

This is an the acid test on whether following  the guidelines actually  mean that someone with a learning disability can access content. They don't.  Understand,  I review a lot of specifications  for the W3C as they get to last call (sometimes for ISO, Dublin core etc). Normally the concepts in the content are  much much harder, and just incase this could be any stronger, so far I was already familiar with every technique I have reviewed (which is why I can follow it at all).  But, because I have a disability, our  techniques document is the hardest to follow of any W3C specification I have reviewed.

 (The key problem is I do not have a reliable visual or auditory short term memory, so I can not track of what the success criteria numbers refer to. It is the same problem as acronyms and I am forever having to scroll or click to the guideline, miss my place, have trouble remembering where I was etc...)

The key point I am making:  We have followed our own guidelines including level three success criteria. But the result was not that the content was accessible to someone with a learning disability.

My 2 cents, is we need to lose the clame that we have written guildines that will make content accessibility to people with a learning and cognitive disabilities and then we need to start working on an extension checkpoint that does address the different needs of Learning styles. We need to do it like any difficult technical problem. We need to analyze the problems in depth, understand the issues, make a gap analysis, then innovate and come out with a solution, then we need to test it, and then write the guideline.

All the best
Lisa