W3C

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

17 Dec 2009

See also: IRC log

Attendees

Present
+0127320aaaa, Jeanne, AllanJ, Greg, Kim, iheni, mhakkinen
Regrets
Jan, Simon, Kelly_Ford
Chair
Jim_Allan
Scribe
AllanJ

Contents


 

 

<trackbot> Date: 17 December 2009

<iheni> Patrick H Lauke

<Greg> Henny says that Patrick H. Lauke has agreed to take her place on our working group while she's on maternity leave.

review survey http://www.w3.org/2002/09/wbs/36791/20091208/

<Greg> Re 4.9.6, Kim accepts the proposal.

<iheni> I accept too

http://www.w3.org/2009/12/10-ua-minutes.html

<Greg> Jim notes we added a bunch of action items related to this last week.

<Greg> But proposed wording changes were minor.

4.9.6 Playback Rate Adjustment for Prerecorded Content.. The user can adjust the playback rate of prerecorded audio and/or video content, such that all of the following are true (Level A):

- The user can adjust the playback rate of the audio and/or video tracks to between 50% and 250% of real time. @@fix and/or

- Speech whose playback rate has been adjusted by the user maintains pitch in order to limit degradation of the speech quality.

- Audio and video tracks remain synchronized across this required range of playback rates.

- The user agent provides a function that resets the playback rate to normal (100%).

