minutes: Hypertext Coordination Group Teleconference 2010-10-08 [draft]

aloha!

minutes from the 8 October 2010 Hypertext Coordination Group telecon
can be accessed as hypertext at:

http://www.w3.org/2010/10/08-hcg-minutes.html

as an IRC log at:

http://www.w3.org/2010/10/08-hcg-irc

and as plain text following my signature -- please report any errors,
omissions, clarifications, mis-attributions and the like by replying-to
this announcement on list...  note that while i (mostly) used initials 
to indicate speakers, i have tried to identify those who are not 
regular participants in HCG and attempted to gloss unfamiliar 
abbreviations (such as a11y = accessibility) when i could...

thanks to HCG and ChrisL for devoting the vast bulk of today's 
meeting to the discussion of the UI Indepenence proposal so as 
to coordinate close future collaboration, gregory.
    _________________________________________________________

                             - DRAFT -

             Hypertext Coordination Group Teleconference
                            08 Oct 2010

Agenda
http://lists.w3.org/Archives/Member/w3c-html-cg/2010OctDec/0008.html

  See also: IRC log - http://www.w3.org/2010/10/08-hcg-irc

Attendees

  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)

  Chair
         Chris

  Scribe
         Gregory_Rosmaita

Contents

    * Topics
        1. Quick Action Item Review
        2. User Interface Independence for Accessible Rich Internet
           Applications
    * Summary of Action Items
    _________________________________________________________

  <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> 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"
  http://www.w3.org/TR/DOM-Level-3-Events/#key-values

  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

Summary of Action Items

  [End of minutes]
    _________________________________________________________