RE: Please review: New drafts of Gateway techniques

Hello, all.  Wendy, terrific job integrating the rough stuff I sent you
with what Tom had produced! I agree that this should be enough to post
so as to get the discussion started (though some of the roughness may
distract some readers....
Responses to specific questions follow the questions.

Wendy writes:
There are several issues that we need to address that will likely
prevent 
us from publishing the draft this week. I propose that we publish HTML
and 
CSS Techniques this week and WCAG 2.0 and Gateway next week.  

John: I got the impression from the call this morning that the linkages
among the different documents (Guidelines, Gateway, HTML Techniques, CSS
Techniques, etc.) are too tight to support splitting up publication this
way, so we should probably wait a week and publish them as a set.
Wendy goes on:
1. We can generate three views (thanks to Ben)
[1] <http://www.w3.org/WAI/GL/2004/07/test-gateway1>
includes a detailed table of contents (principle, guideline, success 
criteria, and techniques)
[2] <http://www.w3.org/WAI/GL/2004/07/test-gateway2>
includes a less-detailed table of contents (principle, guideline) [3]
<http://www.w3.org/WAI/GL/2004/07/test-gateway3/>
divides the document into several slices: the first is a general table
of 
contents, and then a separate document for each success criterion.

Each view has pros and cons. Which do you like best? Perhaps we can
combine 
them in some way?

John: I prefer the third view, the one that slices up the document.
Second choice would be option (1), and option (2) would be a distant
third.

Wendy:
2. Will testability of Gateway techniques be a concern?  There is an
ednote 
in the first technique that raises this question.

John: I don't think testability of Gateway techniques is an issue, for
reasons I outlined in an earlier message today
(http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JulSep/0245.html)  


3. Benefits and examples from the guidelines document need to be
expanded 
upon in the gateway techniques.  There is an ednote in the first
technique 
that raises this issue.
On a related note, we need to ensure that as we rewrite success
criteria, 
that examples and benefits are also updated.  Working on gateway
provided a 
good perspective on this.  I have a mapping for Guideline 1.1 that I
intend 
to use as the basis for future proposals to both guidelines and gateway.

(this issue is not critical and should not prevent us from publishing
the 
drafts)
John:
I agree that we need to align examples and benefits with the guidelines
and techniques. Perhaps the examples could be briefly described in the
guidelines document (more or less as they are now), then
discussed/explained  at the appropriate point in Gateway techniques?
From there we cold provide links to code in the technology-specific
techniques docs that matches the examples.  

A couple of other ideas:
(1) Group examples explicitly according to the success criteria they
illustrate (in other words, provide additional headings within the
Examples section, e.g., Examples of L1 SC1 etc; Clunky but explicit...)
(2) for each success criterion, provide at least one example for each
technology for which we expect to provide a techniques document (or use
examples that draw on multiple technologies, such as a form that
includes HTML input elements, scripting, and CSS, etc.).


Wendy:
5. I created a separate technique for each subpart of the level 1
success 
criterion for guideline 1.1.  I think this works well, except for c 
(non-text content that is intended to create a specific sensory 
experience...) in which case there are two techniques: one for music and

one for audio.  I'm not sure this is the best approach.  There is an
ednote 
that raises this question.
John: Maybe I just wasn't clear enough in the draft I sent last week.
There are significantly different requirements for different types of
audio content, and I think they're covered by different items under 1.1
L1 SC 1.  In my judgment, spoken-word audio would be covered by ther
requirement to provide "the same information" as the non-text content--
in this case, a text transcript that includes the words in the
recording.  For non-vocal music, the minimum requirement is for a text
label that identifies the piece.  Typically this would be provided via
alt text on a graphical link to the audio file (such as an icon of an
ear or something) or by a a text link.  In some contexts (e.g., a
history of music or a music review) it might be appropriate to include
an additional text description of the piece.  This could be done in
several ways, including nested <object> elements, etc.  In any case, I
think we can solve the problem by dealing with spoken-word audio under
the requirement to provide the same information and with non-vocal music
under the requirement to identify non-text content that creates a
specific sensory experience.

Wendy:
6.  The text for the techniques is not the same as the text in the
success 
criterion.  For example, technique 1.1.1 is named, "Text alternatives
for 
non-text content that provides functionality"
however the success criterion text is, "For non-text content that is 
functional, such as graphical links or buttons, text alternatives
identify 
the purpose or function of the non-text content; or,"  This was from
John's 
draft and I liked it.  However, this might be confusing.  There is an 
ednote that raises this question.

John:Thanks for pointing out the discrepancies between the language used
in the Gateway Techniques and the wording of the actual SC.  It's
important that they match. For example, I think "non-text content that
provides functionality..." is clearer than "non-text content that is
functional..." (the second one is the wording in the SC itself) and will
make a formal proposal to change the wording of the SC if you'd like
(though I think this is purely editorial .
	
Wendy:
7. Some of the text is very rough and hard to read, but it's a start.
John:
Some of the changes I proposed in [2] try to smooth things out a little.
Wendy:
8. how to deal with numbering...
Techniques in the gateway draft are nested below many levels of headings

(principle, guideline, success criterion, technique). How can we number 
techniques so that they are both unique and identifiable out of context 
without creating confusion with other techniques documents and their 
numbering?

John: ugh.
Thoughts?

Best,
--wendy

-- 
wendy a chisholm
world wide web consortium
web accessibility initiative
http://www.w3.org/WAI/
/--  

"Good design is accessible design."

Dr. John M. Slatin, Director 
Accessibility Institute
University of Texas at Austin 
FAC 248C 
1 University Station G9600 
Austin, TX 78712 
ph 512-495-4288, fax 512-495-4524 
email jslatin@mail.utexas.edu 
Web http://www.utexas.edu/research/accessibility 

Received on Wednesday, 28 July 2004 16:21:45 UTC