<trackbot> Date: 08 October 2010

<ChrisL> trackbot, start telcon

<trackbot> Meeting: Hypertext Coordination Group Teleconference

<trackbot> Date: 08 October 2010

<ChrisL> volunteer for scribe?

<glazou> salut darobin

<darobin> hi glazou!

<darobin> bah

<glazou> oedipus: go ahead we'll say our names

<scribe> scribe: Gregory_Rosmaita

<glazou> ScribeNick oedipus

<scribe> scribenick: oedipus

<ChrisL> thanks Gregory

Quick Action Item Review

CL: 2 open

<ChrisL> action-54?

<trackbot> ACTION-54 -- Michael Cooper to install an HTML4+ARIA DTD -- due 2010-09-10 -- OPEN

<trackbot> http://www.w3.org/MarkUp/CoordGroup/track/actions/54

MC: recall that had to do with ARIA in w3c validator - more of political thing than technical thing - have action items in this and PF group but can't promise timeline noe

<ChrisL> action-56?

<trackbot> ACTION-56 -- Michael Cooper to find ways to introduce the W3C editor community to use of ARIA - whitepaper, lightning talk, BOF at TPAC, etc. -- due 2010-09-10 -- OPEN

<trackbot> http://www.w3.org/MarkUp/CoordGroup/track/actions/56

CL: is there a lightning talk about this for TPAC?

MC: hadn't made specific plans, but is opportunity

User Interface Independence for Accessible Rich Internet Applications

<kaz>

CL: [roll call]

<ChrisL> http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html

JS (Janina Sajka): will ask JCraig to present, but wanted to thank HCG for opening discussion; document looks important to WAI/PF

