W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > November 2007

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

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Sat, 3 Nov 2007 22:05:43 -0700
Message-ID: <824e742c0711032205m393c8761t7247bc479dda88b7@mail.gmail.com>
To: "Patrick H. Lauke" <redux@splintered.co.uk>
Cc: public-comments-WCAG20@w3.org

Comment 25: Awkward non-word "turnon"
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0351.html
(Issue ID: 2206)
----------------------------
Original Comment:
----------------------------

"Audio Turnon"

Turnon? Making audio "on/off-able"?

Proposed Change:
"Audio Control"

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

Very good suggestion. We have updated the text as proposed. Thank you.

----------------------------------------------------------
Comment 26: resized without AT
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0352html
(Issue ID: 2207)
----------------------------
Original Comment:
----------------------------

"Visually rendered text can be resized without assistive technology..."

This is still dependent on a user agent that follows UAAG
recommendations, though. Also, "without assistive technology\" may
sound awkward, when you mean "in common user agents" or
similar...admittedly a tricky one.

Proposed Change:
"Visually rendered text can be resized in UAAG compliant user agents,
without the use of any additional magnification software, ..."

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

The techniques used to satisfy this success criterion must be
accessibility supported, as described in the Conformance section. If
non-UAAG compliant user agents are those that are available to users,
the author must still see that this success criterion is satisfied.
Changing the success criterion to depend upon UAAG compliant user
agents would weaken it substantially.

We looked at your suggestion to use "additional magnification
software" but found that using "assistive technology" addressed more
clearly issues of where the magnification was implemented. That the
assistive technology is a screen magnifier is explained in the
Understanding WCAG document.

----------------------------------------------------------
Comment 27: 2.1.1. trying to cover two separate issues in one go?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0354.html
(Issue ID: 2208)
----------------------------
Original Comment:
----------------------------

"All functionality of the content is operable through a keyboard
interface without requiring specific timings for individual
keystrokes, except where the underlying function requires input that
depends on the path of the user's movement and not just the
endpoints."

To me, these feel like two separate issues (operability and timing)
mashed into one. Would it be useful to split these (which admittedly
would need renumbering of the remaining 2.1 SCs)?

Proposed Change:
"2.1.1 All functionality of the content is operable through a keyboard
interface, except where the underlying function requires input that
depends on the path of the user's movement and not just the endpoints.

2.1.2 Keyboard operation does not require specific timings for
individual keystrokes

2.1.3 ..."

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

This provision is to ensure that functionality can be controlled with
individual keystrokes.   The timing clause is critical to this
provision to ensure that the keystrokes are discrete events and not
timed.  For example a person using sip-and-puff Morse code can type
letter but not hold them down for varying lengths of time.

Separating the clause into two would work but would also prohibit any
use of the keyboard in a timed fashion.  That is more than what is
required. It is ok to use the keyboard in that fashion as long as it
is ALSO possible to achieve the function on the keyboard without
timing.

Thus the current coupling of the two aspects is correct.

----------------------------------------------------------
Comment 28: just "users with disabilities"?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0355.html
(Issue ID: 2209)
----------------------------
Original Comment:
----------------------------

"Provide users with disabilities enough time..."

Surely ALL users, not just those with disabilities.

Proposed Change:
"Provide users enough time..."

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

Because WCAG addresses the particular needs of users with
disabilities, we feel it is important to mention them explicitly.
Users with disabilities often need more time than other users, so we
trust that if they have enough time, so will users without
disabilities.

----------------------------------------------------------
Comment 29: in practice, difference between "blink" and "flash" still
unclear, even with appendix
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0356.html
(Issue ID: 2210)
----------------------------
Original Comment:
----------------------------

It's unclear here what the difference between blink and flash actually
is, in practice. Looking at the appendix, there's a definition for
"blink", but strangely not for "flash". The note in the appendix
definition of "blink" still leaves me wondering:

"The slower blink is in contrast with flashing, which refers to rapid
changes in brightness..."

If blinking is a complete on/off, is it not simply a special case of flashing?

