Action item: Rewriting 1.3, "Ensure that information, functionality, and structure are separable from presentation"

Minutes from last week read, in part:


>    jc: GL 1.3 does say .....separable from presentation; should be
>    structure, presentation and behavior
>    ... structure==html; presentation==css; behavior==javascript (as
>    exmaples) should use this format
>    gv: where is information?
>    jc: no one will create empty document with just <p></p> - no web pages
>    with no content
>    gv: is important to say that info [be] separate from presentation - that
>    is intent of the GL
>    jc: can use CSS to add content - but existing wording is problematic
>    js: JC to take action to explain this better
>    <wendy> ACTION: joe write proposal for rewording on guideline 1.3 ala
>    structure, presentation, behavior and explanation how it address gv's
>    concern about separating out information....
>    gv: remember that orig inspiration of 1.3 was to maintain original
>    information in alternate presentations
>    <jslatin> intent of 1.3 to ensure that info is preserved when
>    presentation format changes

The existing wording seems like a na´ve 
approximation of the terminology used and 
accepted by standards-compliant Web developers, 
namely "structure, presentation, and behaviour."

In a typical Web page, HTML provides structure, 
CSS provides presentation, and JavaScript 
provides behaviour. This model is 
noncontroversial and almost axiomatic among 
standardistas, whom I polled.

I sent a message to various leading standardistas that read as follows:

>I have been tasked with coming up with better 
>wording for a guideline in WCAG 2.0, which 
>currently reads:
>>Guideline 1.3
>>Ensure that information, functionality, and 
>>structure are separable from presentation.
>>Level 1 Success Criteria for Guideline 1.3
>>     1. Structures and relationships within the content can be
>>        [111]programmatically determined. [I]
>>     2. Emphasis can be programmatically determined. [I]
>>     3. Any information presented through color is also available without
>>        color (for example, through context or markup or coding that does
>>        not depend on color). [I]
>>Level 2 Success Criteria for Guideline 1.3
>>     1. Information presented using color is also available without color
>>        and without having to interpret markup (for example through
>>        context or text coding). [V]
>My first issue is that the phrase "information, 
>functionality, and structure" in the slug of the 
>guideline seem like a novice's or a non-expert's 
>attempt at expressing a concept by now very 
>familiar to standardistas-- that there are three 
>layers to a typical Web site, the structure 
>(HTML), presentation (CSS), and behaviour (JS). 
>The addition of Flash, multimedia, or PDF 
>complicates matters, but those are unusual cases 
>when the Web as a whole is considered.
>Some WCAG Working Group members think we need to 
>put "information" in there, but I argue that's 
>tautological. Nobody publishes a Web site made 
>up of <p></p> and <h1></h1> with nothing inside 
>them. Among other things, that contravenes the 
>HTML spec, and valid code is going to be a 
>requirement at all times in WCAG 2 [or so I 
>hope-- Ed.].
>Moreover, the examples they give in the 
>compliance section-- emphasis, colour-- are 
>picayune and are a consequence of standards 
>compliance and semantic markup anyway.
>So: Questions.
>1. Based on your knowledge and experience, and 
>what we know already about standards compliance 
>and semantic Web development, what wording would 
>you prefer for the slug of this guideline?
>	"information, functionality, and structure"?
>	"structure, presentation, and behaviour"?
>	other?
>2. What wording would you suggest for the 
>success criteria in this guideline? Would it not 
>have something to do with semantic markup? 
>progressive enhancement?
>3. How do you think we should handle data 
>formats that don't have validators (like PDF, 
>JavaScript) or structure (images)? I'm just 
>looking for vague suggestions here.


1. Jeffrey Zeldman <> (somewhat-tart remarks elided)

>>Some WCAG Working Group members think we need 
>>to put "information" in there, but I argue 
>>that's tautological. Nobody publishes a Web 
>>site made up of <p></p> and <h1></h1> with 
>>nothing inside them. Among other things, that 
>>contravenes the HTML spec, and valid code is 
>>going to be a requirement at all times in WCAG 
>	You are correct.
>>	"structure, presentation, and behaviour"?
>		Bingo!
>		(How can these experts not know that?)

2. Gez Lemon <>

>I would opt for "structure, presentation, and 
>behaviour", or even "content, presentation, and 
>>  2. What wording would you suggest for the success criteria in this
>>  guideline? Would it not have something to do with semantic markup?
>>  progressive enhancement?
>I'm useless at wording things well, but I do 
>think the success criteria should at least 
>include the following:
>1: The document is usable without CSS
>2: The document is usable without scripting
>3: The document is structurally correct
>4: The structure validates to formal grammars if a validator exists
>for the particular grammar
>5: CSS validates to formal grammars
>6: Scripting doesn't result in errors or warnings in a scripting console
>I mentioned documents being usable without 
>scripting at the face-to-face meeting in 
>>  3. How do you think we should handle data formats that don't have
>>  validators (like PDF, JavaScript) or structure (images)? I'm just
>>  looking for vague suggestions here.
>[...] Ideally, it would be good to push the 
>vendors, such as Adobe, to create validators 
>that could check a document for basic 
>accessibility. The only other things I can think 
>of are testing for device independence, and 
>testing with assistive technology if it's 
>available (or Opera 8).
>Browsers like Mozilla and Opera have very good 
>scripting consoles that alert developers of any 
>warnings and errors. I can't think of a means of 
>checking the accessibility right now, but 
>checking that documents behave as expected when 
>scripting is disabled, following progressive 
>enhancement techniques would help.

3. Molly Holzschlag <>

