minutes: Canvas Accessibility subteam telecon 2010-11-29 [draft]

aloha!

minutes from the 29 november 2010 Canvas Accessibility subteam 
weekly teleconference are available as hypertext from:

http://www.w3.org/2010/11/29-html-a11y-minutes.html

as an IRC log at:

http://www.w3.org/2010/11/29-html-a11y-irc

and as plain text following this announcement -- as usual, please
log any comments, clarifications, corrections, mis-attributions and
the like by replying-to this announcement on-list

note that the next Canvas A11y Subteam meeting will be held on 
Monday, 6 December 2010 at 2000h UTC -- logistics and other meeting
info available at:

http://www.w3.org/WAI/PF/HTML/wiki/Canvas/Meetings

gregory.
    _________________________________________________________

                             - DRAFT -

            HTML Accessibility Task Force Teleconference

29 Nov 2010

Agenda
http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/0050.html

  See also: IRC log - http://www.w3.org/2010/11/29-html-a11y-irc

Attendees

  Present
         Gregory_Rosmaita, Rich, Charles_Pritchard

  Regrets

  Chair
         Rich

  Scribe
         Gregory_Rosmaita

Contents

    * Topics
        1. Demo
        2. Review Charles' change to <canvas> in HTML 5
        3. Review of Charles updated draft change proposal to
           Canvas 2D API
        4. Mozilla's refusal to supply the API needed in
           http://www.w3.org/Bugs/Public/show_bug.cgi?id=11328
        5. Implementation of Canvas 2D API context changes for non
           Rich Text Editing scenarios
        6. Steps to assess what HTML elements are allowable in the
           shadow DOM
        7. What are the next steps to address Rich Text Editing in
           HTML 5?
        8. To Do
    * Summary of Action Items
    _________________________________________________________

  <trackbot> Date: 29 November 2010

  <richardschwerdtfe> meeting: W3C Canvas Accessibility subteam

  <scribe> scribe: Gregory_Rosmaita

  <scribe> scribenick: oedipus

Demo

  CP: can fake some things - hitting certain checkbox would cause to
  do a select range -- more of a unit test

  GJR: yes, add things incrementally

  CP: test of API without having to know where to paint things
  ... ways we can start from ground and test it out

  RS: need UA vendors to make change or create java applet to move
  caret

  CP: like i did for focusable, can do for demo purposes --- need to
  compare cross-browsers
  ... for IE9, can make demo that doesn't need to have rich text
  editing ability but demo it will work -- draw caret in x y position
  -- just draw caret at appropriate blink rate and place
  ... hooking up to mouse right now not issue for testing purposes

Review Charles' change to <canvas> in HTML 5

  CP: filed sub-tree with WebKit -- will try and push with Chrome

  RS: defect logged against FF, but probably won't make for FF4

  GJR: DBolter told me FF4 API frozen

  HTML Canvas Element:
 
http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/att-0050/HTML_Canvas_Element.html

  CP: stuck in sentence -- none of elements in shadow DOM should be
  initializaed on OnPageLoad -- if IFRAME has src won't be loaded at
  window load -- need review by FO

  RS: that would go under which defect?

  CP: knowing which elements are to be supported
  ... don't be initialized if don't need be rather than list of
  elements

  plus 1 to CP don't be initialized

Review of Charles updated draft change proposal to Canvas 2D API

  HTML Canvas 2D Context:
 
http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/att-0050/HTML_Canvas_2D_Context.html

  CP: primary change had caret xy position based on text
  directionality

  RS: don't have problem with coordinate -- if selecting text and
  going to right, it is last position

  CP: understand --don't know if needs to be defined -- anyone
  programming will notice cursor placement problems

  RS: want to ensure that on a Mac, don't have caret tracking while
  doing selection -- had when selecting text going in certain
  direction, so is last thing selected

  CP: gotcha

  RS: if going to the left, last on left, if going to right...

  CP: when text selected, not caret

  RS: right

  CP: that is where caret is drawn so needs to be accessible
  ... kinda covered by note saying last drawn position must be tracked
  ... understand what RS intended now -- thought was related to single
  char

  RS: last char that got selected

  CP: exactly

  RS: take another pass at it?
  ... trying to get legal to look at code

  CP: will take another tweak -- if have any other feedback let me
  know

Mozilla's refusal to supply the API needed in 
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11328

  RS: pixel coordinates x and y pixel API

  CP: didn't want accessible to untrusted environment
  ... when installed as extention

  RS: how do you mean?

  CP: trusted extention -- plug-in -- put under security issue, though
  not
  ... trusted script usually because of security or very proprietary
  ... not available to normal web scripting environment -- didn't want
  people to tinker with zoom -- not tinkering, but being aware things
  are bigger -- diddn't want because said programmers wouldn't use
  correctly

  RS: in IE

  CP: don't care -- not going to move on it without mozilla support

  RS: if author wants to change view of canvas, what is problem?

  CP: someone will misinterpret screen metrics to implement own zoom
  effects -- use CSS zoom rather than onClick zoom -- based on idea,
  not going to give web devs one more thing to do wrong -- countered
  that good documentation would counter that; is a11y issue that
  affects people now, and have a proposal, but dead end -- is trying
  to use CSS media queries, but don't know if can get single...
  ... value from media queries

  RS: email?

  CP: on what wg list

  RS: will talk with david bolter

  CP: will send out summaries to try and get more than 1 person's
  attention on it

  davidb, can you help push moziilla on bug 11328?

  RS: if documented in HTML5 spec, that would be right answer

