Lee Roberts, Avi Arditti, Lisa Seeman, Matt May, Wendy Chisholm, Jason White, Bengt Farre, Doyle Burnett, Gregg Vanderheiden, Ben Caldwell, Roberto Scano, Katie Haritos-Shea, Cynthia Shelly, Paul Bohman, John Slatin, Loretta Guarino Reid
John Slatin (partial), Gian Sampson-Wild, Ken Kipnes, Patrizia Bertini
We started out with a discussion about which aspects of this checkpoint are testable. We also discussed what we mean by "testable."
A few definitions of testable that were stated during the discussion:
We then rehashed some of the previous discussion about checkpoint 4.1. Many people feel that the success criteria are not testable and therefore the only thing that could be testable in relation to 4.1 would be testing for inclusion of a review statement. However, we agreed not to put review statements in Minimum level success criteria.
There was also debate about inclusion of 4.1 principles in testing tools.
Some feel that 4.1 criteria are testable, but putting burden on people. That an author could test for a simple, more common word (there are databases). Also, tools could contain simulations and help users step through to figure out conformance.
We also debated what the tool would test for: if a review had been conducted or if 4.1 is satisfied. someone asserted: w/out a conformance claim a site can not be testable (since the claim is often the only way to test that human tests performed).
Then, we debated about 3rd party testing.
When we realized that 4.1 is different and should be treated as such, several possibilities and proposals were suggested. The bottom line is that there is agreement that 4.1 can be satisfied with a review requirement.
issue: if we find the right wording are we comfortable with a review? can 4.1 be handled differently? leave it in, but say "this one is not testable like the others, but here is the best guidance.""
proposal: a statement that "reviewed with these things in mind..." but not that it passes in some fashion.
proposal: be explicit that these are not testable.
proposal: front load, make it an overarching principle?
proposal: a box that contains a variety of design issues that are overarching and need to be considered. (e.g., the screen-shot example from last month, a web app could be accessible but not usable.) general principles could be stated but not made prescriptive.
proposal: you are consistent with a style guide
opinion: word "intended" can't be used since people may not intend for people with disabilities to use their sites.
opinion: variations in the types of cognitive disabilities and the needs of users with these variations is impossible to generalize and codify.
proposal: change to "The words and language structure are preferred to be in plain language or likely familiar to the intended audience"
question: The content should not be limited, sometimes these discussion focus heavily on information passing without saying so, perhaps this should be clarified ?
proposal: general metadata about the abilities people need to use the site (e.g., enter information in forms, read, etc.)
proposal: say "people with disabilities in intended audience" and make it clear the types of disabilities that are likely to be in your audience (e.g., dyslexia, etc.)
possibility: my audience is people who can deal with complex text in this form.
example: Financial Times online... it could be good for intended audience but not readable and understandable for other people (not only people with disability)
opinion: can not write in a way that it works for all people.
opinion: all we can do is ask people to consider it.
proposal: level 1 success criterion is a review requirement.
amendment: based on the following considerations... or "you have considered the following..."
or "content has been reviewed against the following condsiderations..."
key supplment to WCAG is "how people with disabilities use the web"
action lisa seeman: review "how people with disabilites use the web" and make sure adequate scenarios for cognitive disabilities.
proposal: include informative section describing types of disabilities that are part of intedned of audience.
proposal: we could change the point with "The words and language structure are preferred to be in plain language or likely familiar to the web site audience that could be with or without disabilities"
action lisa and ben: work on language for informative section of checkpoint 4.1 (that explains different type of abilities in the audience)
action avi: rework proposal based on this discussion and input from the list.
issue: if a review requirement then testability of each requirement does not appy.
proposal: At level 3 i think is wrong to put "or" at the end of all the three point. I suggest to change it with: "You will have successfully met checkpoint 4.1 at level 3 if you respect one or more of the follow points"
support for this change
gregg makes several proposals for changes in language. (can't capture them all)
others feel that declarative sentences are easier to understand.
proposal: review the content against/taking into account certain design principles such as, - page titles... (then can use simple declarative sentences)
proposal: take into consideration, these principles of clear writing...
issue: we can not declare that this is "clear writing"
proposal: in Level 3 point 2: "A controlled language is used" i think "controlled" must be explain well
issue: should not look like success criteria but good directions.
consensus: "you've reviewed the content with the following in mind: " (avi will work into a new proposal)
Processing the comments received since the 22 August 2002 draft is slow going. If you would like to help , please review the summary of comments and contact Wendy.
$Date: 2003/01/14 20:33:54 $ Wendy Chisholm