>"Structure, presentation, and behavior" gets my 
>vote.  These are the layers in the cake, after 

4. Dave Shea <>

>>  2. What wording would you suggest for the 
>>success criteria in this guideline? Would it 
>>not have something to do with semantic markup? 
>>progressive enhancement?
>Working backwards here...
>Level 1, point 3 & Level 2, point 1. The two 
>references to information/color are almost 
>identical, although the informative notes they 
>reference are different. I don't see any reason 
>why these haven't already been combined into a 
>single Level 2 guideline.
>Level 1, point 2. The emphasis criteria links to 
>an informative note that tells you to use 
>semantic markup, and then goes on to describe 
>nothing of the sort. There should instead be 
>some clear guidelines on different types of 
>possible emphasis, when to use headers vs. 
>strong/em elements, and perhaps a discussion on 
>b/i and why the visual emphasis they add doesn't 
>mean anything when, for example, spoken aloud.
>(And is it just me or is Example 1 on the note --
>  -- a perfect example of presentational content? 
>I'm having a tough time seeing the difference. 
>Between. Doing. This. To. Convey. Emphasis. and, 
>say, using inline pipe characters as list 
>separators, for example.)
>New level 1 point -
>        Any information conveyed through presentational or scripted
>        elements is also available when presentation and/or script are
>        disabled.
>Among other things, this would mean that when 
>images are disabled, when CSS is disabled, when 
>Javascript is disabled, when Flash is disabled, 
>you could still navigate a site and use its 
>content. Exceptions being information locked 
>into images, which the existing informative note 
>attached to Level 1, point 1 goes into greater 
>detail clarifying.
>This also implicitly allows progressive 
>enhancement, as any usage of advanced 
>technologies over top of a sound document 
>structure should gracefully degrade if this 
>point is adhered to.
>>  3. How do you think we should handle data 
>>formats that don't have validators (like PDF, 
>>JavaScript) or structure (images)? I'm just 
>>looking for vague suggestions here.
>Same as always, I suppose. Graceful degradation 
>and alternative data views where possible. If a 
>financial report is locked in a PDF, it should 
>also be made available as structural HTML (or 
>plain text if that's not possible). That's about 
>the best I can suggest until there are automated 

5. Brothercake <>

>>	"structure, presentation, and behaviour"?
>That's the one I prefer as well - gets the 
>concept across neatly because it's instantly 
>recognisable what each aspect is.   The other 
>example sounds very obtuse.
>>2. What wording would you suggest for the 
>>success criteria in this guideline? Would it 
>>not have something to do with semantic markup? 
>>progressive enhancement?
>Perhaps a note to the effect of: "ensure that 
>emphasis is conveyed through mode-independent 
>markup (eg. using <strong> rather than <b> or 
><big> to convey strong-emphasis-- using 
>semantics rather than visual effects)" or "when 
>introducing new technologies to a page, ensure 
>that the functionality degrades gracefully"  [no 
>shortage of XMLHttpRequest fanatics who could do 
>with a reminder about that one ;)]
>>3. How do you think we should handle data 
>>formats that don't have validators (like PDF, 
>>JavaScript) or structure (images)? I'm just 
>>looking for vague suggestions here.
>Maybe .. "whenever information is offered in 
>data formats which are not universally 
>accessible (eg, PDF, scripting, images) ensure 
>that the same information is also available in 
>an accessible form."

Working Group members must accept that a total 
separation of structure and content is not even 
philosophically possible. This fact has been 
discussed on the list before, and if people would 
like citations, I can give them separately.

At root, you the author must understand the 
purpose or meaning of your content and then 
select an appropriate structure. That action in 
itself eliminates the distinction between 
structure and content. Moreover, there are many 
cases, and they aren't even really edge cases, 
where no (X)HTML element is suitable and you the 
author must approximate.

Even XHTML 1.1 permits elements that are 
essentially presentational. You can create valid 
documents that use them.

Furthermore, CSS permits the inclusion of content 
in its presentation layer through, for example, 
background images and the :before and :after 


In addition, the distinction between block and 
inline elements in HTML (and the few that can be 
either of those, like ins, del, iframe) is 
arguably presentationalist, and the people 
arguing that point are in WAI:


>DRAFT UAWG comments about 6 May 2003 XHTML 2.0
>General comments:
>1. Please don't organize the spec in terms of 
>block / inline, which is a visual rendering view 
>of the elements. Instead, group by element 
>semantics. If the semantics are 
>presentation-based, that's a problem.

The inclusion of the word "information" in the 
existing 1.3 is indeed tautological and reflects 
a misunderstanding of HTML and Web development.

I've created a test document with no content that 
is nonetheless perfect HTML according to the 


There is a chance this is the only such document 
on the entire Web. Nonetheless, the validator is 
in error: <p></p>, for example, marks up 
paragraphs, but there is no actual paragraph 
being marked up.

Nobody in their right mind would produce 
documents like this with the serious intent that 
they be read, used, or consumed. "Information" is 
what we use the Web *for*; it does not need to be 
part of that guideline.

The issue of including information in alternate 
presentations is handled by the *structure* of 
the document, the *presentation* of it via CSS, 
its *behaviour* via JavaScript (for example), and 
of course through text equivalents. This too 
reflects a misunderstanding of Web development.

Expert consensus holds that the current wording is inaccurate.

1.3 should be rewritten to read something like the following:

Whenever markup or languages permit, ensure that 
structure, presentation, and behaviour are 
separated to the extent possible for the content.


     Joe Clark |
     Accessibility <>
     Expect criticism if you top-post

Received on Monday, 18 April 2005 16:50:43 UTC