Minutes from Feb. 28, 2002

WCAG2 Teleconference, Feb 28. 2002

In attendance:

JW: Jason White
MM: Matt May
LGR: Loretta Guarino Reid
JA: Jenae Andershonis
BC: Ben Caldwell
JM: Jo Miller
MS: Mark Stimson
GO: Graham Oliver
GSW: Gian Sampson-Wilder
CS: Cynthia Stenger	
LS: Lisa Seeman

Action Items:
JM: Write a revised version of Checkpoint 3.3
GO, GSW: Write a proposal for Checkpoint 4.4


Checkpoint 3.3 Discussion:

JM: (Jo summarized her message on Checkpoint 3.3, sent to the list 
earlier today)

JM: Does anything in the checkpoint require definition?

GO: "content" needs definition
JW: This is already being addressed in the glossary work; subscribe to 
the xtech list for these discussions

GO: It is a good idea to split out step-by-step instructions; also 
Charles Munat has suggested splitting artistic content from non-artistic 
content.

JW: Your proposal is that the success criteria be written on the basis 
of content type

JM: I think instructions should be pulled into a separate checkpoint.
And yes, I think success criteria need to be written by content type.

(Discussion of splitting content type into content that can't be edited by
the author, and content which can be edited by the author)

GSW: I am concerned that people using this document will look at this
division and not understand where they fit in. They may think they are
writing new content when they aren't and may apply the wrong definition.

JM: We should try to make this clear in the examples what kinds of
non-editable content we are talking about: legal decisions, works of
literature

GSW: I am thinking more of content reworked for the web

JM: Anything that can be edited would be subject to the same success criteria

GSW: (comfortable with this narrow definition of "can't be edited")

GSW: We should list this as an exception, with the assumption that all
content is being reworked or written for the web

JM: (takes action item to continue reworking 3.3)

JM: The bad news in my message is that when I was pulling out success
criteria, we find lots of things that are good advice but aren't
testable. We find some testable things that are not very useful. There
are a few things that are testable and useful. This brings us again to
the question of what to do with all this good advice that isn't
testable.

CS: Are we going to separate testable criteria and advice in the document?
JW: That is the only proposal on the table

(Clarification: testable does not mean machine testable)

JM: Some criterion aren't testable because it is impossible to tell
where to draw the line, e.g., use common words

JM: There have been postingss from outside contacts on interface
design issues. Shall we determine where these sit in the guidelines?
If there is a task-related checkpoint, they probably sit there.

JW: We need to draft of new, reworked 3.3, then look at proposals for
new checkpoints for information that doesn't fit under new 3.3

JM: I will contact Charles Munat about working on the artistic
expression subcategory

Checkpoint 4.4 Discussion

JW: Although we haven't yet discussed this at our meetings, it has
been discussed on the list; GO had a proposal, and I posted a proposal

JW: A summary of the history of this checkpoint: it was carried over
from the verion 1 guidelines and has been rewritten a number of times
since the 1.0 version. The current wording is problematic, as CS
pointed out. It makes reference to default processing by user agents,
which hasn't been defined. The criticismas of the 1.0 version are
still applicable. It is highly specific to content formats that have a
form of rendering that doesn't depend on style sheets, scripts,
etc. It makes assumptions about content format implementions by User
Agents, that is, some rendering is built in and some requires external
information like style sheets. The main problem is that it doesn't
apply to XML-based formats that require style sheet-like mechanism to
operate properly. JW suggests it should become a general
backwards-compatability requirement.

GSW: I have some problems with this; it says to make sure Flash
content is accessible if Flash isn't istnalled, if you don't have
Java, etc. These issues fall under backwards compatability, but isn't
obvious.

CS: This goes back to what are we assuming in a baseline browser

GSW: Flash and Java can't be accessed by screenreaders. While this falls 
under 4.3, this isn't explicit here.

LGR: What are we intending?

JW: How would it be written so it doesn't establish a baseline that
will be permanent over the lifetime of the document, since technology
changes. There may not ever be a revision of this document. We need to
be very careful about writing anything into it that holds to a
baseline that is relevant today but may not be relevant in 5
years. How can we write a generalized checkpoint that is explicit
enough to be clear but won't become obsolete?

CS: It needs to be based on time. Require the author to remain
backward compatable with browser technology that is N years old

GO: I suggest the percentage of use rather than number of years. 
age isn't a good barometer

JM: People won't know the age of technologies

JW: Summary of my proposal - must not rely on technologies that haven't
been implemented for at least x years, implemented by AT for X years,
and exist internationalized versions, etc.

