I have promised a dissertation on the <pre> element vis a vis accessibility. This email is that document. DISCLAIMER:All opinions expressed here are my own and do not necessarily reflect the views of any other individual or of any organization except as expressly denoted within quotation marks and attributed by URL reference. The Issue: There have been recent exchanges contesting whether or not use of the <pre> tag constitutes a challenge to accessibility of that content. DEFINITION: <pre> has been in the HTML specs at least since HTML 2.0 (see http://www.w3.org/MarkUp/html-spec/html-spec_5.html) where <pre> was defined (see http://www.w3.org/MarkUp/1995-archive/Elements/PRE.html) as: "PRE: Preformatted text "Preformatted elements in HTML are displayed with text in a fixed width font, and so are suitable for text which has been formatted for a teletype by some existing formatting system." Note: There wasn't really an html 1.0 (See http://lists.w3.org/Archives/Public/www-html/1997Jan/0035.html). The definition from HTML 4.01 (see http://www.w3.org/TR/html401/struct/text.html) explains: ""The PRE element tells visual user agents that the enclosed text is "preformatted". When handling preformatted text, visual user agents: * ""May leave white space intact. * "May render text with a fixed-pitch font. * "May disable automatic word wrap. * "Must not disable bidirectional processing. "Non-visual user agents are not required to respect extra white space in the content of a PRE element. ... "The DTD fragment above indicates which elements may not appear within a PRE declaration. This is the same as in HTML 3.2, and is intended to preserve constant line spacing and column alignment for text rendered in a fixed pitch font. Authors are discouraged from altering this behavior through style sheets." <PRE> is still available in the most recent W3C XHTML 1.1 recommendation (see http://www.w3.org/TR/xhtml11/) and in the public draft for XHTML 2.0 (see http://www.w3.org/TR/2002/WD-xhtml2-20020805/xhtml2.html). ACCESSIBILITY The W3C's recommendation on accessibility in content markup is known as the Web Content Accessibility Guidelines (WCAG). The WCAG 1.0 recommendation is at http://www.w3.org/TR/WCAG10/. The current public draft of WCAG 2.0 is at http://www.w3.org/TR/2003/WD-WCAG20-20030624/. The approach to accessibility in web content is introduced in the WCAG 1.0 as follows: "For those unfamiliar with accessibility issues pertaining to Web page design, consider that many users may be operating in contexts very different from your own: * "They may not be able to see, hear, move, or may not be able to process some types of information easily or at all. * "They may have difficulty reading or comprehending text. * "They may not have or be able to use a keyboard or mouse. * "They may have a text-only screen, a small screen, or a slow Internet connection. * "They may not speak or understand fluently the language in which the document is written. * "They may be in a situation where their eyes, ears, or hands are busy or interfered with (e.g., driving to work, working in a loud environment, etc.). * "They may have an early version of a browser, a different browser entirely, a voice browser, or a different operating system. "Content developers must consider these different situations during page design. While there are several situations to consider, each accessible design choice generally benefits several disability groups at once and the Web community as a whole. For example, by using style sheets to control font styles and eliminating the FONT element, HTML authors will have more control over their pages, make those pages more accessible to people with low vision, and by sharing the style sheets, will often shorten page download times for all users." The WCAG summarizes the process as consisting of twh themes: " The guidelines address two general themes: ensuring graceful transformation, and making content understandable and navigable."
