- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Wed, 8 Mar 2006 07:31:56 -0600
- To: <w3c-wai-gl@w3.org>
- Message-ID: <000a01c642b4$c57bcfd0$ee8cfea9@NC6000BAK>
Here is the INTRODUCTION issues list and proposed dispositions based on
proposed new introduction
ATTACHED IS THE NEW INTRODUCTION
Issue List
Tue Mar 7 01:27:34 CST 2006
_____
25 issues found.
ID Summary
367 Include a section on development process
Consider inserting a section on development process: Choice of technology
and impact on accessibility. This section should talk about "widely
available", time lag before assistive tech adopts the technology,
availability of AT in natural language of site, backword compatibility,
etc. This section may be placed before the guidelines and checkpoints are
listed.
CLOSE with comment - We are unable to go into that kind of detail in a
standard. We are encouraged to keep the intro as short as possible.
392 Better definition of "audience"
I want a better definition of the audience. For a writing project of this
kind of scope, audiences must be defined clearly and explicitly, as well as
how those audiences will use this document.
CLOSE with comment - We are unable to go into that kind of detail in a
standard. We are encouraged to keep the intro as short as possible.
Further information on audience is contained in support documents such as
the WCAG 2.0 overview.
400 What is meant by "perceivable?"
Guideline one needs some introductory material explaining what is meant by
"perceivable".
CLOSE with comment - guideline 1 is much more explicitly spelled out now
- and more information is available in the Understanding WCAG 2.0 document..
515 robust is difficult to understand
Use of the word "ROBUST". Unless you were highly involved in technical
circles, most individuals would not understand the implications of using the
word "robust" .
CLOSE with comment - We have reworded the principle to make it clearer
546 Define key terms in guidelines and make consistent
The descriptions of guidelines in the "Overview of Design Principles," and
the individual guidelines themselves, should be made consistent; and the key
terms used for the guideline level (e.g. perceivable, robust, etc.) must be
defined very clearly, in order for the document to work when translated into
other languages.
CLOSE with comment - We have now made them consistent. Perceivable,
operable, understandable all mean what the standard dictionary definition
means. We would be happy to work with translators if there is any
ambiguity. .
547 Link to WAI resources instead of EOWG home page
Send people to the WAI Resource page, instead of the EOWG home page, for
supporting resources.
CLOSE with comment - We cite both but have moved WAI to the front.
553 Goal of guideline 1
This is an excellent statement of a goal. We understand that the statement
is not saying all content must be understandable by all, but that all users
should at least be able to discern the information presented by a page.
CLOSE THIS ISSUE. - We agree. Thanks. (It is not an issue but a statement
of understanding.)
658 are examples "recommended" or "one of many possible solut...
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.
CLOSE with comment - Done - examples moved to How to Meet and language
added. Should be clear for techniques and examples.
825 Suggestions for front matter and introduction
Mostly frontmatter instructions for Ben. Plus this comment on intro
Introduction, Purpose, 1st paragraph - Remove the sentences about
accessibility to a variety of Web-enabled devices. This is a benefit of
accessibility but it should not be discussed in the first paragraph of the
document. It can be covered later or left to EO to promote.
CLOSE with comment - This has been edited to add focus on disability.
1205 include more examples that show benefit to people without...
Wants examples of how this benefits people without disabilities.
We might consider this as a new header in How To Meet docs.
CLOSE with comment - This is not within our scope. However are
considering this for a later followup activity. At that time we may add to
a support doc.
1327 End users missing from audience
One of the biggest audiences is not covered and that is the group who is
actually served by implementation of a good set of guidelines in a
successful way. It is important that the end user be given high priority in
this process and its aftermath.
CLOSE with comment - Added. Done.
1337 No disabled people, only disabled technology
There were several look a like things I did not comment on but only made one
pass at those similar. This is that there are no disabled people, there is
only disabled technology. We need to reduce functional barriers, not class
people.
CLOSE with comment - Look at new wording in introduction.
1342 Which usability issues are included, and why
The scope of the document states that "the guidelines do not include
standard usability recommendations except where they have specific
ramifications for accessibility beyond standard usability impacts." However,
guideline 2.5 is a standard usability guideline. Maybe it would be useful
to include usability experts in the discussion and come to a joint agreement
on which
usability-related guidelines should be covered in the WCAG and how they
should be worded.
CLOSE with comment - As noted in your comments, we do include
usability measures where they have special disability ramifications. We
have recruited usability people and have a larger number as reviewers and
contributors.
1520 Conformance can't guarantee 100% accessibility
These guidelines provide the basic requirements for designing accessible Web
content. This document is not designed to provide the background needed to
learn about accessible Web design in a thorough or effective manner for
those interested in learning. Readers are therefore referred to the
Education and Outreach Working Group of the Web Accessibility Initiative
BUT DO NOT GUARANTEE ACCESSIBILITY FOR ALL
CLOSE with comment - agree - added note to this affect to conformance
section.
1557 Editorial suggestions for beginning sections
* Abstract
o Change ""Accessible" to a wide range of people ..." to
""Accessible" means that your web content is available to a wide range of
people with disabilities, including those with blindness and low vision,
deafness and hearing loss, learning difficulties, cognitive limitations,
limited movement, speech difficulties, and others. "
DOESN'T FIT CURRENT SENTENCE STRUCTURE
o Change "Following these guidelines will also make your
Web content more accessible to the vast majority of users, including older
users." to "Following these guidelines will also make your Web content more
usable by the vast majority of users, including older users."
DONE
o Change "including a wide variety of assistive
technology." to "including a wide variety of assistive technologies. "
DONE
o Need to explain the purpose of the "Introduction to
Web Content Accessibility Guidelines (WCAG) 2.0 Working Draft Documents".
GONE
* Introduction
o "Web Content Accessibility Guidelines (WCAG) 2.0"
should be "Web Content Accessibility Guidelines (WCAG) version 2.0."
DONE
* Four Principles
o Suggest listing the principles after, instead of
before, the discussion of the structure of the document.
HYBRIDIZED THESE
* Audience and Related Documents
o Guide to WCAG 2.0 should link to the document
DONE
o Guide to WCAG 2.0 and General Techniques should define
for whom they are intended as the others do. We need to differentiate these
better. They sound like the same document.
THEY ARE COMBINED NOW
o Guide to WCAG 2.0 - the first two sentences are not
complete sentences.
FIXED
* HTML and XHTML Techniques - last two sentences
are not complete sentences.
NO LONGER EXIST
* The question of baseline
o Much of the discussion here refers to meetings that
have occurred and decisions that have been made. Will this text remain in
the final document? If not, it would be better to mark it somehow as the
editorial notes are marked so that it is obvious what is part of the WCAG
document and what is just background information.
BASELINE INFO NOW IN CONFORMANCE AND A WHITEPAPER
`
CLOSE with comment - EDITS MADE EXCEPT WHERE OBE
1559 Principles, guidelines, and glossary are not normative
Normative sections of WCAG 2.0
Principles and guidelines are not really normative, only the success
criteria are. The second paragraph actually says this.
The Glossary can't be normative because WCAG doesn't own all of the
terms in it.
Audience and Related Documents
change
"order to determine the exact wording of the guidelines and success
criteria" to
"order to determine the exact wording of the success criteria " - as
previously stated, the principles and guidelines should not be normative.
CLOSE with comment - FIXED edits.. Glossary can be normative. In fact
it has to be.
1584 Need more inclusive terminology than "people with disabil...
There is an overall need to improve the use of terminology relating to
"people with disabilities". A more inclusive term with a higher degree of
coverage is needed. Possible non-exhaustive options include "people with
impairments" or "users with disabilities", "very young and elderly users,
handicapped users, users with special needs"- as also referred to in most
European activities
CLOSE with comment - We have incorporated some of these terms in the
latest draft. Generally we are trying to use consistent terminology
throughout.
1.
1856 Provide definition of accessibility
I would like the wcag20 specification document to provide a definition of
"accessibility", in addition to
the 4 necessary conditions. For 2 reasons:
1) the necessary conditions are vague in what it is mean by "each user",
"understandable", "robust enough to work"
2) a definition might be based on other parameters other than
perceivability, operability, understandability and robustness.
<SNIP>
CLOSE with comment - The working group considered this and decided to
not define accessibility .
1857 add QA and reviewers to audience
Add "people involved in QA or accessibility reviewers" to list of audiences
for WCAG2.
CLOSE with comment - DONE
1859 links to documents missing from guidelines
There is no clear reference on the primary document or the navigation to
some of the supporting documents, such as the Questions and Answers about
Baseline http://www.w3.org/WAI/intro/wcag20-baseline.php which is only found
as a link on one of the subsequent documents.
CLOSE with comment - these have been added
1866 downloaded content vs web content
If the suggested text "Note: If data, software or other materials are
downloaded over the internet but are not used via a user agent then they are
not considered Web content and are not covered by these guidelines." is
included in a future draft it is hoped that care will be taken to more
clearly illustrate the concept. For instance, one might assume that a
spreadsheet workbook downloaded from a site and intended to be accessed by a
compatible spreadsheet application is "data" and would not be covered these
guidelines. It would be unfortunate if the same logic were applied to
content contained in proprietary or open source formats that could - for the
most part - be as easily represented in a baseline technology. Without
guidance, it might be possible to argue that the content of a
downloadable document is "data" for a word processing application or a
document viewing application. Is the distinction drawn between application
software and user agent sufficient to forestall such sophistry? If it is
not, then it should be.
CLOSE with comment - We have decided to not put the topic in question
into the WCAG Document
1867 web applications vs desktop applications
The following proposed Note introduces a grey area: "Note: If data, software
or other materials are downloaded over the internet but are not used via a
user agent then they are not considered Web content and are not covered by
these guidelines." The intent seems to be to exclude things like Office
Automation (OA) applications from being defined as user agents, but in the
Glossary, a user agent is
defined as any software that retrieves and renders Web content for users.
Microsoft Word, for example, does this, especially but not exclusively if
the content is in MS-Word format, and admittedly through integration with
Internet Explorer. It also acts like a helper application for IE when you
are on an HTML page and activate a link to a Word document. So it's not
clear whether it is a user agent or not.
CLOSE with comment - We have decided to not put the topic in question
into the WCAG Document
Keep the following two open til we finish up the baseline doc
1701 potential confusion in baseline examples 2 and 3
I realize these two examples are informative, but they have the potential to
create confusion through multiple interpretations.
Example 2 "...supported by more than one accessible and affordable user
agent for more than one release."
The word release is a relative term. Release cycles vary greatly for
different software. Does this include major and/or minor releases (e.g.
feature release vs a bug fix release).
What about where only one accessible user agent exists, like Internet
Explorer was for the longest time. Use words like "readily available user
agent" rather than "more than one." The words "readily available" could
also remove multiple interpretation of the word "release". A definition of
the phrase "readily available" could be added to the glossary, with a
definition something like "...with minimal effort is attainable by
searching the Internet."
Example 3 "... to reflect the increased ability of affordable user agent
(including assistive technology)..."
I might ask "are there affordable assistive technologies?" thinking about
the current cost of screen readers. The affordability of assistive
technologies is relative to a person's income, or the availability of
funding to them (in Canada funding is available every five years), so this
leaves room for many different interpretations. Perhaps replace
"affordable" with "readily available."
1797 Add SC to select appropriate baseline
There are important reasons why WCAG 2.0 should not establish a baseline or
set of baselines.
(rationale given in Bugzilla)
Suggested criteria that must be taken into account in establishing
baselines:
For each technology:
2. The extent and quality of support for the technology in user
agents.
3. The extent to which user agents implementing the technology
conform to relevant accessibility guidelines and specifications, including
the User Agent Accessibility Guidelines 1.0 as well as any applicable
accessibility API's or other conventions specific to the operating system.
4. The extent to which user agents implementing the technology
support a variety of user interfaces adapted to the needs of people with
disabilities. (i.e., assistive technologies and alternatives interfaces).
5. The extent to which authoring tools supporting the technology
implement the Authoring Tool Accessibility Guidelines, and the capacity of
the developers who will write the content to implement aspects of WCAG 2.0
not sufficiently supported by the available authoring tools.
6. The extent to which the technology is backward-compatible with
earlier versions for which better support is available, and the extent to
which content that uses the technology can be presented and operated by
software that doesn't support this technology. (i.e., does it "degrade
gracefully"?)
The availability, in practice, of user agents supporting both the technology
and accessibility to people with disabilities who may try to access the
content to which the baseline applies.
Attachments
- text/html attachment: intro_with_edits.html
Received on Wednesday, 8 March 2006 13:33:14 UTC