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

RE: Status of RTF format?

From: Bruce Bailey <bbailey@clark.net>
Date: Fri, 21 Jul 2000 17:19:51 -0400
To: "Greg Gay" <g.gay@utoronto.ca>
Cc: <w3c-wai-gl@w3.org>
Message-ID: <000501bff359$69a62bc0$53fe330a@msde>
One of the best ways to test for accessibility is, of course, to ask a blind
colleague to look at the material.  The problem with this technique, of
course, is that he can't compare it to the source document.  Your blind
colleague is also likely to be much more sophisticated than the average
blind person, and is very tolerant (and has good coping strategies) for
dealing with the obstacles of less than fully accessible documents.  This is
the real problem with poorly formatted HTML (and PDF, RTF, etc.) -- the
person who is dependent on a screen reader has no way to independently gauge
what they are missing!

> Thanks for your response Bruce. I'm still not convinced however,
> that rtf is
> inaccessible

>> What do you mean by accessible?
> screen reader, text-to-speech, assistive technology accessible

What about them?  Just because you get SOME speech how do you know that you
are getting ENOUGH of the "real" content?  Many, perhaps most, extremely
inaccessible HTML pages will be read -- to some degree at least -- by a
screen reader.  This hardly makes them accessible.

With RTF, and PDF and word processor documents, you would need some kind of
formal procedure to determine accessible from inaccessible.  Without
something deterministic you are just guessing.  With HTML, guidelines exist
at least!

>> Most RTF documents I have seen convey information and structure
>> using font
>> changes and typographical effects (bold, underline, italics,
>> etc.).  This
>> additional meaning is almost always lost to a screen reader.
>> HTML can capture and transmit this significant content when
>> used correctly
>> (e.g., Hx, STRONG, EM, CITE).  Properly configured screen readers and
>> browsers do MUCH better with robust HTML documents than they do the most
>> strictly formatted word processing file (of whatever format).
>> This one reason why ASCII is better than RTF -- at least the
>> provider has no
>> illusion about the quality of information he is posting!

> I don't question that HTML is more robust, however screen reader
> users are not
> the only ones who might make use of an rtf a document. For a person with a
> reading disability for example, rtf is much more readable than
> ascii.  Ascii is
> accessible, and rtf is no different when screen readers strip any rtf text
> formatting.

ASCII is accessible because it provides the same content (however poorly
formatted) to all audiences.

To a visually oriented person, RTF is obviously MUCH better than plain
ASCII.  Well you know what, to a screen reader, RTF (PDF, Word, WordPerfect,
etc.) _ALL_ end-up looking like ASCII.  HTML (when used correctly) does not
suffer this defect.

All the reasons you want to use RTF instead of ASCII are the very arguments
as to why you should be using HTML instead.

>> RTF are not accessible because there does not exist any public
>> consensus --
>> and no objective tests -- to categorize RTF as such.

> This sound like RTF has been dictated as inaccessible, something
> like "the world
> is flat and one would fall off the edge if one were to travel too
> far west".
> Perhaps it's time to determine just how accessible, or
> inaccessible rtf really
> is. While perhaps not as accessible as html, you cannot say that rtf  "is
> inaccessible." Like priorities, there are degrees of
> accessibility. The average
> rtf document that uses basic text formatting, as most such
> document authors use,
> is read by JAWS without difficulty (and other AT I'm assuming).
> When you get
> into the complex markup, as CharlseMN mentions, like including
> transcripts for
> audio (to be honest I didn't realize rtf could support audio), then
> accessibility issues may emerge. By the same token, an access
> aware author could
> manually include a transcript on another page, much like using a
> d-link in place
> of longdesc. Longdesc may not be supported in most browsers but
> because authors
> use d-link instead, the access barrier longdesc was meant to
> compensate for has
> been accommodated with a work around. RTF documents can be made
> accessible in
> much the same way, by being aware of components of rtf file that
> might create
> barriers.

If YOU want to use RTF instead of HTML the burden is on YOU to make sure
that it is truely accessible.  One HUGE advantage with using HTML instead is
that so much work has been done to define what HTML is accessible and which
is not.  I am sure you can get lots of help from members of this list to
come up with some guidelines for "accessible RTF", but you need to be VERY
careful if you are going to go down this route.  IMHO it would be much
easier to post well formatted HTML than it would be to create and enforce
guidelines for "accessible RTF".

>> You could, I suppose,
>> create your own company wide standards for accessible RTF
>> (e.g., no use of
>> formatting effects without an associated and documented style).
>>  But now,
>> how do you get your customers to agree that your new-and-improved RTF is
>> "accessible"?  How do you implement quality control and testing of this
>> standard?  Is it not MUCH easier to use a conformance compliant format?

> Nowadays it is just as easy to convert a document to html as it
> is to convert to
> rtf. Personally I would chose to convert to html and provide and
> rtf version for
> printing. In the example I linked to below, the rtf file was
> converted from a
> wordperfect document, as was the html (less the template its in).
> I had to spend
> several hours playing with the html to get it to display and
> print right, while
> the rtf document prints perfectly without any modifications. If I
> had dozen such
> documents, I could spend days making html versions look right, or I could
> provide users with rtf formatted files in a matter of minutes.
> Most developers
> will not justify creating html versions when rtf can be created
> with relative
> ease.

Right, and as we all know, the automated tools for creating HTML from within
a word processor are junk.  They don't put in the structure and focus
instead on typographic effects.  This is EXACTLY what happens with the RTF
export.  The different with the HTML is that you have tools for testing the
HTML -- and you know for a fact that the results are invalid and
inaccessible.  Well, the RTF is formated just as badly (from a screen reader
point of view) -- the mechanisms for testing and documenting this just
aren't as good!

>> RTF predates HTML by quite a number of years.  The format's many
>> shortcomings makes it very inferior when compared to HTML --
>> for the MARK UP
>> of textual information.  It this were not so, why didn't they just add a
>> LINK element to RTF and be done with it?

> Could you explain "just add a LINK element to RTF and be done with it?"

If RTF was not inherently flawed, it would have been modestly evolved and
been used instead of creating a whole language.

>> Please post a couple of heavily formatted RTF documents which
>> you think are
>> "accessible".  Even with adequate tools, I bet members of this
>> list can spot dozens of barriers.

> Here's and html version of a document in progress, and the
> equivalent in rtf
> format linked at the top of the table of contents
> http://snow.utoronto.ca/web-savvy/resources/top_ten.html

> Both versions seem accessible, except for perhaps a few confusing spots in
the
> demonstration markup.

Thanks, I'll take a look when I get more time!
Received on Friday, 21 July 2000 17:21:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:05 GMT