- From: Jan Richards <jan.richards@utoronto.ca>
- Date: Thu, 01 May 2008 15:09:13 -0400
- To: "'WAI-UA list'" <w3c-wai-ua@w3.org>
Minute: http://www.w3.org/2008/05/01-ua-minutes.html 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: 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 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