Your comments on WCAG 2.0 Public Working Draft of May, 2007 (4 of 4)

Comment 39: "all" of the following requirements CAN'T be met, as
depends on chosen level
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0367.html
(Issue ID: 2220)
----------------------------
Original Comment:
----------------------------

The first para states

"In order to conform to WCAG 2.0 all of the following conformance
requirements must be met..."

Then, the first 3 requirements are mutually exclusive, or rather
they\'re a single requirement which changes depending on which level
the author wants to claim conformance to.

Proposed Change:
Aggregate the first 3 requirements into a single requirement with sub-points:

1) All SCs for the chosen conformance level are fulfilled:

  - Level A Conformance: ...

  - Level AA Conformance: ...

  - Level AAA Conformance: ...

This then requires a renumbering of the following points:

2) Alternative Versions: ...

3) Accessibility-Supported Technologies Only: ...

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

We have changed the conformance requirements as you suggested.

----------------------------------------------------------
Comment 40: Addition to "Accessibility-Supported Technologies"
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0369.html
(Issue ID: 2221)
----------------------------
Original Comment:
----------------------------

The final para in "Accessibility-Supported Technologies" can possibly
be expanded to mention "alternative versions" again, thus also
reinforcing the previous point.

"...must also be available via technologies that are accessibility supported."

Proposed Change:
"...must also be available via alternate versions using technologies
that are accessibility supported."


A thought, though: would this new wording cover things like fallback
mechanisms of OBJECT element in HTML? Does that count as an alternate
version?

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

The words "Alternate Versions" in our document means alternate
versions of entire web pages. The sentence you cite is meant to
include making the information available on the same page as well as
other pages (including the method you suggested with "object"). We did
not include the "alternate versions" language since it would be too
narrow, and adding all the different ways would make the sentence too
long and hard to parse. But you have the right general idea.

Technique H53 is about using the body of the object element but the
technique is not supported well by assistive technologies and
cross-browser support is irregular.

----------------------------------------------------------
Comment 41: "Non-Interference" "No Keyboard Trap" dependend on UA/plugin as well
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0370.html
(Issue ID: 2222)
----------------------------
Original Comment:
----------------------------

"No Keyboard Trap" is not simply down to authors. It's dependent on
the user agent and the plugin itself (consider keyboard issues in
current and recent browsers + flash, where keyboard focus either gets
lost, or it's not possible to jump into the flash movie in the first
place via keyboard alone).

Proposed Change:
possibly add a note that this is dependent on UAAG compliance of UA
and plugin technology itself.

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

We have moved the keyboard trapping requirement to a new success criterion:

"2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component
of the page using a keyboard interface, then focus can be moved away
from that component using only a keyboard interface, and, if it
requires more than unmodified arrow or tab keys, the user is advised
of the method for moving focus away."

The problem of trapping may or may not involve the user agent.  But if
the keyboard will be trapped by a technology that the author is using
to create content, then it is up to the author to either tell the user
how to get out before they encounter the keyboard-trapping content or
to provide a natural means for them to get out.

----------------------------------------------------------
Comment 42: "machine-readable metadata" preferred...but do UAs support it?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0371.html
(Issue ID: 2223)
----------------------------
Original Comment:
----------------------------

"Optional components of a conformance claim\", first numbered bullet:

"This information should be provided in a form that consumers can use,
preferably machine-readable metadata."

This seems to imply that users CAN actually make use (with current
user agents) of this metadata. In practice, how many end-users have a
UA that can read, say, EARL or DC accessibility data?

Proposed Change:
Drop the "preferably machine-readable metadata" altogether.

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

This is kind of a chicken-and-egg situation. Although current
technologies cannot take advantage of this, AT could be designed to if
pages were so marked.   Providing this information in any other form
would be so much less useful that, if one is going to do this, we
believe they should do it in machine readable (metadata) format.

----------------------------------------------------------
Comment 43: "Optional components..." typo and awkward sentence
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0372.html
(Issue ID: 2224)
----------------------------
Original Comment:
----------------------------

\"3. ... , that the content with which the content has been tested.\"



typo.

Proposed Change:
"3. ... , with which the content has been tested."

if you're not bound by arcane "no split infinitive" rules and actually
use language that is used every day anyway:

"3. ... , that the content has been tested with."

Even easier, to avoid the debacle, turning the sentence around:

