W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2008

Minutes from User Agent Teleconference for 1 May 2008

From: Jan Richards <jan.richards@utoronto.ca>
Date: Thu, 01 May 2008 15:09:13 -0400
Message-ID: <481A1559.6080104@utoronto.ca>
To: "'WAI-UA list'" <w3c-wai-ua@w3.org>


Action items:
- None offically, but Gregory will be sending ACCESS proposal.

Full text:
<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: 

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 

<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 

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

<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: 

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

Jim Allan wrote:
> User Agent Teleconference for 1 May 2008
> ------------------------------------------------------------
> Chair: Jim Allan
> Date: Thursday, 1 May 2008
> Time: 2:00-3:00 pm Boston Local Time, USA (19:00-20:00 UTC/GMT)
> Call-in: Zakim bridge at: +1-617-761-6200, code 82941# for UK use
> 44-117-370-6152
> IRC: sever: irc.w3.org, port: 6665, channel: #ua.
> -------------------------------------------------------------
> Agenda:
> 0. Regrets, agenda requests, or comments to the list
> 1. XHTML Access module - keyboard access, accesskey, event firing
> 2. Printing in a user agent
> Jim Allan, Webmaster & Statewide Technical Support Specialist
> Texas School for the Blind and Visually Impaired
> 1100 W. 45th St., Austin, Texas 78756
> voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
> "We shape our tools and thereafter our tools shape us." McLuhan, 1964

Jan Richards, M.Sc.
User Interface Design Specialist
Adaptive Technology Resource Centre (ATRC)
Faculty of Information Studies
University of Toronto

   Email: jan.richards@utoronto.ca
   Web:   http://jan.atrc.utoronto.ca
   Phone: 416-946-7060
   Fax:   416-971-2896
Received on Thursday, 1 May 2008 19:08:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:38 UTC