- From: Joe Clark <joeclark@joeclark.org>
- Date: Mon, 18 Apr 2005 12:46:03 -0400
- To: WAI-GL <w3c-wai-gl@w3.org>
Minutes from last week read, in part:
<http://www.w3.org/2005/04/14-wai-wcag-minutes.html#>
> 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
MY INITIAL POINT
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.
QUERY TO STANDARDISTAS
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:
>
><http://www.w3.org/TR/WCAG20/#content-structure-separation>
>
>>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.
RESPONSES
1. Jeffrey Zeldman <http://Zeldman.com/> (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
>>2.
>
> You are correct.
>>
>> "structure, presentation, and behaviour"?
>
> Bingo!
>
> (How can these experts not know that?)
2. Gez Lemon <http://JuicyStudio.com/>
>I would opt for "structure, presentation, and
>behaviour", or even "content, presentation, and
>behaviour".
>
>> 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
>Dublin[...].
>
>> 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 <http://Molly.com/>
>"Structure, presentation, and behavior" gets my
>vote. These are the layers in the cake, after
>all.
4. Dave Shea <http://mezzoblue.com/>
>> 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 --
><http://www.w3.org/TR/2004/WD-WCAG20-GENERAL-20041119/content-structure-separation-emphasis.html>
> -- 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
>tools.
5. Brothercake <http://brothercake.com/>
>> "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."
LIMITATIONS ON SEPARATION OF STRUCTURE AND CONTENT
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
pseudoelements.
<http://www.w3.org/TR/REC-CSS2/generate.html#before-after-content>
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:
<http://www.w3.org/WAI/UA/2003/05/xhtml2-comments.html>
>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.
WE DON'T NEED TO INCLUDE THE WORD "INFORMATION"
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
validator:
<http://joeclark.org/dossiers/ContentlessDocument.html>
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.
CONCLUSION
Expert consensus holds that the current wording is inaccurate.
PROPOSAL
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 | joeclark@joeclark.org
Accessibility <http://joeclark.org/access/>
Expect criticism if you top-post
Received on Monday, 18 April 2005 16:50:43 UTC