Greg Lowney's comments on WCAG 2.0 Draft of 2005-06-30

Hello! Here are some comments on the Web Content Accessibility Guidelines
2.0 W3C Working Draft 30 June 2005. Each comment is provided with a number,
ID of the heading or Success Criteria to which it refers (e.g. General, or
1.1 L1 SC1), type (EDITORIAL or TECHNICAL), priority (LOW, MEDIUM, or HIGH),
comment text, and the ID & text of the item to which the comment applies.
I've also attached the same data as a tab-separated variable file. There are
a lot of comments, but many are low priority or merely editorial.

 

1              General                EDITORIAL         LOW PRIORITY
Are you going to provide titles for criteria, or make people refer to it
either by cryptic number or the full criteria text?                [Comment
on "General"]

 

2              General                EDITORIAL         LOW PRIORITY
Each page such as "Guide to Guideline 1.1 Level 1 Success Criterion 2" has a
link such as "1.1 L1 SC2" which takes you to the corresponding section of
the actual guidelines document. However, the link text is cryptic and there
is no surrounding information explaining it; one has to take it to find out
what it is for.                [Comment on "General"]

 

3              General                TECHNICAL                MEDIUM
PRIORITY                Several success criteria use the phrases like "when
something is drawn over a background image, color, or text", but in reality
ALL text is drawn over some background, even if it is just a default solid
color assumed by the user agent. In some cases a background is specified by
the content author, in some cases it is specified by the user agent (i.e.
the application that renders and/or displays the content), and in some cases
it is specified by the author but overridden by the software (which may or
may not be in response to user preference settings or commands).
[Comment on "General"]

 

4              General                EDITORIAL         HIGH PRIORITY
The table of contents in the General Techniques document really needs to be
modified so that it has entries for all success criteria, even if those are
only placeholders for criteria for which no techniques have been written.
Readers may assume that the table of contents in the techniques (which
_seems_ to be a list of the success criteria) is an accurate list of those
criteria, when it is really a subset. The General Techniques document seems
to repeat everything in the main section of the Guidelines document, with
elaboration, which would make it an ideal document to rely on, but in fact
it leaves out many criteria without giving the reader any indication it's
doing so! It fooled me, causing me significant inconvenience when I realized
the problem.                [Comment on "General"]

 

5              General                EDITORIAL         HIGH PRIORITY
I find the current system for providing examples to be confusing and far
less helpful than it could be, because it does not identify which success
criteria they are illustrating. In many cases it is really unclear, or
requires a lot of mental juggling to identify the author's intention. (I
found the extensive examples for Guideline 2.5 illustrate this particularly
well.)                [Comment on "General"]

 

6              General                TECHNICAL        HIGH PRIORITY
Unless I've overlooked it, we should clarify when it's acceptable for
content's default presentation to not comply with certain criteria as long
as the user can make it comply by adjusting options in the content or in the
user agent. For example, can a Web site comply with the criterion "Change of
context are initiated only by user action" if it normally automatically
updates content every five minutes but lets the user disable this by
checking a check box on the page? How about a single check box on a page of
site-wide preference settings? Is it enough even if the user would need to
adjust that setting every time they visit the site? What if the site relies
on a user agent preference setting to turn off automatic refreshing?
[Comment on "General"]

 

7              General                EDITORIAL                MEDIUM
PRIORITY                I suggest gathering into one place the 15 success
criteria specifically about making things programmatically determinable
(identifiable, operable, etc.). They are currently scattered throughout the
document under Guidelines 1.3, 1.4, 2.4, 3.1, 3.2, and 4.2, and I think this
makes it very difficult for the reader to understand what they cover and how
they relate to each other...ideally complementing each other (with minimal
overlap) to provide all the capabilities needed by assistive technology. My
first thought was to move them all into a separate, new principle such as
"Programmatically expose structure, content, and functionality", but I
realize that all the success criteria relating to markup really fall into
this category.                [Comment on "General"]

 

