The technical requirements of WCAG 2.0 are driven by the needs of people with disabilities. However, the users of WCAG 2.0 are a wide audience, and the requirements it expresses must be in language that policy makers can understand, cite and adopt. While the WCAG WG does not set policy, harmonization of accessibility requirements helps drive demand for supporting implementations in Web applications.
JW WAC suggested that we work through examples to determine testability.
WAC Right - as discussed at the sept f2f.
JW two requirements: syntactic (to have a text equivalent) and semantic (if the text equivalent is appropriate). There are some example files
WAC describes the test files (thinks there are about 11 for checkpoint 1.1)
Action JS volunteers to go through initially
Action GSW, LR volunteers review and comment
JW Not determinative but gives us a good indication
JS What it will show us, what types of testing happen and what types of results and could help us figure out how to resolve differences. It is a judgement call. Some things will be easier than others. Help give developers how to decide what to listen to.
WAC Should look at sites to see images in context.
JS A few people and I judging a web contest, there were at least 3 opinions about what the alt on an image should be.
GSW Doesn't it cover more than images?
WAC Pretty sure the test files covers.
Action WAC - send list of files to the list and general idea of what to report.
JW proposes new success criterion:
5. Descriptions, captions and synchronized media equivalents have been reviewed and are believed to be both accurate and sufficient.
GSW Can you review real-time equivalents? Perhaps review the method?
JS Someone should have thought in advance about how they are provided?
GSW Assume some sort of human aspect.
JS If it is feasible.
CS Don't make people think it's required to have a real-time captioner next to webcam.
JW Perhaps have exceptions in the success criterion.
WAC GV had an action to clean-up the language from last week and send ot the list.
GV Did that and will send. Thought I already had. Related to the conformance scheme - if we have levels under checkpoint, it could be at a lower level that even informal web cams are captioned and described. At some point say "our site accessible except x and y." at level 1, talk about formal broadcasts and things that are commerical, even commercial video streams you are playing on your site even if you didn't create it. However, this concerned me, because the idea of "if it is cpationed and described an dprovided you must pass them on." that sounds more like a minimum level in a regulation. the next layer, you don't post any commerical that is not captioned/described. if you want to say have level 3 site don't put up stuff that isn't accessible. level 1 - suppor it, level 2 - don't have commercial that isn't. not defining accessibility as not including something, it would be included lower. however, don't have entire sites that are not accessible. i thought it would be something that would be done in conformance in next release.
WAC need to send to the list rather than edit right into document.
GV agreed, but haven't sent conformance proposal to the list yet so people don't have a context and this is clearly related to conformance.
CS I'm still chewing on the general approach. Look at UWashington home page, they have a webcam. Underneath it is a live weather report. It's an alternative approach for equivalent w/out a description of how many standing in the square, etc. Does captioning exist for streaming video?
WAC I sent a note to Geoff Freed. He responded that realmedia supports real-time captions; also, EITHER quicktime or windows media supports. He'll get back to me with an answer as to which one.
Where this discussion ended: GV's next draft will have conformance scheme and this issue will be covered there.
GV After this next draft, the ideas will be discussed and then put into the document, rather than put into and then discussed. The reason we are progressing that way is that so many things are changing right now.
JS Be sure to include and instead of and/or. It adds an ambiguity. If that's what we want, then we try to make the same phrase do 2 things. 1 goal: adopt because they understand. if another goal is to cite in discussion, that's a diff issue and is weaker than making it understand, cite, and adopt.
GV Do any one of the three or all three.
JS striking the and/or does not preclude them doing only one.
GV The or isn't for them, it's for us. We should make all three easy, not one or the other.
JW Also proposal to combine both points.
GV Nice distinction is that the first highlights policy makers the second balanced. It used to be 3, moved to 1 so pieces don't get taken out of context.
JS R2 that stipulates that although talking about R1, concern for policy makers understanding is not what is driving the requirements.
JW Right, then subsequent proposals. Need to decide what we are settling on. Nice to decide rather than go around another week. Unless we are not in agreement of the substance. Most of the comments seem to be wording rather than content.
GV cmn's latest proposal combines into one and makes positive:
The technical requirements of WCAG 2.0 are driven by the needs of users with disabilities. However, the users of WCAG 2.0 are a wide audience, and the requirements it expresses must be expressed in language that policy makers can use, reference and directly adopt as appropriate.
original proposal
R1: WCAG 2.0 deliverables should be more understandable and usable by a wider audience than was anticipated for WCAG 1.0, including policy makers. While the WCAG WG does not set policy, harmonization of accessibility requirements helps drive demand for supporting implementations in Web applications; therefore it should be easy for policy makers and individuals responsible for implementing policy to understand, cite and/or adopt WCAG 2.0 and related deliverables.
R2: We will try to express the technical requirements in language that policy makers can understand, adopt, and use, but technical requirements are not driven by policy; they are driven by the needs of users with disabilities.
ASW There are too many expresses. "The requireemnts must be expressed in language that policy makers can ..."
JS To anchor more closely to WCAG 2.0 "and its requirements"
ASW Is this something we can meet?
GV These are consensus statements not requirements.
WAC cmn's proposal does not express, "While the WCAG WG does not set policy, harmonization of accessibility requirements helps drive demand for supporting implementations in Web applications"
GV Add to the end.
JW With WAC's proposal, no one expressed disagreement w/substance. If we fix the and/or business and left it with the existing proposal, even though some people feel it could be worded better, no one has disagreed with it. Perhaps go forward with that than rework and another round of review.
GV I think it is nice to go with them in one statement. It flows as a complete thought rather than two statements that seem to conflict.
WAC Can we go with:
The technical requirements of WCAG 2.0 are driven by the needs of people with disabilities. However, the users of WCAG 2.0 are a wide audience, and the requirements it expresses must be in language that policy makers can understand, cite and adopt. While the WCAG WG does not set policy, harmonization of accessibility requirements helps drive demand for supporting implementations in Web applications.
JS In the first 2 sentences, users refers to two sets of users.
GV Repost to the list if we feel we have done anything other than editorial. My reading of this is that we have not changed that we didn't have agreement on. Does anyone feel we have changed the intent or content?
/* no response */
GV Does everyone feel we can move forward?
JS, LR yes... no other responses
GV JW, Let's send it out?
JW Yes. It is a draft so always possible to change.
Resolved: we'll move forward with theR1 language (as a single point) and try to publish on TR.
GV All checkpoints included, layers w/in checkpoints and a minimum set of criteria. Before, we said these all had to be testable (whether my machine or reliable by humans). Do we have two categories: testable and good advice? Does that mean that all "good advice" go into level 2 or 3 and never in level 1?
JS If we call it conformance then it has to be possible for people to conform.
JW All the levels should be testable. They can claim on the non-testable, non-verifiable claims if they so wish. At the moment, minimum and testable seem to go together.
LR The lang and doctypes, are easily machine testable, right?
GV You can test to see if they did but not if they didn't...unless you but the words through a dictionary. Authors could make statements, "it has been determined..."
JW If I make a claim for my own site, if my uni makes a claim on their site it is a uni procedure.
GV Companies have said that they can not do that. There might be legal ramifications against the statements they think are true.
JS An instance of something that wouldn't be subject to multiple human raters?
GV The language is simple.
JS It's not simple, it's as simple as possible.
WAC You can throw out all sorts of stuff then, like alt-text.
GV Syntax vs semantics. Can require an equivalent, but the appropriateness of it is subjective.
JW If they want a legal disclaimer, that is their decision.
/* missed discussion due to plumber interuption */
JS WAC, what is in conformance review? user testing?
WAC EO recommends that.
LGR You can't claim conformance if you don't do user testing?
JS if that is in place somewhere, there is a mechanism where a company can assert conformance for something that is fuzzy if they have user testing using good testing conventions.
GV If you require user testing, then must require 100-200 users minimum. The variety of people with disabilities, onset, etc.
/* missed more discussion due to plumber interuption */
GV I don't think we can have something that says "has been reviewed" and that is defined somewhere.
/* eeks. more plumbing interuption */
GV does anyone have other comments? /* no response */ Please post to the list any thoughts about how to deal with this. In the draft we will put out, we will put this concept about reviewed per site standards.
JS Presume we'll also make the demand that the review policy of the entity be publicly available.
GV We're only using this in places where people don't agree. Therefore, if people will challenge, there will be problems. If CNN wants to be accessible, if review is more than person who wrote it looks at it, then their page be behind anything else.
WAC But there is quality assurance in place on these sites.
GV right, their policy could be that late-breaking news gets cursory review and other gets different types of review.
$Date: 2002/04/18 22:01:55 $ Wendy Chisholma