W3C

- DRAFT -

SV_MEETING_TITLE

01 May 2008

Agenda

See also: IRC log

Attendees

Present
Regrets
Chair
Jim Allan
Scribe
Jan

Contents


 

 

<GJR> jim, i had hoped to have some prose for 3.1.1 and 3.1.2 of Access module, but had to fight fires elsewhere all morning

<AllanJ> Title: UAWG Telecon

<AllanJ> Scribe: Jan

<scribe> Scribe: Jan

JB: Jeanne Spellman joining us...
... Will be new staff contact with UAWG and AUWG...
... She's just starting
... Thanks to JR

<GJR> we LUV jan! but welcome jeanne!

JS: Working as independent accessibility consultant for 7 years
... Really thrilled to be here...with UAWG
... Working for years with browsers

AC: Introduces self

KF: Introduces self....test lead on IE team and involved with accessibility

SH: Microsoft...work in Accessibility Incubation Lab

DH: From Apple...work on voiceover-QA engineer...deal with accessibility for MacOS

GR: Member of PF, HTML, XHTML

JB: Introduces self

1. XHTML Access module - keyboard access, accesskey, event firing

JA: I posted something a bit late to group

<AllanJ> http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0074.html

JA: these are some of my comments to GRs issues

<GJR> GJR post: http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0068.html

JA: Last week I took action to summarize topic...
... Access: I think of in HTML we accesskey in XHTML we have an element that key is then attached to and element decides what to do when key pressed
... Activate has values yes,no...no is default
... "Activate" attribute
... Also user settings take precedence

<GJR> http://www.w3.org/MarkUp/2008/ED-xhtml-access-20080220/

<GJR> http://www.w3.org/MarkUp/2008/ED-xhtml-access-20080220/#sec_3.1.1.

<GJR> http://www.w3.org/MarkUp/2008/ED-xhtml-access-20080220/#sec_3.1.2.

<AllanJ> There was discussion that a mouse user explicitly knows what is being

<AllanJ> activated - that is, they must place the mouse on the element to be

<AllanJ> activated and THEN explicitly click a button. A mouse user can infer from

<AllanJ> contextual information/content near the element what the activation of the

<AllanJ> element may do. If @activate is set to 'yes' a user using the 'access'

<AllanJ> keybinding has limited contextual information other than the @title of the

<AllanJ> 'access' element to infer the function, because upon focusing on the element

<AllanJ> it is immediately fired. If @activate is set to 'no' then the focus is moved

<AllanJ> to the appropriate element and the user is free to explore context if there

<AllanJ> is any doubt as to actual function.

JB: What should we focus on in this discussion?

JA: I listed out relevant UA checkpoints
... One concern is that in UAAG2 we have requirement to show all
... So if you come across element you can ask what handlers are
... But this seems of dubious use if you don't know what event handler will do

<GJR> will a pointer-driven query of an object for which multiple events have been defined, be interpreted as activate="yes" for all events, or is there something that needs to be stated explicitly about UA and/or user control over pointer device interaction with object for which access has been set?

GR: Really need to answer this open issue.
... With ACCESS you can have multiple events on a single object
... If one of them is set to activate...
... I have an action to take Jim's mapping back to XHTML

<GJR> SMIL2 cutting-room floor text: "The user agent must provide a means of identifying the [shortcuts] that can be used in a [page]. This may be accomplished in different ways by different implementations, for example through direct interaction with the application or via the user's guide. The [access key] requested by the author might not be made available by the player (for example it may not exist on the device used, or it may be used by the player itself). Therefor

GR: Plus a bit of text from Al (above)
... THye are glad there is a normative reference they can point to
... Concern of Jim's about poiinter is still most outstanding
... We do need to balance keyboard user's range of action with the keyboard user's

KF: So today no user agent can put all mouse things on hold and then step through them.
... So if I put mouse a control with 5 events? I can separately choose them?

AC: This is something any kind of application would be relevant to...eg OS

KF: Is in general an OS behaviour
... Technically possible for UA to change...not easy

AC: Spirit of idea of helping mouse user appeals to me

KF: I think there is some point to what you say...from implementation standpoint this is complicate to make usabel

GR: That's why I though a third state-inspect- would work, but was rejected

<GJR> need a mouse fucntional access specification as there are keyboard functional access specifications, but for now we need to implement it correctly via UAAG 2.0

<AllanJ> JR: things fire in a linear way, e.g. 2 handlers mousedown and mouse up but fires them in different orders may cause errors

KF: If people already confused about click vs. double click....much harder to imagine

GR: Meta problem...no bouncekeys, sticky keys etc. for mouse

KF: We can slowthings down etc

AC: In a sense a mouseover....is a prallel to inspect

KF: From user perspective..imagine menu sliders out on mouseover
... I'm in my don't activate mode...
... Mouse over menu...
... Tells me there is a mouseover...
... I choose it etc

GR: Lot's of mouse developer resistance...
... Mouseover vs. onfocus event....
... Mouseover might say month...month...
... THey say do I want to see everything...I say ARIA politeness could be the filter

