W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2001

Re: WCAG 2 simplified

From: David Woolley <david@djwhome.demon.co.uk>
Date: Sat, 11 Aug 2001 10:53:57 +0100 (BST)
Message-Id: <200108110953.f7B9rv306574@djwhome.demon.co.uk>
To: w3c-wai-ig@w3.org
Joe Clark wrote:
> 
The following is plain text; if your user agent tries to interpet it
as HTML, it is broken.

> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
> "http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
> <head>
> 	<meta http-equiv="content-type" content="text/html; 
> charset=iso-8859-1" />
> 	<title>WCAG 2 simplified by Joe Clark</title>

Don't use initials here; titles are seen out of context, e.g. in bookmarks
and search engine results.

> </head>
> <body>
> <div id="toc">
> <h1>WCAG 2 simplified by <a href="http://joeclark.org/access/" 

Historically, at least, this should have had a rev="made" attribute,
but, in spite of talks of the semantic web, and their ability to do
the job done by meta better, rel and rev are more or less dead.

> title="Joe Clark: Media Access">Joe Clark</a></h1>
> 
> 	<h2><a accesskey="c" id="contents" name="contents">Table of 
> Contents</a></h2>
> 	<ul>
> 		<li>
> 			<a href="#presentation">Guideline 1 - 
> Presentation. Design content that allows presentation according to 

This seems to have lost meaning to the extent that almost everyone
could claim compliance.  The following individual points to clarify,
but they seem not to include the important one of using designs which
will survive if all the presentation is overridden by the user.

> the user&#8217;s needs and preferences</a>
          ^^^^^^^
This does not allow graceful fallback to older technology.  There are
still a lot of browsers in the field that do not understand Unicode,
and even some Unicode aware ones may not know how to map this into
available fonts.

> 			<ul>
> 				<li>
> 					<a href="#natural-lang">1.4 
> Identify the primary  language of text and text equivalents and all 
> changes in  language.</a>
> 
> <ul>

Although this appears not to be part of the published version, this
still appears to be an abuse of lists for presentational purposes.

> 	<li><strong>Note</strong>: I dropped <cite>human</cite> and 
                                             ^^^^^^^^^^^^^^^^^^
This IS an abuse of cite for presentational purposes; subsequent
uses not explicitly noted.

> <cite>natural</cite> completely. Neither is necessary, frankly.</li>
> </ul>
> 
> 				</li>
> 				<li>
> 					<a href="#use-style">1.5 Keep 
> content and structure separate from presentation.</a>
> <ul>
> 	<li><strong>Note</strong>: &#8220;Separate content and 
                                   ^^^^^^

This should be <q> for modern browsers or " for older browsers.  In
this context, I would go for " - similar points not explicitly noted.

> structure&#8221; can be read as a noun phrase, with 
> <cite>separate</cite> as an adjective. This way it&#8217;s 
> unambiguous.</li>
> </ul>
> 
> 				</li>
> 			</ul>
> 		</li>
> 		<li>
> 			<a href="#navigation">Guideline 2 - 
> Interaction. Design content that allows interaction according to the 
> user&#8217;s needs and preferences</a>

I think users should be plural, i.e. users'.

> 			<ul>
> 				<li>
> 					<a 
> href="#consistent-behaviors">2.1 Handle input errors, such as 
> misspellings.</a>

This can be overdone resulting in garbage in, correctly spelled garbage out.

> 				</li>
> 				<li>
> 					<a 
> href="#consistent-responses">2.2 Provide consistent and predictable 
> responses to user actions.</a>
> 				</li>
> 				<li>
> 					<a 
> href="#extreme-context-change">2.3 Give users control of mechanisms 
> that cause extreme changes in context.</a><ul>
> 	<li><strong>Note</strong>: This is an example of a guideline 
> that cannot be simplified further because it requires a fuller 
> explanation just to understand the main point.</li>

The average commercial web page author isn't going to realise that
this refers to what he does every day!

> </ul>
> 
> 				</li>
> 				<li>
> 					<a 
> href="#avoid-interfering">2.4 When content requires a timed response, 

I think this has lost all meaning.  The only obvious literal cases I can
think of are where an e-commerce session gets timed out after about 20 
minutes, or maybe a pre-"e-commerce" timeout is exceeded, e.g. a hold
on an airline seat.

