Regrets

Structure and presentation of guidelines and 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

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