The PRE Element and Accessibility (2 of 3 LONG)
Janina Sajka
janina at rednote.net
Sun Aug 31 14:43:08 EDT 2003
The WCAG further explains its approach by explaining how the
recommendation is organized:
"This document includes fourteen guidelines, or general principles of
accessible design. Each guideline includes:
* "The guideline number.
* "The statement of the guideline. ...
* "The rationale behind the guideline and some groups of users who
benefit from it.
* "A list of checkpoint definitions.
"The checkpoint definitions in each guideline explain how the
guideline
applies in typical content development scenarios. Each checkpoint
definition includes:
* "The checkpoint number.
* "The statement of the checkpoint.
* "The priority of the checkpoint. Priority 1 checkpoints are
highlighted through the use of style sheets.
* Optional informative notes, clarifying examples, and cross
references to related guidelines or checkpoints.
* ""A link to a section of the Techniques Document
where implementations and examples of the checkpoint are
discussed.
"Each checkpoint is intended to be specific enough so that someone
reviewing a page or site may verify that the checkpoint has been
satisfied."
ANALYSIS
This analysis of the accessibility impact that using the <PRE> element
in web content imposes on various individuals who are persons with
disabilities will, therefore, consider each of these 14 guidelines in
turn. Does the guideline apply? What impact does it have? On who?
It is worthwhile to note that by definition, <PRE> exists in tension
with the basic themes underlying web accessibility as expressed in the
WCAG. By definition <PRE> does not "gracefully transform" to any other
presentation. It's very purpose is to lock in a particular presentation.
Nor can it assist accessibility by making larger blocks of text
"understandable and navigable." It allows no navigational elements
within its bounds. Furthermore, people whose comprehension is challenged
by larger blocks of undifferentiated text can be expected to have
greater difficulty accessing content bounded by <PRE>.
The <PRE> element does figure directly in the WCAG once, namely at:
"Guideline 3. Use markup and style sheets and do so properly.
"Mark up documents with the proper structural elements. Control
presentation
with style sheets rather than with presentation elements and
attributes.
"Using markup improperly -- not according to specification -- hinders
accessibility. Misusing markup for a presentation effect (e.g., using
a table for layout or a header to change the font size) makes it
difficult for users with specialized software to understand the
organization of the page or to navigate through it. Furthermore,
using
presentation markup rather than structural markup to convey structure
(e.g., constructing what looks like a table of data with an HTML PRE
element) makes it difficult to render a page intelligibly to other
devices (refer to the description of difference between content,
structure, and presentation).
"Content developers may be tempted to use (or misuse) constructs that
achieve a desired formatting effect on older browsers. They must be
aware that these practices cause accessibility problems and must
consider whether the formatting effect is so critical as to warrant
making the document inaccessible to some users."
Indeed, content producers may be tempted simply to dump content into the
<PRE> tag, wrapping it with <html> and <body>, as we have seen recently,
to my great surprise and dismay. In the instance noted on this list in
previous discussion there was no mention of a need to preserve white
space, or to preserve a particular look and feel. Indeed, the
justification was ease under conditions of constrained time. One writer,
perhaps recognizing the inconsistency, nevertheless defended the
practice on the grounds that it was acceptable as a temporary expedient.
Since the <PRE> tag is not being used as intended, it seems clear that
this guideline is violated. But even more, it seems clear that it is
being suborned for convenience sake. I would warrant that any client
paying for markup might have legal grounds not to pay for such
deliverables on the simple ground that no markup, as defined by W3C
recommendations, is being delivered. Simply wrapping content as:
<html><body><pre> [CONTENT] </pre></body></html
hardly constitutes markup. Certainly, it does not constitute markup as
intended even by the earliest extant HTML specifications. Guidance on
appropriate use of <PRE> can be found at
http://www.w3.org/TR/html401/struct/text.html, where the example is a
poem whose visual appearance is considered important to its artistic
purpose, i.e. the spacing of alternate lines in the poem. I wonder,
frankly, that a poem by e. e. cummings might not have been used to make
the case even more clearly.
More information about the Speakup
mailing list