[1.3] Summary of guideline 1.3

Summary of guideline 1.3


Introduction

This document is meant to review guideline 1.3 and discuss the open issues
with this guideline. The current and proposed wordings are based on the
February 14 working draft [1]. Unless otherwise stated, the current wording
is used.
 
The current wording for 1.3 is: Information, functionality, and structure
are separable from presentation. The proposed wording is: Make information,
structure, and functionality recognizable even when users or user agents
change the presentation format. -- OR -- Preserve information, structure,
and functionality when changing visual or auditory presentation format.
 
My personal opinions are marked with my initials (YPH).

Outstanding issues


Issues in Bugzilla

The issues in Bugzilla can be found in the status report "Guideline 1.3
(content-structure-seperation) issues [2].

#317: Add color to 1.3 [3]

Ben Caldwell suggested that 1.3 should cover color as well (information
presented through color is also available without color). 
 
Suggested solution (YPH): 
This has been incorporated in WCAG 2 since the July 2003 draft. Some
word-smithing may need to be done but that's no reason not to close this
issue. 

#374: How do AT users learn what makes structure distinct and how these
distinctions can be specified [4]

Comment from Harvey Bingham about how the users can perceive the structure
through their user agents. For example, how should emphasized content be
pronounced (by speech pace, voice, etc.) and should the user have any
control over this presentation?
 
Suggested solution (YPH): 
Harvey Bingham's suggestions and concerns are beyond the scope of WCAG.
These are user agent issues. This guideline should make structure seperate
from presentation, and then the user agent guidelines will make sure the
structure is used by the user agents in an appropriate way. I propose to
take a vote to close this issue.

#405: Understanding which HTML elements to use w/out reading techniques [5]

Kynn Bartlett feels this guideline is very open ended and would the wording
to be a bit more concrete so someone reading this guideline will have an
idea of what to do without going into the techniques document.
 
Suggested solution (YPH): 
When Kynn Bartlett raised this issue, the wording was more abstract than the
current proposed wording. I think the current wording gives developers a
better idea of what is expected of them. Perhaps we can ask Kynn Bartlett if
he feels the same way and then close this issue.

#487: Are tables for layout a violation of 1.3? [6]

Greg Gay wonders if layout tables violates 1.3. 
 
Suggested solution (YPH): 
The working group has discussed a lot about whether to ban or allow tables
for layout. Consensus is that banning layout tables is not possible at this
time. Since properly used layout tables (meaning without structural markup)
pose no accessibility problems we will allow the use of tables for layout. I
suggest we close this issue since the above answers this question.

#506: clarify definition of structure [7]

Kansas Web Accessibility Subcommittee suggests to clarify the definition of
structure more clearly. There should
be a clear understanding of the difference between structure of code and
layout of information. Example: Developers use xml to semantically mark up
content but the output uses html/css to render screen layout.
 
Suggested solution (YPH): 
The current and proposed wordings of the checkpoints do not use the word
'structure'. This, together with the 'who benefits' and examples, should
make it clear to developers what is expected from them. I propose we vote to
close this issue.

#556: Clarify what is required by "separate structure and presentation"
checkpoint [8]

The US Access board warns that this is a very interesting requirement that
covers several major issues. The wording should cover all the different
aspects covered by this guideline. The US Access board is concerned that
with the wording at that time (Oct 2003) it wasn't obvious what this section
is addressing without prior accessibility knowledge.
 
Suggested solution (YPH): I agree with the US Access board's remarks.
Whenever I read the checkpoints for this guideline, I always feel that we
have only included the tip of the iceberg. See "Underlying issues", "Did we
cover everything?".

#595: example 4 in 1.3 should cross-reference 4.3 [9]

SIDAR's WCAG2-espa group suggests to cross reference example 4 to guideline
4.3. Example 4 is 
"a list that allows users to sort information on a page according to
preference. ", with explanation: A script allows a user to rearrange a
categorical listing of music files by date, artist, genre, or file size. The
script updates both the structure and the presentation accordingly when
generating alternate views." Guideline 4.3 was "Technologies used for
presentation and user interface support accessibility or alternate versions
of the content are provided that do support accessibility".
 
Suggested solution (YPH): 
I don't quite understand this comment. Perhaps he meant that the script in
example 4 should be acecssible according to 4.3 but I don't think that would
require a cross reference since each example should also follow the other
guidelines. I do not see any benefit in crossreferencing this example to
4.3. Unless someone else can see the merits in doing this, I propose to
close this checkpoint.

#604: proposed wording for first SC under 1.3, level 1 [10]

This bug actually covers 2 comments. The first is a plain language rewrite
by John Slatin for SC 1. 
 
