Your comments on WCAG 2.0 Last Call Draft of April 2006 (3 of 3)

Comment 25:

Source: http://www.w3.org/mid/20060505055625.14A83BDA7@w3c4.w3.org
(Issue ID: LC-505)

Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

It isn't clear what "or other primary resources" means other than a
set of Web units.

Proposed Change:

Delete "or other primary resources", or define what a "primary
resource" is. The former is preferable as there are enough terms
already - "Web unit", "authored unit", and "authored component".
Alternatively, replace "or other primary resources" with "or authored
components", as this seems the most relevant term.

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

Thanks for catching this editing error. We have removed the phrase,
"or other primary resources" from this criterion.

----------------------------------------------------------
Comment 26:

Source: http://www.w3.org/mid/20060505063942.9EBD4BDA7@w3c4.w3.org
(Issue ID: LC-506)

Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

As proposed by Charles McCathieNevile in commenting on the November
2005 working draft, the term "textual interface" should be used
instead of "keyboard interface". Some software interfaces do not
accept keystroke input directly, but instead receive character input;
they are not "keyboard interfaces" as defined in the glossary.

Proposed Change:

Substitute "textual interface" for "keyboard interface", and define
"textual interface" as an interface used by software to receive
characters or keystroke input. Under this definition, keystroke input
is included; thus compatibility with a keyboard interface would
satisfy the success criterion, as would compatibility with any
software mechanism capable of receiving character input, whether from
a keyboard or any other kind of input device.

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

This was discussed on January 12 teleconference and it was decided
then to keep the current phrasing. The rationale is as follows:

The term keyboard interface here is use to refer to the API that the
user agent uses to get its keystrokes from. The keystrokes include up
and down arrows, function keys, and other keystrokes that are not
text. The reason we use the phrase is to cover keyboard emulators
(such as mouse or pen keyboards) and devices that don't have native
keyboards (pda's) but accept them as accessories (via their keyboard
interface). This language also matches a number of other accessibility
standards and is better for harmonization.

Note also that definition of Keyboard Interface now reads:

keyboard interface
   interface used by software to obtain keystroke input

Note 1: Allows users to provide keystroke input to programs even if
the native technology does not contain a keyboard.

Example: A touch screen PDA has a keyboard interface built into its
operating system as well as a connector for external keyboards.
Applications on the PDA can use the interface to obtain keyboard input
either from an external keyboard or from other applications that
provide simulated keyboard output, such as handwriting interpreters or
speech to text applications with "keyboard emulation" functionality.

Note 2: Operation of the application (or parts of the application)
through a keyboard operated mouse emulator, such as MouseKeys, does
not qualify as operation through a keyboard interface because
operation of the program is through its pointing device interface -
not through its keyboard interface.


----------------------------------------------------------
Comment 27:

Source: http://www.w3.org/mid/20060509094110.A4404DAE7E@w3c4-bis.w3.org
(Issue ID: LC-512)

Part of Item:
Comment Type: QU
Comment (Including rationale for any proposed change):

To what extent is this implicit in the definition of "programmatically
determined" and all of the criteria requiring that aspects of the
content must be able to be "programmatically determined"?

Does programmatic determination impose a stronger requirement than sc
4.1.1 in so far as it demands the use of representations supported by
user agents? It is unclear how one could satisfy 1.3 if the user
agents can't unambiguously parse the content in the first place.

Proposed Change:

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

There is often overlap but not necessarily always overlap.   For
example, two browsers might parse a document differently using repair
techniques.  A particular item might be programmatically determinable
but be located in two different places on the page in the two
renderings.   It doesn't affect the meaning, but the inability to
parse the markup can break AT where it doesn't break other browsers.

----------------------------------------------------------
Comment 28:

Source: http://www.w3.org/mid/20060509100040.1E827BDA8@w3c4.w3.org
(Issue ID: LC-513)

Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

This guideline doesn't require the use of technologies, for example
markup languages, in accordance with the semantics defined in
specifications. Assistive technologies such as braille translators, as
well as content transformation tools, rely upon the assumption that
elements and attributes of markup languages are used to convey the
meanings prescribed in specifications. To the extent that content
departs from this requirement, programmatic determination of
structural and other aspects of content is precluded, being reduced
instead to a probabilistic matter requiring heuristics to be
introduced by the software developer. Although the definition of
"programmatically determined" refers to support by user agents, it
doesn't explicitly refer to standards governing the technologies used
in the content.

Proposed Change:

