Re: New Topic: HTML and the Visually Impaired [long]
"Daniel W. Connolly" <connolly@hal.com>
Date: Wed, 31 Aug 94 12:37:32 EDT
Message-id: <9408311636.AA29203@ulua.hal.com>
Reply-To: connolly@hal.com
Originator: html-wg@oclc.org
Sender: html-wg@oclc.org
Precedence: bulk
From: "Daniel W. Connolly" <connolly@hal.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)
In message <m0qfrAj-000ESAC@sq.com>, Yuri Rubinsky writes:
>
>My position is that a rich markup offers so many advantages for the creation
>of Braille, computer voice delivery and large-print publications that it is
>crazy not to take such considerations into account when doing markup.
>
Agreed.
>The technical committee of the International Committee for Accessible
>Document Design, chaired by George Kerscher of Recording for the Blind
>and of which I'm a member, has come up with a technique of using #FIXED
>attributes in any DTD in order to map arbitrary elements to a fixed
>ICADD set. The ICADD set represents the specific document structures
>available to a Braille formatter and also works for the two other formats.
So you can annotate the HTML DTD and then read HTML documents into
a braille printer? Great!
>Although work on the ICADD tagset predates widespread use of HTML,
>the two tagsets overlap significantly. Many elements have the same names;
>others, with different names, are nonetheless nearly identical in their
>intended functionality; only a handful have specific ICADD capability
>and don't exist in HTML.
I wonder about this: are ICADD documents relatively the same size and
scope as HTML documents? I see a BOOK element -- that leads me to think
that ICADD documents are often quite large, and not really suitable
in the same contexts as many HTML documents.
>++++++++++++++++++++++
>
>The Opportunity
>
>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
>that reads their screen will be able to use any WWW browser that
>is compatible (there are specific ways to implement cursors, for
>example, that let the screen reader "find them") with their screen
>reader. NCSA has already agreed to work toward making Mosaic
>"accessible" in this way.
>From an architectural point of view, it makes more sense to me to just
define a new content type: text/icadd, and enhance browsers to support
that type. One handy way to implement this is to parse the ICADD
document, translate it to HTML internally, and render the HTML.
But let's not try to shoehorn everything into HTML. If HTML and ICADD
are isomorphic except for some minor details (e.g. LHEAD), let's fix
that. But I see no reason to make all the ICADD tag names part of
HTML.
>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.
Great. This makes perfect sense. Let's do take care that HTML can be
consumed this way.
>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?
For HTML 3.0, perhaps. But I'd rather see a separate DTD and a separate
MIME content type.
>Here's a table of comparisons and proposed actions:
>
>HTML NAME ICADD NAME EXPLANATION/COMMENT
>_____________________________________________________________________
>
>BLOCKQUOTE [obs] BQ HTML to add back if possible
I don't know where this is documented as obsolete. If you find someplace
in the HTML 2.0 document where BLOCKQUOTE is specified as obsolete,
let us know.
>BYLINE? AU HTML to change/add if possible
>FIG FIG Must allow PCDATA for
>FOOTNOTE FN Ask WWW browsers to accept alias
Are these HTML+ elements?
>HTMLPLUS BOOK May be valuable to keep this distinction
> so browsers will know it's the ICADD DTD
Ah... apparently so.
>I would further propose that ICADD lose the LANG element and replace it
>with the CHARSET attribute as is done with the HTMLplus proposal.
This is an extremely hairy ball of wax. I'd love to see a complete proposal
for multi-lingual documents.
>Anyway, sorry for the length of this posting, but I wanted to present
>this in its entirety. If there is support for this proposal, then I
>will create a version of the HTML2.0 DTD with the 4 or 6 ICADD
>*new* elements in as proposed (AU, BQ, BOX, LHEAD, possibly
>IPP and PP). I think that the aliased elements
>should simply be handled in a note to implementors.
I won't support adding elements to HTML 2.0 unless and until they are
widely implemented and used. HTML 2.1 or HTML 3.0 or whatever, but
not in the current document.
>If we are able to do this, I think I can assure you that at the
>next "Closing the Gap" conference, there will be a move for the
>disabled community to solidly endorse HTML. There's no harm in
>that kind of support!
If the ICADD implementors want to support HTML, great! And if WWW
implementors want to support ICADD, great! But there's no need to
change HTML to make this happen.
By the way... is there a large body of legacy ICADD documents? I have
a hacked up browser that supports all sorts of data formats, and if
you give me the ICADD DTD, I could add ICADD support to my hacked up
browser in about an hour -- just for the purpose of seeing whether
ICADD documents make sense in a WWW browser.
If there is no legacy of ICADD documents, I suggest the ICADD folks
just adopt HTML wholesale, and lobby for the few changes they need
(while supporting them in their own applications, of course). There's
a HUGE body of legacy HTML.
Dan