UAWG Telecon 21 May 2009

Minutes: http://www.w3.org/2009/05/21-ua-minutes.html

IRC Log: http://www.w3.org/2009/05/21-ua-irc

Summary of Action Items

[NEW] ACTION: Jan to Propose rewording of event handling requirements  
into higher level language for 4.1 [recorded in http://www.w3.org/ 
2009/05/21-ua-minutes.html#action01]
[NEW] ACTION: JS to remove interactive element from glossary  
[recorded in http://www.w3.org/2009/05/21-ua-minutes.html#action02]
[NEW] ACTION: KF Update guideline 4.5 to reflect accessibility  
changes. Include first sentence of Simon's proposal 149 and make all  
items reflect accessibity settings. [recorded in http://www.w3.org/ 
2009/05/21-ua-minutes.html#action03]

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

21 May 2009

See also: IRC log

Attendees

Present
Allan_James, Spellman_Jeanne, Ford_Kelly, Swan_Henny_Richards_Jan,  
Hakkinen_Mark, Patch_kim
Regrets
Chair
Jim_Allan
Scribe
Harper_Simon
Contents

Topics
Logistics (Regrets, agenda requests, comments)?
Finish 5/14 survey http://www.w3.org/2002/09/wbs/36791/20090513/
ACTION-181 Investigate / review interactive and enabled for  
contradictions.
Summary of Action Items




<trackbot> Date: 21 May 2009
<jeanne> be right there, I'm trying to get ATAG published. I'll be a  
few minutes.
<KFord> Let's give folks a couple more minutes to arrive.
<jeanne> on my way...
<scribe> scribe: Harper_Simon
<scribe> ScribeNick: sharper
Logistics (Regrets, agenda requests, comments)?

<mhakkinen> mark is p12
Finish 5/14 survey http://www.w3.org/2002/09/wbs/36791/20090513/

KF: Moving to point
#78. (Re 4.2.3 **) ""Activate all input device event handlers""
http://www.w3.org/WAI/UA/2009/ED-UAAG20-20090506/#gl-device- 
independent-handlers
<KFord> Greg's feedback item 78.
<KFord> #78. (Re 4.2.3 **) ""Activate all input device event handlers""
<KFord> 4.2.3
<KFord> #78. (Re 4.2.3 **)
<KFord> ""Activate all input device event handlers"" is unclear: I'm  
afraid that I can't understand this success criterion based on its  
title (""Activate All"")
<KFord> or its text ( ""The user can activate, as a group, all event  
handlers of the same input device event type, for the same  
control""), nor is it clear how
<KFord> it is different than 4.2.1. Both require the user be able to  
activate event handlers, but they differ in: (a) although 4.2.1  
applies to ""(content) elements""
<KFord> that take content focus while 4.2.3 applies to ""(user  
interface) controls"" (per glossary definitons); (b) 4.2.1 requires  
that the user can activate them
<KFord> with the keyboard while 4.2.3 doesn't specify the means,  
presumably making it OK if the user has to click a mouse to activate  
a mouse-click event handler
<KFord> (which seems to remove the point); (c) 4.2.3 says ""as a  
group"" while presumably 4.2.1 finds it enough if they can be  
activated separately; (d) 4.2.1
<KFord> only applies to the event handlers that are ""explicitly  
associated"" with the element that has content focus, while  
presumably 4.2.3 requires it for all
<KFord> UI controls that handle events even if they ""bubble up"" to  
the control rather than being ""explicitly associated"" with it; (e)  
4.2.1 requires the user
<KFord> be able to navigate to and then trigger event handlers for an  
element, while 4.2.3 would presumably be met by providing an entirely  
separate facility that
<KFord> merely allowed the user to pick UI controls and their event  
handlers from a master list; (f) etc., etc. As you can see, I find  
4.2.3 (and probably 4.2.1)
<KFord> need significant changes to be made both clear and useful. I  
recommend that the two SC be combined into a single SC that (a)  
applies to both content elements
<KFord> that have the content focus AND to UI controls that have the  
UI focus, (b) lets the user activate, in a single operation, ""all""  
of the event handlers
<KFord> for the user's choice of input device event handlers  
""explicitly associated"" with that element or control. (Priority: 1  
High) (Type: Clarify)"
JR: What do we mean when there are a number of specific handlers on a  
control and there can be multiple events (ie 2 mouse downs) - what is  
the use case for a keyboard user?
KF: Know of no uA who will do the all thing. my question is what is  
our end goal - what do we want the end user to experience.
<Greg> I'd say the high-level goal is that a keyboard (etc.) user be  
able to access all the functionality that content provides for mouse  
(etc.) users. The means is to let the user emulate mouse input via  
the keyboard.
JR: all not such a problem - who flow is the problem - eg tabbing a  
document - come across a control, how does the system know that there  
is more than mouse down - how can they react?
<Greg> I believe the idea of the guideline may be that the user can  
emulate mouse input more efficiently if it's implemented by the user  
agent and tied directly to its functionality, as opposed to making  
the user rely on a general-purpose mouse emulator (e.g. MouseKeys).
KF: HTML eg - DIV with on click - do we want a tab stop enforced on  
all onclicks on div
who is noisy
<Greg> I support the notion that UA should provide keyboard access to  
all content elements that accept input of any sort. However, I  
believe that's already specified by 4.1.1, but maybe it important  
enough to call out explicitly.
KP: can mouse by speech but harder than anything else - need keyboard  
to be used - can we switch mouse to regular cursor - would this be  
useful?
... Caret browsing is really useful - if you could snap the caret to  
where the mouse is this could be a good option.
JR: Physical order of mouse actions which happen with a real mouse -  
there is an event sequence in which events are processed, how can  
this be done via the keyboard if a request occurs out of sequence?
KF: what if we had a browser in which you could step through in the  
order of your choice?
JR: act of tabbing could be the same as mousing over it?
GL: 4.1.1 already accomplishes this as a high level goal
... We seem to be getting into spec. details (in regard to event  
handlers). For instance Mousekeys would allow the user to trigger  
events in their proper order, several ways of going about it - don't  
need to specify which one is used - just need the high level goal.
... Rewrite all this into the keyboard section to provided all  
functionality including event handlers to the keyboard
KP: need to be careful regarding tab order and malformed contents
KF: WCAG guidelines say that you should not get people into this  
situation - need to do something - but not over spec.
<Greg> In response to the spoken comment, I think the issue of making  
navigation that can be navigated more efficiently is important but  
should be somewhere other than 4.2.
<Greg> I agree that in general the UA should have features that help  
compensate for bad page design, and we can require features that  
mitigate negative effects of inaccessible content.
<Jan> JR: to say +1 to GL - that event handlers can be brought into  
4.1 as a higeher level SC, +1 to Kim re: routing mouse to keyboard focus
<Greg> +1 to Kim's suggestion of ability to route mouse to focus and  
vice versa.
KF: If you have 10 events - how should I show them all.
JR: not sure you need to show all, as the author has a model of the  
universe which may dictate and order.
<Greg> Does anyone have reservations about moving 4.2 (make events  
available via keyboard) into 4.1 (make everything available via the  
keyboard)?
JR: may not exist until used, or are predicated on some other  
sequential action
KF: In summary, Move to 4.1 then condense and make a sub-point of  
keyboard access.
<Jan> ACTION: Jan to Propose rewording of event handling requirements  
into higher level language for 4.1 [recorded in http://www.w3.org/ 
2009/05/21-ua-minutes.html#action01]
<trackbot> Created ACTION-189 - Propose rewording of event handling  
requirements into higher level language for 4.1 [on Jan Richards -  
due 2009-05-28].
RESOLUTION: Move to 4.1 then condense and make a sub-point of  
keyboard access. Actions to be taken by JR.
ACTION-149 to write proposal for 'default settings of UA should be  
accessible'
KF: 3 accepts and 3 needs more discussion
Discussion points
Does the first part mean that Tools>Options needs a keyboard  
shortcut? Is the second part necessary? Maybe I wasn't there when  
this was discussed but ( ACTION-149 to write proposal for 'default  
settings of UA should be accessible') sounds like it was meant to  
mean that certain accessibility settings were going to be on by default.
This may be beyond the scope of this item, but it's also important  
that the user be able to save reconfigured default settings. Even  
better if there's some way to share these settings.
The globally accessible key combination as to bring up a  
configuration dialog. Is it necessary to add this point?
<KFord> Simon's proposal http://lists.w3.org/Archives/Public/w3c-wai- 
ua/2009AprJun/0044.html
<Greg> This sounds like an expanded version of the existing  
requirement for persistent keyboard settings--a general requirement  
for persistent user preference settings. Is that correct?
<Greg> I think that we should not force the UA to instruct the user  
in accessibility features, or prompt them for accessibility settings.  
Perhaps UA documentation should be available outside of the product,  
so that one can get to it and read about accessibility-affecting  
features without being blocked by the product's inaccessible default  
settings.
<Greg> Similarly, the ability to change the accessibility settings  
from outside the product would be extremely useful, although it's  
hard to do so certainly could not be higher than AAA.
<Greg> -1; I think Simon's original wording needs some more work  
before being approved.
<Greg> The ISO/ANSI guidelines for accessible software design include  
a Level AAA success criteria about providing "user settings schemes"  
designed for accessibility. I suggest we compare with those.
<KFord> With respect to Jim's point
<KFord> 4.1.8 Important Command Functions: Important command  
functions (e.g. related to navigation, display, content, information  
management, etc.) are available
<KFord> in a single keystroke. (Level AA)
GL: Problem with this is that most products have many config options  
scattered through the panels / dialogues
KF: needs to not be hard to get to config options via the keyboard
... defined as less than 5 keystockes
<Greg> Kelly, are you suggesting that *all* user preferences options  
be available within five keystrokes, or just, say, the main dialog or  
menu or wizard?
KF: not a standard but a rule of thumb
<Greg> The current discussion seems to be about making everything  
important efficiently available through the keyboard, which is a good  
goal but is it related to 4.5?
<Greg> I do not support requiring the UA to prompt the user to make  
configuration changes on first run, mainly because studies all show  
that users hate it.
KF: Is it important on first launch about default configurations wrt  
to accessibility settings?
JA: no
JR: useful in an ideal word but imposes overheads
KF: Not an absolute must - a UA could decide to do this.
KP and HS agree.
<Henny> Should not prompt automatically, real focus should be on  
discoverability of how you can configure defaults.
RESOLUTION: Don't believe that a UA does not need to prompt re  
accessibility configurations.
KF: is the first part covered by other parts of the guidelines?
<Greg> I am not convinced that a configuration dialog box is so  
special that it should always have a single keystroke. For example,  
using a key sequence such as Office's Alt+T,O is not significantly  
harder than a single key combination.
KF: do we need the first part of the proposal?
JA: Happy with just the first part: The user agent will allow its  
default settings to be reconfigured by the user
<Greg> What do you mean by default. Is it what the user encounters  
the first time they run the product, or the next time they run the  
product? The latter is already covered by 4.5.1.
KF: OK to leave in the first sentance
JR: aren't configuration settings already configurable by the user  
anyhow.
KP: sometimes settings don't stick, ie size of a window or dialogue -  
sometimes the size is importance and we shouls be able to make  
settings stick.
... not sure if they stick - not explicit.
<Greg> I can agree that there may be problems from 4.5 being too  
broad and requiring ALL settings to be saved. Most should be  
persistent, but there are certainly rare cases where temporary  
settings are appropriately.
<Jan> JR: Likes Kim's idea that window resizings are stored between  
sessions
<KFord> We have Kinm.
<KFord> 4.5.3 Portable Profiles: Sets of preferences are stored as  
separate files (allowing them to be transmitted electronically).  
(Level AAA)
KF: We should list in a technical note the settings w=that have an  
impact on accessibility, list why, and put in window size
<Greg> I agree that window size and position should be persistent,  
but the UA should also automatically correct saved settings that are  
no longer appropriate (e.g. the window is now off the screen because  
the screen resolution has changed between sessions).
JR: does the single keystoke open 1 dialogue or multiple ones.
KF: not going to have the single keystroke - how do we say we are  
going to prompt or allow configuration. Need something to say  
'configure it'.
GL: first sentance covers it.
<Greg> (I don't think I said anything like "first sentence covers it".)
SH: In the introduction of the draft we say.../
A default user agent
setting may be useful for one user but interfere with accessibility
for another, therefore this document prefers configuration
requirements rather than requirements for default settings
<Greg> -1; I cannot vote for adding this until you define defaults".
JR: would be ok if accessibility settings is inserted
Questions: how to define accessibility settings.
KF: how about, we change 4.5 to configure and store accessibility  
setting - and add accessibility to the guidelines and tehn add the  
first sentence.
<Greg> The danger of changing it to "configure and store  
accessibility preference settings" is that developers tend to wrong  
distinguish between mainstream (useful) and accessibility (obscure)  
features.
JA: works for me.
GL: risk whenever you apply something to only accessibility settings  
that these get un-implemented. As a general approach it makes sense.
KF: most UA do everything we want here today.
... Do we need it in a survey to get final sign off.
RESOLUTION: Change 4.5 to configure and store accessibility setting -  
and add accessibility to the guidelines and then add the first sentence.
ACTION-181 Investigate / review interactive and enabled for  
contradictions.

5 accepts and 2 neutrals
<KFord> Resolved: Interactive element removed
RESOLUTION: Interactive element removed
<KFord> ACTION: JS to remove interactive element from glossary  
[recorded in http://www.w3.org/2009/05/21-ua-minutes.html#action02]
<trackbot> Created ACTION-190 - Remove interactive element from  
glossary [on Jeanne Spellman - due 2009-05-28].
<KFord> ACTION: KF Update guideline 4.5 to reflect accessibility  
changes. Include first sentence of Simon's proposal 149 and make all  
items reflect accessibity settings. [recorded in http://www.w3.org/ 
2009/05/21-ua-minutes.html#action03]
<trackbot> Created ACTION-191 - Update guideline 4.5 to reflect  
accessibility changes. Include first sentence of Simon's proposal 149  
and make all items reflect accessibity settings. [on Kelly Ford - due  
2009-05-28].
<Greg> I see useful distinction between static vs. interactive  
elements, and the latter can be in two states, enabled and disabled.
<Greg> I agree we can take 'interactive element' out for now; we can  
always add it back in if we later decide to use the term.
Summary of Action Items

[NEW] ACTION: Jan to Propose rewording of event handling requirements  
into higher level language for 4.1 [recorded in http://www.w3.org/ 
2009/05/21-ua-minutes.html#action01]
[NEW] ACTION: JS to remove interactive element from glossary  
[recorded in http://www.w3.org/2009/05/21-ua-minutes.html#action02]
[NEW] ACTION: KF Update guideline 4.5 to reflect accessibility  
changes. Include first sentence of Simon's proposal 149 and make all  
items reflect accessibity settings. [recorded in http://www.w3.org/ 
2009/05/21-ua-minutes.html#action03]

[End of minutes]

Received on Thursday, 21 May 2009 18:42:27 UTC