Add a requirement under this guideline to the effect that, for each
technology in the baseline that is defined in a specification, every
feature of the technology is used in conformity with the meaning and
purpose prescribed in the specification. Even better, require it to be
used in accordance with the meaning, purpose and syntax prescribed in
the specification. Alternatively, if the above is too strong a
requirement, restrict it at level 1 to every feature used to enable
the structure, purpose or meaning of the content to be
programmatically determined. That is, if the feature is used to enable
programmatic determination for purposes of meeting the guidelines,
then it must be used in accordance with the syntax and semantics
defined in the specification governing the technology. This falls
short of a requirement of full syntactic and semantic correctness, but
the stronger requirement could be added at level 2 or level 3.

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

The working group looked at this topic carefully over an extended
period of time and concluded that requiring strict adherence to all
aspects of specifications does not necessarily result in an increase
in accessibility. For example, it is possible to create invalid pages
that present no accessibility barriers. It is also possible in certain
situations to enhance accessibility through the use of markup that is
not part of the specification.

The working group must work within its charter and only include things
that directly affected accessibility. Some aspects of "use
technologies according to specification" and validity do relate to
accessibility. However, others do not. So requiring validity would
take us beyond our charter. We do recommend it though and it is our #1
technique listed for conforming to SC 4.1.1.

----------------------------------------------------------
Comment 29:

Source: http://www.w3.org/mid/20060509103434.1B79ABDA8@w3c4.w3.org
(Issue ID: LC-514)

Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

This criterion refers to the possibility of other versions of the
content being available from the same URI. However, if the content
consists of multiple Web units, there is no single URI from which the
content as a whole is available, since each Web unit included in the
content (i.e., within the scope of conformance) has its own URI.

Proposed Change:

Change "the content" to "each Web unit in the content", since the
requirement applies at the level of the individual Web unit rather
than to the content as a single entity. Equivalent language may be
employed to achieve this; the above is just a suggestion.

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

We have moved discussion of alternate versions of content to the
Conformance section of the Guidelines, and we have clarified by adding
a note that addresses your concern. The revised conformance criterion
reads:

"Alternate Versions: If a Web page within the scope of a claim does
not meet all of the required WCAG 2.0 success criteria at the level
claimed, then a mechanism to obtain an alternate version that meets
the success criteria can be derived from the nonconforming content or
its URI, and that mechanism meets all success criteria at the level
claimed.
Note: The alternate version does not need to be matched page for page
with the original (e.g. the alternative to a page may consist of
multiple pages)."

----------------------------------------------------------
Comment 30:

Source: http://www.w3.org/mid/20060509104026.DF870DAE7E@w3c4-bis.w3.org
(Issue ID: LC-515)

Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

See my comment on sc 4.2.1, which applies here too.

Proposed Change:

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

We have moved discussion of alternate versions of content to the
Conformance section of the Guidelines, and we have clarified by adding
a note that addresses your concern. The revised conformance criterion
reads:

"Alternate Versions: If a Web page within the scope of a claim does
not meet all of the required WCAG 2.0 success criteria at the level
claimed, then a mechanism to obtain an alternate version that meets
the success criteria can be derived from the nonconforming content or
its URI, and that mechanism meets all success criteria at the level
claimed.
Note: The alternate version does not need to be matched page for page
with the original (e.g. the alternative to a page may consist of
multiple pages)."

----------------------------------------------------------
Comment 31:

Source: http://www.w3.org/mid/20060509104752.F1893BDA9@w3c4.w3.org
(Issue ID: LC-516)

Part of Item:
Comment Type: QU
Comment (Including rationale for any proposed change):

Should there be a criterion corresponding to 4.2.1 and 4.2.3
introduced at level 3, requiring that at least one version of (each
Web unit in the) content satisfy at least 50% of the applicable level
3 success criteria? Alternatively, is it sufficient that all versions
of the content together meet 50% of the relevant success criteria in
order to constitute level 3 conformance?

Proposed Change:

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

We have changed the definition of Level AAA conformance so that all
Level AAA Success Criteria that apply to the content types used must
be satisfied. And we have changed the handling of alternate versions
so that the former SC 4.2.1 and 4.2.3 are addressed in the Alternate
Version conformance criterion, applies to all levels.

----------------------------------------------------------
Comment 32:

Source: http://www.w3.org/mid/20060524030710.ED30247B9F@mojo.w3.org
(Issue ID: LC-583)

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

If it is sufficient that the change in presentation of text can be
programmatically determined, then most changes in presentation (other,
perhaps, than in bitmapped images) will meet this criterion. The user agent,
after all, requires this information in order to render the change.