I think, though, that it is actually talking about "push" technology,
where there is no explicit response expected from the user at all,
and the only implicit response is to finish reading the page.

> 				<li>
> 					<a href="#avoid-flicker">2.6 
> Avoid causing the screen to flicker.</a>

The only real cases I've seen of this would not have been obvious to
the author (alternative dark and white scan lines on an interlaced
display).

We seem to have lost any requirements on distracting animation entirely.
> 				</li>
> 			</ul>
> 		</li>
> 		<li>
> 			<a href="#comprehension">Guideline 3. 
> Comprehension: Make it as easy as possible to use and understand</a>

"possible" is carrying a lot of responsibility here.  The lawyers would
want "reasonably possible", to avoid forcing people to go extremes, and
authors could say the requirement is so subjective that they had done what
was possible anyway.

I'd consider turning it round and say "Make it no more difficult to use or
understand than is strictly necessary for the purpose it serves" (even then
the lawyers might want a "reasonably").  This also acknowledges that different
purposes require different levels of prior knowledge.

> 			<ul>
> 				<li>
> 					<a href="#consistency">3.1 
> Use consistent presentation.</a>

I don't think I would understand what this means if I didn't have prior
knowledge of the issues.  "presentation" is something of a technical term
that is somewhat beyond the level of knowledge of most authors, who
cut and paste or use WYSIWYG tools.  They are doing it, but they don't
need to name it.  This also demonstrates the limits on making content
easy to understand at all levels, without bloating it with explanations.

The whole clause is vague.  What you are really saying is make presentation
a function of the structural component being presented and only introduce
the designer's whim at the site or sub-site level.

> 				</li>
> 				<li>
> 					<a 
> href="#use-style-to-emphasize">3.2 Emphasize structure through 
> presentation, positioning, and labels.</a>

Some aspects of presentation should have adequate default handling by
the browser; identifying it explicitly seems to put a responsibility on
authors to always override the default styling (which actually conflicts
with what I think item 1 is trying to say).  Labels is the only aspect of
this where the typical WYSIWYG page designer might feel they are failing.

> 				</li>
> 				<li>
> 					<a 
> href="#clear-and-simple">3.3 Write as simply as possible in a way 
> that remains appropriate for the site&#8217;s content.</a>
> <ul>
> 	<li><strong>Note</strong>: This is the <cite>only</cite> 
> rendition that makes sense.</li>
> </ul>
> 
> 				</li>
> 				<li>
> 					<a 
> href="#supplement-text">3.4 Wherever possible, use a wide range of 
> modes of expression.</a>

At face value, this conflicts with the write simply requirement.  I think
it means use text, images, sound etc., but it appears to mean use a wide
range of different writing styles in the text.

> <ul>
> 	<li><strong>Note</strong>: This too is the <cite>only</cite> 
> rendition that makes sense.</li>
> </ul>
> 				<li>
> 					<a 
> href="#wcag-possible-lang">4.1 Choose technologies that support the 
> use of these guidelines.</a>

Potential for islands of compatibility.

> 				</li>
> 				<li>
> 					<a 
> href="#use-markup-correctly">4.2 Use technologies according to 
> specification.</a>

Too weak.  The abuse of cite in this text, doesn't violate the objective
part of the specification, but is still incorrect use of markup.  There
are objective parts of the specification, subjective parts, and the spirit.
One is aiming for the spirit.

<q> is a particular problem as it is not covered by objective parts of the
specification and there are good reasons for avoiding its use with the
current state of browsers.

> 				</li>
> 				<li>
> 					<a 
> href="#AT-compatible-UI">4.3 Design user interfaces so they are 
> compatible with assistive technology.</a>

I think I would want more specific points at this level.  People may not
realise that this covers the use of large fonts and non-standard colour
schemes.  These aren't properly covered by the next point as they are 
not turning off the features but changing the defaults.

> 				</li>
> 				<li>
> 					<a 
> href="#new-tech-degrade">4.4 Design content so that, when 
> presentation effects are turned off or not supported, the content is 
> still usable.</a>
> 				</li>
> 			</ul>
Received on Saturday, 11 August 2001 05:59:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:13:55 GMT