Greg Lowney's Comments on WCAG 2.0 Draft of 2003-10-08

Hello,
 
Here are some comments and suggestions based on WCAG 2.0 Draft
2003-10-08. 
I've included them inline below, and also as attached Word and Text
documents.
 
I apologize for these being so late and so voluminous; I leave the
method of whether or how you want to handle them to your discretion.
 
I'm more than happy to clarify or discuss them.
 
    Thanks,
    Greg Lowney
    Lowney Access Research, LLC
 
Greg Lowney's Comments on 
WCAG 2.0 Draft of 2003-10-08

Notes: 

1.	this document is structured with the first level of numbered
items (numbered 1, 2, etc.) identifying the context of my specific
comments/suggestions (numbered 1.a, 1.b, etc.). 

2.	Most of these comments are based on the draft of 2003-09-30, but
later ones are based on the draft of 2003-10-08. 

3.	Much of this was entered using voice dictation so please excuse
any errors that were caused by misrecognition.

 

1.        Some thoughts on reorganization proposal five, dated October
8, 2003.

1.a.        [COMMENT] Overall I'm very pleased with the reorganization
proposal. I like the move to principles and guidelines.  

1.b.        [MEDIUM PRIORITY] I would like to see the guidelines phrased
using prescriptive wording like that used for the principles; for
example, changing "Synchronized media equivalents are provided for
time-dependent presentations" to "Provide synchronized media equivalents
for time-dependent presentations." I believe that wording is more in
keeping with their designation as "guidelines".

1.c.        [COMMENT] Personally I am not thrilled with the terms used
for Single-A, Double-A, and Triple-A designations.  I wish I had a
better proposal. If we were just English I would consider using A, B,
and C, but I doubt that type of thing would be cross culturally
applicable. Another option would be core, expanded, and expanded +. I
wish that the terms would sort in ascending order, which would be true
of "A", "AA", and "AAA". Are Single-A, Double-A, and Triple-A
cross-culturally meaningful expressions?

1.d.        [MEDIUM PRIORITY] I suggest changing the numbering scheme so
that all of the Criteria for a Guideline are sequentially numbered. For
example, under Principle 3 is Guideline 3.3, and under that we have
three separate Criteria numbered "1", one each in the subcategories of
Single-A, Double-A, and Triple-A. (In fact, the first item numbered "1"
isn't a Criterion at all, just a placeholder saying that there aren't
any criteria in this category!) I suggest instead the first criteria
(which is under the Double-A heading) be numbered 3.3.1, and the second
(which is under the Triple-A heading) be numbered 3.3.2. The placeholder
under the Single-A heading should not be numbered. This would make it
MUCH easier to refer to a specific criteria: you could say "3.3.2"
instead of "Triple-A Criterion 1 in section 3.3". Another viable
approach, although more cumbersome, would be "3.3.A.1" and "3.3.AA.1",
or perhaps "3.3.A1" and "3.3.AA1".

1.e.        [COMMENT] There are still comments in the document that
refer to "Extended Checkpoints"; is that concept gone now that we have
Single-A, etc., designations? I hope that we will not move any
principles or guidelines to a separate document just because they lack
Single-A guidelines.

1.f.         [QUESTION] What became of the section on conformance
claims? 

1.g.       [MEDIUM PRIORITY]You should clarify for the reader whether
the examples given are designed to be "recommended" solutions or whether
they are just one of many possible solutions. (Note that some, such as
example one under Checkpoint 2.2, is definitely a solution that I would
not recommend! It reads "Client-side scripting is used to create
blinking text. The user can deactivate the use of scripting in his or
her browser or override the use of scripts with a user style sheet.")

1.h.       [MEDIUM PRIORITY] I find the format used for examples to be
somewhat confusing.  A prime example would be Checkpoint 2.2 -- please
see my comments there about the phrase "examples of content that
requires a response within a timed interval".  In addition, I think you
would beat much clearer if we replace the list of examples, each of
which consists of the name of the problem followed by a solution that is
written in the present tense as if the solution had already been
implemented, with a "scenario" followed by a list of one or more
"possible solutions".  Using 2.2 is an example, I would rewrite as
follows: 

Scenario <number>: <title>

Problem: <text>

Possible solutions: 

                1. <sample solution 1>

                2. <sample solution 2>

Two examples of rewriting sample solutions:

1. The web site can provide a user-controlled option which causes the
server to offer up web pages to use another form of emphasis rather than
blinking.

2. If client-side scripting is used to create blinking text, user can
deactivate the use of scripting in his or her user agent, or override
the use of scripts with a user style sheet.  (However, this approach is
not recommend because it will also disable other scripts which may be
necessary for use of content.)

2.        Principle 1. "Make content perceivable by any user"

2.a.        [MEDIUM PRIORITY] I suggest defining "content" here, as well
as in the glossary, since it is so key to understanding the principle.
For example, does it include UI elements as well as text and graphics?

2.b.        [MEDIUM PRIORITY] The distinction between UI elements and
other content is somewhat artificial, since in most browsers the user
can interact with any text or graphics (for example, select and copy
text, click on text or graphics that is also a link, etc.).

3.        Guideline 1.1 "All non-text content that can be expressed in
words"

3.a.        [HIGH PRIORITY] I still have reservations about the concept
of non-text content that cannot be expressed in words. To me, almost
anything can be expressed in words, even a piece of artwork or musical
piece.  For example, I believe that I could describe a painting in terms
that would satisfy most blind or not physically present listeners
(although not art students who are looking for a level of detail beyond
the superficial) and I could do it in fewer words than would be required
to convey all the information found in a large work and complex table.
I even her story on NPR recently about how some symphony orchestras are
providing real-time, synchronized text descriptions of the music as it
is being played, in order to help their patrons appreciate the
subtleties of what they're hearing.  Isn't that a textual description of
a piece of classical music?

4.        Guideline 1.1 Benefits of Checkpoint 1.1

4.a.        [LOW PRIORITY] I believe there are quite a few benefits to
Checkpoint 1.1 which are not currently listed. Some of these are
mainstream advantages, rather than being particular to people with
disabilities; I believe it is useful to list these because it
strengthens our case, although it is probably good to distinguish them
from the accessibility advantages. Some examples include:

4.a.1.   Transcripts, and certain types of captions, allow users to
absorb the information at their own pace rather than being forced to try
to keep up with a synchronized presentation.

4.a.2.   Textual descriptions can be translated into other natural
languages for users who are not fluent in the content's original
language.

4.a.3.   Textual equivalents can be presented in the user's choice of
visual attributes and layout, which is usually not true of non-textual
content.

4.a.4.   Textual equivalents facilitate reusing the information in the
web content by allowing the information to be extracted and in many
cases parsed, understood, and altered by automated systems.

4.a.5.   Textual equivalents and facilitate navigation within content,
such as when the user specifies that they want to go to a certain phrase
and that phrase is found in the textual equivalent of a piece of content
(such as ALT text).

4.a.6.   Users can request that they are user agent will download the
textual equivalents of non-text content in order to download more
quickly over low bandwidth connections.

4.a.7.   Textual equivalents are needed by user agents for do not
support non-textual content, including those on some handheld devices.

4.a.8.   Visual descriptions are often necessary to allow a person with
disabilities up to communicate effectively with people who are using the
default visual presentation.

5.        Guideline 1.1 "Example 1: an image used as a button. (short
description of function)"

