See also: IRC log
<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
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
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
<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
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]