- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Thu, 17 May 2007 16:37:26 -0700
- To: "Joe Clark" <joeclark@joeclark.org>
- Cc: public-comments-WCAG20@w3.org
Comment 1:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-843)
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
The documents are unreadable
Every attempt has been made to make WCAG 2.0 and the related documents
listed above as readable and usable as possible while retaining the
accuracy and clarity needed in a technical specification. Sometimes
technical terms are needed for clarity or testability.
In fact, at 72 pages and 20,800 words, the WCAG 2 main document is
half a book's length and is studded with jargon. Informed people with
no disability whatsoever will find it hard to understand. The Working
Group has failed to deliver a standards document that can be
understood unto itself without reference to two other documents
(notably the WCAG 2).
----------------------------
Response from Working Group:
----------------------------
We received a great deal of input on the last call draft and have made
a large number of changes including a rewrite of much of the draft to
make it easier to understand. We have also included a new quick
reference document that provides a tool for practitioners who just
want the bottom line on the requirements and the techniques for
meeting them in different technologies. We also shortened the
Guidelines document considerably.
Here are some of the things we have done.
Easier language to understand
- Wrote simpler guidelines
- Removed as many technical terms (jargon) as possible replacing them
with plainer language or, where possible, their definitions
- Eliminated several new or unfamiliar terms. (authored unit, etc.)
- Removed the term Baseline and replaced it with "web technologies
that are accessibility supported" and then defined what it means to be
accessibility supported.
- Removed the nesting of definitions where we could (i.e. definitions
that pointed to other definitions)
- Tried to word things in manners that are more understandable to
different levels of Web expertise
- Added short names/handles on each success criterion to make them
easier to find and compare etc.
- Simplified the conformance
Shortening the document overall
- Shortened the introduction
- Moved much of the discussion out of the guidelines and put it in the
Understanding WCAG 2.0 document
- Shortened the conformance section and moved it after the guidelines
- Moved mapping from WCAG 1 to a separate support document (so it can
be updated more easily)
Creating a Quick Practitioner-oriented Summary / Checklist-like document
- Created a Quick Reference document that has just the Guidelines,
success criteria and the techniques for meeting the success criteria.
----------------------------------------------------------
Comment 2:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-844)
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
Natural languages
The primary natural language or languages of the Web unit can be
programmatically determined.
* A document may be bilingual or multilingual with approximately equal
proportions of content in different languages. At that point there is
no ""primary"" natural language. (I tried to explain this to the
Working Group, to so little avail that I hung up on Gregg Vanderheiden
during a conference call. Your guess is as good as mine why the
Working Group cannot accept this simple concept.)
* Some documents, like type samples, have no natural language. (As above.)
* There are some languages without language codes or whose language
codes are in dispute or that diverge from specification to
specification. In particular, [3]SIL is pretty much taking over the
process of language-coding and has proposed many codes that do not
match [4]ISO 639-2.
* Additionally, buried deep in the ISO 639-2 specification is a
language code for multiple-language documents, lang=""mul"". Support
for that code will be rather questionable in real-world devices, and
its existence came as a surprise even to Richard Ishida of the W3C,
who wrote a [5]Xerox paper that mentioned it.
----------------------------
Response from Working Group:
----------------------------
We have revised our terminology to "default human language" to clarify
the accessibility use of the information. Authors of multilingual
documents are encouraged to meet SC 3.1.2, even if they are only
claiming Level A conformance.
Even if a document contains no natural language text, it will need
text equivalents for the non-text content, and the default language is
used for the text equivalents.
While lang=""mul"" is a legal ISO 639-2 specification, it does not
specify a default text processing language.
Regarding the work of SIL; they are working on ISO 639-3. We have
updated the reference to RFC 3066 to RFC 4646 and have added "or its
successor."
----------------------------------------------------------
Comment 3:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-845)
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
audio description
narration added to the soundtrack to describe important visual details
that cannot be understood from the main soundtrack alone. [...] Audio
descriptions of video provide information about actions, characters,
scene changes, and on-screen text. [...] In standard audio
description, narration is added during existing pauses in dialogue.
1. Audio description provides ""information about actions,
characters, scene changes, and on-screen text"" among other things.
Nobody has produced an exhaustive list, and maybe we do or do not
need such a thing, but it isn't limited to those items.
2. Audio description is typically ""added during existing pauses in
dialogue."" There are quite a few occasions in which it is necessary
to describe over dialogue.
3. ""Audio description"" is generally written as a mass noun, like
""captioning."" Hence ""audio description of video provides.""
----------------------------
Response from Working Group:
----------------------------
WCAG 2.0 defines audio description (AD) as an alternative that is
inserted during natural occurring pauses. We cannot require AD to
occur over dialogue, even if there is not enough space to fully
describe the content, because putting AD over dialogue would make that
dialogue inaccessible. Level AAA requires extended audio description
which is usually how this should be handled.
Although AD is not yet standardized as a Mass noun
(http://ncam.wgbh.org/richmedia/tutorials/audiodesc.html), there is
momentum in the industry to make it a mass noun and therefore we have
changed it according to your recommendation.
We have also revised the first note in the definition of audio
description to read, "Audio description of video provides information
about actions, characters, scene changes, on-screen text, and other
visual content."
----------------------------------------------------------
Comment 4:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-846)
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
captions
text presented and synchronized with multimedia to provide not only
the speech, but also sound effects and sometimes speaker
identification
The term they're looking for here is ""non-speech information,
including meaningful sound effects and identification of speakers""
(the latter a slightly different sense than ""speaker
identification,"" which seems to require explicitly naming the
speaker).
Note: In some countries, the term ""subtitle"" is used to refer to
dialogue only and ""captions"" is used as the term for dialogue plus
sounds and speaker identification. In other countries, subtitle (or
its translation) is used to refer to both.
Those other countries are wrong. [6]Captioning is captioning and
subtitling is subtitling. WCAG 2 should not muddy the waters by giving
any credibility to errors of nomenclature in other English dialects.
----------------------------
Response from Working Group:
----------------------------
We changed "sound effects and sometimes speaker identification" to
"non-speech information conveyed through sound, including meaningful
sound effects and identification of speakers"
We kept the note since, although one might consider them wrong, they
still do this in both common and official language. The note is
therefore accurate and important for people to understand".
----------------------------------------------------------
Comment 5:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-847)
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
label
text, image, or sound that is presented to a user to identify a
component within Web content
Apparently it's possible to label something solely with a sound.
Doesn't a sound, like an image, then require a text equivalent? Don't
you always end up with text? And doesn't this ban the use of video or
multimedia as a label? I'm not proposing such a thing, but it seems
no less palatable than using an image or a sound as a label.
----------------------------
Response from Working Group:
----------------------------
Thanks for catching. "Sound" shouldn't be there and was removed. And
labels are not limited to text and images.
It now reads:
label
text, or other component with a text alternative, that is presented to
a user to identify a component within Web content
Note: See also [name].
----------------------------------------------------------
Comment 6:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-848)
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
sign-language interpretation
translation of spoken words and other audible information into a
language that uses a simultaneous combination of handshapes, facial
expressions, and orientation and movement of the hands, arms, or body
to convey meaning
One may translate only spoken words? Under WCAG, it becomes illegal
to translate from one sign language to another. It also becomes
illegal to do what Canada's Copyright Act [7]permits - translate a
written work into sign language.
----------------------------
Response from Working Group:
----------------------------
We cannot find anything in the guidelines that prohibits sign language
to sign language translation. The definition of sign language
interpretation in WCAG 2.0 clearly does not prohibit it. It simply
defines the term as used in the success criteria. The success
criteria make requirements but do not in any way prevent or forbid
translation of one sign language into another.
----------------------------------------------------------
Comment 7:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-849)
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
text
sequence of characters[INS: [.] :INS] Note: Characters are those
included in the Unicode/ISO/IEC 106464 repertoire.
One may use only characters in Unicode. Given that several scripts are
[8]unencoded in Unicode, this may present a problem. Some East Asian
languages are more robustly published with legacy encodings even if
that is ""improper."" I repeatedly tried to explain to the Working
Group that all that matters is a defined and understandable character
encoding.
----------------------------
Response from Working Group:
----------------------------
We have changed the definition of text and non-text so that it is
clear that we don't preclude the use of non-Unicode encodings as long
as AT can handle them (i.e. they can be 'programmatically
determined').
text: http://www.w3.org/TR/2007/WD-WCAG20-20070517/#textdef
non-text content:
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#non-text-contentdef
----------------------------------------------------------
Comment 8:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-850)
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
text alternative
programmatically-determined text that is used in place of non-text
content, or text that is used in addition to non-text content and
referred to from the programmatically-determined text
Hence a title attribute absolutely is a text equivalent. An image with
empty alt plus a title containing what would otherwise be the alt
text will pass WCAG 2. (There is some overlap here with UAAG, which
can be interpreted to allow presentation of title text instead of
regular or alt text.)
----------------------------
Response from Working Group:
----------------------------
The use of title alone (with empty alt text) would not constitute
alternate text and would not be sufficient for use as a text
alternative. If the alt attribute were empty, it would be stating that
the image was decorative and did not need alternate text.
Speaking Technically, programmatically determined means that it is
supported by assistive technology. A null alt attribute value is an
indication to assistive technology that it should be ignored. Since a
title attribute would not be presented by assistive technology if the
alt text were empty, it would not be programmatically determined text.
----------------------------------------------------------
Comment 9:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-851)
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
used in an unusual restricted way
words used in such a way that users must know exactly what definition
to apply in order to understand the content correctly
As opposed to when? When is it possible to misunderstand the
definition yet still ""understand the content correctly""?
----------------------------
Response from Working Group:
----------------------------
We have modified the definition slightly to clarify that that this
situation applies to situations where words are used in ways where
multiple definitions may apply and which definition to use may be
unclear to the user.
----------------------------------------------------------
Comment 10:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-852)
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
variations in presentations of text
changes in the visual appearance or sound of the text, such as
changing to a different font or a different voice
Web authors now have to worry about sound of text? How, exactly? We
don't control people's screen readers. (Does this mean we have to find
a way to mark up intonation and prosody in our podcasts? How,
exactly?)
----------------------------
Response from Working Group:
----------------------------
SC 1.3.4 has been folded into SC 1.3.1, in order to clarify that text
variations are one of many types of design that must be semantically
identified. SC 1.3.2 is thus more clearly specifically about the
non-semantic aspect of the visual design specific to color. As a
result, the definition has been removed from the document.
----------------------------------------------------------
Comment 11:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-854)
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
WCAG 2 violates WCAG 1 by listing an equation (for brightness as used
in the [9]general flash threshold) as plain text. In so doing it
pointlessly explains that ""the ^ character is the exponentiation
operator."" I thought this kind of thing is what we had MathML for.
----------------------------
Response from Working Group:
----------------------------
Because support for MathML varies across browsers and platforms,
because the information from the equations can be mis-presented in
some cases, and because it was possible to represent the luminosity
contrast ratio in ASCII, a MathML version of the equations was not
included in the guidelines themselves. We have, however, added a note
to the definition which points to a MathML version. Should support for
MathML change prior to publication, we will include this version in
the guidelines themselves.
----------------------------------------------------------
Comment 12:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-855)
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
We are starting to gather implementation examples during this Last
Call review process. Implementation examples are examples of pages or
sites that conform to the proposed WCAG 2.0 at various levels of
conformance.
I don't see any evidence that the Working Group is ""starting to
gather"" anything. I don't see evidence that they're looking for or
soliciting ""implementation examples,"" which in any event are
virtually nonexistent. WCAG 2, after all, wasn't released in anything
resembling a final version until late April 2006. There hasn't been
time for authors, even if they wished to comply with WCAG 2, to take
measures to do so. (Then there is the fact that there is no payoff for
authors to comply with a specification that, first of all, isn't final
yet and, second of all, that they may seriously disagree with.)
----------------------------
Response from Working Group:
----------------------------
The Implementation phase begins with the completion of Last Call. We
are however already talking to companies and individuals regarding
implementations. To make this clearer, we have added the following
sentence:
"For those interested in contributing to this effort, please contact
Michael Cooper, W3C staff contact to the WCAG WG."
----------------------------------------------------------
Comment 13:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-856)
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
The first public Working Draft of WCAG 2.0 was published 25 January
2001. Since then, the WCAG WG has published nine Working Drafts,
addressed more than 1,000 issues, and developed a variety of support
information for the guidelines.
Exactly how these 1,000 issues were ""addressed"" is open to dispute.
Start with the use of a Mozilla Bugzilla database as a front end for
bug reports. It's a remarkably inaccessible form, and baffling even to
a nondisabled expert. It's true that many, possibly hundreds, of bug
reports were remedied by rewriting the spec, but it's also true that
many bug reports were simply ignored (with responses that boiled down
to ""We don't agree this is a bug"").
At time of writing, WCAG Bugzilla had [10]27 open bugs.
----------------------------
Response from Working Group:
----------------------------
All comments received on the 27 April 2006 Last Call Working Draft
have been tracked in a separate database (not bugzilla), and responses
written for all the comments. The explanations may include how the
working group has modified the spec to address the comment, why the
working group feels the issue is outside the scope of the spec, or why
the working group does not agree with the commenter.
----------------------------------------------------------
Comment 14:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-857)
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
If a success criterion relates to a feature, component or type of
content that is not used in the content (for example, there is no
multimedia on the site), then that success criterion is met
automatically.
What should happen is that the success criterion is not applicable.
You can't pass a guideline that doesn't apply to anything in your
document. By that logic, we'd all be awarded gold medals in the
100-metre dash just for not showing up.
----------------------------
Response from Working Group:
----------------------------
We have rewritten the conformance section to require that all success
criteria be satisfied, and that satisfaction of a success criterion
happens when when the evaluation of it is not "false".
This addresses the problem without authors getting into labeling
success criteria as "not applying" (which others have pointed out
leads to problems with people using 'not apply' too broadly).
----------------------------------------------------------
Comment 15:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-858)
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
After many, many warnings that they were making a series of mistakes
and were not considering real-world Web sites, which they apparently
never read, the WCAG Working Group went right ahead and listed the
following for text equivalents to ""non-text content"":
If non-text content presents information or responds to user input,
text alternatives serve the same purpose and present the same
information as the non-text content. If text alternatives cannot serve
the same purpose, then text alternatives at least identify the
purpose of the non-text content.
How do I ""present the same information"" - note, the same information
- if my non-text content is, say, a thumbnail image of the front page
of a newspaper? That's a lot to retype into an alt text, don't you
think?
----------------------------
Response from Working Group:
----------------------------
If the non-text content is a thumbnail image of the front page of a
newspaper, its purpose is not to present information. What is it used
for; what is it's purpose? If it provides a link to the newspaper, the
text alternative should be something like "Smallville Times" which
serves the same purpose as the thumbnail image does. If it is simply
decorative, the text alternative should be null as indicated by the
last bullet. To clarify this point, we have added a thumbnail image
example to HTM 1.1.1.
----------------------------------------------------------
Comment 16:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-859)
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
Again after many unheeded warnings, the Working Group published the
following guideline for multimedia (at the highest level):
Sign-language interpretation is provided for multimedia.
First of all, which sign language? For an English-language source, no
fewer than five distinct, if not always mutually unintelligible, sign
languages can be identified (American, British, Irish, Australian, New
Zealand).
More importantly, WCAG now requires translating a document (a
multimedia file) into another language as a claimed accessibility
provision. To restate the same question I have been posing for years,
what prevents a Ukrainian-speaker from demanding that a Web site be
translated into Ukrainian? After all, in both cases the issue is the
incomprehensibility of the language of the original, not the
disability. (A deaf person is not necessarily unable to read. Deaf
people can and do understand and communicate in written language. A
reliance on sign language, or even a preference for it, does not
logically follow from being deaf.)
----------------------------
Response from Working Group:
----------------------------
This is a level AAA success criterion and is provided for those who
want to make their pages particularly accessible to people who are
deaf and for whom a written form of the spoken language is hard for
them to read. The success criterion does not assume that all
individuals who are deaf have trouble with written language but
acknowledges that some do. The specific type of sign language is not
specified and is therefore up to the author.
----------------------------------------------------------
Comment 17:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-860)
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
Following these guidelines will also make your Web content more
accessible to the vast majority of users, including older users. It
will also enable people to access Web content using many different
devices - including a wide variety of assistive technologies.
1. Older users are within the remit of Web accessibility inasmuch as
they are people with disabilities and in no other way.
2. We are not writing accessibility guidelines for devices.
----------------------------
Response from Working Group:
----------------------------
We have modified the introduction to make clearer the relationship
between aging and disabilities, and we have removed the reference to
other devices.
----------------------------------------------------------
Comment 18:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-861)
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
The concepts of scoping, baseline, and target audience are so
misguided as to derail WCAG's entire project. The first two topics
were addressed in my A List Apart article. The last one deserves
mention here.
Information about audience assumptions or target audience. This could
include language, geographic information, or other pertinent
information about the intended audience. The target-audience
information CANNOT specify anything related to disability or to
physical, sensory or cognitive requirements. [INS: [Overwrought
emphasis sic] :INS]
In other words, even if you extensively test your site and can
demonstrate the following is true, you cannot state that your site is
accessible to people with disabilities. While the guideline appears to
be intended to make it impossible to declare, for example, that a site
is not meant to be used by blind people, it also becomes impossible
to state that it provably can be used by them.
----------------------------
Response from Working Group:
----------------------------
WCAG no longer includes the sentence that target-audience information
cannot specify anything related to disability.
However, we continue to feel that it is invalid to say that the target
audience does not include people with disabilities or particular
disability.
----------------------------------------------------------
Comment 19:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-862)
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
Nobody can understand what the hell a ""Web unit"" is. In the
following explanation -
A Web unit conforms to WCAG 2.0 at a given conformance level only if
all content provided by that Web unit (including any secondary
resources that are rendered as part of the Web unit) conforms at that
level.
- what happens if I have a page full of thumbnail images, each with
correct alt text as required and each of which links to an image file
of a larger version of the picture? Since the image by itself has no
HTML or other markup, it's impossible to write an alt text for it. Is
this not a ""secondary resource""? If it isn't, does it not then
constitute a ""Web unit"" unto itself? Since Web units that are simple
image files cannot be made accessible, doesn't WCAG 2 essentially ban
freestanding image files?
(We are later told that linking to nonconforming content ""is not
prohibited"" - gee, thanks - but only if ""the content itself is [INS:
[not] :INS] a Web unit within the set of URIs to which the conformance
claim applies."" Hence if my freestanding image is still hosted on my
site, I have to make it comply with my conformance claim, which at the
very least requires a text equivalent, in turn meaning I have to wrap
the image file in HTML. But by the time you the site visitor have
selected and loaded that expanded image, you will already have had a
chance to read the alt text on the thumbnail image.)
----------------------------
Response from Working Group:
----------------------------
We have revised the guidelines and eliminated the word "Web unit" in
favor of "Web page." We have defined "Web page" (see
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#webpagedef ):
Web page
a resource that is referenced by a URI and is not embedded in
another resource, plus any other resources that are used in the
rendering or intended to be rendered together with it
Note: Although any "other resources" would be rendered together
with the primary resource, they would not necessarily be rendered
simultaneously with each other.
Example 1: When you enter http://shopping.example.com/ in your
browser you enter a movie-like interactive shopping environment where
you visually move about a store dragging products off of the shelves
around you into a visual shopping cart in front of you. Clicking on a
product causes it to be demonstrated with a specification sheet
floating alongside.
Example 2: A Web resource including all embedded images and media.
Example 3: A Web mail program built using Asynchronous JavaScript
and XML (AJAX). The program lives entirely at http://mail.example.com,
but includes an inbox, a contacts area and a calendar. Links or
buttons are provided that cause the the inbox, contacts, or calendar
to display, but do not change the URL of the page as a whole.
Example 4: A customizable portal site, where users can choose
content to display from a set of different content modules.
In the situation that you describe, the freestanding images would
constitute separate Web pages and would need to conform to WCAG or not
be included in a claim. Putting it in an HTML page would be an easy
way to make it accessible if that was desired.
----------------------------------------------------------
Comment 20:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-863)
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
WCAG 2 is nearly consistent in pretending that Web standards do not
exist (with one curious exception that I'll get to shortly). Some
teenagers have greater understanding of valid, semantic markup than
the Working Group does, as evinced in passages like these:
Information that is conveyed by variations in presentation of text is
also conveyed in text, or the variations in presentation of text can
be programmatically determined.
Now, what does ""presentation"" mean? Really?
Doesn't the requirement to convey the information in text make it
possible to write instructions for an online form as follows?
* Fields marked in red are required.
* Fields marked in green are optional but recommended.
I have just ""conveyed"" the colour differences. (It so happens that
the colours are exactly the rare ones that are confusable to
colourblind people.)
If I am using markup to vary presentation of text, as one typically
will (how else do you do it if you aren't using a picture of text?),
how is that markup ever not programmatically determinable? The browser
had to read it to vary the presentation in the first place. All the
usual elements, like em, strong, b, i, and u, are understandable by a
machine. So is CSS, even at the simple level used in this document as
a demonstration (span class=""red"" or =""green""). More complex CSS
selectors, like :last-child, are also programmatically determinable.
In essence, for any author using markup, even lousy presentational
markup, how is it possible to flunk this criterion?
----------------------------
Response from Working Group:
----------------------------
SC 1.3.1 and 1.3.4 have been combined to read "Information and
relationships conveyed through presentation can be programmatically
determined or are available in text, and notification of changes to
these is available to user agents, including assistive technologies."
This wording is similar to the wording of SC 1.3.4 at the time of the
comment, but the success criterion is clear that it is the
_information_ conveyed by variations in presentation that must be
conveyed, not the _fact_ that such information exists as the example
in the comment suggests. The How to Meet document for the combined
Success Criterion has been expanded to make this clearer.
----------------------------------------------------------
Comment 21:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-864)
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
Some parts of Web accessibility are not under the control of the
author. The user agent, like a browser or screen reader (the latter of
which is definitely included in WCAG 2's definition of ""user
agent""), has a significant role to play. Nonetheless, WCAG lists
these requirements:
More than one way is available to locate content within a set of Web
units where content is not the result of, or a step in, a process or
task.
Why can't people be expected to simpy use the Find command in their
browsers, or the back button?
The same issue reappears in that classic bugbear of Web-accessibility
pedants, hyperlinks:
Each link is programmatically associated with text from which its
purpose can be determined. [...] The purpose of each link can be
programmatically determined from the link.
""Purpose""? Doesn't Slashdot have an enormous mass of code in its
system to prevent people from linking to notorious vulgar images in
the guise of a real hyperlink? (There the ""purpose"" is to deceive.)
The ""purpose"" of a link is to provide a link, obviously.
Did they not mean the ""destination"" of a link? If so, how is it not
obvious from the semantics of the link? Isn't it embedded right in the
a href=""""? How is it impossible to ""determine"" the destination of
a link? That's the user agent's job, is it not?
Incidentally, there have been a few experimental all-sign-language
sites in which many links and their targets are given completely in
sign language. There is no link text per se. What's between and is a
video file or image of a person using sign language, and where you end
up is another such video file or image (or a page full of those).
Given the semantics of all markup systems in use on today's Web, the
hyperlink has to contain text characters in order to function. A still
image has to contain an alt text (though alt="""" is plausible in some
cases).
Nonetheless, there are a few scenarios in which a page intended to be
accessible to sign-language speakers uses no text at all. How is such
usage accommodated in WCAG 2? (And must authors, by implication, use
an interpreter to voice the sign language for blind visitors, which
must then of course be captioned or transcribed? Where does it end?)
----------------------------
Response from Working Group:
----------------------------
SC 2.4.2 is about locating content in a set of pages, not on a single
page, so reliance on a UA Find command is not sufficient to address
the concern. RE Back button, it is not clear how a back button
helps you to navigate except to go back to the previous page.
The use of the term "purpose" is intentional as SC 2.4.4 is a
requirement to convey meaning. Destinations, in the form of URLs, are
not meaningful for many people.
The usage of video-only media, including sign-language, is permitted
by WCAG 2.0. Per SC 1.1.1 a text alternative would be required.
Assuming each sign video conveys information, but is not otherwise
interactive, a text transcript (or longdesc) would be required to
satisfy SC 1.1.1. There is no implication that an interpreter is
required or that non-text content needs to be voiced. Only text
alternatives are required for non-text content (SC 1.1.1). And there
is no provision in WCAG that text alternatives need to have
alternatives etc.
----------------------------------------------------------
Comment 22:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-867)
I argued with the Working Group for months over the concept of
semantics in markup, that is, the use of the correct element for the
content. This argument betrayed the Group's arrogance and its thorough
incomptence at standards-compliant Web authoring. It also proved
they've been asleep at the wheel for the last eight years, in which
people like me have been labouring to improve Web standards. This
nonsense alone is enough to generate suspicion and distrust among
competent and up-to-date Web developers.
Nonetheless, now the word ""semantics"" is included, without
elaboration or definition, in the Understanding and Techniques
documents (whose examples I am condensing into one excerpt below).
Occasionally, the term is recast as ""structure.""
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
1. A simple text document is formatted with double blank lines before
titles, asterisks to indicate list items and other standard formatting
conventions so that its structure can be programmatically determined.
2. HTML Techniques for Marking Text [...] [11]Using semantic markup to
mark emphasized or special text
3. Making information and relationships conveyed through presentation
programmatically determinable USING the technology-specific techniques
below (for a technology in your baseline) [...] [12]Using semantic
elements to mark up structure [...] The semantics of some elements
define whether or not their content is a meaningful sequence. For
instance, in HTML, text is always a meaningful sequence. Tables and
ordered lists are meaningful sequences, but unordered lists are not.
4. CSS Techniques [...] [13]Positioning content based on structural markup
The WCAG main document does a drive-by and just barely avoids
mentioning semantics by name:
[INS: [Content] :INS] includes the code and markup that define the
structure, presentation, and interaction, as well as text, images,
and sounds that convey information to the end-user.
This means your markup is also your content, which will come as a
surprise to those who are interested in separation of content,
structure, presentation, and behaviour. Here, ""markup that define the
structure, presentation, and interaction"" clearly refers to
semantics.
----------------------------
Response from Working Group:
----------------------------
The principle is "separate information and structure from presentation."
.title {text-size: 200%}
is presentational and resides separately on the style sheet
The markup in the content is
. This is certainly part of the content. It has meaning. The
presentation features (i.e. text-size of 200%) of that title class are
on a separate stylesheet. Some markup is absolutely necessary as part
of the content. Otherwise we could not identfy anything as a heading
or a paragraph. We do not believe we have broken the principle of
"separate presentation from content". The definition of "content" has
been revised. It now is defined as, "information and sensory
experience to be communicated to the user by means of a user agent, as
well as code or markup that define the structure, presentation, and
interactions associated with those elements" Information and structure
should be separated from presentation, and the techniques etc all flow
from this. We are careful only to use the word 'semantic' in its
'semantic markup' form since there has been so much misunderstanding
around the multiple definitions of semantic.
----------------------------------------------------------
Comment 23:
Source: http://www.w3.org/mid/Pine.LNX.4.60.0605231711000.14640@aristotle.multipattern.com
(Issue ID: LC-869)
>From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
Some omissions immediately spring to mind. I have not done an
exhaustive check for such omissions.
1. There are no exemptions for examples or teaching materials. It is
illegal under WCAG to publish known incorrect documents as a learning
aid. You cannot publish the homework for your Web-development students
online (e.g., ""Fix these pages"") and have it all pass WCAG.
2. No accommodation of languageless documents like type samples.
----------------------------
Response from Working Group:
----------------------------
This is correct. If content does not conform to the success criteria
then it would not be listed as conforming. We have reworded the
conformance section so that WCAG does not delineate what should or
shouldn't conform but rather what does or doesn't conform.
Content that does not conform can be left out of any conformance claim
or the statement of partial conformance can be used to identify it.
There can be good reasons, such as the examples listed in the comment,
for content not to conform. It is out of the scope of WCAG to say what
should or shouldn't be a good reason but the working group
acknowledges that such reasons exist. Such content should not be
labeled as conforming though.
Received on Thursday, 17 May 2007 23:37:48 UTC