Re: New Topic: HTML and the Visually Impaired [long]
Terry Allen <terry@ora.com>
Date: Wed, 31 Aug 94 12:18:37 EDT
Message-id: <199408311616.JAA04100@rock>
Reply-To: terry@ora.com
Originator: html-wg@oclc.org
Sender: html-wg@oclc.org
Precedence: bulk
From: Terry Allen <terry@ora.com>
To: Multiple recipients of list <html-wg@oclc.org>
Subject: Re: New Topic: HTML and the Visually Impaired [long]
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: HTML Working Group (Private)
| From: yuri@sq.com (Yuri Rubinsky)
| To: Multiple recipients of list <html-wg@oclc.org>
| Subject: New Topic: HTML and the Visually Impaired [long]
I support Yuri's aim; ICADD is a great approach. Some thoughts:
Yuri, you had a little scripting language or something of the sort
for use with ICADD attributes, I believe in order to indicate
treatment of elements-in-context. Have you decided you don't
need it for this purpose?
| The ICADD tagset is described and "formalized" in an annex to ISO 12083.
Is this new?
| This is my idea, in two parts:
|
| 1) If we extend HTML ever-so-slightly with a tiny handful of new
| elements (AU, BOX, IPP, LHEAD, etc) , and encourage browser
| builders to alias certain ICADD elements to existing HTML elements
| (ANCHOR to A, PARA to P, etc), then we overnight make every
| Web browser into an ICADD browser. Blind people with software
Not overnight; the developers will need at least a week. I like
the idea of aliasing; that suggests that browsers can still get
by without interpreting HTML as SGML.
| (I'll talk about tables separately, in a later posting, if people agree
| that this is all worthwhile activity. In one sentence: I've convinced
| the ICADD people to change the table element names where they
| match to HTML names -- ROW to TR, STUBCELL to TH, CELL
| to TD. When we work on HTML 3.0, I'll propose the ICADD table
| model with two or three levels of implementation, level 0 being
| roughly the HTMLplus tables of old with optional COLDEF elements
| to hold more formatting when needed, level 2 being full Braille- and
| voice-enabled tables.)
Please. This is worthwhile and tables are needed.
| 2) When HTML2.0 is finalized, I'll add the ICADD attributes to it
| in a version that we distribute to content providers who work with
| the blind (Braille translation houses, electronic book creators, etc).
| This will establish the mappings from HTML elements to ICADD
| elements and will mean that all HTML text is *instantly* and
| automatically translatable into both print and on-line Braille.
I think these attributes should be part of the regular DTD, not
just in some other version. I'm beginning to wonder about how
many sets of fixed atts a DTD can handle, but this is about the
most important set I can think of.
| So, my question is: Should I propose the extra ICADD elements
| now, as "proposed" for future versions so people can be thinking
| about them, starting to implement, and so forth? Or should I
| wait and make all these proposals as part of the HTML 3.0
| process?
Both. If I understand things correctly, they aren't used now,
hence won't be in 2.0. But there's no reason to hold off
discussing what might go in 3.0 until 2.0 is final; people
will do so anyway. One might also imagine that if certain
elements become common usage during the time 3.0 is under
discussion, a 2.1 DTD might be promulgated, including them.
| Here's a table of comparisons and proposed actions:
| HTML NAME ICADD NAME EXPLANATION/COMMENT
| _____________________________________________________________________
| HTMLPLUS BOOK May be valuable to keep this distinction
| so browsers will know it's the ICADD DTD
| even if they don't read the DOCTYPE
could you explain that?
| OL/UL LIST OL/UL distinction not meaningful in ICADD
| since the generated content must be
| there. Would be good to add LIST to
| HTML if possible or ask developers to
| accept alias.
the latter is the better route; we don't want to suggest that there is
a third kind of list here.
| Software could ignore the following elements or do special processing:
| IPP Would be best if browser makers turned
| this into generated text such as
| "Print Page: ". These are used both
| to alert blind person to matching
| page in printed book and also as
| targets of <PP>. Content could be
| turned from <IPP>154</IPP> into
| <IPP NAME="154"> or equivalent.
| PP Reference to <IPP>. Could be treated
| as <A HREF="154"> or equivalent.
Would you give an example of usage?
| Concepts not in HTML which would be added for ICADD support:
| BOX Could simply be <HR> at <BOX>
| and another <HR> at </BOX>; browser
| developers could draw vertical lines.
what is this supposed to be? a sidebar? I'd rather leave it out
than suggest a new structure for specifically online
presentation that would be problematic to render.
| LHEAD Optional list headings are useful.
Could add an optional Title to lists.
| I would further propose that ICADD lose the LANG element and replace it
| with the CHARSET attribute as is done with the HTMLplus proposal.
Is this sufficient? In our Docbook discussion we decided that
charset, lang, and locale were all needed. We haven't implemented
anything yet, hoping that SGML Open will suggest a standard
approach.
| For tables, the proposal is that ICADD adopt TR and TD from HTML, and
| potentially, say, TH and THSUB, and that rest of model be adopted by
| the HTML community from ICADD. I'll post the DTD if there's interest. To
| a very great extent it's forward compatible from the HTMLplus tables.
Yes, the DTD please. It might be useful to supply a mapping from CALS,
too, or at least a description of what aspects of CALS tables may be
too complex to translate to HTMLn.
--
Terry Allen (terry@ora.com) Editor, Digital Media Group
O'Reilly & Associates, Inc. Sebastopol, Calif., 95472