21 Nov 2002 - WCAG WG Teleconference Minutes


Andi Snow-Weaver, Bengt Farre, Ben Caldwell, Cynthia Shelley, Gregg Vanderheiden, Jason White, John Slatin, Katie Haritos-Shea, Ken Kipnes, Loretta Guarino Reid, Matt May, Paul Bowman


Avi Arditti, Doyle Burnett, Gian Sampson-Wild, Lee Roberts, Roberto Scano, Wendy Chisolm


We are still searching for a phrase to capture the notion of mark-up language/API/data structure/information set/interface for exposing content to tools like assistive technology.

There was general agreement on Jason's proposal for conformance requirements for sites with multiple versions, and Gregg, Ben, and Cyntha are working on the wording.

There was acceptance of Jason's proposal for presenting conformance claims; while EARL conformance claims should be encouraged and made as easy as possible to generate, they should not be required. Jason will work on wording to incorporate into the Guidelines.

Action Items

GV, BC: Come up with an appropriate term for use in the document for the concept of interface/mark-up language/data set/...
JW : Identify places where this term is used/needed in the Guidelines
GV, BC,  CS: Work on language for the proposal on conformance requirements for content with multiple versions
JW: Work on language for the proposal on the requirements for conformance claims

Checkpoint 1.3 Proposal

GV: Need to say that the encoding is supported by assistive technology.
JW: I was trying to replace mark-up language, information set, data structures, meta-data, etc.
GV: It not helpful to use meta-data unless it is standardized. But I worry about inventing a new term because it becomes jargon. On the other hand, try to reuse a different term will mislead people.
JW: I worry about using "mark-up language". If we really mean mark-up language, we should use it, but if we mean something more general, we can't really redefine it.
GV: Seems like we need accessible as a key term.
JW: I'm concerned about the relation to guideline 5. At level 1, 5.3 lets author rely on inaccessible technology.
KHS: Why explicit encoding, instead of just encoding?
JW: It implies machine processable, rather than information that is implicitly present but can't be extracted reliably
KHS: Can we add an asterisk and draw people's attention to our definition of the term?
JW: What term would you suggest?
KHS: Continue to use "mark-up"
CS: API needs to be in there, too. "can be derived programmatically" is what we are trying to say.
JW: The concept appears in 1.1, 1.3, 4.1, 4.2, etc. We really need a succinct term to use consistently throughout. I explicitly don't want to use markup.
CS: It is too explicit a term. I understand what you are trying to get at.
GV: We need to get "accessible in there.
CS: If it can be derived programmatically, assistive technology can derive it, too
Gregg: What if it can only be derived by a programmer at the company that wrote it?
CS: There are APIs available?
GV: But the guideline doesn't require that.
CS: Available programmatically through a published API or mark-up language?
JW: My proposal would cover this set of mechanisms
GV: But we have to be careful not to use our new term when we only mean one thing. e.g, using meta-data for alt text for graphic images in HTML isn't ok
CS: But we can imagine a different language for which that might be appropriate
GV: if we add an "accessible" qualification, then the technology-specific techniques can expand on this
CS: 1.3 is at a lower level. it wants to make it possible to develop a tool to access the content.
GV: But if there is no tool, it still isn't accessible
CS: If I invent a new technology, and it makes the content available via an API,and I publish the API, I've done my bit.
GV: Accessible means it can be used by people with disabilities. If there isn't assistive technology, things are potentially accessible, but not yet accessible.
CS: 1.3 is about making the information available. The presence of tools is out of the control of the author
GV: We write a checkpoint in general terms, but with something specific in mind. We need to make sure that we aren't leaving loopholes that satisfy the checkpoint but don't reach the goals of accessibility.
CS: The proposal says "assistive-technology compatable mark-up".
GV: In the checkpoint or guideline?
CS: It is in the success criteria
JW: There is so much context here, we really need a short term for it
CS: I think the word you are looking for is "interface"
JW: Will people take that to mean API?
CS: API is one kind of interface; so is mark-up. I'm concerned that people would confuse it with user interface
JW: Who can take an action to come up with an appropriate term?
CS: Let's make up a placeholder word for it, and play with the concept for a while?
GV and BC will take this action.
JW action: Identify places where this term is used/needed in the Guidelines