GO?: Why is this checkpoint in the guidelines at all? it isn't about
people with disabilities, it is about backwards compatability. Where
are the specific benefits for people with disabilities?

JW: Here are the arguments that have been put forth: Assistive
technologies take a while to catch up with changes to technology. Once
the AT have been created, it takes more time for them to be
disseminated to users. For a variety of economic and other reasons,
people with disabilities are slower to upgrade. This is why we need a
backward-compatability requirement.

JM: At various meetings, people pointed out that upgrading, bandwidth
etc are issues for people with limited economic means. It was pointed
out that limited economic means are not a disability, just as being a
foreigner is not a disability.

JW: Some people feel limited economic means is a consequence of
disability, so it more likely to impact the disabled.

CS: Has this group come to a consensus on where this line is?

JM: This is my recollection from the Seattle meeting. Greg claimed
that economic means won't be considered as a disability

CS: Face-2-face meetings are biased towards those who can afford to
travel. Can we attempt to gain consensus on the list?

JW: It has never been classified as a disability anywhere. Disability
is related to the capabilities of the person, apart form the social
context. (inherent in them rather than a result of circumstance). The
issue is whether it should be taken into account as a consequence of
disability in practice.

CS: I understand that. Can we settle that question and base our
decision on whether to keep 4.4 based on our consensus.

GO: The description you gave is the medical model, but the social
model is more accepted now. I'm uncomfortable with settling for
medical model.
 
CS: The group needs to decide which model we accept

JW: One of the major issues under 4.4 had to do with assistive
technologies and the time it takes for them to track technological
developments. CMN also raised ocalization issues for AT as things
which slow down adoption of AT. EVen with economic issues aside, there
are issues of availability.

??:  asks JW to summarize non-economic rationale

JW: There is the problem of assistive technologies and the time it
takes for them to take advantage of new formats, APIs, etc. Also,
there is an argument that people with cognitive disabilities are in
less of a position to recognize the importance of upgrades or to do
the upgrading themselves. Changes to their computing environment can
be hard to deal with. Also, there are issues of internationalization
and localization. Even when AT supporting new feature becomes
available in English, localized versions take even longer to become
available.

CS: I'm fine with backward compatability as long as we can define it
in a way that doesn't go stale and doesn't require people to continue
to support Mosaic 1.

JW: If we are going to include this checkpoint, how can we define it?

GO: Section 508 completely sidesteps this issue. e.g. Javascript must
be usable by assitive technology. Can WCAG mention specific products
and versions?

JW: That would be questionable. We must be vendor neutral. And in 5 to6 years, how relevant will such a list be?

CS: Isn't this the same problem as "until user agents", and did that
document ever get updates?

JW: No, and part of the problem is having the resources to do that.

GO: Let me dscribe what we do as an organization. This is purely
pragmatic: browsers that are used by less than 1% are getting beyond
what we can support; browsers used by 1-5% will probably be included;
browsers used by >5% definitely. It gets more complex for AT. It is
very hard to get hold of the numbers for AT. Browser use numbers are
easier to get. In the end, we need to decide what AT to test with. It
has to be based on its use. We are more likely to use JAWS than Home
Page Rreader or Hal. We are more likely to use JAWS 3.7 than JAWS
4.01. It comes down to numbers in the end.
 
JW: There is also the issue that Greg raised a few weeks ago: suppose
we said we wanted technologies relied upon to be supported by
AT. Which ATs count? On-screen keyboard vs voice browser vs screen
reader vs screen enlarger? What kind of support is sufficient?

GSW: The Disability Discrimintation Act requires that you make web
site accessibility. You need to test with a variety of OS and
browsers. You can only be sued by people with disabilities.

GO: So how do you decide which OS, browsers, etc. you test with?

GSW: It depends on which company I am working for. It someone is
looking for an A or AA rating, I recommend Netscape 4 and above. For
an AAA rating, Netscape 3 and above.

JW: We still have the problem of how to write 4.4 so it will adapt over time.
 
GO: I'll work on a redraft of 4.4
GSW: I'll help

LGR: I am concerned that there is a conflict between compatability
with older technology and multi-media support

GO: Consider PDF files - need newest technology to make PDF files accessible.

LGR: I was worried more about uses of technologies like CSS, which
didn't work in Netscape 4, or techniques that depend on User Agents providing
ways for users to configure which content is displayed.

JW: Techniques need to say which level of which technology is needed,
e.g. HTML 3.2.

LGR: I'm concerned that we'll find that none of the techniques needed for
some checkpoints may be available with older technology

JW: This is an issue that will affect conformance.

GO: a real Gordian knot
??: you can kiss SVG goodby under these constraints

Received on Thursday, 28 February 2002 21:32:39 UTC