phone: Doyle Burnett, Lee Roberts, Wendy Chisholm, Michael Cooper, Matt Mirabella, Matt May, Ben Caldwell, Gregg Vanderheiden, Jason White, Bengt Farre, Loretta Guarino Reid, Paul Bohman, Andi Snow Weaver, Preety Kumar, Gian Sampson Wild, Avi Arditti, Ken Kipnes, Cynthia Shelly
IRC: Ben, bengt, wendyBOS
Patrizia Bertini, John Slatin, Roberto Scano, Eugenia Slaydon
no meeting 28 november - u.s. thanksgiving and ozewai
jw comments on andi's proposal re: 1.2?
pb i had comments on the list.
pb summary: don't know that enough research to say that always bad. if research to contrary, include as is.
pb voicing a concern.
gv there were some revisions that were posted (in the "Highlights").
gv could you clarify your question? if such a problem put in, but not sure there is a problem?
pb i don't need captions to understand video content, but i have watched foreign movies and read the captions.
pb generally, i can read captions and not have loss of understanding. even the cooking demo - is it necessary?
pb i feel i could read captions and understand what was going on.
gv for cooking shows, etc not usually a problem. only during a detailed training.
gv usually, if you click on them you can pause them.
gv in a videotape you can pause.
cs pause live streamed content?
pb before getting into live streams, since that is a bit diff concept, is there evidence that it is better to have simultaneous caption and demo, or demo then caption.
action pb do some follow-up research to answer question about producing captions (check with ncam, gallaudet, etc.) re: checkpoint 1.2
pk i have an example. we were giving a webex seminar. someone was using a screen reader. but we are using the phone to talk through the demo.
pk using screen reader to do something like captions. it changes from minute to minute.
pb to address my own concern, i will do some research. perhaps more appropriate to change the example.
gv the example is definitely a problem.
pb along w/the changed example, supply an example where this would not apply.
pb make it clear that this is an exception.
gv good point.
jw someone should take an action to rewrite the criterion so that it more clearly specifies the situation under which it applies.
db last week i did some research about the cognitive load. i found some that spoke to the amount of time someone's eyes might spend reading the captions.
db i think it pretty clearly showed that captions take the majority of the time.
action gv redraft checkpoint 1.2 success criterion
jw action on checkpoint 1.3?
jw several people had actions.
what is "seriously interferes"
gv how can we make that objective?
gv perhaps looking through a small whole, you see characters not words. the characters begin looking like something else when look at char by char if the background adds extra lines to them.
gv work on measures off-line?
asw we had some comments in the IBM comments. our feeling was that the min was that you can turn off the background.
asw couldn't think of anything at level 2. level 3 is "don't have any" or meet some criteria.
asw visual and audio things in the background.
gv text over background and whole ...
wac turn off the image (in the browser)
gv text remain.
cs good alt-text.
cs have other checkpoints about text in images.
cs part of doing a background image well, ensure contrast between text and color that appears when image is not loaded (if designed w/background image).
jw we're getting into user agent issues.
cs i could write scripts to turn off the background, but the UA does it.
bc svg example: turn off pieces of image interactively.
jw or written into the tool.
gv "unless the background image can be turned off..." techniques say "commonly available on browsers...."
cs commonly available? or just an accessible plug-in that will do it.
gv if not commonly available, people who have trouble reading won't be able to read.
jw in cases where UA has options for doing it, success criterion satisfied.
jw make it clear that any implementation support necessary to enable turning off of background is provided.
jw whatever features or elements in the content to facilitate turning off are provided. so the author has fulfilled what is there process.
asw if have a feature, then use it. if not, then don't?
gv if have a background image that doesn't interfere, (gv gives characteristics...)
gv shouldn't be excluded.
wac make sure that cascade can happen.
gv but users don't know how to choose from the cascade.
wac enable it to happen. let the tools become usable to take advantage of it.
jw don't accidentally build in a legacy.
jw make sure not dependent on today's limitations.
wac html techniques be tied more to today's implementations.
action asw rework proposal for checkpoint 1.4 success criterion
in internal draft, 1.4 has become 1.5. the question marks are no longer there.
not sure where 20 db came from.
jw someone should take an action to find a reasonable number.
asw how did the benchmarks get defined?
gv i can check research with hearing enhancement center and gallaudet tap program, ....
db i have a person down the hall i can ask
asw what about a length of time?
bf the example has question marks, but rule has solid numbers.
gv need to add question marks.
gv talking about low frequencies (at a recent meeting), i could be speaking at certain frequency but if filter out then could cancel out decrease volume.
gv what was 20 db could drop to 5 db and be intelligible.
db patrick is looking that up.
gv the difference needs to be at frequencies below X Hz to acknowledge that many people with hearing impairments it is the higher frequencies.
wac how have a value?
db like contrast. hard to tell what work for someone.
gv we're talking about a minimum. ramps can't make too steep.
gv set something as a standard that is reasonable.
mc in contrast we don't specific contrast values, we have to fall back on "most people agree sufficient contrast."
db patrick says for people with normal hearing needs to be 2 x's, for people with hard of hearing needs to be 10 x's.
bf twice as loud is 3 db.
gsw how would you test for something like this?
gv see it on your mixer.
cs what if you have background sounds playing and not using mixing equipment. you can create sounds in html w/out access to mixing equipment.
wac should handle similarly to visual, where you can turn off the background sound. if i am accessing through a phone, the noise of the street is too loud.
gv yes, handle similarly.
action gv take a stab at handling checkpoint 1.5 (was 1.4) success criteria 2 wrt audio backgrounds.
jw set minimum contrast requirements. at level 1 either min. contrast requirement is met or can turn off.
jw bring auditory and visual cases into parallel.
gv must be necessary to access w/out background. it might be a recording and can't turn off 1/2 of it. perhaps have separate version.
action gv and asw will both work on redrafting checkpoint 1.5 (28 august 2002 draft) success criterion (gv will send something to asw).
acronyms and abbreviations be identified at the "first instance" but on a web site, any page could be first instance depending on where someone comes in at.
wac thus, should be first instance on "page"?
lr if on a page and person follows an anchor fragment then even on a page, they might miss the first instance.
lr thus, every instance?
cs if can be done in markup.
jw arises in other contexts, what page comprises can depend on the device one is using.
cs true of things built from databases and content management systems.
cs any one might be the first paragraph in a different page.
jw at some point, we need to specify how they apply under these types of circumstances.
mc on the issue of abbreviations read every time, is that a user agent problem that we shouldn't worry about?
mc my interpretation is that it is something that the screen reader or user agent would be requested.
cs in printed documents, the first instance in particular scope (in an article or paper) the first is expanded.
jw might not be the user agent that ends up handling it. at any point from originating server to UA the processing could be carried out on the content (proxy servers, etc. that perform transformations).
jw the same holds true of other adaptation processes. we need to be careful about assumptions about the user agent responsibility.
wac perhaps we should focus on the final form.
jw but then with personalization...
wac enable those personalizations to happen.
cs sometimes you don't want to spell it out, e.g. snafu or dos
mm xhtml
wac i'm not talking actually spelling it out, i'm talking about a concrete example, e.g. acronym or abbr element in html.
jw could have a dictionary in metadata that contains all abbreviations/acronyms on your site.
jw thus, programmatically possible to associate an acronym/abbreviation w/its expansion.
jw in techniques, in html first instance marked w/element in other cases by means of metadata or other techniques.
mc but, the first instance approach: if you have a site about the american dental association's adoption of the american with disabilities act, you would have to expand in each case.
mc the ADA has adopted to ADA...
aa context
gv i'm beginning to worry this is not an accessibility problem. that's a problem for everyone.
gv we brought this up because of screen readers and others having trouble.
cs perhaps, "wherever you expand in visual, also do w/abbr"
gv what is the accessibility issue that someone with a disability has. these are not usability guidelines they are accessibility.
mc cognitive disabilities make that a fuzzy line.
mc although usability, accessibility for that group.
cs having that debate for a while. not sure have solved or that we can.
jw decided to shelve that contrast.
cs this is an example of writing style.
jw explicitly associate an expansion with each item.
gv too much.
jw it's simply a matter of requiring software to identify instances and determine expansion.
cs the way that you do is w/tags. it will make Screen readers read expansions on every one.
wac allow users to query for it.
resolution: ("first instance" of abbreviations and acronyms) we'll wait on proposal for 1.3 to see how programmatic access is rephrased, then rework so that it is parallel with 1.3.
gv we talked about the sound level, not sure it is needed at level 2 or 3. everything is captioned.
gv every show has people talking with noises in the backgrounds. if someone has trouble understanding...
mc wac and i talking about kick-starting the techniques documents.
mc coming from several points, i (as an evaluation tool dev) want techniques as well as content developer...so there are lots of users.
mc by working on techniques we can do some bottom-up development.
mc wac and I have been thinking about this and have a proposal.
mc first, think we need a requirements doc to help direct the work.
mc w/everyone's approval, i'll draft a proposal, run it past the chairs, and propose a conference call during the week of 25 november
mc a subset of people interested in working on techniques. sometime after thanksgiving, bring to the rest of the group.
mc today, updating. any feedback?
jw suggestion: requirements be checklist generation mechanism as well as techniques.
jw they are so closely related - e.g. extracting info from techniques. could affect techniques dtd.
next steps: mc will send a proposal and initial draft of requirements doc for techniques to chairs, then to the mailing list. plan a telecon to discuss the week of 25 November.
$Date: 2002/11/15 21:44:48 $ Wendy Chisholm