04 December 2003 WCAG WG telecon minutes

IRC log: http://www.w3.org/2003/12/04-wai-wcag-irc.html

Review draft: http://www.w3.org/WAI/GL/2003/11/18-f2f-review-draft.html

Present: Mat Mirabella, Michael Craddock, Doyle Burnett, Yvette Hoitink, 
Wendy Chisholm, Mike Barta, Ben Caldwell, Loretta Guarino Reid, Jason 
White, Matt May, Gregg Vanderheiden, Andi Snow-Weaver, Avi Arditti, Bengt 
Farre, Roberto Scano, Kerstin Goldsmith

Regrets: Cynthia Shelly, David Donovan, Roberto Castaldo, Patrizia Bertini, 
Maurizio Vittoria

Summary of action items:
1. action: editors add an example to the unicode guideline about hard to 
read font. due to UAAG the UA could swap font.
2. action: wendy, loretta, mat, gregg, doyle work on visual contrast 
guideline(s)


Topic 1: Guideline 1.6 in visual presentations, make it easy to distinguish 
words and images.
http://www.w3.org/WAI/GL/2003/11/18-f2f-review-draft.html#visual-contrast

Several issues with this guideline and its success criteria
1. "easy" is subjective (although this is a guideline not success criterion 
and thus does not have the same testability issues)
2. level 2 sc (proposed wording): when displaying text against a 
background, provide a method to make the contrast between foreground and 
background greater than ____ as measured by ____.  This success criterion 
could be testable, if we can fill in the blanks.
3. Is "provide a method" needed in the success criterion? or leave it as 
"...make the contrast between..." or "it must be possible for the viewer to 
obtain contrast..."
4. "when displaying text against background" talking about text or raster 
image of text?

The 4th point became the primary discussion in order to clarify the goal of 
this Guideline and success criteria.  For example, if the user is able 
to  select text (to create contrast via highlight mechanisms), does this 
satisfy the guideline?  The user could then copy and paste the text into 
another application to read it. Does selecting text get rid of the 
background image?

Using selection is not what is intended, instead the user should be able to 
change colors and/or turn off background images (in HTML).   In SVG, Flash 
and PDF, what are the requirements?

Perhaps we say at level 3 - be readable (by default). level 2 - user can 
make it readable.

This raises other questions such as:
1. Can an author do anything that would prevent author from turning 
off  background image?
2. Do we assume UAAG is implemented and therefore can assume that the 
ability to change settings is available?

WCAG 1.0 has "until user agents." in the past we've said, "user agents 
should do X, but they don't so authors have to do y." at some point it 
would be ideal to say "these are the author responsibilities (x,y,z) and 
these are user agent responsibilities (a,b,c)."  Ideal to constrain author 
responsibilities as much as possible to prevent us from getting lost in the 
relationships. Even if this explanatory, it should be able to help us reach 
decisions and help us show others how reached them.

Returning to the SVG/Flash discussion, there were several questions about 
pulling the text from the markup/file format.  We need to do research in 
this area.

Regardless, we want to describe how content should behave without knowing 
what generated the content.  Thus, at level 2: material should either have 
contrast or have a way to create that condition.

Discussing how it should behave, we wondered about:
1. What about dropcaps? frillwork makes it unreadable to person with low 
vision.  We don't say anything about fonts being recognizable. i.e., i can 
use wingdings and that's a font.  in svg i can have a word, change first 
letter into something that is not easily recognizable as a character. it 
can have background and other features. it can be ornate. illuminate it and 
can create a font that is embedded (in svg) screen reader could read plain 
text, but if look at it...change to readable font by user preference. so, 
at core it is a letter. similar to embedded fonts in css. can apply to just 
the first letter. it's still overwritable.  this is an issue for pdf. fonts 
are drawings of characters. in pdf, critical to know what character a glyph 
represents.

2.  Are we trying to address issue of background obscuring what is there or 
how readable the default font is?