8              "Change of context"                TECHNICAL
MEDIUM PRIORITY                This definition should be narrowed, as the
current wording makes several success criterion in the guideline prohibit
commonly-used and well-regard mechanisms (such as several in 3.2 L2). For
example, scrolling the viewport should not be considered a change of context
unless it is done other than in response to a user action; in particular, it
should be OK to scroll the viewport to keep the focus visible.
[Comment on "Change of context: A change of user agent, viewport, user
interface controls, or focus; or complete change of content."]

 

9                "Function"                TECHNICAL        LOW PRIORITY
I can't think of cases where we'd want to refer just to things that are
"functional" according to this definition, which says things that react to
user input (directly or indirectly) are "functional" but things that react
to other external events are not. The strangeness comes because the
definition does not limit this category to things that _take_ input
directly, instead including things that change in response to input
elsewhere (such as a static text field that changes to display help related
to the control that has the selection). I understand that we don't want to
limit it to things that themselves take input directly, as at an
implementation level a button may react to a keystroke by changing some
static text elsewhere on the form, while from the user's perspective both
the button and the text seem to be reacting to the user's input. Still, it
leads to strange examples: if text on a Web page changes to show when a
server goes down, that text is NOT functional, but if the same page lets you
select which server the text is monitoring then the text IS functional. I'm
curious whether this is used in other documents, and if so, how well it
works.                [Comment on "Function: Performs or is able to perform
one or more actions in response to user input."]

 

10                "Function"                EDITORIAL         LOW PRIORITY
I suggestion changing "Performs or is able to perform" to "Is able to
perform." The existing phrase is redundant because something that performs
is necessarily able to perform, and thus "Is able to perform" is
functionally the same as "Performs or is able to perform."
[Comment on "Function: Performs or is able to perform one or more actions in
response to user input."]

 

11            "Non-text content"                TECHNICAL
MEDIUM PRIORITY                This definition could be interpreted as
saying that all content on an 8-bit encoding scheme is considered non-text,
which is clearly not the intention. Is Unicode so universally used now that
all other systems don't occur in the real world?                [Comment on
"Non-text content: Content that is not represented by a Unicode character or
sequence of Unicode characters."]

 

12                "Programmatically determined"                TECHNICAL
HIGH PRIORITY                I strongly agree that communicating via
standard means is a key requirements for complying with these guidelines. I
suggest adapting the wording I proposed for HFES/ANSI 200.2, which reads
"Software should use the accessibility services provided by the operating
system to provide information to the operating system and other
applications, especially to assistive technologies. If that is not
sufficient to comply with guidelines 9.2.3, 9.3, 9.4, 9.5, and 9.6, software
should use other publicly documented software services supported by
assistive technology." The key aspects are (a) use OS-provided means where
those exist and are sufficient, otherwise (b) use means that are documented
and supported by at least SOME assistive technology products.
[Comment on "Programmatically determined means that the specific value can
be determined in a standard, machine or software readable form."]

 

13                Conformance                EDITORIAL         LOW PRIORITY
If you maintain three levels of success criteria this might also mention
that some guidelines do not contain level 3 success criteria.
[Comment on "NOTE: Some guidelines do not contain level 1 success criteria,
and others do not contain level 2 success criteria."]

 

14            1.1 L1 SC2                TECHNICAL                MEDIUM
PRIORITY                I suggest rewording the clause "if text alternatives
can not serve..." to clarify that this phrase refers only to situations
where it is impossible for the author to supply a text alternative that
would provide equivalent functionality, rather than cases where the supplied
text alternative merely fails to provide equivalent functionality.
[Comment on "1.1 L1 SC2: For functional non-text content, text alternatives
serve the same purpose as the non-text content. If text alternatives can not
serve the same purpose as the functional non-text content, text alternatives
identify the purpose of the functional non-text content"]

 

15            1.1 L1 SC5                TECHNICAL        LOW PRIORITY
Need to define "live" as in "live audio-only content." This should clarify
that live content need not include live actors or speakers; real-time data
from an automated weather station and an automated stock ticker would each
count as "live". Would "real-time" be a clearer term to use than "live"?
[Comment on "1.1 L1 SC5: For live audio-only or live video-only content,
text alternatives at least identify the purpose of the content with a
descriptive label."]

 

16            1.2 L1 SC1                TECHNICAL                MEDIUM
PRIORITY                Comments in the document say there is debate about
whether captions should be L1. I think providing either transcripts AND/OR
captions should satisfy L1, while providing BOTH transcripts AND captions
should satisfy L2. I say this because in many if not most cases a transcript
of audio and important visuals will make the content will be entirely usable
without captions. (Transcripts are also often cheaper and easier to produce,
and in many cases provided more benefit than captions, such as being
searchable, indexable, supporting copy/paste, allow quick visual or tactile
scanning, etc. For some content transcripts would be more useful to most
viewers than captions.) However, I wonder if there exists content for which
captions alone would be unsatisfactory.                [Comment on "1.2 L1
SC1: Captions are provided for prerecorded multimedia."]

 

17            1.2 L1 SC2                TECHNICAL                MEDIUM
PRIORITY                As with 1.2 L1 SC1, I feel that audio descriptions
should not be L1, but that either audio descriptions OR transcripts that
describe the visuals should satisfy L1, while providing BOTH would satisfy
L2. I say this because in many if not most cases a transcript of audio and
important visuals will make the content will be entirely usable without
captions. (Transcripts are also often cheaper and easier to produce, and in
many cases provided more benefit than captions, such as being searchable,
indexable, supporting copy/paste, allow quick visual or tactile scanning,
etc. For some content transcripts would be more useful to most viewers than
captions.)                [Comment on "1.2 L1 SC2: Audio descriptions of
video are provided for prerecorded multimedia."]

 

18            1.2 L2 SC1                EDITORIAL         LOW PRIORITY
I suggest we change "Real- time captions" to just "Captions" and in the
notes explain that it is accepted that captions of real-time multimedia,
often referred to as "real-time captions", are generally of lesser accuracy
than is expected of captions on prerecorded multimedia. This is because
there is no definition of "real-time captions", and I doubt that there's a
technical distinction between real- time captions and all other captions.
Using two different terms actually hurts clarity by implying there's a
technical difference when there isn't; I think the distinction merely serves
to reassure the provider that captions of live multimedia can be of lower
quality than that of prerecorded multimedia. (In fact, low- quality captions
of prerecorded multimedia comply with success criteria just as well as
high-quality captions due.)                [Comment on "1.2 L2 SC1:
Real-time captions are provided for live multimedia."]

 

19            1.2                EDITORIAL         LOW PRIORITY
Example 2 for Guideline 1.2 shows captions for a tutorial being in all upper
case. If that is not really _the_ recommended style I would avoid showing it
that way, as people will interpret it as a recommendation. NCAM's samples
use mixed case and I would follow their lead.                [Comment on
"1.2: Examples"]

 

20                            EDITORIAL         LOW PRIORITY
The title of Guideline 1.3 says it addresses "information, functionality,
and structure" but the actual success criteria only address information and
structure, not functionality. Therefore it would be more accurate to delete
"functionality," from the guideline text.                [Comment on "1.3:
Ensure that information, functionality, and structure can be separated from
presentation."]

 

21            1.3 L1 SC1                TECHNICAL        HIGH PRIORITY
See my comment on the definition of "programmatically determined."
[Comment on "1.3 L1 SC1: Structures within the content can be
programmatically determined."]

 

22            1.3 L1 SC2                TECHNICAL        HIGH PRIORITY
Reword this criterion as "When information is conveyed by color, the color
can be programmatically determined or the information is also conveyed
through another visual means that does not depend on the user's ability to
differentiate colors." This embodies two changes. First, it is especially
important to delete the clause "the color can be programmatically
determined, or", because allowing color to be determined programmatically is
NOT an adequate substitute, especially at L1, as it does not help the vast
majority of viewers who have color deficiencies or are using monochrome
displays. Second, I believe the "other means" by which the information is
conveyed should be limited to _visual_ means (as is made clear by the
wording of 1.3 L2 SC2.)                [Comment on "1.3 L1 SC2: When
information is conveyed by color, the color can be programmatically
determined or the information is also conveyed through another means that
does not depend on the user's ability to differentiate colors."]

 

23            1.3 L2 SC2                TECHNICAL        HIGH PRIORITY
The wording of this criterion is flawed and should be replaced by a an L1
reading "When information is conveyed by color, the color can be
programmatically determined or the information is also conveyed through
another visual means that does not depend on the user's ability to
differentiate colors." Please see my comments on 1.3 L1 SC2 for more a more
detailed explanation. However, also note that the current wording of this
criterion ("...when color is not available") is seriously flawed because it
could be interpreted as only applying when running on a non-color display,
rather than also applying when the user cannot perceive the colors on the
display.                [Comment on "1.3 L2 SC2: Any information that is
conveyed by color is visually evident when color is not available."]

 

24            1.3 L3 SC1                TECHNICAL                MEDIUM
PRIORITY                I recommend removing the "When..." clause, because I
can't think of real-world examples where reordering the contents would not
affect their meaning. I don't think you can assume reordering content is
ever harmless, and including an exception like this just opens room for
authors to assume order is unimportant in cases where that's probably not
actually true. (For example, even with an _explicitly_ unordered list a
reader will refer to "the fifth" item, etc.)                [Comment on "1.3
L3 SC1: When content is arranged in a sequence that affects its meaning,
that sequence can be determined programmatically."]

 

25            1.3 L3 SC1                EDITORIAL         LOW PRIORITY
It's also noteworthy that using color to highlight required or missing
fields helps any users who can give the document a quick visual scan (e.g.
people who read slowly, even if it's not because of cognitive impairments).
[Comment on "1.3 L3 SC1: When content is arranged in a sequence that affects
its meaning, that sequence can be determined programmatically."]

 

26            1.4 L1 SC1                TECHNICAL        HIGH PRIORITY
It is important that ALL text can be programmatically determined, not just
text that is drawn over certain backgrounds. I would change this to read
"Any text that can be programmatically determined" and move it out of the
section on foreground/background, probably to section 1.3.
[Comment on "1.4 L1 SC1: Any text that is presented over a background image,
color, or text can be programmatically determined."]

 

27            1.4 L2 SC1                TECHNICAL        LOW PRIORITY
See my comment above about the fact that all text is drawn over some
background.                [Comment on "1.4 L2 SC1: Text and diagrams that
are presented over a background image, color, or text have a contrast
greater than X1 where the whiter element is at least Y1 as measured by
_____."]

 

28            1.4 L2 SC2                TECHNICAL        LOW PRIORITY
How does one define the width of a character's serifs? I don't see this
number discussed among standard font metrics, and in most fonts a serif's
thickness varies along the length of the serif. How is the typical content
author or graphic artist supposed to measure this to determine whether
accommodation is needed?                [Comment on "1.4 L2 SC2: Text that
is presented over a background pattern of lines which are within 500% +/- of
the stem width of the characters or their serifs must have a contrast
between the characters and the lines that is greater than X2, where the
whiter element is at least Y2."]

 

29            1.4 L2 SC3                TECHNICAL                MEDIUM
PRIORITY                If this is meant to imply that the user should be
able to turn off background audio without silencing foreground audio, then
the criterion needs to be reworded to reflect that. As it reads today, all
multimedia would comply as long as the user can turn off their speakers or
mute all audio at the operating system level.                [Comment on
"1.4 L2 SC3: A mechanism is available to turn off background audio that
plays automatically."]

 

30            1.4 L2 SC3                TECHNICAL        LOW PRIORITY
The current wording only applies this criterion to background audio that
plays automatically, but if it doesn't play automatically--only in response
to some user action--then one could argue that the user can effectively turn
it off by declining to start it. Therefore I suggest removing the phrase
"that plays automatically" as unnecessary.                [Comment on "1.4
L2 SC3: A mechanism is available to turn off background audio that plays
automatically."]

 

31            1.4 L2 SC3                TECHNICAL                MEDIUM
PRIORITY                I suggest adding a success criterion to the effect
that "A mechanism is available to turn off display of background patterns
and images that are displayed behind text and/or graphics and to control the
color of the solid background behind such text and graphics." I would make
this L2. (Or is this a UA issue?)                [Comment on "1.4 L2 SC3: A
mechanism is available to turn off background audio that plays
automatically."]

 

32            1.4 L3 SC1                TECHNICAL        LOW PRIORITY
See my comment above about the fact that all text is drawn over some
background.                [Comment on "1.4 L3 SC1: Text is not presented
over any background (image, text, color or pattern), or if any background is
present, the contrast between the text and the background is greater than
X2."]

 

33            1.4 L3 SC2                TECHNICAL                MEDIUM
PRIORITY                I would add a third option, "..., or the user can
turn off playing of the background sounds."                [Comment on "1.4
L3 SC2: Audio content does not contain background sounds or the background
sounds are at least 20 decibels lower than the foreground audio content,
with the exception of occasional sound effects."]

 

34            2.1 L1 SC1                TECHNICAL                MEDIUM
PRIORITY                I remain unconvinced of the usefulness of the phase
"that can be described in a sentence." I prefer the approach of saying that,
to be L1 compliant, "All of the functionality of the content must be
operable using only non-time dependent keyboard (or keyboard equivalent)
input that does not rely on visual recognition of pointer location." This is
similar to the wording we are using in HFES/ANSI 200.2, where we also add
"This includes, but is not limited to, editing text and other document
components, and navigation to and full operation of all controls." Note that
this would effectively be promoting 2.1 L3 SC1 ("All functionality of the
content is designed to be operated through a keyboard interface.") to L1,
albeit with added restrictions.                [Comment on "2.1 L1 SC1: All
of the functionality of the content, where the functionality or its outcome
can be described in a sentence, is operable through a keyboard interface."]

 

35            2.1 L3 SC1                EDITORIAL         HIGH PRIORITY
This criterion ("All functionality of the content is designed to be operated
through a keyboard interface") is described as L2 in Web Content
Accessibility Guidelines 2.0 W3C Working Draft 30 June 2005
(http://www.w3.org/TR/2005/WD-WCAG20-20050630/) but L3 in General Techniques
for WCAG 2.0 of the same date
(http://www.w3.org/TR/2005/WD-WCAG20-GENERAL-20050630/).
[Comment on "2.1 L3 SC1: All functionality of the content is designed to be
operated through a keyboard interface."]

 

36            2.1 L3 SC1                TECHNICAL        HIGH PRIORITY
I recommend folding this into 2.1 L1 SC1; see my comments on the latter for
details.                [Comment on "2.1 L3 SC1: All functionality of the
content is designed to be operated through a keyboard interface."]

 

37            2.2 L1 SC1                EDITORIAL         LOW PRIORITY
It would be clearer if each list item ended with "and/or" instead of "or",
to reinforce the fact that at least one should be true (rather than exactly
one).                [Comment on "2.2 L1 SC1: Content is designed so that
time-outs are not an essential part of interaction, or at least one of the
following is true for each time-out that is a function of the content:"]

 

38            2.2 L1 SC1                TECHNICAL        LOW PRIORITY
It currently says "the time- out is part of an activity where timing is
essential (for example, competitive gaming or time-based testing) and time
limits can not be extended further without invalidating the activity", but I
think that to achieve L1 time-based testing should be designed so that
administrators can extend the allowed time (e.g. for students with certain
disabilities) even if the end user cannot.                [Comment on "2.2
L1 SC1: Content is designed so that time-outs are not an essential part of
interaction, or at least one of the following is true for each time-out that
is a function of the content:"]

 

39            2.2 L2 SC1                TECHNICAL        LOW PRIORITY
Change "any" to "all" because use of "any" implies that the user can be
required to turn off each blinking item independently. While that level of
control can be useful for many users, it would be impractical for users who
need to stop large number of blinking elements, especially if new ones might
continually start blinking over time.                [Comment on "2.2 L2
SC1: Content does not blink for more than 3 seconds, or a method is
available to stop any blinking content in the delivery unit."]

 

40            2.2 L2 SC2                TECHNICAL        LOW PRIORITY
Change to "...paused by the user for at least N minutes" (with N to be
filled in before publication) because allowing the user to pause the content
only for a short time period should not be sufficient to comply.
Alternatively you could say "...paused indefinitely..." but I don't believe
that is always feasible.                [Comment on "2.2 L2 SC2: Moving or
time-based content can be paused by the user."]

 

41            2.2 L3 SC3                TECHNICAL        LOW PRIORITY
I fear that in many cases it is not feasible to let the user resume an
operation after a session has been idle for a very long time, because it
would be a large burden for servers to maintain state of each session
indefinitely. (However, since this is only L3 it doesn't really matter.)
[Comment on "2.2 L3 SC3: When an authenticated session has an inactivity
timeout, the user can continue the activity without loss of data after
re-authenticating."]

 

42            2.4 L1 SC1                TECHNICAL                MEDIUM
PRIORITY                This criterion is entirely redundant to other
criteria. Navigational features are defined as either functional elements or
structural (grouping) constructs, each of which are already required to be
programmatically identifiable by criteria 4.2 L1 SC3 and 1.3 L1 SC 1,
respectively.                [Comment on "2.4 L1 SC1: Navigational features
can be programmatically identified."]

 

43            2.4 L2 SC1                TECHNICAL                MEDIUM
PRIORITY                Currently there are no criteria that recommend
providing ways for locating content within the current delivery unit, such
as providing a table of contents or search function within a very long page.
The current wording only addresses locating content within a set of delivery
units, which could be interpreted as merely identifying which delivery unit
contains a phrase, for example, of even just providing the titles of each
unit. (Overall this criterion is extremely vague.)                [Comment
on "2.4 L2 SC1: More than one way is available to locate content within a
set of delivery units."]

 

44            2.4 L2 SC2                TECHNICAL        LOW PRIORITY
Interesting to note that most DVDs fail this because they will not let you
bypass the copyright notices and piracy warnings at the beginning of each.
Do we need to provide an exemption for blocks of content required for
contractual reasons?                [Comment on "2.4 L2 SC2: Blocks of
content that are repeated on multiple perceivable units are implemented so
that they can be bypassed."]

 

45            2.4 L2 SC4                TECHNICAL        LOW PRIORITY
The term "programmatic reference" is used by not defined. I think it is
being used here to mean something functional (e.g. a link or control) that
causes a contextual transition, but I'm not sure.                [Comment on
"2.4 L2 SC4: The destination of each programmatic reference to another
delivery unit is identified through words or phrases that either occur in
text or can be programmatically determined."]

 

46            2.4 L2 SC4                TECHNICAL                MEDIUM
PRIORITY                The goal of this criterion is unclear. It works if
it's designed to benefit people who use assistive technology, but if it's
designed to help anyone else then allowing compliance merely by exposing
information programmatically undermines it. For example, all Web pages using
normal links ("A" elements) would comply because many user agents show the
destination of the link that has the focus, and the user can read that,
mentally parse it, and compare it with the URL of the current page (also
currently displayed) to determine if it's an external link (a link to
another delivery unit). In fact, it would still comply even if the user
agent didn't display either location, as long as they are programmatically
available. Are those matching the intent of the guideline authors?
[Comment on "2.4 L2 SC4: The destination of each programmatic reference to
another delivery unit is identified through words or phrases that either
occur in text or can be programmatically determined."]

 

47            2.4 L3 SC2                TECHNICAL        LOW PRIORITY
This is pretty vague; what type of information would be required to comply?
Luckily it's only L3 so it's not really important.                [Comment
on "2.4 L3 SC2: Information about the user's location within a set of
delivery units is available."]

 

48                            EDITORIAL         LOW PRIORITY
It's just funny that the word "them" in this title could apply to either the
mistakes or the users...grammatically and/or semantically.
[Comment on "2.5: Help users avoid mistakes and make it easy to correct
them."]

 

49            2.4 L2 SC1                TECHNICAL        LOW PRIORITY
If you want content designed for audio-only output to be able to claim L2
compliance, you'll have to reword this, as they normally don't provide
anything to the user as text.                [Comment on "2.4 L2 SC1: If an
input error is detected, the error is identified and provided to the user in
text."]

 

50            2.4 L2 SC3                TECHNICAL                MEDIUM
PRIORITY                This seems unclear in a number of areas. I don't
understand why this list of clauses was chosen to define when and where this
criterion applies. Why is changing a value in a remote database more serious
than changing a value in a local database? (Is it on                [Comment
on "2.4 L2 SC3: For forms that cause legal or financial transactions to
occur, that modify or delete data in remote data storage systems, or that
submit test responses, at least one of the following is true:"]

 

51            3.1 L3 SC1                TECHNICAL        LOW PRIORITY
Aren't all these criteria of the format "A mechanism is available (to look
up information)" the responsibility of the user agent?
[Comment on "3.1 L3 SC1: A mechanism is available for finding definitions
for all words in text content."]

 

52            3.1 L3 SC5                TECHNICAL        LOW PRIORITY
I note that when it says providing "a spoken version of the text content" is
sufficient to comply with this criterion, it addresses the needs of people
who have difficulty with the act of reading, but not those who have
difficulty reading at or above the upper secondary education level" because
of difficulty with complex sentences or vocabulary (nor those who have
hearing impairments). (However, it's only L3 so it isn't really important.)
[Comment on "3.1 L3 SC5: When text requires reading ability at or above the
upper secondary education level, one or more of the following supplements is
available:"]

 

53            3.2 L1 SC1                TECHNICAL                MEDIUM
PRIORITY                This seems very unclear. I read this criterion's
current wording as meaning that software needs to be able to
programmatically determine when a change of context occurs, but that seems
contradicted by Example 2, which talks only about being able to identify
links that would cause a chance of context. (If Example 2 isn't about L1 S1,
then I can't see what criterion it would be about.)                [Comment
on "3.2 L1 SC1: Any change of context is implemented in a manner that can be
programmatically determined."]

 

54            3.2 L1 SC1                TECHNICAL        LOW PRIORITY
Either this 3.2 Example 2 needs to be changed or the definition of "change
of context" need to be redefined. This example says, "At the beginning of
each link is an icon of an arrow with the text equivalent, 'Link will open
in new window.'", but what link WOULDN'T result in change of context?
Remember, change of context is defined as including changing the contents
displayed in the current window, not just creating a new window.
[Comment on "3.2 L1 SC1: Any change of context is implemented in a manner
that can be programmatically determined."]

 

55            3.2 L2 SC1                TECHNICAL        LOW PRIORITY
A reasonable goal but the wording seems vague. For example, does it prohibit
a Web site from having a list of sections in a left-hand navigation pane, if
it would show the pages in the current section and hide the pages in the
other sections (which is a frequently used and generally well-regarded
mechanism)? As silly as it sounds, would it technically prohibit having a
series of pages specifically designed to present the same contents sorted by
different keys? As the term "component" is not defined, could it be
interpreted as only entirely repeated blocks of content, or structural
elements, repeated sections of text, or repeated controls or groups of
controls, etc.?                [Comment on "3.2 L2 SC1: Components that are
repeated on multiple delivery units within a set of delivery units occur in
the same order each time they are repeated."]

 

56            3.2 L2 SC2                TECHNICAL                MEDIUM
PRIORITY                Great criterion, but since "change of context" is
defined as including a "change of viewport" the criterion as written would
prohibit the user agent from scrolling the viewport to display the control,
link, etc. that receives focus, and that's clearly not what we intend. I
actually think this is a problem with the definition of "change of context"
rather than of this criterion...see my comments about that definition.
[Comment on "3.2 L2 SC2: When any component receives focus, it does not
cause a change of context."]

 

57            3.2 L2 SC3                TECHNICAL                MEDIUM
PRIORITY                As above, see my comments on the definition of
"change of context", as that makes this criterion prohibit such
commonly-used mechanisms as hiding or deactivating certain controls to
reflect which options are available given the information already entered.
(For example, a date entry field is only enabled when the preceding "Show
only items created after:" check box is checked.)                [Comment on
"3.2 L2 SC3: Changing the setting of any input field does not automatically
cause a change of context ."]

 

58            3.2 L2 SC4                EDITORIAL         LOW PRIORITY
I think this is OK, but perhaps in examples we should make clear that, for
example, it's acceptable for one page to have a "Save Contact" button while
the next page has a "Save Appointment" button, etc. That is, things can be
consistent without being identical.                [Comment on "3.2 L2 SC4:
Components that have the same functionality in multiple delivery units
within a set of delivery units are labeled consistently."]

 

59            3.2 L3 SC1                TECHNICAL        LOW PRIORITY
This would prohibit having a graphical button have the text equivalent "Edit
Contact" on one page and "Edit Appointment" on another, but I don't think we
should prohibit that. (However, it is only L3, so I it can't be too
important.)                [Comment on "3.2 L3 SC1: Graphical components
that appear on multiple pages, including graphical links, are associated
with the same text equivalents wherever they appear."]

 

60            3.2 L3 SC2                TECHNICAL        LOW PRIORITY
Is it acceptable if the content updates automatically by default, but the
user can disable this by adjusting preference settings on the Web site or in
the user agent? (This comment is low priority because the criteria is only
L3.)                [Comment on "3.2 L3 SC2: Changes of context are
initiated only by user action."]

 

61                            EDITORIAL                MEDIUM PRIORITY
I suggest separating this into two separate Guidelines. I don't understand
why these two separate issues (ensure user interfaces are accessible, and
provide alternatives when things-not just user interfaces-aren't accessible)
are lumped together. 4.2 L1 SC3 through SC6 and L2 SC1 are all about
exposing information for use by assistive technology, which should always be
done, and I don't see any logical connection with L1 SC1, L1 SC2, or L3 SC1.
Please see my suggestion above about reorganizing success criteria about
programmatic access.                [Comment on "4.2: Ensure that user
interfaces are accessible or provide an accessible alternative(s)"]

 

62            4.2 L1 SC 1                TECHNICAL                MEDIUM
PRIORITY                An interesting circular argument: if a Web site
doesn't meet all the Level 1 success criteria but it provides an alternate
version that does, then I think this is saying the primary site complies
with 4.2 L1 SC1...but is it at all useful for the content developer to
comply with only one of the L1 success criteria? (I'm assuming this is not
trying to imply that by providing an alternate version that is L1 compliant,
the original site itself can claim L1 compliance, and yet there should be
some incentive to provide the alternative version.)                [Comment
on "4.2 L1 SC 1: If content does not meet all level 1 success criteria, then
an alternate form is provided that does meet all level 1 success criteria."]

 

63            4.2 L1 SC 1                TECHNICAL                MEDIUM
PRIORITY                Is it supposed to be implied that the alternate
version must be advertised on or directly available from the original
version? That would be implied by the (visual change required) notation on
this criterion. As with many other accessibility guidelines, the issue comes
up of whether the more accessible options need to be known and/or
immediately available in order to count towards compliance.
[Comment on "4.2 L1 SC 1: If content does not meet all level 1 success
criteria, then an alternate form is provided that does meet all level 1
success criteria."]

 

64            4.2 L1 SC 2                EDITORIAL                MEDIUM
PRIORITY                To say that something applies both to content that
uses X and content that doesn't use X is to say nothing; therefore can't you
change "Content using baseline technologies or non-baseline technologies,
must meet the following criteria" to "Content must meet the following
criteria"?                [Comment on "4.2 L1 SC 2: Content using baseline
technologies or non- baseline technologies, must meet the following
criteria: (a) Content that violates international health and safety
standards for general flash or red flash is marked in a way that the user
can avoid its appearance, (b) If the user can enter the content using the
keyboard, then the user can exit the content using the keyboard."]

 

65            4.2 L1 SC 2                EDITORIAL                MEDIUM
PRIORITY                I don't understand the point of this criterion. Why
does it lump together to things that seem utterly disparate (way to avoid
flashing and ability to exit a context using the keyboard)...why aren't
these two separate criteria? However, the first portion seems to already be
covered by 2.3 L1 SC1 and the second by 2.1 L1 SC1; the purpose of
reiterating them here--or the functional difference between those and
this--eludes me.                [Comment on "4.2 L1 SC 2: Content using
baseline technologies or non- baseline technologies, must meet the following
criteria: (a) Content that violates international health and safety
standards for general flash or red flash is marked in a way that the user
can avoid its appearance, (b) If the user can enter the content using the
keyboard, then the user can exit the content using the keyboard."]

 

66            4.2 L1 SC 2                TECHNICAL                MEDIUM
PRIORITY                When it says "If the user can enter the content
using the keyboard, then the user can exit the content using the keyboard"
we have to be clarify that this does not mean that every page has to have a
"close this window" link. I think it is sufficient to rely on user agents to
provide the ability to close their window and navigate "back" using the
keyboard.                [Comment on "4.2 L1 SC 2: Content using baseline
technologies or non- baseline technologies, must meet the following
criteria: (a) Content that violates international health and safety
standards for general flash or red flash is marked in a way that the user
can avoid its appearance, (b) If the user can enter the content using the
keyboard, then the user can exit the content using the keyboard."]

 

67            4.2 L1 SC 3                TECHNICAL                MEDIUM
PRIORITY                This should also apply to output-only controls (and
content) that are only updated when the page is rendered.
[Comment on "4.2 L1 SC 3: The role, state, and value can be programmatically
determined for every user interface component of the web content that
accepts input from the user or changes dynamically in response to user input
or external events."]

 

68            4.2 L1 SC 4                TECHNICAL                MEDIUM
PRIORITY                This should apply to controls that display
information as well as those that take input. For example, take a page where
a static text field displays the label "Name:" and to its right a static
text field displays the value "George"; in this case the former text control
is presenting the label of the latter, and this relationship is no less
important to the viewer than it would be if the user could directly edit the
displayed value.                [Comment on "4.2 L1 SC 4: The label of each
user interface control that accepts input from the user can be
programmatically determined and is explicitly associated with the control."]

 

69            4.2 L1 SC 5                TECHNICAL        LOW PRIORITY
Replace the phrase "changed programmatically" with "programmatically
changed" throughout the document, and add a definition for the phrase. The
document already defines and uses "programmatically determined",
"programmatically identified", and "programmatically located", so using
"programmatically changed" would be more consistent, readily identifiable,
and appear with the related phrases in the alphabetically-arranged glossary.
[Comment on "4.2 L1 SC 5: The states and values of content that can be
changed via the user interface can also be changed programmatically."]

 

70            4.2 L1 SC 5                TECHNICAL                MEDIUM
PRIORITY                The term "changed programmatically" (or
"programmatically changed") is undefined and vague enough that _all_ Web
content will automatically comply, because assistive technology on all major
operating systems can simulate mouse clicks and keystrokes. I believe the
intent of this success criterion is that assistive technology be able to
directly change the values--certainly without moving the mouse pointer or
"hunting" by simulating TAB until the focus arrives as the desired control.
Unfortunately the distinction is somewhat blurry; for example, it is not
about whether the AT communicates directly with the user agent or content,
since in many cases the AT would use an operating-system supplied wrapper to
do that. In HFES/ANSI 200.2 we have a number of Checkpoints and Notes that
work together to set out appropriate expectations.                [Comment
on "4.2 L1 SC 5: The states and values of content that can be changed via
the user interface can also be changed programmatically."]

 

71            4.2 L1 SC 5                TECHNICAL                MEDIUM
PRIORITY                It seems like this the responsibility of user agents
rather than content.                [Comment on "4.2 L1 SC 5: The states and
values of content that can be changed via the user interface can also be
changed programmatically."]

 

72            4.2 L1 SC 6                TECHNICAL                MEDIUM
PRIORITY                As with "programmatically changed", the definition
of "programmatically identified" could use clarification in order to ensure
that the methods are actually practical for use by assistive technology.
[Comment on "4.2 L1 SC 6: Changes to content, structure, selection, focus,
attributes, values, state, and relationships within the content can be
programmatically determined."]

 

73            4.2 L1 SC 6                TECHNICAL        HIGH PRIORITY
Assistive technology needs to be able to determine these attributes even
when they are not changing.                [Comment on "4.2 L1 SC 6: Changes
to content, structure, selection, focus, attributes, values, state, and
relationships within the content can be programmatically determined."]

 

74            4.2 L2 SC 1                TECHNICAL        LOW PRIORITY
We need to clarify this because it leaves undefined whether content must
follow ALL accessibility conventions or merely AT LEAST TWO of them.
Requiring all available conventions to be followed is too large a burden,
whereas requiring only two (as the wording is plural) is too low a bar.
[Comment on "4.2 L2 SC 1: Accessibility conventions of the markup or
programming language (API's or specific markup) are used."]

 

    Thanks,

    Greg Lowney

    Lowney Access Research, LLC
    http://www.access-research.org