31 Oct 2002 - WCAG WG Teleconference Minutes


(phone): Matt May, Matt Mirabella, Bengt Farre, Gregg Vanderheiden, Ben Caldwell, Andi Snow-Weaver, Jason White, Eugenia Slaydon, Wendy Chisholm, Avi Arditti, Preety Kumar, Cynthia Shelly, Ken Kipnes, Doyle Burnett, John Slatin

(IRC): MattSEA, Zakim, Ben, mvittoria, wendy, bengt, rscano


Loretta Guarino Reid

Structure and presentation of guidelines and checkpoints

wac a few related issues:

wac 1. style of checkpoints vs informative info (people want to scan checkpoints)

wac 2. the informative info "gets in the way." is that because style in the way?

jw there is a style issue. does anyone disagree?

asw i have to print things off. i highlighted checkpoints.

jw in my proposal, disagree with separating out into a separate document.

jw link to it from the beginning. the principles and checklist go through W3C process, be published together.

jw support asw's suggestion that should be clear web page with full details and links to relevant documents (techniques, checklists).

jw min checklist contain only normative info

js agree. what is good about guidelines is that the underlying principles are explained.

gv also support. also useful to have a document that comes fully expanded but can ask it hide info.

asw earl commented that the rationale be placed right after the checkpoint. think it is a good idea. if you understand what you are trying to accomplish, the success criteria make more sense.

db i agree.

js agree.

rscano (on irc): i agree too

mvittoria (on irc): me too

gv rationale usually applies to guideline.

gv separate success criteria from checkpoint?

asw not all of the informative info. only what ej requested.

asw after each checkpoint "what does this do? why am i doing it?"

asw just that piece of it (benefits). help people understand success criteria.

mvittoria (on irc): also with examples.

asw try it on one to see what it looks like.

MattMir if guidelines in XML, then use XSLT to transform however you want.

jw yes, the markup is good enough to do that.

