W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2006

RE: the techniques document is hard to follow

From: Yvette Hoitink <y.p.hoitink@heritas.nl>
Date: Thu, 18 May 2006 15:00:49 +0200
To: 'Gregg Vanderheiden' <gv@trace.wisc.edu>, 'Tim Noonan' <tim@timnoonan.com.au>, 'WCAG-WG' <w3c-wai-gl@w3.org>
Message-id: <001601c67a7b$15ef05b0$d200a8c0@heritas.local>

Just my two cents:
Wouldn't a 'Associated success criteria' section (or something like that) in
each technique help here? In this section the success criteria that this
technique is trying to meet are listed and a link is provided to the how to
meet document for each success criterion. 
I see several benefits to having such a section:
* It gives a framework in which to understand the technique (which should
address Lisa's concern)
* It's two-way navigation: from the SCs to the techniques and vice versa
which means people have multiple ways to find the same content and make it
easy to learn about alternative approaches. 
* Some people will use search engines and land on a techniques page without
having been on any other. Supplying information (and links) about what the
technique is for will help them understand where they are and where to go. 
* Seeing that one technique helps to meet multiple success criteria might
aid the builder in deciding which technique to use. 
* You don't need to duplicate the techniques for each success criterion
(although we could still have another version that does include all the
techniques per SC)

Yvette Hoitink
Heritas, Alphen aan den Rijn, the Netherlands
E-mail: y.p.hoitink@heritas.nl
WWW: http://www.heritas.nl 


	From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]
On Behalf Of Gregg Vanderheiden
	Sent: donderdag 18 mei 2006 14:18
	To: 'Tim Noonan'; 'WCAG-WG'
	Subject: 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

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




				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


		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!





		Tim Noonan
		Tim Noonan Consulting Pty Ltd: Excellence in Accessibility
and Usability
		+61 419 779 669



				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





		        SC 1.1.2

		            Understanding 1.1.2





		    Guideline 1.2

		        SC 1.2.1

		            Understanding 1.2.1








		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.





				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
		Subject: the techniques document is hard to follow


		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

Received on Thursday, 18 May 2006 13:01:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:34:00 UTC