Wendy Chisholm, Chris Ridpath, Matt May, Bengt Farre, Michael Cooper, Ben Caldwell
Roberto Scano, Ken Kipnes
issue: these documents are technical and should not attempt to meet the needs of non-technical people. that is EO and others job.
proposal: trainers are an audience, clarify that these are not *the* training materials i.e. that groups such as EO will use for less-technical audiences.
issue: additional audiences are other WAI guidelines since they will depend on these techniques to develop their own techniques. also, I18N and other groups might want to draw from them as well. we could have a unified document for assessing content. need to coordinate is recognized.
proposal: publish to TR then send request to review to other groups.
proposal: add a requirement in the "structure" section that says something specific about the need to keep other groups in the loop.
issue: will there be techniques that apply to only one locale? this might be needed (or very useful) for translations. i.e., localized techniques might only appear in the translations for that locale.
proposal: should be possible to localize the techniques (not a must). i.e., needs to be a way to indicate (via a term in the schema) *if* a technique is localized to some locale. perhaps by using xml:lang on any element. likely an issue (and desired piece) for I18N.
Issue: wcag (guidelines and checkpoints) will need more structure,
action WAC and BCC: look into using xmlspec for WCAG 2.0 guidelines and checkpoints
proposal: label techinques as machine-testable, human-testable, or not testable.
issues:
open issue (for WCAG WG): say in tech-req, "testability of techniques will be labeled, not clear the best way to do it. possibilities: "machine or human testable" "machine-, human-, machine+human-, not-testable"
chris r objects to "untestable" - everything must be testable since humans can perform tests either alone or in conjunction with tools
open issue (for WCAG WG): defn of testability needs more interpretation.
issue: do these techniques only apply to WCAG? can we make the source available? if so, then someone could take source and regenerate based on needs. in the schema, the applies-to element identifies both checkpoint and success criterion. someone could map checkpoints to 508 paragraphs or whatever set of guidelines they want to map to.
issue: should one map every country's 508 ??
if someone wanted to they possibly could. we're not saying we will do it, but that it could be possible for someone ELSE to do.
w3c process issue: can we make the source available? (action WAC: research answer)
proposal: in intro (to requirements for techniques), mention "requirements for wcag 2.0" and say that techniques help satisfy the requirements as well as inherit (most of) those requirements.
issue: where techs work together, put the techniques of the dependent technology in the host technologies techniques. would css (a dependent technology) be retired?
not necessarily. css-specifics would stay in css, but bulk in host tech (e.g., html, xml) e.g., html techs on relative sizing would link back to css doc (chapter on sizing) where the relative sizing is being controled by css
issue: some guidelines will not apply to any technology, e.g. write clearly is not technology-dependent thus goes into core.
proposal: techs can be complete if there is some combination of documents that implements every checkpoint. e.g. core+html+css
issue: can you generate a checklist that leaves out some checkpoints? thinking about different technologies: PDF, Flash, SMIL, SVG, HTML, CSS... in particular, SMIL might not be able to address all techniques.
proposal: that for each technology if the tech cannot meet a checkpoint refer to another technique/technology that can satisfy it OR say that this tech can not meet checkpoint/criterion X.
issue: are we saying, provide content in alternative format?
open issue: are we saying, provide content in alternative formats for technologies that can not satisfy all of the checkpoints?
issue: what about user agent issues (e.g., tabindex doesn't work in many browsers) and user issues
open issue: how do we address user agent and user issues?
issues:
proposal: we must have positive test cases for each checkpoint, we should have negative test cases for each checkpoint.
proposal: add something about developing test cases in coordination with AUWG
issue: are example implementations diff from test cases.
yes - and part of WCAG 2.0 implementation testing. might not be live sites, might be case studies.
proposal: add an "or" to last bullet of testability that says "or descriptions of implmentations"
issue: Ben expected to see more detail about checklists
agenda item for future call: figure out detail about checklists.
a section to describe specifics of generating checklists
We will meet again next week (15 January 2003) to discuss
request for volunteers to help PF review future CSS spec for accessibility issues
contact Wendy privately if you are interested.
$Date: 2003/01/09 19:57:57 $ Wendy Chisholm