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
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
$Date: 2002/03/01 10:03:01 $ Loretta Guarino Reid