RE: Your comments on WCAG 2.0 Public Working Draft of May, 2007

After carefully looking at the responses in context with the changes
that were made, I can confidently say that I'm satisfied with the
proposed changes and the explanations that were given to me.

Thank you for all your work! 

Juan C. Ulloa
Webmaster, Web Services
Bellevue Community College
julloa@bcc.ctc.edu
425.564.2487
N216e
:-)

-----Original Message-----
From: Loretta Guarino Reid [mailto:lorettaguarino@google.com] 
Sent: Saturday, November 03, 2007 9:54 PM
To: Juan Ulloa
Cc: public-comments-WCAG20@w3.org
Subject: Your comments on WCAG 2.0 Public Working Draft of May, 2007

Dear Juan Ulloa,

Thank you for your comments on the 17 May 2007 Public Working Draft of
the Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2007/WD-WCAG20-20070517/). The WCAG Working Group
has reviewed all comments received on the May draft, and will be
publishing an updated Public Working Draft shortly. Before we do that,
we would like to know whether we have understood your comments
correctly, and also whether you are satisfied with our resolutions.

Please review our resolutions for the following comments, and reply to
us by 19 November 2007 at public-comments-wcag20@w3.org to say whether
you are satisfied. Note that this list is publicly archived. Note also
that we are not asking for new issues, nor for an updated review of
the entire document at this time.

Please see below for the text of comments that you submitted and our
resolutions to your comments. Each comment includes a link to the
archived copy of your original comment on
http://lists.w3.org/Archives/Public/public-comments-wcag20/, and may
also include links to the relevant changes in the WCAG 2.0 Editor's
Draft of May-October 2007 at
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20071102/

Thank you for your time reviewing and sending comments. Though we
cannot always do exactly what each commenter requests, all of the
comments are valuable to the development of WCAG 2.0.

Regards,

Loretta Guarino Reid, WCAG WG Co-Chair
Gregg Vanderheiden, WCAG WG Co-Chair
Michael Cooper, WCAG WG Staff Contact

On behalf of the WCAG Working Group

----------------------------------------------------------
Comment 1: confusion with non-live audio/video
Source:
http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0247.
html
(Issue ID: 2082)
----------------------------
Original Comment:
----------------------------

Overall confusion is that pre-recorded audio and pre-recorded video
are not well represented in the guideline when it is *not* a part of a
multimedia presentation.   It often only refers to non-live
audio/video in multimedia, but multimedia is defined as video or audio
synchonized with some other method of providing information.  Since
Video includes Audio, video is not multimedia, it's just video.  If
the definition of Multimedia should include Video, this should be made
clear.


Whats not clear:

The entire sentence.  It mentions multimedia (which is defined as
audio or video combined with another component) and it includes live
audio or live video.  But since the definition of multimedia doesn't
include non-live audio or video, I get confused.  This is specially
true because the ways to meet this criteria seem like you should also
use for non-live audio and non-live video.

Proposed Change:
I would expect to see something about pre-recorded audio/video under
guideline 1.1.1.  Since 1.1.1 differentiates live audio/video to only
have a clear label/name, then I would think that non-live audio/video
would be required to at least have a full text transcript, right?
This is particularly true since audio/video are linear unless when
they are a part of a multimedia presentation.

---------------------------------------------
Response from Working Group:
---------------------------------------------