AC: Idea of not triggering event....should hovering or putting focus...automatically put focus

JA: Except access module specifically concerned about keyboard not mouse
... So are saying there is something in mouse that we want keyboard to be able to do

GR: Access module aimed at keyboards but can't ignore implications for pointer.
... Must work together
... Can't wait for mouse module since there won't bwe one - they are custom or by convention
... Don't want to advis a solution that suddenly cuts of a majority of navigation on web.

JA: So can do different mouse things ...but less keyboard things

GR: In XHTML events
... Events are onfocus and onactivate

JA: Other pointer....
... 11.2, 11.3, 11.4 in UAAG1 about binding, rebindings
... But they apply to UI, not content
... So we address that in UAAG2

GR: Mitigating thing is that access module is by its nature about content
... This is all because accesskey was so underspecified

JA: So I've made a proposal that users be able to override author bindings
... Plus if no bindings provided, UA must add them as long as they don't conflict

<OedipusWrecked> SMIL2 cutting-room floor text: "The user agent must provide a means of identifying the [shortcuts] that can be used in a [page]. This may be accomplished in different ways by different implementations, for example through direct interaction with the application or via the user's guide. The [access key] requested by the author might not be made available by the player (for example it may not exist on the device used, or it may be used by the player itself

AC: When talking about user changeable bindings...if users permitted to change keybindings, do we want to talk about changing other things like accesskeys for menus

GR: Access module is for content
... We in UAAG will, but for access module its out of scope

JA: Also we have chckpoints to cover some of those

4.1.10 is the success criteria

JA: My message includes a few proposals

GR: I'm going to try to send a proposal too

JA: Deadline?

GR: Hope to have last call at next meeting
... But if we could have something to them by the end of the weekend...they could consider it

JB: What turnaround?

GR: Sunday night
... Would give 48 hours for people to think about it
... They have said they will listen to us
... But needs to get done

JA: Do you need help in call?

GR: I should be ok?

JB: So what message are you going to be making?

GR: 3.1.1, 3.1.2 I'm hoping to get them up for tomorrow for review by this group

JB: Sounds like timing is too close

KF: Would prefer if you propose on list, we can discuss then we can deice next Thursday

JB: So PF not sending anything

GR: Yes
... Yes they are not sending anything

JB: So GR will send proposal by tomorrow...then decision next Thursday
... GR please also log it on wai-liaison

<OedipusWrecked> wai-liaison@w3.org

JA: OK we have 10mins

2. Printing in a user agent

JA: This was brought up and discussed on list
... I've had issues plus I've surveyed people and it is a major concern

<OedipusWrecked> [FYI] http://lists.w3.org/Archives/Member/wai-liaison/ (note member confidential

JA: made proposal

UA printing

<AllanJ> SC: 3.11.X Print Scale: If a print from viewport feature is provided, the user has the option of printing using the viewport's scale settings such that the user agent should attempt to *passively reflow* the content into the horizontal dimensions of paper. If passive reflow is not possible, more than one sheet of paper will be required horizontally.

<AllanJ> JR: - by *passively reflow* I mean the kind of reflow that happens when you resize a window manually.

<AllanJ> - do any languages favour horizontal over vertical paper flows?

JA: Any comments?

DH: Makes sense

KF: Kind of makes sense

AC: Need to think it through

<OedipusWrecked> [FYI] http://www.w3.org/Style/CSS/Test/Print/

<AllanJ> JR: 2 sheet horizontal example. text is easily reflowed. but image can't be reflowed

<AllanJ> ...if the image is too large then should be printed across mulitple pages

<AllanJ> GRG: large table example, printing on multiple pages

AC: Up to user to figure out how pages fit togeter

JA: Currently just the left most page gets printed

KF: On surface seems reasonable
... But will need to talk to printing people

GR: Support success criteria but wary about removing "paper" from defintiion because of screen viewing problems\

<AllanJ> JR: I agree, but in UAAG if replace viewport with paper, they no sense.

<AllanJ> GRG: propose use "paged media"

GR: Use Paged media instead of peices of paper

JA: OK for next week, major issue is ACCESS module and come to decision

<OedipusWrecked> paged media info in: http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0066.html

JA: And we will also need to figure out a better focus for our meetings

<AllanJ> KF: regrets next week

KF: Unfortunately I have to give regrets fo rhte next xall

GR: THanks for comments on access module

<OedipusWrecked> kelly - 1 973 746 1192

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/05/01 19:05:10 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: Jan
Inferring ScribeNick: Jan
Found Scribe: Jan
Inferring ScribeNick: Jan

WARNING: No "Present: ... " found!
Possibly Present: AC Alan AllanJ Cantor DH DeanHudson GJR GR GRG Gregory_Rosmaita IPcaller JA JB JR JS Jan Jeanne Judy KF KFord Microsoft OedipusWrecked SC SH Sean Title
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Agenda: http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0070.html
Got date from IRC log name: 01 May 2008
Guessing minutes URL: http://www.w3.org/2008/05/01-ua-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]