5.a.        [HIGH PRIORITY] I believe is important to provide a textual
description of the appearance of an image used to represent a button in
order to allow effective communication between a person using the
textual description and a person using the visual presentation.  For
example, it poses a significant problem when a person who is blind tells
a coworker to click on the "delete button" when the sighted user sees a
picture of a garbage can-and vice versa.

6.        Guideline 1.1 'The text equivalent is "Next Slide," so that
what is read by a screen reader would be "link: Next Slide."'

6.a.        [LOW PRIORITY] We should not imply that all screen readers
read the same, so I recommend changing this slightly to say "so that a
screen reader might read".

7.        Guideline 1.1 "A link to a text transcript is provided
immediately after the clip."

7.a.        [MEDIUM PRIORITY] When supported by the content format,
metadata should be provided for the non-textual content that provides a
link to the textual description.  This should allow a user agent to
request and present to the user the textual description of the
non-textual content without requiring the user to hunt around for a
corresponding link, and it would also avoid having extraneous links
clutter the presentation for users who do not require them.

8.        Guideline 1.2 "an audio description is provided"

8.a.        [MEDIUM PRIORITY] Is an audio description alone sufficient?
It doesn't help a person who is deaf-blind, who would instead benefit
from having a textual description of the visuals, which in turn could be
reformatted into Braille or presented on a Braille display. If you
decide not to require textual descriptions for any checkpoints, then I
recommend at least making and explaining the explicit decision to do so.

9.        Guideline 1.2 "if content is rebroadcast from another medium
or resource that complies to broadcast requirements for accessibility
(independent of these guidelines), the rebroadcast satisfies the
checkpoint if it complies with the other guidelines"

9.a.        [HIGH PRIORITY] I'm not sure I understand this exception.
Take the example of a news broadcast on television which is provided
with closed captions when broadcast live; if the live broadcast complies
with accessibility guidelines for live broadcasts, that would seem to
invoke this exception and thus mean that the web site where the
broadcast is available for later viewing is not required to provide any
captioning.  Is that your intention?  Is the implication that Checkpoint
1.1 would still be required, and be satisfied by providing static rather
than synchronized transcripts?  I do not understand why the requirement
should be higher for a multimedia presentation which is only on the web
site that it is for something that is now owned on the web site but at
one time was available somewhere else.

10.     Guideline 1.3 "Information, functionality, and structure are
separable from presentation."

10.a.    [HIGH PRIORITY] The wording of this guideline seems too vague,
and it's hard even for me to see how the actual checkpoints under this
guideline relate to the guideline's title. I also believe that those
checkpoints fall into two distinct groups that are so different that it
would make more sense to separate them into two separate guidelines:
"Content, structure, and formatting are available programmatically" and
"Give user control over presentation of content, structure, and
formatting". 

11.     Guideline 1.3 "the following can be derived programmatically
(i.e. through a markup or data model that is assistive technology
compatible)"

11.a.    [HIGH PRIORITY] I would modify this to say that structural
elements must be distinguished by standard structural markup or API
where such exist; non-standardized (e.g. proprietary, platform- or
application-specific) markup or API may also be used and should be used
when no standardized markup or API is defined for the content type. This
will allow a wider range of user agents to change the presentation of
the structural elements in a concerted fashion than would be the case
when proprietary markup or API are used. 

11.b.    [MEDIUM PRIORITY] We probably need to define "assistive
technology compatible" if we want this to be measurable. Note that the
issue of compatibility with assistant technology is not a simple one.
Markup is great if the data format, pipeline, user agent, user agents
platform, and assistive technology all support it. Similar restrictions
apply to the data model.

12.     Guideline 1.3 "the following can be derived programmatically:
.any emphasis"

12.a.    [LOW PRIORITY] Do we need to define emphasis?  Is emphasis any
occurrence of a section of text which is formatted differently than the
text around it?  

12.b.    [LOW PRIORITY] Might it be necessary for the user to
distinguish between different types of emphasis, which are usually
indicated by different fonts or formatting (as when an author uses
underscoring to mean something different than bolding)?  