<shepazu> [for those who aren't subscribed to the HCG list: http://lists.w3.org/Archives/Member/w3c-html-cg/2010OctDec/0013.html]

JC (James Craig): ARIA does good job of declaring things from webapp that can get to AT; declarative markup works well getting info out to AT

<shepazu> [UI Independence for ARIA: http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html]

JC: AT = Assistive Technology such as screen-reader, on-screen keyboard, etc.
... no good way to get events back into app
... ARIA has been specified in tandem with set of de facto keypresses developed by DHTML Style Guide
... think is ok stopgap measure to define keyboard associations, but not ideal for i18n, a11y, localization, different hardware, etc
... came up with proposal to allow AT of whatever kind to send events into the rendering engine so can be passed along to webapp so that can be notified - controlled by remote (AT) rather tahn primary interface
... request events - instead of touch of PageUp etc. if gesture based interface, UA reqs a scroll event -- if capture scroll event browser and AT can communicate

DS: it is not a standalone proposal - requests other specs include things -- different from ARIA -- aimed at number of specifications

JC: good point; new DOM events - additions to client side javascript for set properties

CL: introduce specific features?

http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html

JC: part of proposal is premise why is needed; DHTML Style guide keypresses can be very complex
... example: control+shift+m opens popup during drag and drop - unlikely that authors going to adhere to keyboard presses defined by DHTML style group
... user would have to learn new key commands to use apps with AT
... localization problems address as is operating system agnosticism
... new devices fully touch screen
... been telling authors to use simple non-character keys and not to worry about more complex commands which don't make sense for a large part of target audience

DS: developed by DHTML Style Guide WG?

JC: ad hoc group that used wai-xtech for communication but not formal WAI group
... UIRequestEvents and types of events pertaining to request - if user presses DEL then first sent would be delete req unless UA recognized and cancelled; no notification from UA; if does not recognize, then UA can have fallback method for accessing delete key
... child of UIRequestEvent says want UA on my behalft to change this attribute with this attribute -- replacement for DOMAttrModified

CL: example of use outside of a11y, if menu item that fires events be useful?

JC: menu items not necessary for most of theses

CL: but menu could be used
... trying to think of use cases outside of a11y

JC: not specific at all to a11y (accessibility)
... [reads from proposal]
... if web app doesn't recognize undo request event, UA can use fallback event, such as sending KeyPress event

SP (Steven Pemberton): this is about DI, but goes hand-in-hand with a11y, both apply, right?

JC: yes
... DI part of it; called UIInterface because wanted it applying to OS- and browser-independence as well

RS: would save devs a lot of time if didn't have to worry about gestures as well as keyboard input -- want to know there is request to open menu, and menu will open -- works cross-browser and app

JC: agreed to consider OpenRequest and CloseRequest at Rich's suggestion, DOMActivate, EscapeRequest, and DOMAttrChangeRequest may suffice there
... for most cases, open would be default action of a button

RS: tree item have to hit right arrow key to open easier to say "open"

JC: expand/collapse to expose lower level tree on windows and mac - different keypresses on each

DS: [reads from proposal]

JC: might want to use DOMAttrChangeRequest request for styling from DOM

DS: like proposal's UI request thing -- seems would be useful in context of DOM3 events to redo/undo these things often tied closely to keypresses
... in DOM3 events, there is a list of keys - each key value can be character value (a,1,@ - any printing char) unicode value kbd can produce
... second class of keys: ENTER, TAB, CONTROL
... instead of char and key codes on event to pass along either char value as anchor string (not numeric code) or pass along a string such as ENTER or TAB or CONTROL and that string tells you what the key is that has been pressed
... one of those is undo - for keycode and charcode in past, if press control+Z don't get undo, but got control key then event for z key

<kaz> DOM3 Events "6.2.7 Key Values Set"

DS: if press shift+a you don't get A you get shift + a to create value A (the character to which kbd is mapped plus all modifiers)
... big win for authors - don't have to guess due to series of keypresses x might be the outcome
... undo is key balue, but should be mapped to what OS uses as default undo (command+Z or control-Z) -- at end should throw undo command
... question of support -- if shake iphone to undo won't be picked up by key event, so i like the idea of abstraction and adding this particular interface to DOM3 Events
... can then say "in addition to throwing kbd event with undo keyvalue, this should have default action of throwing an undo or redo event
... for devices without kbds very useful for users, authors, devs
... if can get UAs -- specifically IE9 -- to say "yes" we will implement this -- willing to put that part in DOM3 Events

<ChrisL> doug - which part specifically do you propose to put in DOM3 events?

DS: change event issue different -- simply another iteration on mutation events - problem is when have event mechansism there is a lot of overhead - feedback from all UA vendors

JC: put note in proposal noting that there are certain events such as TouchStart and TouchEnd could be ShakeStart and ShakeEnd -- UAs need give precedence to continuous input events (such as touch or shake)
... if had web app that looked for shake event -- need to know when shake starts and ends - UA should ShakeStart first
... diff order than discrete keypress events -- undo sent first if not canceled keypress sent without delay on UI side

<Zakim> ddahl, you wanted to ask about how this would work with speech recognition-based AT

JC: noticed that particular area is lacking, but continuous input events will take precedence over UI events

DD: how work with speech recognition? think that if user wants to undo, AT responsible for turning spoken request into undo event which would then be fed to UA -- if that is correct, this will be great for speech recog AT - undo would mean undo or "i din't meanthat" for undo; can't code for UA, so would help

JC: intention on UA side -- OS side up to interpretation - may be that when UA understands listening for undo, broadcast through platform's a11y API

a11y = accessibility

JC: if speech recog engine tied in closely enough with UA, UA should be able to request an undo

DS: you expect undo event to fire before the event propagation or keypress event

JC: gives web app ability to receive and cancel before UA goes to fallback

DS: is that stated in proposal?

JC: believe it does - is in prose, not in interface methods
... reason is depending on interface hitting keypress might be a fallback itself -- if web app looking for certain keypress, and UIRequestEvent captured, and author calls for default on event UA doesn't have to use fallback evetns

DS: exclusively within web app -- if i was doing something in text editor in web app, undo may act differently when used in textarea but not synced to web app if undo in location bar

JC: undo event will be registered if haven't typed anything yet, if hit undo control in location bar, UA would send to web app, if sees on toolbar, knows to send undo request to go back to UA, which then does a chrome undo event

DS: if you want to edit text and said undo, natively, would go back last char because i'm typing, but if i said undo last word, could cancel undo so browser doesn't get it and i as user go it
... think browsers going to let you do that?

CL: depends on who grabs event first

JC: would be browser passing event to rendering engine, rendering engine replies to browser which finishes it off -- browser always has first right of refusal
... on OS side, browser app going to get key event from OS
... if knows that user interacting with web content at that time, and UA has implemented these events, should offer undo thorugh the UIRequestEvent

DS: apologize for going into such detail

JC: don't think would override UA behavior when inappropriate

DS: think you should join dom3 events telecon or have a joint telecon to sort out this level of detail
... DOM3 events is only 1 target of proposal

<Zakim> janina, you wanted to ask how best to move forward--don't want to get to the end of the hour without discussing that

JS: getting near 15 minutes left - want to discuss where and how to move forward in W3C outside of WAI -- eager for DOM3 to move forward, but don't want proposal to take many years either because benefit will be immediate
... where and how to continue work on this?

CL: review spec and then have specific conversations on sections

JC: HTML A11y TF would be perfect place for section 4 of proposal

Glazou: events model just discussed: 3 layers: 1 at OS level catching key; second at chrome level; third level is web app itself

JC: after event would bubble up same change

Glazou: could capture before hist web app - is doable

JC: sections of spec - scroll request, way to indicate div role="slider" could pre-set to max or minimum
... 1 proposal considering is in mainstream safari, can tap title bar on iPhone which sends scrollevent even though don't want to override touch event
... screen reader intercepts all such events; need iPhone to pass to web app so can be understood

DS: high level overview of interfaces and where applicable
... DOMAttrChangeRequest - DOM3 events is "natural" place, but need call to discuss more

JC: mutation events have had performance events think this proposal will take care of that
... section 2 for mainstream UA and AT
... third section more specific to AT -- focus and blur events that fire via screen reader cursors (screen readers use virtual cursors)
... final section: AT technology notification - separate from DOM 3
... Window.Navigator Window.Navigator.Accessibility.SpecificAT = window.Navigator.Accessibility.Speech , dot version, identify engine being used;
... magnifier focus could tell mag here are coordinates so would allow use of Bespin type apps (canvas-only web app)
... all UA sees is 1 canvas tag, this would allow for OS level screen mag to follow along

DS: which parts would you like to see in DOM3 Events

JC: section 2 and section 3

CL: 2 candidates for DOM3 Events - hadn't expected to add anything to it - would it have a substantial impact on schedule?

DS: currently in LC -- anticipated first LC because of lenghth of development
... first last call to finish - will be second last call; chief concern: don't want to create spec that is out of step with what authors can expect to find in browsers

<glazou> plh: bwahaha

DS: IE9 implemented lion's share of spec - real value having spec reflecting what is happening in IE9 and other UA releases
... don't want to throw in stuff that won't make it into IE9
... will need to telecon with MS IE devs to find out how much can implement in short time they have
... alternative: if can't get into DOM3 Events, which is an extendable framework, so can add events using DOM3 events framework
... could be stand-alone a11y spec with these events in here, but also think easy wins for DOM3 Events such as undo, redo

RS: 1 events not limited to a11y

DS: not what i said - i meant in a diff spec

JC: section 3 could go into aria spec that uses DOM3 model

RS: IE train has left

DS: not true

RS: that's what IE team tells me - don't think will implement in next 2 or 3 weeks
... real issue is mobile devices - whatever we do, don't want it to take another 3 or 4 years for it to become a spec - IE is 1 implementation, and need 2 for CR

DS: and i don't want to add another 10 years to DOM3

RS: much will be for mainstream mobile apps -- touch, shake, voice-recog -- all need to control apps

DS: possibility of getting some into DOM3 Events - proposal comes fairly late, so there is value in considering idea that some events may belong in another spec

JC: section 3 specific to a11y; UIRequest events is what we want in DOM3 now; undo/redo depends on it; DOMAttrChangeRequest another would like in DOM3
... we believe DOMAttrChangeRequest will not have the same performance implications as DOMAttrModified

DS: one suggestoin: another section 4 around navigator stuff -- is that aimed at HTML5?

JC: not sure where that should move, but HTML5 the best location for it or ARIA 2.0

DS: requested HTML WG look at this?

JC: extensively cross-posted proposal

DS: can we schedule a time when can all talk about this?

RS: have time scheduled during what is usual ARIA call on monday at 10am boston time

JC: when is DOM call?

DS: wednesdays at 1pm boston time
... may need followup meetings

RS: focus on DI Independent events that benefit more than a11y

CL: DougS appreciate flexibility; Janina, thank you for suggesting this joint meeting

<ChrisL> chair: Chris

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/JS: think is ok/JC: think is ok/
Succeeded: s/JC:/DS:/
Succeeded: s/it across the board not just for a11y/it applying to OS- and browser-independence as well/
Succeeded: s/DOMActivate in as placeholder for Rich/agreed to consider OpenRequest and CloseRequest at Rich's suggestion, DOMActivate, EscapeRequest, and DOMAttrChangeRequest may suffice there/
Succeeded: s/browser doesn't have to pay attention to mutations, all it has to do is wait for an AT/we believe DOMAttrChangeRequest will not have the same performance implications as DOMAttrModified/
Found Scribe: Gregory_Rosmaita
Found ScribeNick: oedipus
Default Present: +33.9.50.89.aaaa, glazou, Gregory_Rosmaita, Debbie_Dahl, ChrisL, darobin, Shepazu, Steven, Kazuyuki, Michael_Cooper, Janina, +1.512.567.aabb, jcraig, Rich, Bert, Plh, Janina_Sajka
Present: Bert ChrisL Debbie_Dahl Gregory_Rosmaita Janina_Sajka Kazuyuki Michael_Cooper Plh Rich Shepazu Steven_(muted) darobin_(muted) glazou jcraig
Regrets: Cameron_McCormack Erik_Dahlström Art_Barstow Charles_McCathieNevile Frederick_Hirsch Lofton_Henderson_(partial)
Agenda: http://lists.w3.org/Archives/Member/w3c-html-cg/2010OctDec/0008.html
Found Date: 08 Oct 2010
Guessing minutes URL: http://www.w3.org/2010/10/08-hcg-minutes.html
People with action items: 

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