3. Do these need to be covered separately or in the same guideline? Do we 
need to cover both of them? Have we already covered the issue in the "map 
to unicode" guideline? if not readable, still map back to unicode. No, that 
is for instances where it can not currenlty be mapped to unocide, but these 
characters (although heavily illuminated) would be mappable. partly, user 
agent issue. perhaps draw attn to fact that depend on ua guidelines.  once 
represented in unicode and assuming it is valid, then css could handle it.

action: editors add an example to the unicode guideline, about hard to read 
font, due to UAAG the UA could swap font.

Another interpretation of the current wording ("provide a mechanism") is 
that an author would have to write a script to increase the contrast if it 
isn't enough.  A UA-independant solutions might involve other inaccessible 
techniques such as client side scripts.

This statement cause a discussion about the "content must work when 
technologies not supported" checkpoint. what are the base technologies?  if 
an author uses an inaccessible technology,  but the user should be able to 
control contrast, then the author can conform to this guideline (i.e., if a 
mechanism is provided, one could conform to this checkpoint) but if it is 
not accessible, then fail that part of the guidelines. Do we want to make 
sure that users can manipulate a browser to increase contrast or that 
authors must provide mechanisms?

Since we opened up the discussion, we went back to the original intent of 
the guideline: foreground content is distinguishable from background...for 
visual default presentation. It was suggested that we change this back to 
"make foreground content easily differentiable from background." But, this 
doesn't seem to clarify the issue. Other issues:

1. make it possible use ua to distinguish foreground/background.
2. originally, w/out asst. tech and w/out ua it is easy to tell the 
difference (started at level 2). today, talking about ua and non-ua.
3. guideline said default but sc said "mechanism"
4. if you have a formula to determine contrast, difficult to say if enough 
contrast or not.  how many pixels does it take for something to not be 
readable? don't think we can find a formula.

This has been a good discussion, but there are several issues to discuss. 
To move forward, a group of folks will work on a proposal to discuss.
action: wendy, loretta, mat, gregg, doyle work on color contrast guideline(s)


Topic 2:  Guideline 1.7 In default auditory presentations, make it easy to 
distinguish foreground speech and sounds from background sounds.
http://www.w3.org/WAI/GL/2003/11/18-f2f-review-draft.html#audio-contrast

History: this guideline and the previous used to be one guideline that was 
generalized to talk about contrast.  It was separated because some believe 
it easier to think about the different levels of success criteria if keep 
audio and visual separate.  There is concern that by separating them we 
have a guideline (1.7) that only has level 3 criteria.

Questions about the success criterion:
1. Is 20 dB of difference between loudest background noise and softest 
foreground noise or at any given time?  proposal: "does not have background 
sounds that are at least 20 dB...x% of the time" thus, could be a cymbal 
crash (that would conflict with part of foreground) but could still be ok.
2. most auditory content is a single track, thus no way to control 
foreground vs background noise. Thus, if you want to go beyond level 1, you 
have to save this as multiple tracks? Or, does an author not have level 2 
if have content that has lots of noise?
3. what about a text transcript as alternative?  was this a level 3 at one 
time? what if audio is always captioned?

discussion about moving this to level 3, since if have a movie or other 
audio content, make it impossible to conform to level 2? if there is a 
transcript or captions and you have difficulty understanding what is said, 
why is that not accessible? thus, it is nice to do this one (thus level 3), 
if have captions or transcript then accessible. it's only the fact that 
there are captions, that make it possible to move this to level 3.

for wording: audio content does not contain audio sounds or are at least 20 
dB... except for occasional sound bursts...short sounds. have to clarify 
"short" "background" and "short"

background and foreground may switch, depending on content. e.g., person 
entering parliament. when person talking, trumpets are background. when 
trumpets move to foreground, get turned up.

resolved: use the plain lang rewrite.  make it a level 3. explain why it is 
3 and not 2.

-- 
wendy a chisholm
world wide web consortium
web accessibility initiative
http://www.w3.org/WAI/
/--

Received on Monday, 8 December 2003 13:31:03 UTC