Conformance Proposal

JW: If the content developer provides multiple forms or version of the same content, what is the conformance requirement? There must be at least one form of the document that meets the minimum requirements. But the developer can report the higher-level conformance of the other forms. The purpose of the proposal was to address this situation. If the developer provides the switching mechanism between the versions, that mechanism must meet the guidelines.
CS: If they are chosen via the page content. If they are chosen via User Agent, it needs to meet the UA Guidelines.
JW: Right. Discussion only applies when the content provides the chosing mechanism.
CS: Allows for final format, with graceful degradation to accessible version.
GV: Why is the second caveat necessary, that the way you choose it meets the guidelines?
CS: If the default version is not the accessible version, how to you proceed?
GV: You come to a page and it says you can get this in HTML, X, or Y, and you choose Y. You get there any discover it is inaccessible. You can always hit "Back".
CS: So hitting "back" satisfies the caveat. But you may have gotten there in some way that doesn't let you use "Back".
GV: If you choose an inaccessible version, the means to back out must be accessible and meet minimum requirements. On some pages, the Back button won't work  because you get redirected immediately.
JW: If the author provides the UI through which you make the selection.. Note that in device independence work, the selection is made via protocol negotiations.
GV: In the redirected Back button example, the author did not provide the UI. They just defeated the UA interface.
CS: Usually that particular error is accidental.
JW: We need a proposal to go into the Guidelines. Do people agree with the essence of the proposal?
CS: It seems reasonable, and more realistic than what was in WCAG1, where we just said to make a second page.
BC: I'm still concerned about the 3rd item about negotiations. Let's suppose we have a site in 3 technologies, and one is a Flash version of the site. Why isn't 5.4 adequate to cover this?
CS: This is making it accessible from the same URI, just making it more explicit that the way to choose is accessible.
BC: I was reading this to mean the entire interface has to be accessible
CS: No, just the piece that let's you do the picking.
GV: There are things the author can do that defeats the User Agent, like the Back button example. But the author hasn't create a choice interface, so it is not covered by this proposal. How do we forbid things like this?
JW: What I do want to allow is the case where the choice is entirely carried out by content negotiation. That is what the technologies in this area are heading towards.
CS: The configurator screen in the user agent needs to be accessible.
Action item: work on language for this proposal to go into the document. Gregg and Ben and Cynthia

Conformance Profiles

JW: I posted a proposal that a conformance profile can either be included in the frame, or linked to. Al Gilman proposed disallowing textual conformance claims, to which I objected.
CS: Can we provide standard text for inclusion in text version of claim? The question is whether it is a burden to require EARL.
JW: Ease of automated processing the motivation for Al's proposal to disallow text. Lisa volunteered to develop tools.
CS: We could provide hand-crafted metadata for level 1, 2, or 3. Then people could just post this or a link to it, comparable to applying logo. WE can also provide XSLT for converting to text.
JW: We should provide that, even if we permit other ways of making the claim.
CS: Not sure we can really require metadata. We can encourage it and make it as easy as possible.
JW: There is no obligation to make a conformance claim, more or less publish it. If you want to make a conformance claim, should metadata be the only way to do it? If not, what are other acceptable ways? And what about ability to link?
CS: Posting canned claims that people can link to on W3C site would also be a good idea.
JS: I think it is a bad idea to require metadata. It imposes a technical burden. It also turns the conformance claim into an arcane technical object that can only be understood by people with deep technical knowledge.
CS: I don't think we can require this, but I think we should encourage it.
JS: I just don't think this is pragmatically a good idea.
JW: Most of the checking tools will be generating the metadata anyway.
Action: Jason to incorporate this proposal into the discussion of how to make a conformance claim.
CS: We should provide 3 canned EARL statements for the 3 conformance levels and XSLT to translate EARL statements back to checkpoint text. Would also be nice to provide a tool to generate checkpoint by checkpoint conformance claims.
KHS: Dublin Core is working on how to use existing elements for making accessibility claims.

$Date: 2002/11/22 00:29:51 $ Loretta Guarino Reid