Implementation of Canvas 2D API context changes for non Rich Text
Editing scenarios

  RS: i'm working to get approval on that
  ... need FrankO for HTML elements that are allowable
  ... CP does your change address that?

  <davidb> oedipus, what bug database?

  davidb, http://www.w3.org/Bugs/Public/show_bug.cgi?id=11328

  CP: better approach is to keep src from initializing, not to have
  list of elements

Steps to assess what HTML elements are allowable in the shadow DOM

  RS: need to get cross-UA support

What are the next steps to address Rich Text Editing in HTML 5?

  RS: trying to get ok from attorneys to work on this
  ... have to write API addition for grammar and spell checking to get
  ranges

  CP: brought that up in WHAT WG -- got response from most UA vendors
  -- trying to push to get something out of them, but no spell
  checking a11y from DOM on basis of privacy concerns

  RS: that is fallacious

  CP: contenteditable -- addressed on own grounds -- trying to find
  middle ground -- not going to allow full API in untrusted scope --
  if added password to list of suggested spellings, that password
  might be exposed via brute force, so any addition to dictionary is
  private
  ... raised "getSpellingRange" -- replied that going to expose user's
  language and their OS -- replied already have that exposed

  RS: can get ranges for selectoin

  CP: worried if have system dictionary and says something is
  misspelled, can tell what lang dictionary user is using -- exposing
  what natural language user preferes

  RS: just asking for where spelling is

  CP: for example color versus colour
  ... can we at least get range?
  ... even with range, they said security issue
  ... CSS proposal for highlighting -- without ranges, can only
  highlight -- can't make bigger because don't know range
  ... why not open to discussion so don't have separate APIs or use
  system prompt and make that a function, but so far, been met with
  negativity -- trying to make problem as small as possible

  RS: need to make proposal for it, submit it, and say "this is what
  we need for someone with low vision to operate a canvas RTE for
  spelling and grammar errors" and let them say "can't be done" if
  that is their opinioin

  CP: contenteditable is the key
  ... spelling a defect in contenteditable, not in each UA

  GJR notes still needs to route mouse cursor to speech cursor to get
  right-click dictionary entries in FF

  RS: where is this defined?

  CP: MSDN has APIs

  RS: HTML5 APIs for getSelection

  CP: think is under ranges
  ... API for text field selections
  ... single textarea API

  RS: link?

  <Downchuck>
 
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#textFieldSelection

  <Downchuck>
  http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html

 
http://dev.w3.org/html5/spec/association-of-controls-and-forms.html#textFieldSelection

  RS: need to add for grammar
  ... use ranges for grammar

  CP: makes sense

  RS: getSpellingRanges and getGrammarRanges

To Do

  RS: will write change proposal for that section

  http://dev.w3.org/html5/spec/webappapis.html#webappapis

  http://dev.w3.org/html5/spec/editing.html#contenteditable

  CP: leave off to UA and DOM

  RS: need one for selection, as well

  CP: "UA should offer way to move images..."
  ... about non-editable elements inside hosts -- drag'n'drop images
  ... trying to keep contenteditable entirely within UA -- will send
  summary of proposals to RS to work with

  RS: in contenteditable says up to UA to get selection?

  CP: basically

  RS: should or must?

  CP: not uppercase must, but prose must

  RS: we can just add text to do selection and query for ranges of
  grammatical and spelling errors

  CP: using GetRanges or getSelection -- easier to do on a given
  element -- either would work -- from HTML5 viewpoint, that is all UA
  side and not exposed to scripting environment

  RS: should be allowed ability to get selection?

  CP: could make a selection, don't talk about getting a selection --
  can make selection with KeyDown events -- completely undefined save
  for drag and drop
  ... input method editor with spelling, grammar, etc. entirely up to
  UA and should not be scripted seems to be the spec's leaning

  RS: work on change for that
  ... could provide annotation/non-visible attribute (grammarerror
  tag) for elements that say this is beginning of grammatical range

  CP: a tag is technically semantic...
  ... what about spelling or grammar tag so is marked up is reasonable
  to have in HTML5 spec

  RS: that way, author of page can mark spelling or grammatical error
  -- write own grammar or spelling checker for canvas

  CP: applications -- canvas is a method
  ... would allow author to convey spelling mistake in text and would
  look/render same as other spelling mistakes

  RS: like to run this by frankO -- don't expose what is inside
  contenteditable section, then allow author to annotate in markup
  beginning of a grammatical error section, go through DOM to mark --
  could then style it and do all sorts of stuff

  CP: absolutely

  davidb, thank you

  RS: propose a few new tags until more malleable on contentditable
  ... will ask FO what route to travel: work on contenteditable or
  introduce spelling and grammar tags

  CP: could do in ARIA -- aria-spellingerror

  RS: put on list for ARIA.next

  CP: spelling tag a good idea -- it is just a tag -- whatever styling
  one is using, use on this span

  <scribe> meeting: HTML Accessibility TF Canvas Sub-Team

Summary of Action Items

  [End of minutes]
    _________________________________________________________