<jeanne> ACTION: jeanne to update the document with the new language for 4.9.6. See minutes of 17 December for correct text. [recorded in http://www.w3.org/2009/12/17-ua-minutes.html#action01]

<trackbot> Created ACTION-259 - Update the document with the new language for 4.9.6. See minutes of 17 December for correct text. [on Jeanne Spellman - due 2009-12-24].

<Greg> Discussing 4.4.1 etc.

4.4.b The user has the option to set flash rates for user agent defined flash. (Level AAA)

4.4.c "Override flash rates: The user has the option to limit the flash rate for any recognized flashing content to less than 3 flashes in any one second. (AAA)

<Greg> The distinction between the proposed 4.4.b and 4.4.c is the former seems to (or I interpreted it as being) about where the content requests flashing but leaves the flash rate up to the user agent, whereas 4.4.c is about cases where the content requests flashing AND specifies a flash rate in a way that the user agent can recognize, renders, and can choose to override the requested flash rate.

GL: nothing in HTML or CSS where author can set a rate.

<Greg> However, there may be equivalents in other Web technologies where the content can specify a rate.

<Greg> We need the "recognized" limitation because we can't expect the UA to stop scripts from flashing at an arbitrary rate, since the UA may not be aware of exactly what the script is doing.

<Greg> As for priority, as we discussed last week, this is one of the few success criteria where failure actually potentially harms the user rather than just making it difficult to carry out some tasks.

<Greg> Thus I recommend Level A for 4.4.b/c. I don't know of any UA that would fail, and certainly if it fails on 4.4.b it would be a very easy fix. It's possible nothing CAN fail on 4.4.c because no Web technologies apply at this time; it would be interesting to gather feedback on whether there are such.

the user has to option to override any recognized flash rate (author or user agent defined.

proposed: Override flash rates: The user has the option to limit the flash rate for any recognized flashing content to less than 3 flashes in any one second. (AAA)

<Greg> Except propose changing to Level A, not AAA.

<Greg> (Recognize is already defined in the glossary.)

<jeanne> +1

<KimPatch> =1

<Greg> +iheni

looking at 4.4.a 4.4.a

The user agent defined flash rates are less than 3 times in any one second, for all items for which the user agent has sole control of the rate.<Level

A)

+1 to combined b/c

GL: seems that A is redundant to B/C, A is already covered.
... A seems overboard, because slow flash or low contrast.

UA has no knowledge of size of the element flashing, only its flash rate.

GL: thinking of marching ant border, then may not be dangerous.
... or in flash have a 1 px flashing dot.
... not sure A is too bad, seems beyond health guidelines. at a loss for wordage

proposed: Override flash rates: The user has the option to limit the flash rate for any recognized flashing content to less than 3 flashes in any one second. (A)

<jeanne> ACTION: jeanne to add 4.4.b/c to the document as proposed above in minutes of December 17. [recorded in http://www.w3.org/2009/12/17-ua-minutes.html#action02]

<trackbot> Created ACTION-260 - Add 4.4.b/c to the document as proposed above in minutes of December 17. [on Jeanne Spellman - due 2009-12-24].

<Greg> My thought was, if a Web technology has an element where the flash rate is defined by the UA, BUT which can never exceed the flash threshold because it can never be a large area (or a high contrast), then prohibiting it from flashing quickly is going beyond health requirements.

<Greg> I'm not sure that's very important, but it should be considered.

<Greg> I'm trying to figure out why we need to keep 4.4.a, as it seems very close to being a subset of 4.4.b AND has the same priority.

<Greg> One difference is that 4.4.a changes default behavior while 4.4.b can be optional, which is a significant difference.

<Greg> There are a whole bunch of variable, such as: (a)where the user can specify a blink rate or merely turn on a pre-defined limit on and off; (b) whether any limit is imposed by default, vs. only when requested by the user; (c) whether it applies to rates solely under the control of the UA vs. also to content-specified rates recognized by the UA; (d) priority.

<Greg> (e) limiting flash rate in all cases vs. limiting flash rate only when it would exceed a threshold because of size and/or luminance.

<Greg> (f) whether it applies to the UA UI vs. and/or applying to Web content.

4.4.2 Three Flashes: No part of the user interface ever flashes more than three times in any one second period. (Level AAA) [WCAG 2.0]

<Greg> What am I missing with this matrix?

<Greg> 4.4.1 UI - rate OR threshold - always - A

<Greg> 4.4.2 UI - rate - always - AAA

<Greg> 4.4.a Content - rate - always - A

<Greg> 4.4.b Content - rate - optional - A

<Greg> Jim: 4.5.1 says user can adjust settings that affect accessibility (Level A), which is very broad but included so every possible setting doesn't need its own entry.

<Greg> Jim and Greg will work on ACTION-258 off-line, reviewing all of 4.4.

agree with Kim, that 4.4.b should be a special case and called out, separate from 4.5.a

<Greg> We'll need to make sure the combined 4.4.b/c doesn't lose the distinction between user SPECIFIED rate vs. merely user option to cap the rate.

<Greg> Moving on to Jim's proposal in email titled Toggle Metadata Visibility.

Toggle metadata visibility

http://lists.w3.org/Archives/Public/w3c-wai-ua/2009OctDec/0103.html

too much infomation is just as bad as too little

<Greg> If the user doesn't have the option to select WHICH types of alternative content trigger notification, turning on display for all types could make the document unusuable, or cause the type of alternative content the user cares about to be lost amidst a sea of things they don't care about.

KP: important for people to discover, organize and share settings

<Greg> Kim: Important for people to be able to save and share settings for things like this.

GL: expand acronym inline would be great for all users

<Greg> Mark: what would showing alternative content do to screen real estate?

GL: need a unified way for UA to expand or contract items, and access to all the content. and layout is over ridden

<Greg> Kim: Numbered links feature in Firefox had screen real estate problems, but has evolved over time to be more usable.

<Greg> We are definitely telling UA developers that they need to handle cases where the user overrides author formatting (such as by making text large enough for them to read), and this is just one more example of where that will apply.

<scribe> ACTION: Jim to create proposal to reinstate 3.2.4 simultaneous rendering [recorded in http://www.w3.org/2009/12/17-ua-minutes.html#action03]

<trackbot> Created ACTION-261 - Create proposal to reinstate 3.2.4 simultaneous rendering [on Jim Allan - due 2009-12-24].

rragent, draft minutes

Summary of Action Items

[NEW] ACTION: jeanne to add 4.4.b/c to the document as proposed above in minutes of December 17. [recorded in http://www.w3.org/2009/12/17-ua-minutes.html#action02]
[NEW] ACTION: jeanne to update the document with the new language for 4.9.6. See minutes of 17 December for correct text. [recorded in http://www.w3.org/2009/12/17-ua-minutes.html#action01]
[NEW] ACTION: Jim to create proposal to reinstate 3.2.4 simultaneous rendering [recorded in http://www.w3.org/2009/12/17-ua-minutes.html#action03]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/12/17 19:34:47 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/riden/ridden/
No ScribeNick specified.  Guessing ScribeNick: AllanJ
Inferring Scribes: AllanJ
Default Present: +0127320aaaa, Jeanne, AllanJ, Greg, Kim, iheni, mhakkinen
Present: +0127320aaaa Jeanne AllanJ Greg Kim iheni mhakkinen
Regrets: Jan Simon Kelly_Ford
Found Date: 17 Dec 2009
Guessing minutes URL: http://www.w3.org/2009/12/17-ua-minutes.html
People with action items: jeanne jim

[End of scribe.perl diagnostic output]