W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2002

Re: Trying to better explain concern about mapping technology-specifics to success criteria

From: Jason White <jasonw@ariel.ucs.unimelb.edu.au>
Date: Sat, 13 Jul 2002 10:44:45 +1000
Message-ID: <15663.30717.182936.989990@jdc.local>
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
Received on Friday, 12 July 2002 20:44:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:42 UTC