Proposed Change:
Just stick with flashing or blinking throughout the document, as it's
confusing (and in practice, completely irrelevant I'd argue) to
distinguish between a blink and a flash.

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

We have added a definition for flash and clarified the difference
between flash and blink both in the definitions and (in longer form)
in the understanding document

---

flash: a pair of opposing changes in relative luminance of 10% or more
where the relative luminance of the darker image is below 0.80

Note: Flash is characterized by rapid changes of relative luminance
occurring more than three times per second, while [blink] is less than
three times per second.

Note: See [general flash threshold] and [red flash threshold] for more
precise information about the applicability and constraints of flash.

---

blink: switch back and forth between two visual states in a way that
that does not qualify as [flash] (e.g. it is too slow and/or the
change in relative luminance is too small to qualify as flashing)

Note: The slower blink is in contrast with [flash], which refers to
rapid changes in brightness which can cause seizures. See [general
flash] and [red flash] thresholds.

---

Added to understanding documents: NOTE: In some cases, what we refer
to as "blinking" and what we refer to as "flashing" may overlap
slightly.  We are using different terms for the two because one causes
a distraction problem which you can allow for a short time as long as
it stops (or can be stopped) whereas the other is a seizure trigger
and cannot be allowed or it will cause a seizure.    The seizure would
occur faster than most users could turn it off.  "Blink" therefore
refers to slow repeating changes that would distract.     Flash refers
to changes that could cause a seizure if they were bright enough or
persisted long enough.    Blinking usually doesn't occur at speeds of
3 per second or more so blink and flash do not overlap.  However,
blinking can occur faster than 3 per second so there could be an
overlap.




----------------------------------------------------------
Comment 30: the SC should be applicable even on a single page
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0357.html
(Issue ID: 2211)
----------------------------
Original Comment:
----------------------------

"A mechanism is available to bypass blocks of content that are
repeated on multiple Web pages."

This should be just as applicable to content that's just on one page,
surely? Yes, we're thinking navigation and "skip to content" here, but
it's just as important to ensure that content itself, even if on only
one page, is properly structured etc to allow for structured
navigation.

Proposed Change:
"A mechanism is available to bypass blocks of content, particularly if
these blocks are repeated on multiple Web pages"

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

You make a good point, we strongly promote structural markup. We
require that information and relationships conveyed through
presentation are also available programatically (1.3.1), which is a
level A requirement. The expectation is that over time, this provision
will enable user agents and assistive technology to rely on grouping
and structure to navigate around a page more efficiently.

This is why the provision is worded as "a mechanism is available". If
the document structure provided allows user agents to support skipping
the content, then a mechanism is available and this success criterion
is satisfied.

This provision is designed to free users of repeatedly navigating the
same menu structures from page to page, and which they have already
understood. However, within a single page, content that is not
repeated on multiple pages will likely be new to the user. SC 1.3.1
discusses the importance of structural markup which facilitates
effective navigation.

We have added a note to 2.4.1

"Note: Although this success criteria deals with blocks of content
that are repeated on multiple pages, we also strongly promote
structural markup on individual pages as per Success Criteria 1.3.1."

----------------------------------------------------------
Comment 31: just "users with disabilities"? (GL 2.4)
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0358.html
(Issue ID: 2212)
----------------------------
Original Comment:
----------------------------

"...to help users with disabilities navigate..."

surely ALL users.

Proposed Change:
"...to help users navigate..."

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

Because WCAG addresses the particular needs of users with
disabilities, we feel it is important to mention them explicitly here.
Users with disabilities often need more or different help with
navigating, finding content, and orienting themselves than other
users, so we highlight addressing their needs.

----------------------------------------------------------
Comment 32: whole SC seems unnecessary
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0359.html
(Issue ID: 2213)
----------------------------
Original Comment:
----------------------------

I'd contend that the whole SC falls under the realm of usability.
There are many situations in which this SC, under the lax definition
of "set of Web pages", would be considered applicable but shouldn't.
What about a small site for a design freelancer with "who i am / see
my work / hire me" sections. These have a "specific relationship" to
each other. So, does the site need both a navigation and a search
function, for instance? Or a table of contents?

Proposed Change:
Drop the SC altogether, or seriously tighten the definition of "set of
Web pages".

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

We have narrowed the definition of "set of web pages" as follows


set of Web pages
collection of Web pages that share a common purpose and that are
created by the same author, group or organization.

Note: Different language versions would be different sets of Web pages.

----------------------------------------------------------
Comment 33: mechanism, or should it be "programmatically determined", or both?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0360.html
(Issue ID: 2214)
----------------------------
Original Comment:
----------------------------

"A mechanism for finding the expanded form or meaning of abbreviations
is available"

Should it be a mechanism, or a mechanism and/or programmatically
determined, or just programmatically determined? Probably the second
option (so it could cover both the use of ABBR with relevant TITLE
attribute and the possibility of a separate glossary page).

Proposed Change:
"A mechanism for finding the expanded form or meaning of abbreviations
is available, or the expanded form can be programmatically
determined."

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

Programmatically determined expanded forms are already sufficient to
meet this success criterion.  However, there are other mechanisms
which are also sufficient, such as adding a glossary.

While the working group has provided both types of techniques, we feel
that adding the "programmatically determined" to the success criterion
would make it unnecessarily difficult to read.

----------------------------------------------------------
Comment 34: reclassing 3.2.5 from AAA to A
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0361.html
(Issue ID: 2215)
----------------------------
Original Comment:
----------------------------

"Changes of context are initiated only by user request. (Level AAA)"

As changes in context (auto-loading a new page, moving focus, etc) can
be problematic for many users (those using AT, those with cognitive
disabilities, etc), I'd posit that this should be reclassed to A, not
AAA.

Proposed Change:
Change from AAA to A, or at the very least AA.

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

SC 3.2.5 is a Level AAA success criterion because there are some web
sites that provide functionality that is not possible if changes of
context are only initiated by user request. Examples are activities
with realtime properties, time-out warnings, and emergency
notifications.

SC 3.2.1 and SC 3.2.2 are Level A success criteria that prevent the
most common types of changes in context that cause problems for users
- changes in context when a component receives focus, and changes in
context without warning when a setting has changed.

SC 2.2.1 is a Level A success criterion that requires that users be
given control over actions like auto-loading new pages. This
particular issue is called out in Failure F58 - Failure of SC 2.2.1
due to using server-side techniques to automatically redirect pages
after a time-out.

----------------------------------------------------------
Comment 35: just "in text"?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0362.html
(Issue ID: 2216)
----------------------------
Original Comment:
----------------------------

"...described to the user in text."

Why "in text"? Provided that the description also follows the relevant
other WCAG 2 guidelines, the error description could be an image, or
use of colour, or anything else for that matter.

Proposed Change:
""...described to the user."

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

The requirement of text is not exclusive. Images, color etc can be
used also. The working group feels that it is helpful that the
sentence includes the words "in text" even though technically this is
required by SC 1.1.1. Our goal is to make the Success Criterion as
understandable as possible, and we feel this improves the clarity of
what is required. We have added to the understanding section the
following:
 "It is perfectly acceptable to indicate the error in other ways such
as image, color etc, in addition to the text description."

----------------------------------------------------------
Comment 36: bullet 2, "checked", seems unnecessary
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0363.html
(Issue ID: 2217)
----------------------------
Original Comment:
----------------------------

"Checked: Submitted data is checked for input errors before going on
to the next step in the process."

The concept of checking for errors sounds to me like a common
application design tenet, not an accessibility one. Also, why should
the app check for errors before moving on to the next step? Would a
final screen saying "there were errors in steps 3 and 5, here are the
fields for you to edit" or similar not work as well?

Proposed Change:
Bullet 2 seems unnecessary, or requires better wording.

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

Although this is a common application design tenet, this success
criterion addresses a problem that affects some users with cognitive
or learning disabilities disproportionately. We changed the wording of
this option to make it clear that feedback on input errors should be
given as soon as possible, but it is not required to give such
feedback instantly.

Some processes wait until all the input has been gathered and check
for errors just before submitting. We changed the wording of this
option to make it clear that users should be given feedback on input
errors as soon as possible:

----------------------------------------------------------
Comment 37: Awkward and incomplete wording
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0364.html
(Issue ID: 2218)
----------------------------
Original Comment:
----------------------------

It's understandable that, by not wanting to mandate "validates", the
wording became awkward.

"...has elements with complete start and end tags, except as allowed
by their specifications, and are nested according to their
specifications."

It's also, in its current form, very much HTML/XML specific. Also, it
doesn't really drive home the idea of "semantic/structural" markup,
when this would be a great place to put it in, potentially?

Proposed Change:
A more tech-agnostic and elegant way:

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

The working group struggled for a long time, trying to write a
tech-agnostic, elegant success criterion. Ultimately, the group
determined that in fact the accessibility concerns of validity are
specific to markup languages. This wording emerged because:
- in stricter technologies, such as XML-based technologies, well
formedness problems affect everyone, so they are not an accessibility
issue
- many validity problems cause failures that are already covered by
other success criteria
- the problems with determining structure due to parsing problems in
markup languages cause accessibility problems, since they interfere
with assistive technology in a way that they do not interfere with
host user agent

For these reasons, the Working Group believes this success criterion
is worded as clearly and accurately as is possible for the situation.

----------------------------------------------------------
Comment 38: Addition to "Creating your own list..." section.
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0365.html
(Issue ID: 2219)
----------------------------
Original Comment:
----------------------------

Current wording of the "Creating your own list..." bit could be
misread to mean authors etc can just make them up as out of thin air.
May need clarification.

"Authors, ... accessibility-supported technologies."

Proposed Change:
"Authors, ... accessibility-supported technologies, based on the rules
outlined in the following section."

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

We have added the following "However, all technologies on the list
must meet the definition of accessibility supported content
technologies above." to the definition of accessibility supported.
Received on Sunday, 4 November 2007 05:05:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:09 UTC