12.c.    [MEDIUM PRIORITY] Isn't it also important for the user to be
able to find out about the visual formatting of the text (as distinct
from its semantic formatting) in order to communicate about the text
with people hoary using the normal visual formatting?  

12.d.    [LOW PRIORITY] Are drop caps an example of formatting or of
emphasis? Offhand I think they're probably used most often in a purely
decorative fashion, but they probably do convey to the visual reader the
fact that they are starting a new section of the text, and in some cases
they may be used with a more explicit meaning, such as introducing a
section dealing with that emphasized letter.

13.     Guideline 1.3 Checkpoint 3 "Text content is not presented over a
background image or pattern OR the text is easily readable when the page
is viewed in black and white (no grayscale)."

13.a.    I think this belongs under 1.6 "Foreground content is easily
differentiable from background for visual default presentations" rather
than under 1.3.

14.     Guideline 1.3 "The markup that creates the columns is separate
from the markup that specifies the logical structure of the document."

14.a.    [MEDIUM PRIORITY] I recommend clarifying the meaning of
"separate from." By this phrase, do you mean to require that the two
categories of markup be distinguishable, or that they actually have to
be physically separate? If separate, must they be in separate files or
can they be in separate sections of the same file? Personally I believe
they should only be distinguishable from each other. 

15.     Guideline 1.3 "Example 2: a scrolling list of stock prices.
Current stock quotes are scrolled horizontally across the screen. The
data are separate from the methods used to scroll the text across the
page."

15.a.    [MEDIUM PRIORITY] So what is the recommended solution in this
case? It is not obvious, given that the server probably does not have
all the quotes at any one time, nor does it necessarily retain values
after they are displayed.

16.     Guideline 1.4 "All text can be decoded into words represented in
Unicode"

16.a.    [LOW PRIORITY] You should include Unicode in the glossary and
provide a reference to the official specification.

17.     Guideline 1.4 "Abbreviations and acronyms are clearly identified
each time they occur if they collide with a word in the standard
language that would also logically appear in the same case (e.g. all
caps)."

17.a.    [MEDIUM PRIORITY] The draft includes a pointer to an online
discussion wherein Ben Caldwell suggests that abbreviations and acronyms
need only be marked up as such in the first occurrence with a document.
That makes some sense, but I see two problems with the proposal: first,
that this would place the burden on user agents to keep track of all the
acronyms and abbreviations encountered a document, which probably none
of them today and which might be difficult on platforms with very small
memory allocations; second, that the definition of "within a document"
might be problematic in a large number of cases, particularly where
multiple pieces of content are pulled from a database and assembled.  Is
a document a single web page or is it a section of web page for a web
site?  One additional danger is that marking up the term only the first
occurrence will leave the term out of sections of the document that are
copied for storage or pasting into another document. I recommend that
all occurrences be marked up, but I'd also recommend that authoring
tools automate this process as much as possible (e.g. applying acronym
markup to all occurrences of the term).

18.     Guideline 1.4 "Example 2: an acronym in a page title. In the
following heading, "People of the W3C." the acronym 'W3C' is marked as
an acronym"

18.a.    [LOW PRIORITY] Actually in this document in this example the
term is not marked as an acronym.  I suggest you to be marked up
properly in this file or else the wording be changed to "the acronym...
should be marked as an acronym."

19.     Guideline 1.5 "Structure has been made perceivable through
presentation"

19.a.    [HIGH PRIORITY] I consider user control to be more important
than having the default presentation distinguish between these elements
either visually or audibly. I guess that's covered by section 1.3, which
requires structure to be programmatically determinable, which in turn
should allow UA to adjust the presentation. However, for a document to
be accessible it requires that for all content types used there be an
available UA (or plug-in, etc.) that displays that content type and
meets UA accessibility guidelines. Do we already say that anywhere? 

19.b.    [MEDIUM PRIORITY] I would move "users can control the
presentation of structural elements or the emphasis on the structure can
be varied through alternate presentation formats" up to requirement
(Level 1 Success Criterion), with an added caveat like ", if supported
by the technology".

20.     Guideline 1.5 "for visual presentations, font variations,
styles, size and white space can be used to emphasize structure.color
and graphics can be used to emphasize structure."

20.a.    [LOW PRIORITY] These two bullet items both list things that can
be done to visually emphasize structure; why are they not combined into
a single bullet item?

21.     Guideline 1.5 "if content is targeted for a specific user group
and the presentation of the structured content is not salient enough to
meet the needs of your audience, additional graphics, colors, sounds,
and other aspects of presentation can be used to emphasize the
structure"

21.a.    [LOW PRIORITY] I cannot figure out what this bullet item is
supposed to convey. Why is this limited to documents targeted at
specific user groups?

22.     Guideline 1.5 "Subtle differences between the appearance of the
chapter title and the section headings helps the user understand the
hierarchy and relationship between the title and headings"

