08 Jan 2003 - WCAG Techniques Teleconference Minutes


Wendy Chisholm, Chris Ridpath, Matt May, Bengt Farre, Michael Cooper, Ben Caldwell


Roberto Scano, Ken Kipnes

Requirements for WCAG Techniques

add trainers to audience

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.

additional 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.

localizing techniques

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.

Need for structure in WCAG

Issue: wcag (guidelines and checkpoints) will need more structure,

action WAC and BCC: look into using xmlspec for WCAG 2.0 guidelines and checkpoints

Labeling testability

proposal: label techinques as machine-testable, human-testable, or not testable.


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.

Techniques only apply to WCAG 2.0?

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)

Relation to WCAG 2.0

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.

Retire dependent technology documents?

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

Combining technologies and completeness

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.

"provide alternative formats?"

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?

Documenting user agent and user issues

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?

Positive and negative test cases for very techniques


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

Example implementations

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"

Detail about checklists

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

Next meeting and agenda

We will meet again next week (15 January 2003) to discuss

PF request for CSS reviewers

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