Re: Status of RTF format?

Bruce

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

> 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.

> 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.


> 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.

> 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?"

>
>
> 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.

>
> --
> Cheers,
> Bruce Bailey
>
> >>> My question is, if a developer includes RTF copies of word processed
> >>> documents on a web site, are they obliged to include an html
> >>> version in order to satisfy guideline 11.1?
> >>
> >> Yes, absolutely.  RTF is only modestly more accessible than PDF
> >> (or Word or WordPerfect for that matter).
> >
> > We have not been able to create an instance where an rtf file are
> > inaccessible
> > (with correct use of images and layout, that also applies to html
> > documents),
> > though pdf file are almost always inaccessible (for now). I can see some
> > justification for providing alternatives for proprietary Word  or
> > Wordperfect
> > documents  (in many cases developers include an rtf equivalent of
> > these), but
> > not for an html equivalent of rtf documents. If someone could
> > demonstrate an
> > inaccessible rtf file, It might help me understand why this
> > format is not an
> > acceptable accessible alternative for any of the above file formats.
> >
> >> Sure, its a shared non-proprietary format,
> >> but there are no public specifications for "validity", let alone
> >> "accessible".
> >
> > Does this mean by default that it is inaccessible because  its
> > accessibility has
> > not been documented? I have a hard time justifying this without
> > some concrete
> > evidence  that demonstrates rtf in an inaccessible form. I have
> > an easier time
> > making html documents inaccessible than I do making an rtf files
> > inaccessible.
> >
> > Specifications
> > http://www.geocities.com/~vmushinskiy/fformats/files/rtf.txt
> > Microsoft's Specs
> > ftp://x2ftp.oulu.fi/pub/msdos/programming/formats/rtfspec.zip

--
Greg Gay
Web Projects & Instructional Design
Centre for Academic and Adaptive Technology
University of Toronto
416 978-4043
ICQ 9020587

Received on Friday, 21 July 2000 13:29:26 UTC