22.a.    [MEDIUM PRIORITY] I disapprove of recommending subtle
differences; I know from personal experience that I am often confused by
standard technical publications (such as Microsoft's printed manuals)
where a very slight difference in font size is all that distinguishes
different levels of headings. That may be fine when you see the
different styles together on the same page and so can see that one is
larger than the other, but when you only see one it is very difficult to
be sure whether it is a sub header or a peer to a header that occurred
on an earlier page. Ideally the visual presentation should tell you what
you need to know about the structure without having to get out a ruler.

23.     Guideline 1.6 "Foreground content is easily distinguishable from
background.default presentations"

23.a.    [HIGH PRIORITY] I consider the user's ability to adjust the
presentation to be much more important than the details of the default
presentation.  Therefore I recommend we also include a recommendation or
requirement that the user be able to omit backgrounds that overlap text
or information-bearing graphics.

23.b.    [MEDIUM PRIORITY] I believe that the guidelines are lumping
together two separate issues involving the distinction between
foreground and background content: 

23.b.1.      First, there is the distinction between content that is
important (because it carries information) and that which is purely
decorative (meaning it carries no information). It would be useful to
let users reduce visual clutter and distraction by choosing to hide or
de-emphasize purely decorative content. 

23.b.2.      Second, it can be difficult to interpret a presentation
where two pieces of content overlap each other, either visually or
audibly. To address that, we should say that the presentation should
either not overlap pieces of content or it should provide the user with
the ability to forces pieces to not overlap. The latter can be
accomplished either by rearranging the pieces or by hiding pieces that
are purely decorative (that is, pieces which do not convey any
information). 

23.c.    Is it possible to replace this distinction between "foreground"
and "background" with one of useful vs. purely decorative content, such
as saying that the user should be able to hide all purely decorative
content? Or, if you're really only talking about background harming the
legibility of foreground content, then maybe a more general thing about
making sure that background does not overlap foreground, or can be
hidden. After all, distinguishing one from another does not necessarily
imply that the foreground is legible.

24.     Guideline 1.6 "text that is presented over a background color or
grayscale has a mechanism that allows the text to be presented in a
fashion."

24.a.    [MEDIUM PRIORITY] The wording of the Guideline is at odds with
the wording of this Success Criterion: the Guideline says it's
addressing "default presentation" but the Success Criterion discusses
providing a mechanism that lets the user choose a non-default
presentation option. Therefore you might want to remove the word
"default" from the Guideline title.

25.     Guideline 1.6 "Groups of rows or columns are labeled with
headers."

25.a.    [MEDIUM PRIORITY] Add that headers should be visually distinct
from content cells.

26.     Guideline 1.6 "[use].a different, more formal voice to read
titles and headers so the listener can easily identify the words as a
title and not part of the running text"

26.a.    [LOW PRIORITY] You might also want to mention that can be
useful to pause before voicing headers.

27.     Guideline 1.6 "text that is presented over a background color or
grayscale"

27.a.    [HIGH PRIORITY] I would rephrase this to "text that is
presented over a nonblank background" or something similar that would
include background images and patterns as well as background colors and
grayscale.

28.     Guideline 1.7 "Example 1: a background image on a page."

28.a.    [MEDIUM PRIORITY] This example is applicable to 1.6, so it
should be deleted from 1.7.

29.     Guideline 1.7 "Where speech is mixed or recorded so that it is
at least 20 db above any background sounds people do not need to rely on
captions to understand the dialog."

29.a.    [LOW PRIORITY] Minor, but I'd qualify this as ".MOST people do
not need." since some people clearly do still need to rely on captions
to understand the dialogue.

30.     Principle 2 "All functionality is operable at a minimum through
a keyboard or a keyboard interface" and "Example 2: examples of Web
content that would and would not be operable from a keyboard or keyboard
interface"

30.a.    [HIGH PRIORITY] I just want to make sure that I'm clear on
this: according to my interpretation of this guideline and its
checkpoints, it seems that ALL Java applets would comply with this
guideline because they can be run on platforms that support the
MouseKeys feature. That is, the guidelines do not seem to require that
the product to be easily used with a keyboard, or in fact to take any
steps that would accommodate keyboard users.  Is this your intention?
Can you provide any other examples of things that would fail to meet
this criterion? (I noticed that an earlier draft of this document noted
that the editors were going to try to create some tests that would
require more than just MouseKeys to pass.)

31.     Guideline 2.1 "where the functionality or its outcome can be
expressed in words"

31.a.    [LOW PRIORITY] The glossary defines content that can be
expressed in words, but not functionality or its outcome that can be
expressed in words. Since you use this unusual term, should you explain
what it means?

32.     Guideline 2.1 "wherever a choice between event handlers is
available and supported, the more abstract event is used"

32.a.    [MEDIUM PRIORITY] You might want to define "event handlers" in
the glossary (and refer to the definition here), and also discuss what
makes them more or less abstract.

33.     Guideline 2.2 "control any time limits.unless.real time events
or competition"

33.a.    [LOW PRIORITY] Is competition really different from other "real
time events" already mentioned? Oh well, I guess a little redundancy
can't hurt and might make things clearer.

33.b.    [MEDIUM PRIORITY] You might add a note (either in the glossary
or in Guideline 2.2) to the effect that developers should take care to
give the user as much control as possible over any interaction that will
interrupt the user's task or train of thought. It is usually possible to
give the user the option of delaying or suppressing most interactions
that are triggered by external, real-time events, such as notice of
incoming email or the availability of updated content. 

34.     Guideline 2.2 "content is designed so that time limits are not
an essential part of interaction or at least one of the following is
true for each time limit"

34.a.    [HIGH PRIORITY] I suggest adding another means of complying
with this criterion: an alternative method of accomplishing the same
goal is provided which meets the above exceptions.

34.b.    [HIGH PRIORITY] I suggest adding another means of complying
with this criterion: in a supervised or moderated setting (such as a
student taking a computer-based test), the person supervising or
moderating the experience is able to deactivate the time limit or adjust
the time limit over a wide range which is at least 10 times the average
user's preference.

35.     Guideline 2.2 "People with physical disabilities might not be
able to move quickly or accurately enough to interact with moving
objects"

35.a.    [LOW PRIORITY] I would add ".or may take longer than usual to
interact with the UI elements."

36.     Guideline 2.2 "Examples of content that requires comprehension
or a response within a timed interval"

36.a.    [MEDIUM PRIORITY] I suggest rewarding this slightly to make it
clear that the things listed are not things which are granted an
exemption but rather are things that require modification in order to
comply with Checkpoint 2.2.

37.     Guideline 2.2 "Client-side scripting is used to create blinking
text. The user can deactivate the use of scripting in his or her browser
or override the use of scripts with a user style sheet."

37.a.    [HIGH PRIORITY] I really dislike this recommended solution
because it's using a sledgehammer to pound in a nail: deactivating all
scripts would have a lot of and potentially very harmful effects on the
user's ability to carry out their work.  A far better solution would be
one that is very specific to this problem: the site should provide an
option that would let the user disable the blinking text while still
leaving other, more benign formatting intact.

38.     Guideline 2.3 "user can avoid experiencing screen flicker"

38.a.    [MEDIUM PRIORITY] It seems that screen flicker could be limited
by the User Agent, which would be a more reliable approach because it
would protect the user from badly designed web content. 

38.b.    [MEDIUM PRIORITY] I seem to recall a discussion of whether a
web page (or equivalent) the displays multiple items, each updating
slower than three hertz but all visible simultaneously can equal the
effect of having one element which updates more frequently than three
hertz. Is that true?  Is that something we should warn against?

39.     Guideline 2.3 "content was not designed to flicker (or flash) in
the range of 3 to 49 Hz"

39.a.    [MEDIUM PRIORITY] I think you would be more accurate to
recommend that "content was designed not to flicker..." (rather than
"content was not designed to flicker."); that is, the current wording
would seem to be met by any web page which flickers inadvertently rather
than by design. Or were you intentionally trying to say that the
requirement is merely that it not intentionally flicker, and that
avoiding inadvertent flickering is only a best practice?

39.b.    [MEDIUM PRIORITY] Might the actual flicker rate very depending
on the hardware and software platform?  It seems like a web page which
does not visibly flicker when displayed on a fast PC might visibly
flicker when displayed on a very slow PC.  Should we address this?
Should we specify something like what platforms need to be tested to
verify that is not flickering unacceptably?

40.     Guideline 2.3 "Individuals who are easily distracted may not be
able to focus on page content with flicker occurring in the same visual
field"

40.a.    [HIGH PRIORITY] Isn't it also true that these individuals will
probably be just as distracted by pieces of content updating within
their visual field, even if the updating is not at a rate which is
considered flicker? Should we address this by saying, in essence, that
the user should be able to disable any animations or automatic updates?
The more inclusive recommendation seems much more useful. 

41.     Guideline 2.4 "Mechanisms have been added to facilitate
orientation and movement in content"

41.a.    [LOW PRIORITY] I think the word "added" should be changed to
"included", making the sentence "Mechanisms have been included that
facilitate orientation and movement in content". The reason is that
"added" makes it sound like something that is only done for
accessibility reasons, as an afterthought or extra action.

42.     Guideline 2.4 "a user is able to move through the content in an
order that follows the visual layout or follows the order the page is
read." (This is the proposed new wording, per the BBS posting.)

42.a.    [HIGH PRIORITY] What do you mean by "move through the content"?
Simply scroll? Or are you requiring the UA to have the equivalent of a
cursor that the user can position within the content? What content would
fail this checkpoint? If the user agent is able to figure out the
spatial locations of all elements in the document as they are visually
presented (e.g. a Web browser knows where it is displaying each element
of the HTML) it can choose whatever order it feels is appropriate,
including making a best guess at the order the user might read it in. Is
that sufficient? What does the content have to do to facilitate this?

It is not always advantageous to follow the visual layout: users of
screen readers, for example, would usually like to skip the navigation
links and get right to the page-specific content. Since the new
guideline does not address this need, what exactly is its goal?

Maybe what we're getting at is more like: the UA must be able to
recognize structural elements identifying and naming blocks of content
that are essentially the same between pages or documents within the
document set, thus allowing the UA to provide the user with the option
of skipping over those sections. (See my note below about the glossary
entry for Structure.) Of course, we should also require that at least
one UA be available that actually offers this feature, or else we leave
a loophole of almost infinite size. Also, of course, we'd need to push
to get such markup added to HTML and other standard document formats.

43.     Guideline 2.4, under Benefits, "When the logical structure is
provided in markup or a data model.the content can be presented on a
variety of devices because the device software can choose only those
elements of the content that it is able to display and display them in
the most effective way for that device."

43.a.    [LOW PRIORITY] This is clearly not related to structural
markup, but rather to markup describing data types. It could be
rewritten to discuss structural markup by saying ".the content can be
presented on a variety of devices, including those with serial
presentation (such as voice output) and those with small visual
presentations, because the UA can allow the user to choose to present
only selected sections or choose the order in which they are presented.

44.     Guideline 2.5 "The CKW proposal suggested that this success
criterion be combined with one of the (now AAA) items and that another
best practice item be moved up."

44.a.    [COMMENT] I like the proposed rewrite of this guideline.

45.     Guideline 2.5, Benefits, "Individuals with speech disabilities
might not be recognized properly in voice input applications"

45.a.    [LOW PRIORITY] This is funny: anyone's speech can be
misrecognized (and often is!). I suggest that, if you keep this, you
rewrite it as "Individuals with disabilities affecting their speech or
manual dexterity will often have a higher error rate when communicating
with speech or handwriting recognition, or typing, and therefore benefit
proportionately more from features that assist in recognizing and
correcting input errors."

46.     Guideline 2.5 "Example."

46.a.    [LOW PRIORITY] I suggest adding another example, that when
providing a form for submitting feedback, the form UI include an
optional spell-checking feature. 

47.     Principle 3 "Content and controls"

47.a.    [MEDIUM PRIORITY] Are "controls" the same as "Interface
Elements" mentioned elsewhere? Should we use consistent terminology?

48.     Guideline 3.1 "document attributes identify the natural language
of the document."

48.a.    [LOW PRIORITY] I agree that we need the requirements to
effectively guarantee that all content can be identified by its natural
language (and, if applicable, character set), but I don't like the
phrasing of this nor the artificial distinction between the two
Requirements. Not all formats allow the document to be categorized by
language, so I propose combining the two Single-A checkpoints into
something like "it must be possible to unambiguously and
programmatically identify the natural language and character set of all
textual content in the document." In explanation it can say that the
primary language of the document can be specified as attributes of the
document itself and/or using markup within the document (such as using
tags to the entire body of the document), and that any passages of text
within the document whose language or character set differ from that
around them must be demarcated and identified.

49.     Guideline 3.1 "Example 1: a French phrase in an English
sentence"

49.a.    [LOW PRIORITY] I don't think you should say "In the following
sentence.is marked as French" when it is not actually marked that way in
the guidelines document. Instead you should say "In the following
sentence.should be marked as French".

50.     Guideline 3.2 "The definition of abbreviations and acronyms can
be unambiguously determined"

50.a.    [COMMENT] This is a very interesting topic! Some questions
worth thinking about include: (1) Is it that much more important to
provide definitions of acronyms than, say, names, or words that are
usually omitted from abridged dictionaries? (2) I agree that someday
there should exist a way to link from a word in a document to an
unambiguous definition-think how much easier that would make automatic
cross-language translation! 

50.b.    [LOW PRIORITY] Does this also apply to abbreviations that use
punctuation rather than letters? For example, the double-quote character
(") is sometimes used for quoting, but sometimes it serves as an
abbreviation for "inches" (a unit of measurement for linear distance) or
"seconds" (a unit of measurement for arc). Similarly, the symbol #,
commonly referred to in the U.S. as a "pound sign", may be used for
"pounds" (a unit of measurement for weight) or as an abbreviation for
the word "number" (ordinal counting). As far as I know, HTML allows
marking up non-characters this way, but I never see sites do so. Should
we recommend this? How about cases where punctuation is itself
ambiguous, such as distinguishing the period in "3.4" from the identical
character used to indicate the end of a sentence, or the end of an
abbreviation? It would be nice to address this someday, although
probably not needed right now.

50.c.    [MEDIUM PRIORITY] Do we have to make exceptions for media types
that don't really allow links or markup like this, such as an audio
recording of a speech?

51.     Guideline 3.2 "acronyms and abbreviations do not appear first in
standard unabridged dictionaries"

51.a.    [LOW PRIORITY] I doubt that the standard dictionaries for
English are 100% consistent on the order they list possible meanings of
acronyms and abbreviations. Does that matter? Probably not, but should
acknowledge it?

52.     Guideline 3.2 "a list is provided on the page or home page of
URIs to cascading dictionaries that can or should be used to define
abbreviations or acronyms"

52.a.    [MEDIUM PRIORITY] Is there a standard for such "cascading
dictionaries"? If so, we should reference it; if not, then is this
meaningful?

52.b.    [MEDIUM PRIORITY] Putting something on the home page doesn't
help with documents that get copied around, or converted to another
medium, etc. Therefore it is preferable to have such links in every
document.

52.c.    [LOW PRIORITY] The current wording seems a bit HTML-centric,
talking about the page and so forth.

53.     Guideline 3.2 "provide a definition or link (with the first
occurrence) of phrases"

53.a.    [MEDIUM PRIORITY] As mentioned in another comment, putting an
annotation on the first occurrence requires defining first occurrence-is
it first in a document, section, page, etc.?-and also means that copying
a selection may not include the annotation. This could be addressed by
providing the annotation on every occurrence, and leaving it to the UA
to hide redundant occurrences if the user so chooses.

53.b.    [LOW PRIORITY] Should that be first occurrence other than in
headings, or first including headings? Often books indicate trademark on
the first occurrence in normal text.      

54.     Guideline 3.2 "if contracted forms of words are used such that
they are ambiguous, provide semantic markup to make words unique and
interpretable"

54.a.    [LOW PRIORITY] This guideline is not clear to me. What are
examples of ambiguous contracted words?

54.b.    [COMMENT] If we're going to require markup to disambiguate
contractions, why not non-contracted words that have ambiguous meanings?
Other than the fact that it'd be a lot of work to comply, that is. 

55.     Guideline 3.3 "the content has been reviewed, taking into
account the following strategies for evaluating the complexity of the
content, applying them as appropriate"

55.a.    [MEDIUM PRIORITY] I don't think this should be a requirement
because it is neither measurable (since you have to take their word for
it that they reviewed it) nor provably beneficial (because they are not
required to actually make changes based on the findings of the review).
In addition, I doubt there are widely accepted measurements of
complexity that cover all of these points. Therefore I think it has to
be relegated to a recommendation. 

55.b.    [LOW PRIORITY] 1.e should be broadened to recommend "accuracy
and uniqueness of page and section titles" rather than just page titles.

56.     Guideline 3.3 "Example 2: a concrete concept. The primary
concept on a page is concrete."

56.a.    [LOW PRIORITY] This doesn't really say anything. In fact, it
could be taken as saying that the document discusses concrete (the
material). I hope that all examples will be concrete (specific). This
describes a document that does lots of things, but the Example doesn't
make clear which things are key, or why they are being done. A negative
example would help, for contrast. See my suggestions elsewhere for
reformatting Examples to be clearer.

57.     Guideline 3.3 "Example 4: child's report of school trip"

57.a.    [MEDIUM PRIORITY] This example, as several others, describes a
scenario without making clear what aspects of the scenario are key. That
makes the example more confusing and less helpful than it would be if it
called out the things that are important. See my proposal above about
reformatting all examples. 

58.     Guideline 3.3 "Note: Designers need to be cautious in deciding
when to use illustrations."

58.a.    [LOW PRIORITY] I think this note should be revised or removed,
because it could be interpreted as recommending against using any
illustrations, which would either lead to less usable web content or to
designers deciding that the guidelines are unreasonable and discounting
them altogether. I think that what you're trying to say-with complete
validity-is that designers should avoid conveying any information solely
by illustrations, but that illustrations can also be very helpful for
many readers. I don't feel this paragraph makes clear what we are
recommending.

59.     Guidelines 3.4 "Key orientation and navigational elements (such
as navigation bars) are generally found in one or two consistent
locations."