"3. A list of user agents, ... , that were used to test the content."

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

Thank you. We have updated this item to read, "A list of user agents,
including assistive technologies, that were used to test the content."

----------------------------------------------------------
Comment 44: "Optional components..." meta-data reference, pt 2
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0373.html
(Issue ID: 2225)
----------------------------
Original Comment:
----------------------------

"5. ... , in machine-readable metadata."

As with my comment on point 1 of the same list, this assumes that
programs that can consume this metadata are readily available. As
this, to my knowledge, is not the case, I'd suggest dropping the
reference to metadata altogether.

Proposed Change:
drop the reference to metadata altogether.

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

See Response to Issue 2223.

----------------------------------------------------------
Comment 45: "Contrast ratio" definition and user-selected colours
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0397.html
(Issue ID: 2263)
----------------------------
Original Comment:
----------------------------

"Note 4: ... white is assumed."

May be worth mentioning that users could have set their own bg colour as well.

Proposed Change:
"Note 4: ... white is assumed. However, it's worth noting that users
may have set their own preferred background color, which may differ
considerably from the luminance value of white." or similar

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

Respond with: We have changed the note to state that foreground and
background colors must be specified together to avoid arbitrary
contrast. This is supported by F24: Failure of SC 1.4.3 and 1.4.5 due
to specifying foreground colors without specifying background colors
or vice versa.

"Background color is the specified color of content over which the
text is to be rendered in normal usage. It is an error if no
background color is specified when a foreground color is specified,
because the user's default background color is unknown and cannot be
evaluated for sufficient contrast. For the same reason, it is an error
if no foreground color is specified when a background color is
specified."

If the user has explicitly set their own background color, then they
should also set the foreground color because in common web
technologies in use today, the content has no way to respond to this
in a way to preserve contrast ratio.

----------------------------------------------------------
Comment 46: "tactilely" in "human language" definition
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0398.html
(Issue ID: 2264)
Status: VERIFIED ACCEPTED
----------------------------
Original Comment:
----------------------------

"...(visually or tactilely)..."

although grammatically correct, it's far from common usage.

Proposed Change:
change "tactilely" to "by touch"

"...(visually or by touch)..."

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

Response:
We have changed the wording of "visually or tactilely" to "through
visual or tactile means"

----------------------------------------------------------
Comment 47: "idioms"
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0399.html
(Issue ID: 2265)
----------------------------
Original Comment:
----------------------------

may be worth either expanding the first para, or adding an additional
note, to mention that idioms can't be translated word for word /
verbatim.

Proposed Change:
"note: idioms cannot be translated directly, word for word, without
losing their (culture or language dependant) meaning."

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

We have added the note that you suggested.

----------------------------------------------------------
Comment 48: "keyboard interface"
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0400.html
(Issue ID: 2266)
----------------------------
Original Comment:
----------------------------

there's no explicit mention of switch access or sip/puff devices.
should there be?

Proposed Change:
add a mention of switch access + sip/puff devices.

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

We have added these examples to the definition of assistive technology

----------------------------------------------------------
Comment 49: "large scale"
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0401.html
(Issue ID: 2267)
----------------------------
Original Comment:
----------------------------

the definition talks of "points", but these end up being relative due
to user/OS settings. worth noting that they're not really absolute, as
they can be overridden (knowingly or unknowingly) by the user.

Proposed Change:
"note 3: in the context of digital displays, actual point size, like
any other 'absolute' measurement unit, depends on the user's display
size/settings."

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

It is true that text is not always displayed at the author-requested
size, even if the author specified a point size. This can be due to an
incorrect pixels per inch setting on the user's display device, or
user font size preferences. The author cannot be responsible for these
conditions, though should be aware of the potential. Therefore we have
added a note to the definition that reads: "The actual size of the
character that a user sees in dependent both on the author-defined
size and the users display or user-agent settings. This success
criterion is based on common pixel sizes available today. Users who
have low vision would be responsible for choosing appropriate
settings."

----------------------------------------------------------
Comment 50: "non-text content"
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0402.html
(Issue ID: 2268)
----------------------------
Original Comment:
----------------------------

maybe pedantic, but worth rewording the note to be even more explicit:

"Note: This includes ASCII Art ..."

Proposed Change:
"Note: This also includes sequences of characters used as ASCII Art ..."

side note: what about emoticons?

Received on Sunday, 4 November 2007 05:06:33 UTC