The second is a suggested rewrite from Greg Lowney. He suggests to modify
the phrase "the following can be derived programmatically (i.e. through a
markup or data model that is assistive technology compatible)". He would
modify this to say that structural elements must be distinguished by
standard structural markup or API where such exist; non-standardized (e.g.
proprietary, platform- or application-specific) markup or API may also be
used and should be used when no standardized markup or API is defined for
the content type. This will allow a wider range of user agents to change the
presentation of the structural elements in a concerted fashion than would be
the case when proprietary markup or API are used. 

Suggested solution (YPH):
Ben Caldwell has included his suggested wording as proposed wording in the
Feb 14, 2004 draft. Personally I think his proposed wording focuses to much
on the benefits and less on the principles behind it. Let's keep the
guidelines and checkpoints as clean as possible. I think we should discuss
this point during the discussion of guideline 1.3.
 
I think Greg Lowney's comment is going to much into the how of user agents,
and is not a content issue. I do not think we want to say anything in this
guideline about the use of API's and markup since that is already covered in
the Robust principle. 

#605: Proposed wording for Guideline 1.3 SC 3 [11]

This is John Slatin's plain language rewrite for SC 3 (text over
background). He wonders if this shouldn't be level 2, and feels it's a near
duplicate of 1.6 (In visual presentations, make it easy to distinguish
foreground words and images from the background).
 
Suggested solution (YPH):
The suggested wording has been incorporated in the proposed wording for the
February 14, 2004 draft. 
However, I think this point belongs under 1.6. I think different people have
different feelings about what this guideline is about which need to be
resolved first. See "underlying issues", "What's this guideline about?".  

#669: misc. questions about guidelines 1.3 [12]

First question is whether we need emphasis. Second is if it's necessary to
differentiate between different kinds of emphasis (is every paragraph with
different formatting a type of emphasis?). Third question is whether it is
necessary for people to know the visual formatting of the text to be able to
communicate about the text with people using the default visual
presentation. Fourth question is whether Dropcaps are emphasis. 
 
Suggested solution (YPH):
Q1: emphasis is deemed important enough by the W3C to have a special element
in HTML. I think we should keep emphasis in this guideline.
Q2: I don't think we should go into different kinds of emphasis in the WCAG.
If an author wants to format a text in a different way, for example by using
a different font (visual) and different pitch (auditory) than it's upto
them.
Q3: If I were to talk to a blind person about a page, would I say "did you
like the red text as much as I did?". No, of course I wouldn't. The whole
reason for this checkpoint is that people can perceive the content in
different ways. I think it has no use to tell users who selected one kind of
presentation about the characteristics of other presentations. People will
perceive the content in different ways, which shouldn't be considered a
barrier to accessibility but rather as a benefit.
Q4: Depends on the use. I think this is something for the techniques
document, not the WCAG itself.
 
I think we should just discuss and answer these questions in the 1.3
discussion and then close this issue.

#670: location of 1.3, level 1, item 3? [13]

Greg Lowney also thinks SC 3 (text over background) belongs in 1.6.
 
Suggested solution (YPH): I agree, see #605.

#671: what is means by "separate from"? [14]

Greg Lowney to suggests to clarify the meaning of "separate from". By this
phrase, do you mean to require that the two
categories of markup be distinguishable, or that they actually have to be
physically separate? If separate, must they be in separate files or can they
be in separate sections of the same file? Personally I believe they should
only be distinguishable from each other.
 
Suggested solution (YPH):
I agree with Greg that it's not clear what it means to have your structure
separate from presentation. We need to figure out what this guideline is
about (See "underlying issues", "What's this guideline about?") which will
probably resolve this issue as well.

#672: 1.3 example 2 [15]

Greg Lowney has a question about example 2 (scrolling stock prices). Greg
asks what the recommended solution is in this case?  It is not obvious,
given that the server probably does not have all the quotes at any one time,
nor does it necessarily retain values after they are displayed.
 
Suggested solution (YPH):
Apperently Greg Lowney did not understand the example which in itself is a
problem (we need to have examples that are clear and easy to understand).
The example already said "Current stock quotes are scrolled horizontally
across the screen. The data are separate from the methods used to scroll the
text across the page." The last sentence is the solution: the stock prices
are available seperate from the methods to scroll the text, which will make
the content perceivable even if the scrolling is not available (for example
in speech browsers). We need to clarify this example and then we can close
this issue.

747. Guideline summary (to do) [16] 

Wendy Chisholm mentions we need a guideline summary for 1.3.
 
Suggested solution (YPH):
This is getting a bit meta :-) This document is the guideline summary. This
issue can be closed.


Underlying issues


What's this guideline about?