59.a.    [LOW PRIORITY] I recommend saying something like "(such as
navigation bars, page numbers, and section titles)" to avoid giving the
impression that we're only referring to things outside the primary
content.

60.     Guideline 3.4 "when inconsistent of unpredictable responses.the
user is warned in advance of encountering them"

60.a.    [MEDIUM PRIORITY] I'm not sure what you mean. Can you give an
example showing recommended UI for this? Are you suggesting that a game
present a warning that what the challenges the user will encounter will
vary? Is it enough that the documentation says that every game will be
different?

61.     Guideline 3.4 "Whenever there are extreme changes in context,
one of the following is true."

61.a.    [LOW PRIORITY] In-line warnings and options to deactivate are
good, but it seems like UA could also handle this in most cases, such
as: letting the user adjust whether they want to allow, block, or be
asked how to handle pop-ups; notifying the user when a page transition
makes significant changes to the page layout; identifying links that
will pop up a new window or go to a different site; etc. 

62.     Guideline 3.4, "pages with similar function should have similar
appearance and layout"

62.a.    [LOW PRIORITY] But we might note that it's also good for
separate sections to be easily distinguishable, which implies not using
identical appearance; distinct visual elements such as colors or
graphics will help readers orient themselves, keep in mind which section
they are in, and avoid mistaking similar pages.

