- From: John M Slatin <john_slatin@austin.utexas.edu>
- Date: Wed, 28 Jul 2004 15:21:31 -0500
- To: "Wendy A Chisholm" <wendy@w3.org>, <w3c-wai-gl@w3.org>
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