- From: John M Slatin <john_slatin@austin.utexas.edu>
- Date: Fri, 18 Mar 2005 11:45:25 -0600
- To: "Jason White" <jasonw@ariel.its.unimelb.edu.au>
- Cc: "Gregg Vanderheiden" <gv@trace.wisc.edu>, <w3c-wai-gl@w3.org>
Jason wrote: <blockquote> Take a single techniques document. It contains a list of techniques (required and, if we so decide, advisory) related to each success criterion. One way of ordering these is by success criterion. Another way is by the features of the language used, for example the different parts of the HTML spec that deal with block and inline structures, forms, multimedia, etc. The main question then is whether the techniques can be so drafted that they make sense in both orderings. </blockquote> Hmmm. I hadn't understood the difference between Reference and Application sections quite this way. I had understood the Reference section much as you describe it, but I had thought the Application section would be focused on apply the techniques in various desin scenarios, such as trying to create an accessible form or a complex table, or designing a navigation scheme, and so forth. The idea would be to appeal to task-oriented developers and designers who come to WCAG seeking guidance about how to accomplish some specific task in a conforming way. I think this might make it more difficult to write technology specific techniques in a way that lends itself readily to both orderings. Jason added: <blockquote> For the general techniques this might be problematic as there aren't any tasks or language features involved; rather, the general techniques serve to complete the technology-specifics by providing those techniques that would otherwise be repeated in each technology-specific document, because they are independent of the implementation technologies. </blockquote> Hmmm again. I'm not sure why you say there aren't any tasks involved in the General Techniques. I have been trying to see the General Techniques not just as a repository for techniques that would otherwise have to be repeated in each technology-specific document, but also as a place to frame the problem: what is the accessibility problem to be solved here? What is the approach that developers might take in addressing that problem? What tasks must they accomplish no matter what technology they're using? (Examples include writing text alternatives, thinking hard about what's "structure" and what's "presentation," planning a consistent design, etc.) So maybe General Techniques shapes up as the introductory part of the Applications section? John -----Original Message----- From: Jason White [mailto:jasonw@ariel.its.unimelb.edu.au] Sent: Thursday, March 17, 2005 8:59 PM To: John M Slatin Cc: Gregg Vanderheiden; w3c-wai-gl@w3.org Subject: RE: Possible format for techniques Doc.doc On Thu, 17 Mar 2005, John M Slatin wrote: > > It's also a little daunting! I say that because it sounds like these are > actually two separate documents, each one pretty large in its own right > (I'm seeing a heavy book in my mind's eye). And I'm not sure I > understand how they relate to what's presently in the > Technology-specific or the General Techniques docs. Take a single techniques document. It contains a list of techniques (required and, if we so decide, advisory) related to each success criterion. One way of ordering these is by success criterion. Another way is by the features of the language used, for example the different parts of the HTML spec that deal with block and inline structures, forms, multimedia, etc. The main question then is whether the techniques can be so drafted that they make sense in both orderings. For the general techniques this might be problematic as there aren't any tasks or language features involved; rather, the general techniques serve to complete the technology-specifics by providing those techniques that would otherwise be repeated in each technology-specific document, because they are independent of the implementation technologies. What do you think? Does this help to solidify the proposal?
Received on Friday, 18 March 2005 17:45:26 UTC