See also: IRC log
<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
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
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.[End of scribe.perl diagnostic output]