63.     Guideline 3.4 "the content has been reviewed, taking into
account."

63.a.    [MEDIUM PRIORITY] Isn't there some way that this criterion
could be made to have some impact or benefit? I'm afraid that, as it is,
criteria phrased this way will just be a checkbox that can be checked
without anyone doing anything! Perhaps, to have some benefit, the web
site could post a review of its usability and rationale for their
decisions to avoid making improvements. Something? Anything?

64.     Guideline 3.4, Example 3: "frames that do not track history
making the back button behave unexpectedly"

64.a.    [MEDIUM PRIORITY] This doesn't describe a recommendation; is it
simply to avoid frames? (Again, it seems like UA should be able to solve
this problem without changes to Web sites.) 

65.     Guideline 4.1 "Technologies are used according to
specification."

65.a.    [HIGH PRIORITY] I firmly believe the technology should only be
used according to their specification when the specification leads them
to be used in an accessible manner.  I do not believe you should assume
that all specifications when followed exactly will lead to accessible
results, and when they do not, the author should follow unofficial
guidelines to result in more accessible content. I'm sorry if that
doesn't make for a simple, objective guideline. (On the other hand, I
also admit that the consistency that comes from everyone following
specifications usually has other advantages.)

65.b.    [LOW PRIORITY] In the description of benefits, you could add
that following specifications (especially for markup and other file
formats) is that it allows reformatting, repurposing, and reuse of
content, which is especially important to users who can only make full
use of the content in a different format.