Prerecorded audio/video is multimedia and is specifically covered
under the second exception. (though note that we are using
"synchronized media" instead of multimedia now since it includes more
than classic multimedia")

Prerecorded (non-live) audio-only and prerecorded (non-live)
video-only are not listed in an exception because they are included in
the main 1.1.1 provision.

However, since that was not clear to you - it may not be clear to
others. So we have added the following note to the exception.

"NOTE: Prerecorded audio-only and video-only files would be covered
under [Success Criterion 1.1.1], which requires text alternatives that
present equivalent information."


----------------------------------------------------------
Comment 2: Why is Sign Language not required on non-multimedia
Source:
http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0248.
html
(Issue ID: 2083)
----------------------------
Original Comment:
----------------------------

If 1.2.5 requires Multimedia to have Sign Language Interpretation,
shouldn't there be a requirement for video as well?   Actually,
shouldn't this requirement be for Audio/Video in general? My
assumption is that you only need to provide sign language
interpretation for Audio/Video in a multimedia presentation, right?
If that is the case, this should be moved out of guideline 1.2. But
since Sign Language is not text, this wouldn't fin int guideline 1.1
and since this is not multimeda, it woudln't fit in 1.2.  I would
maybe place it under 1.3 because we are essentially asking the user to
have information provided in diffrent ways.  In this case, we are
asking for voice audio to be provided in sign language.

On a separate note, why would we require a website to provide sign
language if they are already providing captioning?  Wouldn't
synchronized captioning along with synchronized descriptions for video
and multimedia and transcripts for audio-only methods of distributing
content be enough to make the content fully accessible?

---------------------------------------------
Response from Working Group:
---------------------------------------------

Let us answer your questions in turn.

 - Video-only doesn't have sign language because there is no audio
information that the deaf person is missing.

 - Captions are not sufficient for some people who live mostly in a
signing environment and who do not read a lot of text because these
individuals often cannot read text fast enough to keep up in a movie
where the text by necessity is only displayed for a limited time.

 - Sign language is not required on audio-only because a text
transcripts are required and people have as much time as they need to
read them.

We have added an advisory technique under Guideline 1.1 to provide
sign language videos for audio-only files.

----------------------------------------------------------
Comment 3: 2.1.1 and 2.1.2 don't seem to have a clear distinction
Source:
http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0249.
html
(Issue ID: 2084)
----------------------------
Original Comment:
----------------------------

I'm not clear in the distinction between the 2 guidelines.  I don't
understand what the following sentence means: "except where the
underlying function requires input that depends on the path of the
user's movement and not just the endpoints."  This seems to be the
only distinction between the two requirements.

Proposed Change:
Add more supplementary information to make the distinction clear.  Add
references on 2.1.2 to 2.1.1 to state the difference.

---------------------------------------------
Response from Working Group:
---------------------------------------------

There are some activities where it is not possible to provide control
from the keyboard without requiring a very large number (thousands) of
keystrokes.  The exception in 2.1.1 covers that.  (for more
information - see Understanding 2.1.1 in the Understanding WCAG 2.0
Document.). For 2.1.2 there is not exception. You cannot include those
types of activities on a page that would meet 2.1.2.

An example of something that would fall into the exception category
would be water color painting or freehand sketching.

An example of something would not meet the exception is handwriting
recognition. Even though the act of handwriting depends on the user's
movement and not just the endpoints, the function (text entry) does
not, and can be supported also via the keyboard.

----------------------------------------------------------
Comment 4: 2.4.8 is not clearly differentiated from 2.4.4
Source:
http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0250.
html
(Issue ID: 2085)
----------------------------
Original Comment:
----------------------------

I'm not 100% clear about the difference between the two guidelines.
Specially since one of the first sufficient techniques listed for
2.4.4 is to provide "link text that describes the purpose of a link"
and guideline 2.4.8 requires that "the purpose of each link can be
identified from the link text".  I'm confused as to how the first
sufficient technique of a level A requirement also seems to meet a
level AAA requirement.

Proposed Change:
Clarify 2.4.8 so to make the distinction clear.   If I understood the
distinction better, I would provide some ideas.

---------------------------------------------
Response from Working Group:
---------------------------------------------

In order to clarify the difference between SC 2.4.4 and 2.4.8, we have
changed SC 2.4.4 to read "2.4.4 Link Purpose (Context): The purpose of
each link can be determined from the link text or the link text
together with its programmatically determinable link context."

We have also changed SC 2.4.8 (now 2.4.9) to read:

"A mechanism is available to allow the purpose of each link to be
identified from link text alone."

----------------------------------------------------------
Comment 5: Should 2.4.9 be a AA requirement?
Source:
http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0251.
html
(Issue ID: 2086)
----------------------------
Original Comment:
----------------------------

Shouldn't 2.4.9 be an AA requirement?  It seems to me that it should
be an AA requirement because this would help users who aren't using
assistive technology, for example, a visual user running a web browser
that doesn't understand styles in a PDA or cell phone.

Proposed Change:
Make 2.4.9 be an AA requirement

---------------------------------------------
Response from Working Group:
---------------------------------------------

In order to be a AA or A requirement, it must possible for all types
of content to meet the requirement.  In addition, all success criteria
must be reliably testable.  After a great deal of effort, the working
group was unable to craft a criterion that met both requirements.  By
defining a section in a way that allowed reliable agreement between
parties on what is and is not a section, some types of longer-form
text content (e.g. novels) cannot pass.  Because of this limitation,
the Success Criterion must remain level AAA.

Below is the text of the SC and the definition of section

2.4.10 Section Headings: Section headings are used to organize the
content.
Note: "Heading" is used in its general sense and includes titles and
other ways to add a heading to different types of content.

Note: This success criterion covers sections within writing, not user
interface components. User Interface components are covered under
Success Criterion 4.1.2.
Section Headings: Where content is organized into sections, the
sections are indicated with headings.

Note: "Heading" is used in its general sense and includes titles and
other ways to add a heading to different types of content.

section: A self-contained portion of written content that deals with
one or more related topics or thoughts.

NOTE: A section may consist of one or more paragraphs and include
graphics, tables, lists and sub-sections.

----------------------------------------------------------
Comment 6: Add Exception to 3.1.1
Source:
http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0252.
html
(Issue ID: 2087)
----------------------------
Original Comment:
----------------------------

Shouldn\'t requirement 3.1.1 have an exception?  Just curious. Because
it seems to me, working for a college in the US that it would be
assumed that the language would be English and a user with assistive
technology would make that same assumption.  Because of that, I would
think that all web pages that are in English shouldn\'t need to state
their natural language.  But, I would think that if I have a website
(lets say the French department) that is primarily in French, that it
should state that French is its natural language because that page is
an exception of our overal website.

Proposed Change:
Add exception to 3.1.1 so that you don\'t need to state the language
if the website user could assume the language of the website based on
geographical region/customer base.     Or Maybe this could be split up
into an A and AA requirement.  A requirement would be for web pages in
an organization that break the assumption of the natural language.
The AA requirement would be for all web pages to include their default
language.

---------------------------------------------
Response from Working Group:
---------------------------------------------

In your case of a university, which English would be used? A United
Kingdom university might have an English 101 class for their British,
Scottish, Canadian, Australian and United States students. Different
languages versions would be used for each target audience, because
proper/correct English depends on the linguistic rules of the default
human languages of a particular culture.

One cannot assume that because a person is in a specific geographic
location that they use/speak one specific language. What of someone in
Belgium, where the languages are Dutch, French and German? What would
be the location default human language? It would depend on that
author, and the specific audience that the author was trying to reach.

The intent of this success criterion is to ensure that content
developers provide information in the Web page that user agents need
to present text and other linguistic content correctly. Both assistive
technologies and conventional user agents can render text more
accurately when the language of the Web page is identified. Screen
readers can load the correct pronunciation rules. Visual browsers can
display characters and scripts correctly. Media players can show
captions correctly. As a result, users with disabilities will be
better able to understand the content.

The default human language of the Web page is the default
text-processing language as discussed in Internationalization Best
Practices: Specifying Language in XHTML & HTML Content. When a Web
page uses several languages, the default text-processing language is
the language which is used most. (If several languages are used
equally, the first language used should be chosen as the default human
language.)

----------------------------------------------------------
Comment 7: Multimedia and Video confusion
Source:
http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0253.
html
(Issue ID: 2088)
----------------------------
Original Comment:
----------------------------

Is video w/ Audio multimedia? If not, what is Video w/ Audio called?
 I would assume that Video that has audio is still Video.  But this is
unclear through the definitions provided on this document.

Proposed Change:
Can the Video definition mention that Video can often include audio?

---------------------------------------------
Response from Working Group:
---------------------------------------------

We have moved away from the term "multimedia" and are now using the
term "synchronized media" for audio or video that is synchronized with
anything else (e.g.  video, audio, interaction etc).

We are also using the term  video-only when we mean video without
audio (or interaction).   Also using audio-only in the same way if we
mean an audio file.

----------------------------------------------------------
Comment 8: Does video with synchronized captions fit into 1.2?
Source:
http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0254.
html
(Issue ID: 2089)
----------------------------
Original Comment:
----------------------------

Would a Video file that was made accessible by adding synchronized
captions (through something like SMIL) be considered multimedia?
Judging by the definition of multimedia, I would think that is the
case.

Proposed Change:
Add an exception in either the definition of Multimedia *or* in all
the 1.2 requirements stating that video with synchronized audio for
the purposes of making its audio accessible does not make the video a
"multimedia" presentation.

---------------------------------------------
Response from Working Group:
---------------------------------------------

We think we understand your comment.

- if the file is video only - then you would not need to add captions
because there is no audio to caption.
- if the file was "video with audio" then it would be multimedia
- if the file was "video-only" and you added audio descriptions then
you do not need to caption the descriptions (because they are
descriptions of information that is already presented visually.)
However we don't currently say that anywhere.  So we assume that is
the problem you are point out?

To fix this - a note has been added to the definition of 'CAPTIONS' as
follows
"NOTE: Audio descriptions can be, but do not need to be, captioned
since they are descriptions of information that is already presented
visually. "

Received on Monday, 5 November 2007 15:57:27 UTC