We really have to figure out what this guideline is about. Different people
seem to have different viewpoints and think different aspects should be
covered. At the moment, you have to read the checkpoints and examples to get
some idea of what this guideline is about. YPH: I think we need a unifying
view, a formulation of the guideline itself that communicates clearly what
it's about. 
 
The proposed wording for the guideline in the February 14, 2004 draft is
"Make information, structure, and functionality recognizable even when users
or user agents change the presentation format. -- OR -- Preserve
information, structure, and functionality when changing visual or auditory
presentation format." This is a lot narrower and more applied to one benefit
than the original "Information, functionality, and structure are separable
from presentation".
 
What do we want to say here? YPH: I personally like the "Information,
functionality and structure are separable from presentation". That this
makes the information recognizable when users change the presentation format
is a consequence or benefit of this guideline, I do not think it should be
the guideline itself.
 
YPH: To me, this guideline is about separating structure from presentation
so people can still perceive the structure of the content even if they
select a different presentation. In other words, if you strip away the
presentation, the web content should still be useable and logical with all
the structural elements intact. This allows user agents to make the
structure perceivable (for example present headers by a larger fonts or
accompany reading them by a beep, etc.)

Did we cover everything?

YPH: When I look at the HTML techniques document, I see a lot of techniques
that seem to address this guideline, but do not seem go with any of the
success criteria. [17]. For example: marking up quotations, using style
sheets to change list bullets, etc.
 
I think it's best if someone would go through other work done on
accessibility (like WCAG 1, section 508, HTML techniques) to see if we have
missed any important issues that are candidates for checkpoints in 1.3. I
would be happy to volunteer for this.

Dependencies between guidelines


Guideline 1.5 - Make structure perceivable

Guideline 1.3 says to separate content from presentation. This is a
prerequisite for 1.5. Perhaps 1.5 can be incorporated into 1.3.

Guideline 1.6 - Easy to distinguish foreground from background

SC 3 of guideline 1.3 is about presenting text over a background and (YPH)
should go under 1.6.

Guideline 2.4 - Facilitate orientation and movement

Guideline 1.3 says to use data models and markup to indicate (hierarchical)
relationships in the content. This overlaps with guideline 2.4's requirement
to markup the hierarchical structure (level 2 SC 1a), non-hierarchical
relationships (such as crossreferences, header cells in tables, etc.).
 
YPH: It sounds like guideline 2.4 is yet another guideline that builds on
1.3. I think the SC about relationships in 2.4 should be moved to 1.3. 2.4
should be about facilitating orientation and movement, not about indicating
structure since that's covered under 1.3.

Guideline 4.1 - Use technologies according to specs

Applying 1.3 means structural structural elements shouldn't be used for
visual effects and visual effects shouldn't be abused for structural
elements. ("If it walks like a duck and talks like a duck, it should be a
duck"). But this is also covered by guideline 4.1.
 
A few examples from HTML to make this more tangible:

*	use structural markup instead of visual presentation to represent
structural elements:

*	use headings (<hx>) instead of visual markup (for example <div
style="font-size:xx-large;">) to indicate headings 
*	use the listitem attributes if you want to use a picture for a
bullet instead of placing a <img> in front

*	do not abuse structural markup for visual effects

*	do not use th to create bold rows
*	do not use headings to achieve a certain visual effect if the texts
aren't headings

These two issues could become success criteria for either 1.3 or 4.1 (as a
special case of lvl 1 SC 1b). I think these two issues are important enough
to be explicitely incorporated into WCAG 2.

Assumptions

I have assumed that this checkpoint is about separating structure from
presentation, like a generalized version of guideline 3 in WCAG 1 (Use
markup and style sheets and do so properly.) [18]. I assumed we shouldn't go
into how to present the structure, since that's either a user agent issue or
covered by 1.5.

Rationale

If you separate structure from presentation, this means the structure
remains intact even if the user doesn't use the default presentation.
Letting users choose their way of using web content is an essential part of
web accessibility. Guideline 2.4 ensures that the user can select their
preferred presentation and still perceive the structure. For example, the
user can use a speech browser but still recognize headers, lists,
crossreferences, emphasis, etc. 

Author

This summary was written by Yvette Hoitink, February 2004 
Contact: y.p.hoitink@heritas.nl 

Notes

[1]. http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20040214.html
[2].
http://trace.wisc.edu/bugzilla_wcag/issuereports/content-structure-separatio
n_issues.php
[3]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=317
[4]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=374
[5]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=405
[6]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=487
[7]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=506
[8]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=556
[9]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=595
[10]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=604
[11]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=605
[12]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=669
[13]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=670
[14]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=671
[15]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=672
[16]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=747
[17]. http://www.w3.org/TR/2003/WD-WCAG20-HTML-TECHS-20031209/
[18]. http://www.w3.org/TR/WCAG10/#gl-structure-presentation