However, programmatic determination of the change in presentation is not
sufficient to meet the requirements of user agents and assistive technologies
providing presentations in other modalities (or in the same modality with
different stylistic requirements according to the needs of the user with a
disability). How is the user agent supposed to map the change in presentation
to a corresponding change, whether in text or in presentation, in its
generated rendering, if the purpose or meaning of the variation in
presentation cannot be programmatically determined? In the worst case, it
could simply \"announce\" the change, e.g., \"voice pitch flat\" or \"font size
14pt\" and leave the user to try to work out the significance, if any, of this;
but a better solution is to use the capabilities of the technology to convey
the meaning or significance of the change, while also allowing \"merely
decorative\" changes having no meaningful purpose to be ignored.

This shortcoming of the current criterion is addressed in the proposal below.

Proposed Change:

\"The meaning or purpose of the change in presentation of text can be
programmatically determined\". Alternatively, just \"purpose\" could be used in
place of \"meaning or purpose\" in the above. Alternatively, keep this criterion
as is and add a more stringent requirement at level 2 or level 3.

----------------------------
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 ensures that it is the meaning conveyed by the
presentation that must be programmatically determined, and allows the
author to indicate the meaning in text if it is not feasible to do so
programmatically. The How to Meet document describes this in some
detail.

----------------------------------------------------------
Comment 33:

Source: http://www.w3.org/mid/20060524051205.8E67133205@kearny.w3.org
(Issue ID: LC-584)

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

Some people use the word \"diagram\" to refer only to charts, schematics and
other drawn illustrations, excluding such graphics as photographs.

If this criterion is not meant to be so restricted, it would be better to use
\"graphics\". If a restriction is meant, \"diagram\" should be defined in the
glossary.

Proposed Change:

\"text or graphics\", or add a definition of \"diagram\" (see above).

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

SC 1.4.3 (formerly 1.4.1) has been changed only to address text content:

"Text and images of text have a contrast ratio of at least 5:1 with
their background. Text or images of text may have a contrast ratio of
at least 3:1 where all of the following are true:

    * Text is at least twice the height of the body text; and
    * the text has a stem width of at least three times the stem width
of the body text; and
    * the text is presented over a non-patterned background.

Note: This requirement does not apply to text or images of text that
are pure decoration."


----------------------------------------------------------
Comment 34:

Source: http://www.w3.org/mid/20060524051632.4DC6647B9F@mojo.w3.org
(Issue ID: LC-585)

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

Same as 1.4.1 re \"diagrams\".

Proposed Change:

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

SC 1.4.5 (formerly 1.4.3) has been changed only to address text content:

"Text and images of text have a contrast ratio of at least 10:1 with
their background. Text or images of text may have a contrast ratio of
at least 7:1 where all of the following are true:

    * Text is at least twice the height of the body text; and
    * the text has a stem width of at least three times the stem width
of the body text; and
    * the text is presented over a non-patterned background.

Note: This requirement does not apply to text or images of text that
are pure decoration."


----------------------------------------------------------
Comment 35:

Source: http://www.w3.org/mid/20060617031418.2263F47BA1@mojo.w3.org
(Issue ID: LC-817)

Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):

http://www.w3.org/WAI/WCAG20/quickref/
This reference document is highly accessible in
my hardware and software environment, and the
material is well organized, offering a
summary of each technique with a link to the full
explanation in the techniques documents.

I am confident this reference will be useful to
content developers who want to know how to apply
the guidelines with their chosen technologies,
wish to avoid working through lengthy techniques
documents, but find the application of the
high-level success criteria in the normative
document not to be straightforwardly obvious.

Proposed Change:

Consider whether to add a view in which all the
glossary definitions in the guidelines are
(optionally, of course) inserted into the body of
the document, as in the \"key terms\" sections of
\"Understanding WCAG 2.0\".
Consider also whether to publish the PHP source
code of the quick reference in case developers
want to install it on their intranets.

I would further suggest that when WCAG 2.0
reaches the Candidate Recommendation stage, a
prominent link be provided from the normative
guidelines document to the Quick Reference. For
many developers, I expect, the Quick Reference
will be the preferred means of reading the
guidelines.

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

All of the definitions are linked to directly from the words in the
Quick Reference. Clicking on any term will take you to the relevant
item in the glossary.  The glossary itself is quite long, so we do not
want to include it directly in the Quick Reference.

We have added links from the Guidelines to the Quick Reference. The
How To Meet links for the success criteria now take the reader to the
Quick Reference instead of the Understanding document.

With regard to the source code - we will be consider this in
conjunction with the EO working group as the Quick Reference becomes
stable.

Received on Thursday, 17 May 2007 23:36:50 UTC