- From: Jason White <jasonw@ariel.its.unimelb.edu.au>
- Date: Fri, 1 Apr 2005 15:15:59 +1000
- To: "John M Slatin" <john_slatin@austin.utexas.edu>
- CC: Web Content Guidelines <w3c-wai-gl@w3.org>
These are good proposals that should be integrated into the guidelines irrespective of the outcome of the "baseline" discussion. I support most emphatically the claim that the success criteria should be written in generic terms, independently of variations in UA and other technology-dependent details. I would also argue that the very term "baseline" is misleading; a baseline in typesetting is the line above which a character is printed; yet the main use of the concept of a baseline in these discussions is to require content to be compatible with user agents that meet the baseline and preferably some of those which fall below it to various degrees. Perhaps the concept of a profile is preferable here: the content has a profile, comprising the formats, protocols and API's that it is written to support, some of which it requires in order to be operative. A user agent also has a profile, or a set of parameters defining the supported and active formats, protocols and API's, in addition to its accessibility-related characteristics. Where the two profiles match, at least in so far as the required items in the content's profile are included in the user agent's profile, the encoded content will be successfully decoded and acted upon. Any sample profiles (or baselines if you still prefer that term) provided by this working group must be non-normative, and should be offered either in the guide to the guidelines document, or in a separate document. It is reasonable to limit the scope of techniques to the sample profiles provided. Also, as pointed out earlier in this discussion, there should be a limitation imposed on the range of acceptable content profiles by the guidelines themselves, based on the existence of implementations that support, or largely support, UAAG Level A. That ground has been adequately covered and summarized by Wendy, and thus need not be recapitulated here.
Received on Friday, 1 April 2005 05:16:25 UTC