66.     Guideline 4.2 (formerly 4.3) "programmatic user interfaces are
accessible or alternative, accessible versions are provided"

66.a.    [LOW PRIORITY] Terminology point: I don't think APIs are
accessible, but rather APIs support accessibility and are implemented in
accessible ways.  That is to say, APIs are in fact specifications for
the communication method between software components; different
platforms (including different versions of the same operating system or
operating environment) provide different implementations of the API in
the form of specific code or components.  An API is accessible if the
definition allows or requires the caller to provide all the information
and functionality needed to render the end result accessible.  I would
therefore suggest rephrasing this guideline.

66.b.    [MEDIUM PRIORITY] I'm not familiar with the term "programmatic
user interfaces"; by that do you mean API that report on the
presentation (e.g. enumerate sections of content and give their screen
coordinates and names), or API that control the program (e.g. change
selection, move focus, activate controls), or both, or something else
altogether? This should probably be clarified in the document.

67.     Guideline 4.2 "the interface has been tested using a variety of
assistive technologies.to determine that those assistive technologies
are able to access all information on the page or hidden within the
page"

67.a.    [MEDIUM PRIORITY] This is very screen-reader specific; I
recommend making it more general by saying ".assistive technologies are
able to access all content, structure, and formatting information on the
page or hidden within the document, and are able to identify and
manipulate all user interface elements on the user's behalf."

68.     Guideline 4.3, Double-A Checkpoint 1, "the Web resource includes
a list of the technologies (other than standard HTML) users must have in
order for its content to work as intended. Users who do not have one or
more of these technologies can still access and use the resource, though
the experience may be degraded."

68.a.    [HIGH PRIORITY] I think we need to do more to explain this
guideline. What constitutes sufficiently documenting the list of
required technologies? For example, when a web page contains an OBJECT
element that specifies the technology required, is that sufficient? Or
are you saying that the page would have to list those required
technologies in human-friendly text in addition to the UA-friendly tags?
Does the list of required technologies have to be posted with every link
to the document, so that users can view the list before downloading the
document? Would you, for example, require every Web page that links to a
site's online store have some text indicating that the store requires
SSL? Does every link to a PDF document need to identify it as such?

68.b.    [LOW PRIORITY] It seems to me that the two sentences in this
checkpoint are really making two separate points, and so should be
broken into two separate checkpoints. Thus: Checkpoint 1, "The Web
resource includes a list of the technologies (other than standard HTML)
users must have in order for its content to work as intended", and
Checkpoint 2, "Users who do not have one or more of the technologies
used by the document can still access and use the resource, though the
experience may be degraded." This allows a document to get credit for
degrading gracefully even though it might not list required technologies
up-front. 

