W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2006

INTRODUCTIONS - issues and proposed resolutions

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.




Received on Wednesday, 8 March 2006 13:33:14 GMT

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