W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2001

review of:Web Content Accessibility Guidelines 2.0 W3C Working Draft 24 August 2001

From: David Poehlman <poehlman1@home.com>
Date: Tue, 28 Aug 2001 16:34:02 -0400
Message-ID: <010b01c13000$c65e8120$2cf60141@mtgmry1.md.home.com>
To: <w3c-wai-gl@w3.org>
Thanks to all who have contributed to the process so far.  I have an
over all good feeling about the document and what it is shaping up to
be.

I took some notes while reading through it, which I share in hopes of
assisting and being assisted below.  I will be happy to Address any
issues raised here or answer questions.  I was especially aware of the
notes for reviewers and provided feedback where possible.

To reach me since I am not on the list, please feel free to reply
through this address or use the link to it at the bottom of this
message.

Begin review:

I have placed my comments after portions of the guidelines beginning
with the word "comment" and ended each section with three dashes on a
line by themselves.
---
Note to reviewers: it has been proposed to include a discussion of
accessibility vs usability and how we define our scope.
Comment:
I support this in perhaps the veign that other moves on accessibility
such as that spawned by the ada make the physical world more usable by
the general public.  It seems to me that accessability may even
encompass usability.
---
Non-text content includes images, text in raster images, image map
regions, animations (e.g., animated GIFs), applets and programmatic
objects, ascii art,
scripts, images used as list bullets, spacers, graphical buttons, sounds
(played with or without user interaction), stand-alone audio files,
audio tracks
of video, and video. Note to reviewers: This definition is under
discussion. Suggestions are welcome.
Comment:
This seems fine to me.  the more inclusive the better.
---
According to the deffinition of alternatives, I have proposed some
rewording of examples of alternatives below:

Examples (informative)
  Example 1: a short label.
  A right arrow icon is used to link to the next slide in a slideshow.
The text
  equivalent is "Next."
comment:
It would be best if the alternative equiv in this case were something
like: "slide 22 next in series" or "next slide".

  Example 2: a short label and a longer explanation of a data chart.
  A bar chart compares how many widgets were sold in June, July, and
August. The
  short label says, "Graph of the numbers of widgets sold in June, July,
and
  August." The longer explanation provides the data presented in the
chart.
comment:
take out the word graph in the short label.

  Example 3: a short label and a longer explanation of animation.
  An animation shows how to tie a knot. The short label says, "An
animation
  showing how to tie a square knot." The longer explanation describes
the hand
  movements needed to tie the knot.
comment:
the short label should be "how to tie a square not".
---
comment on the use of the word natural as in natural language:
perhaps it should be human instead of natural language in order to
distinguish it from machine or programming or other processing
languages?
---
Note to reviewers: We are currently discussing the scope of this
checkpoint and
what is required. Does providing multiple site navigation mechanisms
increase
accessibility or are we trying to get at something else? Refer to the
benefits
for the issue we are trying to tackle. Suggestions are encouraged. How
do we set
limits for when to apply this checkpoint? If a site consists of only 5
pages, a
site map might look exactly like the home page.
comment:
this seems to be a function of the user agent.  we are asking in the
user agent accessibility guidelines that user agents provide multiple
paths to navigation and views.  I would caution that If I had to wade
through a list of possible views on a site not knowing what the content,
presentation or structure of the site was that I might have a hard time
with this.  I would also caution that being a developper, This might not
be something that could be tested through automation and unless
authoring tools are quite inteligent in this regard, it may be difficult
not only to decide which and how many to provide but to provide them
effectively.
---
Checkpoint 2.3 Either give users control of mechanisms that cause
extreme
changes in context or warn them of pending changes.
comment.  the word pending here seems to indicate that something will
happen regardless of what you do.  Perhaps we need a different word as
the example:
  "Link will open in new window."
suggests here?
---
  Example 1: a form to deactivate pop-up windows.
  Provide a checkbox on a page of links to let the user select whether
they want
  the resultant pages to appear in new windows or not.
comment:
I see a possible danger here.  will I be able to undo the check box?
suppose I am deep into the site or someone else has taken over browsing
the site or I forget to check the checkbox?  I may be using a user agent
that does not support mechanisms that allow for this type of user
interaction and this may not be under my controll.  Could we discourage
the use of new window spawning?
---
Checkpoint 2.4 Either give users control over how long they can interact
with
content that requires a timed response or give them as much time as
possible.
comment: one example that is quite problematic but which is not included
here is where you are litterally timed out after what constitutes a
period of inactivity by a site for security reasons.  Instead of being
timed out, you should recieve an opportunity not to be timed out.
---
  Example 2: a news site that is updated regularly.
  A new site causes its front page to be updated every 1/2 hour. The
front page
  contains minimal text and primarily consists of links to content. A
user who
  does not wish the page to update selects a checkbox. The checkbox is
in the
  "user preferences" portion of the site which is one of the first links
on each
  page.
comment:
this is equivalent to the other check box example I mention above.  It's
nice that there is a link to the site settings preferences though I
still have a problem with sites providing an interface for manipulating
their comment that may not be supported in some user agents and may not
be necessary in others and may again be difficult from a verification
and testing stand point.  I have seen sites that provide some content
manipulation capabilities and for many users, they seem awkward.
---
Checkpoint 3.4 Supplement text with non-text content.
comment:
I've seen a lot of discussion on this topic not the least of which bears
out the fact that there is no consensus on a lexical form for this.  I
ask also, do we then provide text alternatives for the non text
alternatives?  Text only pages are not accessible to lots of people so
some indication of links, top, bottom, devisions, buttons and the like
should be on them and perhaps some formatting and font styling if this
is what you mean here.  Anything that can aid in comprehention of a site
should be employed if possible and prudent.  This is kind of a turn
around look at the other view.  One should not go too far either way.
While making sites attractive and orientative to those who cannot
utilize text, it will be necessary to be sure that textual comprehention
is aided as well and not necessarily in too simple a fashion as that may
be a barrier in and of its self.
---
  Note to reviewers: there is active discussion on the requirement of
user
  testing as success criterion.
comment:
since these are guidelines and not requirements, it seems reasonable and
prudent to me that user testing is a good test of how something works if
done correctly.  Perhaps the word appropriate should be added when
addressing issues of user testing.  appropriate user testing should be
part of any site development if for no other reason than to gage the
effectiveness of the site as intended.  If I had to access the web
without assistive technology, I couldn't even crawl through it.
assistive technology in this instance also includes someone to read the
site and possibly manipulate the mouse.  I might be able to crawl into a
building.
---


Hands-on Technolog(eye)s
Touching The Internet
http://members.home.com/poehlman1/
mailto:poehlman1@home.com
voice: 301.949.7599
Received on Tuesday, 28 August 2001 16:39:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:12 GMT