- From: Jason White <jasonw@ariel.ucs.unimelb.edu.au>
- Date: Sat, 13 Jul 2002 10:44:45 +1000
- To: Wendy A Chisholm <wendy@w3.org>
- Cc: w3c-wai-gl@w3.org
> > Does this make more sense now? Can you see how a sub-priority scheme is > almost forming from this? Or do you think they are all equally > important? This might be an incorrect premise on my part (that some are > less important to accessibility than others). Uncharacteristically (for me, anyway) my response is to analyse the example. To generate proper contracted braille output, in English as well as (most?) other languages, it is necessary to distinguish between "literary" text, i.e., words and sentences, on the one side, and "computer notation", on the other. Computer notation involves a one-to-one representation of ASCII characters and is used to represent the kind of text for which CODE, SAMP and VAR elements in HTML were designed. Standard contracted braille can't be used in this context because it designed under the assumption that, for instance, most punctuation characters cannot occur within words; it provides no definition for various characters from the ASCII set; it doesn't fully take into account the possibility of mixtures of uppercase and lowercase letters occurring in a single word, etc. For this reason it is important to distinguish between ordinary text (with ordinary punctuation and capitalization patterns) and the kind of text that frequently arises in computer-related contexts. Thus CODE elements in HTML matter significantly for access purposes. The distinction between CODE, SAMP and VAR is not important, however, as long as any text likely to contain "irregular" sequences of letters, digits and/or symbols are distinguished from ordiary words and sentences. I don't think SITE is particularly important. Checkpoint 1.3 is reasonably clear as to the types of distinctions which matter, so perhaps one solution might be to fine-tune the list, while being careful not to constrain it to current technologies. I also have a broader suggestion which will be posted in a separate message.
Received on Friday, 12 July 2002 20:44:53 UTC