68.c.    [LOW PRIORITY] You might explicitly note that the first example
shows listing required technologies, and the second shows degrading
gracefully.

69.     Guideline 4.3, Triple-A Checkpoint 1, "a list of technologies
and features, support for which is required in order for the content to
be operable, has been determined and is documented in metadata and / or
a policy statement associated with the content."

69.a.    [LOW PRIORITY] How about giving priority to using metadata
(which is then computer-usable) by saying ".documented in metadata if
such metadata is supported by the file format, otherwise is documented
in a policy statement associated with the content."

70.     Glossary definition of "Audio Descriptions"

70.a.    [MEDIUM PRIORITY] The glossary entry for audio descriptions are
redundant to the entry for audio description.

71.     Glossary definition of "Feature"

71.a.    [MEDIUM PRIORITY] I think we should clarify the word "Feature"
has several meanings. The definition currently gives only one
definition, but in the WCAG 2.0 document the word is used in a variety
of meanings.

72.     Glossary definition of "Keyboard Interface": "A keyboard
interface is the point where the application accepts any input that
would come from the keyboard (or optional keyboard)." 

72.a.    [LOW PRIORITY] I would change this to read "A keyboard
interface is the point where the application accepts any input that
would come from a keyboard, optional keyboard, or assistive technology
simulating keyboard input."

73.     Glossary definition of "Media equivalents" : "Media equivalents
present essential audio information visually (captions) and essential
video information auditorily (audio descriptions)."

73.a.    [MEDIUM PRIORITY] I would include presenting essential audio or
visual information in textual form, which would then be usable by people
who are deaf-blind and by accessibility aids, as well as supporting
mainstream uses such as searching and indexing.

74.     Guideline 3.4, Glossary entry for "Mechanisms that cause extreme
changes in context"

74.a.    [LOW PRIORITY] The two examples, "in an auditory presentation,
the speaker changes with no visual cue and no notation in the captions"
and "captions that do not identify change in speaker" seem redundant to
each other.

75.     Glossary definition of "Non-Text Content"

75.a.    [MEDIUM PRIORITY] The definition of "non-text content" is
currently just a list of examples. A simple way to summarize the
definition might be to start with something like "Non-text content is
any content that is not displayed for the user as Unicode text."

76.     Glossary definition of "Operable"

76.a.    [MEDIUM PRIORITY] The definition of "operable" is specific to
the context of "operable using a keyboard", but the word really has a
broader definition. I suggest (a) keeping the definition, but changing
the glossary entry to "Operable using a keyboard," or if that's not
acceptable then (b) prefixing the definition with something like "In
this document the term 'operable' is used in the context of content
being usable through a keyboard or assistive technology that simulates
keyboard input."

76.b.    [MEDIUM PRIORITY] I have suggested that we might be able to
come up with a metric for keyboard usability, which would be something
like "The number of keystrokes required to carry out an operation should
be no more than five times the number of discrete actions required when
a pointing device is available." Discrete actions include keystrokes,
mouse movements, and mouse button presses. Worth thinking about. 

77.     Glossary definition of "Real-Time Events"

77.a.    [LOW PRIORITY] I would recommend against defining a phrase by
referring to one of its own components, such as defining "Real-time
events" as, essentially, events that happen "in real-time"; therefore I
would remove the phrase "in real-time" from the definition. In addition,
I would supplement "where the events are not under the control of the
author" by adding "or the user". How about something like "Real-time
events are those whose timing is triggered by outside events and
therefore cannot be put under the control of the author or user without
compromising their usefulness. For example, a stock ticker or emergency
warnings could potentially lose their value if delayed significantly and
are therefore real-time events, whereas any direct and immediate
reaction to the user's input is not a real-time event."

78.     Glossary definition of Site Navigation Mechanism

78.a.    [MEDIUM PRIORITY] An additional recommended mechanism would be
providing navigation links that allow the user to skip portions of the
content which are consistent between documents or sections of the
document. This can also be achieved by providing sufficient markup,
along with names meaningful to humans, allowing the user to recognize
which are recurring and instruct compatible UA over or to those
sections. 

79.     Glossary definition of Structure: "Structure includes both
hierarchical structure of the content and non-hierarchical relationships
such as cross-references, or the correspondence between header and data
cells in a table. The hierarchical structure of content represents
changes in context."

79.a.    [LOW PRIORITY] I recommend against defining a phrase by
referring to one of its components, such as "structure includes both
hierarchical structure." Can we phrase this to avoid using the term
structure in the definition? How about "Structure includes both
hierarchical relationships between elements (such as the division into
sections and sub-sections) and non-hierarchical relationships."

79.b.    [LOW PRIORITY] In one instance the word "hierarchical" is
misspelled as "heirarchical".

79.c.    [LOW PRIORITY] Missing space between "in a table." and "The
hierarchical".

79.d.    [MEDIUM PRIORITY] One of the most important relationships
between pieces of content is that which tells the user agent in what
order they should be presented.  Is this structure or presentation?  The
most common case is where the presentation order is implied by the order
in which the pieces of content are defined in the source file (e.g.
HTML) and in most cases this is the default, but it is not always the
only order specified.  Is there a standard way to specify alternate
orders? IF so, would that be in the style sheet, and if so, would it
thus be presentation?

79.e.    [LOW PRIORITY] Might note that structural markup serves to aid
in identification (it identifies a block of content), orientation
(allowing the user to tell where they are in relation to various blocks;
this can happen at the user's request or automatically as the content is
being presented to the user), reference/navigation (allowing the user to
refer to a location for any purpose, including asking the user agent to
begin acting there), and reformatting (such as allowing the user to hide
or skip certain blocks, or alter their presentation).

 

[End of Greg Lowney's Comments on WCAG 2.0 Draft of 2003-10-08]