21 Nov 2002 - WCAG WG Teleconference Minutes
Present
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
Regrets
Avi Arditti, Doyle Burnett, Gian Sampson-Wild, Lee Roberts, Roberto Scano,
Wendy Chisolm
Summary
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