RE: the techniques document is hard to follow

We have referred to that as a "kitchen sink" version and we have talked
about such a doc.  Remember however that many techniques are used in
multiple success criteria so organizing them as suggested (interleaved)
would result in many techniques being listed many times - making the monster
file even larger.  The approach has usually been to break monster documents
up.  And to layer presentations (as we have) so that relevant information is
together rather than spread out. 

 

Our plan though is to provide different forms so suggestions are welcome.  


Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 
The Player for my DSS sound file is at http://tinyurl.com/dho6b
<http://tinyurl.com/cmfd9>  

 

 


  _____  


From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Tim Noonan
Sent: Wednesday, May 17, 2006 11:38 PM
To: 'WCAG-WG'
Subject: RE: the techniques document is hard to follow

Let me start by saying that In My first reading of the various documents, I
was very pleased with the clarity of most of the wording and consistency of
terminology, and I think you guys have really excelled in this regard.

 

To the topic at hand, though, I also am in strong support of a linearised
complete document being available. For people who are sighted, it means a
printable version, for people who are blind, it means a version that can be
referenced from within a portable note-taker, electronic book reader etc.

 

I want to particularly emphasise the benefits of such a version ,
particularly for people using screen readers, because the process of
traversing links, and then returning to where you left off, is quite time
consuming, and screen readers are notorious for the time taken to stabilise,
and return the reading pointer to the right place, or often they just lose
it altogether, and start back at top of document.

 

I can also see some benefit in additional mark-up being available in one
version of such a complete single document which textually indicates heading
levels and overall structure.  For example, 1 2 3 or four asterisks
preceding headings, respectively indicating the level of the heading.  

 

This allows people to do searches for the requisite number of asterisks
relating to the level of heading they wish to advance to.  It is an
unfortunate reality that many of the note-takers in common use don't support
HTML files as well as they do with more vanilla formats, and converting a
document such as the guidelines to text, naturally loses the essential
structural components like heading level.

 

 Great work with the draft!

 

Regards

Tim

 

Tim Noonan
Tim Noonan Consulting Pty Ltd: Excellence in Accessibility and Usability
+61 419 779 669
tim@timnoonan.com.au
www.timnoonan.com.au

 


  _____  


From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Cynthia Shelly
Sent: Thursday, 18 May 2006 9:39 AM
To: Lisa Seeman; WCAG-WG
Subject: 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