Minutes: User Agent Teleconference for 17 December 2009

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

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

    * Topics
         1. review survey http://www.w3.org/2002/09/wbs/36791/20091208/
         2. Toggle metadata visibility
    * Summary of Action Items

Summary of Action Items
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]

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]

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

Received on Thursday, 17 December 2009 19:39:21 UTC