rscano (on irc): i think examples could be put in another area, like the new beta version of HTML Validator (http://validator.w3.org:8001/)

jw try andi's proposal in next draft?

The phrase "not expressed in words" as used in Checkpoint 1.1

asw said, "There should not be a success criteria for non-text content that "cannot be expressed in words". Checkpoint 1.1 begins with the phrase "For all non-text content that CAN be expressed in words". Worded this way, the checkpoint does not apply to "non-text content that canNOT be expressed in words". and someone else said, "if non-text content, can not be expressed in words" but success is a label, e.g. "words" is confusing.

js identifies but not equivalent

pk ascii art?

asw example would be: a symphony, mona lisa

asw can label but can't make equivalent

js a long description is not an equivalent? say it is a description not an equivalent.

asw we could either change the checkpoint: for all non-text content provide a text alternative

asw then in success criteria leave as it or do 2 separate checkpoints

js like change to "text alternative" seems more accurate

aa, pk, db agree

rscano (on irc): agree

bengt (on irc): yup

jw it suggests that it is a substitute, whereas an equivalent is that they achieve the same functionality.

jw the primary form versus a secondary form. that is an underlying though in the terminology.

js maybe we want "equivalent text alternative" it is important to ask people to come as close as they can to equivalence, but a fundamental contradiction.

js data is not equivalent to a graph

gv function is the real key.

gv i like equivalent better than alternative. it provides the equivalent information.

jw the current text tries to distinguish where possible or not.

js asw's and others issues, it should be clarified.

rscano (on irc): we could change it in "non-text content that can be expressed in words has an equivalent text-alternative explicitly associated with it"

wac reads definition of "equivalent" from WCAG 1.0

Content is "equivalent" to other content when both fulfill essentially the same function or purpose upon presentation to the user. In the context of this document, the equivalent must fulfill essentially the same function for the person with a disability (at least insofar as is feasible, given the nature of the disability and the state of technology), as the primary content does for the person without any disability.

MattMir - does that imply that the equivalent is more than the same function? if have a symphony that the equivalent should be more than the graphic?

MattMir primarily the purpose.

jw the equivalent should not go beyond that

gv does not need to go beyond

jw identify what it is but there's not much point in reproduce functionality where it can not be

MattMir like "text alternative" and in success criteria define difference between equivalent, description, etc.

gv if describing does not fulfill the function, stop at a label.

js author using to express feelings of joy, perhaps use different text equiv that express joy in some other way.

gv it's self-fulfilling. if expressed in words, they should.

js suggesting ways it could happen.

jw seem that we want to say what we've said, but clarify it so it doesn't seem to contradict itself.

action MattMir - draft a proposal to address the clarification issues of "equivalency" in checkpoint 1.1.

jw should not depart from phrase "text equivalent" unless have a compelling reason.

Compound success criteria

wac outlines another issue from earl, that some success criteria are collections. perhaps separate out into several statements?

js plus an "etc"

jw the list has to be open. we can provide examples. what is the best way to make clear that it is open, but provide sufficient examples?

wac two issues: open-ended versus clarifying what is needed.

gv "users should be able to access headers" rather than "associate them"

gv made up example: technology x knows about headers b/c of some mechanism. so whenever read cell, get the header.

gv any table, they need to figure out the headers. kind of getting into something that is not only html specific but screen-readers of today specific.

gv navbars, even if do in another technology, have an equivalent...perhaps navigation blocks.

jw in xhtml 2.0 "navigational menu" - to be non-visual.

jw interesting case when author doesn't supply and it is generated from the structure.

jw in which case the author doesn't have control...

jw my concern an open-ended list of items and don't want to be technology-specific in examples.

jw want to indicate the broad nature.

jw as techs change some may become more important than others.

js adding "including but not limited to..." in front of the list suggest open-endedness. split out.

jw single success criterion with individual items.

wac people might feel more at ease once we have tech-specifics in place?

db have a checklist, let the readers know it is not exhaustive.

jw no, leave the text as it is but take items under 1.3 and make into itemized list.

pk on 1.3, "headings, paragraphs, and lists..." we're citing that in the examples.

jw yes, in examples also.

pk just leave in examples?

pk they are meant to illustrate.

pk if look at other success criteria, are there lists?

wac then perhaps break into separate success criteria/

js worried that "derived programmatically" is too technical.

js perhaps describe the end result trying to achieve.

js "assistive technologies can recognize these things" or "get at the relationships"

cs also important to have rigorous text?

js as long as there is something somewhere.

wac a "guide to the guidelines" - something to work with EOWG to develop.

jw 1.3 is technical if authoring doesn't do, then the only way to satisfy is to intervene and satisfy yourself.

js even if the authoring tool does it, you have to know enough to ask it.

jw that's under 3.1.

jw adding structure.

asw even people who are technical do not get it the way it is worded.

asw it means "code it properly in html"

cs that's where html techniques

cs it's more broad, it's using the standards for whatever technology.

asw there might be a better way to word it so can get it before they go to the tech-specific.

pk if put in more direction, sometimes it can cause confusion for other technologies.

asw not suggestion put more html-specific wording, but there is a problem with the way it is worded.

action PK play with the wording of the 2nd minimum level success criterion of 1.3 to see if can break into separate success criteria.

action asw and cs comment on or discuss or review PK's proposal

"dual simultaneous attention"

wac reads asw comment, "Where possible, provide content so that it does not require dual, simultaneous attention or so that it gives the user the ability to effectively control/pause different media signals " sounds like success criteria.

wac add it as success criteria? if so, where?

gv agreed.

js "dual-attention" bothers me. it is confusing wording.

pk pls clarify?

gv if something is captioned, "in order to diffuse bomb, you must do this while that happens" you either watch person or read captions.

gv have to freeze captions to understand. sometimes people looking in 2 places at once.

js there may be situations to read caption and watch action on screen.

gv either freeze material or don't have to read at same time

js i sent wording to the list. i can dig it up.

js agree should be success criteria.

gv should be a 2 or 3. if doing a tv broadcast, if no way to freeze...

jw important for accessibility. probably 2. not include "where possible" then becomes non-testable.

rscano i agree

gv then all those sites can never get above level 1 if do live.

gv do something similar to time-delays. if you can't tell people need more time (auctions), perhaps places (live, non-bufferable programs) where you can't allow them to freeze.

jw exclude live broadcasts in the success criteria.

bc already have 2 exceptions at level 1. why not have another? :)

gv keep exception if generic as long as not so generic.

gv e.g. can't freeze at movie theater. want to be careful that...

jw content is freezeable, they choose not to.

gv not an author thing, at the user end.

jw as long as it is freezeable...

gv becomes a UA thing. if sent at quicktime and perhaps lets you freeze but using XYZ video viewer and it doesn't allow freeze...

bc can you provide it in a way they can view it again?

gv don't let them pick up the stream. can't freeze webcast.

asw that's where we mix up content and delivery method. what does the author have to do vs the delivery method

asw e.g. i have tivo and i can freeze live tv. someone could deploy for web cast.

jw we are only dealing with content issue.

asw we keep getting hung up on.

gv then the whole thing is mute. "either do this or allow to freeze" and always something that can freeze it...then why add it?

asw i buy that.

jw if the tech has a setting that prevents freezing.

gv maybe at level 3, "where possible avoid the need for simultaneous" then don't worry about freezing. say then show rather than overlay.

wac likewise, make primary audio track directly accessible. e.g. instead of relying on audio description to provide info about "i use this, then that" say, "the cat does this..."

action asw: draft wording for new success criteria at level 3 for checkpoint 1.2.

$Date: 2002/11/02 05:59:28 $ Wendy Chisholm