JASON: Notes on WCAG 2.0 Sufficiency/Checkpoint Criteria
GREGG: Comments on WCAG 2.0 Sufficiency/Checkpoint Criteria
GV When houses on the block all look the same, children get lost. If don't have differences, people will confuse. Therefore can't look exactly the same everywhere.
JW The idea in writing this, every element type will have a uniform style applied to it. Usually via style sheet. Sometimes not the case. Consistency understood in terms of hierarchical divisions. Every element should have its own style properties.
WC In CSS draft, identify function of terms or function of pieces, each piece have similar presentation throughout site.
GV Agreed.
JW Reading too much into it GV.
GV So all bathrooms should be laid out the same.
GR Different aspect: braille should always be to the right of the objects.
GV We're all agreeing, but we're writing sufficiency or requirement language. Doesn't matter intent, but the actual words. Instead say, "when setting up type structure, use controls consistently so that users can predict or know or behave way.."
WC We separated behavior from presentation.
JW Think this would work if redrafted.
ASW problem with the word must.
GV We struck on this before, if this were to be a P3, can't use must language in a lower priority checkpoint.
JW Perhaps rewrite that not every element has to have consistent style.
WC More to do with function. e.g. W3C copyright.
GV What if nav always on top, on some on bottom, would that site be not be AAA b/c nav bar moved?
JW Yes, would be a problem.
WC Although, in future, depend on semantics. Won't have to worry so much about positioning.
GV Instead of having a requirement...
JW Examples.
GV Statement of intent, pages should be generally consistent layout so that easy to locate info.
JW Propose "Intent" for each checkpoint.
WC Similar to rationale that I already took as an action to put into the draft. We need to create tests and then reach consensus on which we think conform and which don't.
GV Absolutely great idea.
JW Need next draft first.
GV Before the next draft, put in things that we are comfortable with.
GV Are these techniques or requirements?
JW Add these as examples under the checkpoint, others for positioning and labels be added.
WC Therefore some don' thave requirements?
GV Might find that we can't set them for all. e.g. clear and simple language.
WC Need to give guidance as to how to determine if met. If a judgement, what quesitons ask?
ASW removing checkpoints if can't determine?
GR Minimum for 3.2 is ensure distinctions captured in markup.
JW Yes, but redundant w/1.5
Resolved: put in as examples, along with examples of positioning and labels.
GV Same issues.
WC Change in text of checkpoint, basically what we had in 1.0 - include audience. Therefore: a. identify audience, b. identify reading level, c. test that these match up.
JW Nothing in there that it relates to complexity of content.
WC Also want to capture - make use of the web. Use meta data to associate simpler versions, i.e. for WCAG - quicktips or work from IBM or other simplified versions or other EO work...also translations.
GR Link at top to checklist.
GV Not an equivalent for people with CD/RD/LD. How relate to other checkpoints?
JW WC Proposal was this being reworked to mention audience and context. The requirements under checkpoint: identify audience, use appropriate language, take into account complexity, then make sure that met requirement.
WC What about link to simpler content - examples?
GR links are "if all else fails" metadata something different.
GV We're getting into "if you want to make things simpler" instead of "if you want to make it accessible."
JW Agree make it more usable, but that it doesn't make the document more accessible.
WC This will go on the open issues list. A portal's content is their organization of content, not their own written content. Many sites combine content. Content is more than a static page, it is blurring. It is applications. Metadata and annotations are important pieces of content. Linking to other sites - part of content. Some of this is usability, but the usability/accessibility issue is something we still have to figure out.
GV Because there is no bright line, it is difficult.
Resolved: WC Proposal was this being reworked to mention audience and context. The requirements under checkpoint: identify audience, use appropriate language, take into account complexity, then make sure that met requirement.
WC: GR, PB, and I discussing coordinating with Chris and Josh about test files.
Action GR and WC (and anyone else who is interested) - create tests and bring discussion to group to determine which conform or not. Also, see if can coordinate with Josh and Chris on creation of test files for ER.
GV These are techniques.
JW Are the set of items sufficient to satisfy the checkpoint and are they required. 2 different things. Any obvious omissions? counterexamples?
WC "illustrations" is
GV multimedia means graphic and sound. it says you must illustrate every concept with a movie. this is unreasonable.
WC We don't state that. that's the point of this exercise. what does it take to satisfy it?
JW The use of multimedia is inconsistent with all of the other documents, it has to include graphical, multimedia, and etc.
JM People who are working in 508 has a clear idea of multimedia since defined in the law.
JW That's one country's view. We're concerned about consistency within our documents.
GV "non-text presentations for concepts presented only in text" - then can use multimedia or other...auditory does not count, it has to be graphic. if that's what is intended then we should say graphic. Not sure of the intent. Want to leave 3 questions: is a page accessible if only some of the ideas on it are accessible or does the whole page have to be accessible? previously, not ok for some parts of a page to be accessible. if the answer is no, then this requirement would have to say that every concept would have to be represented in graphical form or page not be accessible unless we're talking about usable.
JW If we're going to include this checkpoint, it will lie more along the lines of non-text presentations can help clarify meaning, and they are useful. We don't have consensus beyond that.
WC But, for some people, this is necessary to access the content. /* reminds people of the discussion that I sent re: this checkpoint to the list last week. lots of axes and possibilities. how do we define "most"? */ Charles had propose if you describe relationships or data, clearly can illustrate.
GV But does that really help people with CD/LD/RD?
GR Yes. the data is put into graph to help people process.
JW Someone with a CD/LD would not understand a scie
WC From Anne and my discussion last week, the intent of our people pages was to give people a better idea of who we are. They don't have to understand every concept on the page. However, they have some idea of concepts: who we look like and some things we are involved in (through the logos).
GV Yes, perhaps there is a misunderstanding about how much is needed to illustrate to make it work. We need to create a gallery of example and if people think they go one side or the other. To determine if we're all on the same page or where we differ. Figure out the difference between our words and our intent. You can't say thing precisely, in the normative part I would like to err on the side of flexibility, then in the techniques we should err on the side of lots of examples for how to do it.
WC I would like to continue discussion with Anne to determine if I am understanding what she is saying.
GV We ought to greek the page and see what info people take from it. Comparison tests to determine if guidelines making a difference or not.
WC Have the minutes from the F2F, can pull out questions to move forward on the discussion. This was one thing we discussed: usability of them versus the effectiveness. Wrestled with CSS draft to come up with criteria. Think intent and ways to test are important. I can write "these are the ways that I know how to conform, but here's what I'm looking for..."
JW For guidelines 1 and 2 we were able to come up with criteria, it's 3 and 4 that we're having trouble with. Therefore, we'll have to reserve judgement.
Resolved: next week with new draft, come back to next week.
CSS
Techniques for Web Content Accessibility Guidelines 2.0
W3C Working Draft 16 July 2001
Issue Tracking
for CSS Techniques for WCAG 2.0
Open Issues
Did not discuss this today, but please review and comment.
Timeline: July through November
Did not discuss today, but please review and comment.
Thursday, July 26th, 2001 @ the usual time, on the MIT bridge +1-617-258-7910.
Telecon Details: All WCAG 2.0 conference calls are on the MIT bridge
+1-617-258-7910.
Meetings are held Thursdays from 4:00 to 5:00 PM Eastern USA Time (although
may run until 5:30 depending on the discussion).
Last Updated: $Date: 2001/07/20 17:38:26 $
by:
Wendy Chisholm or Katie Haritos-Shea