W3C home > Mailing lists > Public > public-html-a11y@w3.org > November 2010

minutes: Canvas Subteam of HTML5 Accessibility TF 2010-11-15 [draft]

From: Gregory J. Rosmaita <oedipus@hicom.net>
Date: Mon, 15 Nov 2010 21:23:52 +0000
To: Charles Pritchard <chuck@jumis.com>, franko@microsoft.com, public-canvas-api@w3.org, public-html-a11y@w3.org
Message-Id: <20101115212239.M7026@hicom.net>

minutes from today's meeting of the Canvas Sub-team of the HTML 
Accessibility Task force are available as hypertext from:


as an IRC log from:


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

sub-team members are asked to:

1. mark your calendars: Canvas sub-team meetings have resumed at their
former time-slot: mondays at 2000h UTC -- more info about meeting 
logistics can be found at:


minutes from past meetings are also available:


2. PLEASE review the latest canvas proposal from rich, archived at:


and begin commenting on-list in preparation for discussion on 2010-11-22

thank you, gregory.


                             - DRAFT -

            HTML Accessibility Task Force Teleconference

15 Nov 2010


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


         Charles_Pritchard, Gregory_Rosmaita, Rich, frankolivier




    * Topics
    * Summary of Action Items

  <trackbot> Date: 15 November 2010

  rich, when you have the time, IA2_ROLE_NOTE aria role note 
  and HTML5 aside:

  <scribe> scribe: Gregory_Rosmaita

  <scribe> scribenick: oedipus




  RS: don't know how much can cover -- only 3 of us on call
  ... getting up to speed
  ... at last TPAC there were a couple of things that got resolved
  ... address RTE but not by first last call -- have to go in and
  address issues in HTML5 spec about what can be renderred inside of
  canvas -- IE team reported that IFrame inside CANVAS subtree needs
  to be explored
  ... need API modifications to contenteditable areas -- ranges for
  grammar and spelling errors

  HTML WG TPAC 2010 F2F Canvas A11y Discussion:

  RS: selection and caret info consistently exposed across browsers --
  compare API notes to ensure that all available and specced out --
  plus need implementations

  HTML Canvas 2D proposal:

  RS: need to work some prototypes to sync what is in contenteditable
  within CANVAS -- textfield synchronization in RTE

  RTE = Rich Text Editor

  HTML Canvas 2D proposal:

  RS: modification based on feedback from James Grahame about rocus
  ... hixie tried to conflate focus ring and caret tracking -- on some
  APIs they are entirely unrelated API calls -- couldn't put X Y
  coordinates into focus ring
  ... width and height attributes for focus ring -- different types
  for diff paths (square, oval, elliptical, etc.)
  ... subtree has element with focus -- used to have parameter
  "CanDrawElemen t" requests OS to do default focus ring call --
  determines success or failure -- if OS can't do, author has to draw
  it so no info on where focus is
  ... modified call to take an element and by default draw FocusRing
  for that element -- A11y API will have all info on it ; use drawing
  tab used before FocusRing call made -- if need high contrast, could
  draw high contrast ring and use that for conveying position to AT
  ... drawing path

  CP: sounds possible
  ... happy to just have shadow DOM in first place
  ... focusRing have to be run against every single element in
  ... haven't used API yet, but simplifying to 1 call is right move
  ... how will caret work is right next step

  RS: like to have CP's feedback on draft attached to agenda
  ... not like a request -- by default, draw what OS specifies (if
  high contrast, then browser needs to follow OS convention and
  respect high contrast settings
  ... doesn't draw caret -- have refresh rates to consider -- can
  cause issues -- we need to be able to get caret position out of
  ... kinda like an a11y API call -- just like focusRing -- element
  with focus that has this caret position
  ... on windows there is SetCaretPosition on windows -- screen mag
  could follow -- have to compensate for "moving windows", so need
  update on browser side
  ... when selecting text in IE, and caret browsing "on" -- selecting
  text with arrow keys, caret moves with where you are selecting --
  rectangle of where selectionPoint is can be exposed

  CP: caret browsing mode shows locked cursor -- exactly how selection
  would work -- has copy+paste and caret position have something all
  can reference -- can we produce that via the API?
  ... 2 things to bring to table: 1) don't understand use case of
  ... nothing on bug list about zooming -- found zooming to be an
  issue -- IE only ones who know what current zoom level is -- canvas
  mapped to device units, if start zooming in will get blurry canvas
  -- need to redraw, but how to do without knowing dimensions need to
  be redrawn -- complicated issue -- hacking way through it on some
  browsers -- related to Windows API but still an issue for...
  ... canvas a11y

  RS: by zoom you mean control/command plus/minus?

  CP: yes

  RS: browser has info...

  CP: in Chrome can grab onRate type event -- in chrome is onResize --
  doesn't happen in FF -- no standards event for zoom -- need to know
  relative ratio for zoom so can redraw clean and crisp canvas
  ... found this to be a11y problem, because i use a computer monitor
  for TV screen -- if don't have zooming, have to use CSS zoom which
  blurs; if know pixel relative measurement, can get clean zoom
  ... MS done well; Chrome needs patch, FF in "logical pixels"

  <frankolivier> , a media query based approach was introduced on the
  webkit blog some time ago:
  http://webkit.org/blog/55/high-dpi-web-sites/ but afaik is not
  actually implemented anywhere.

  CP: need to know zoom onLoad

  RS: return what?
  ... integer?

  CP: need to talk about with MS -- as long as zoom changed, can get
  that info -- zoom event gets window.screen to get relative pixel

  RS: change in zooming level should be accurate

  CP: just peeking into window.screen to get pixel coordinates

  RS: have MS app?

  http://msdn.microsoft.com/en-us/library/ms533721(VS.85).aspx -

  CP: window.screen.logical.devicexdpi

  RS: will return x and y position

  CP: returns DPI -- can derive x and y -- want consistency across
  browsers so that zooming works as well as native zoom in UAs
  ... why IFRAME inside a CANVAS?
  ... if inside CANVAS could be there if canvas not supported and want
  to fallback to IFRAME in old browser

  RS: need to log defect on zooming
  ... i will log bug for that

  FO: webkit blog mentinos approach to solving same problem -
  ... proposal on 26 April 2006 on returning zoom level via media
  queries -- don't think implemented anywhere

  CP: using webkit device pixels ratio as windows variable -- will see
  only on iPhone probably -- extended to targetdensityapi done by
  google for android -- 2 media queries, may need one more -- what is
  there isn't sufficient -- works with CSS and window.global

  FO: the google approach?

  CP: no -- that was guessing -- on android have targetdensity API
  close to zoom level but more semantic infor
  ... will send link to list

  RS: 1 thing CP asked for is zoom event -- is providing another
  missing event an issue for IE?
  ... instead of pulling API values, have a zoom event -- use
  control/command plus/minus app detect that to make changes to canvas

  CP: zoom event clarification: as long as window.screen is included
  and fires, can use it -- reason for zoom event is more semantics --
  need standardized behaviour for resize function

  RS: chrome have resize or zoom

  CP: chrome triggers reszie on zoom -- just implemented something new
  -- using window.screen on windows, can get info perfectly

  RS: resize event -- need to state that zoom triggers a resize

  CP: that would do it

  RS: logical approach cross-browsers
  ... compute the resize on zoom
  ... have to decide if 1 or 2 defects to log
  ... explained current version of API based on JGrahame's feedback
  ... explained rationale behind changes

  FO: didn't hear

  RS: originally, was DrawFocusRing in canvas 2d api that took an
  element, an xy coordinate, and a request to have browser do drawing
  based on system settings

  <Downchuck> something of a summary about target-densityDpi and

  RS: 2 problems: x and y positions for caret are dealt with
  separately from FocusRings
  ... second: provide x y position and width and height -- asked to
  use current drawing path before call DrawFocusRing so can calculate
  focus rectangle for api based on that -- also, can you do high
  contrast settings
  ... problem with spec text is if can't do FocusRing, have
  author-defined FocusRing which system can't find -- collapsed into 1
  call -- if OS can draw FocusRing bassed on system settings

  FO: will review and comment in detail on list

  frankoliver, HTML Canvas 2D proposal:

  RS: CaretSelectRectangle -- hixie wants tied to drawing call -- SO,
  to set caret position, like to go through API again next week to see
  if any issues that need correcting

  CP: CaretSelectionRates -- issue: can't get baseline of text i'm
  using without more info on current font (basefont determines
  relativity -- don't want caret jumping all over the place
  ... tried to propose in a few fora -- extend MeasureText -- only has
  legnth -- don't need height, but need baseline to draw rectangle or

  RS: want to propose a modification and post to public-html-a11y and
  ... look at baseline text
  ... caret blink rate: weren't going to have for RTE, but if
  reproducing in TEXTAREA need to know blink rate -- please look at
  that API
  ... have to modify hixie's example -- broken in several places
  ... question for FO -- IE can put elements in subtree in keyboard
  navigation -- is that in IE9 beta?

  FO: in IE9 beta -- should work for many issues
  ... been extensively tested -- doubled "get cost"

  RS: certain nodes that shouldn't be allowed -- FRAME and IFRAME

  FO: FRAME and IFRAME security risk when below non-visual layer
  ... agree no FRAME or IFRAME in CANVAS
  ... define what controls can be used -- radioboxes, checkboxes, etc.
  -- visual authoirs should make canvas as simple as possible

  RS: basic DIV and SPAN and few simple things like INPUT type="text"?

  FO: reuse INPUT types -- checkboxes; text entry more tricky -- need
  to do a lot more work as said at TPAC

  RS: what about DETAILS?

  FO: good question -- will mull on it

  RS: FO, will you list thngs that will be real problems -- FRAME,
  IFRAME and what else?

  FO: will put together list

  RS: canvas should not be a child of canvas!

  CP: IFRAME, FRAME and CANVAS are the only ones -- should be possible
  to take existing web page go underneath BODY and wrap all in CANVAS
  -- if don't support canvas, go back to native rendering -- only
  restriction is need fallback content to work and to show up if want
  it -- SCRIPT, IFRAME would have security issues


  RS: asks FO about cross-browser comparison promised at TPAC

  FO: need a few more days

  RS: did mention getting selection objects; spelling and grammer
  window.get spell or grammar errors that pulls back collection of
  ... prototype in IE? don't see FF working on CANVAS before 4.0
  ... FO have cycles for this?

  FO: focused on shipping IE9

  RS: timeframe? how much longer?

  FO: no answer to that
  ... prototyping may not be possible until beginning of 2011

  RS: examples of RTE on CANVAS

  CP: started project a while ago -- tried to implement full set of
  layers needed for RTE -- what to do with CSS? how to use DOM? all
  issues down to text-entry -- spec has ranges and contenteditable, so
  stopped thre -- text entry works nicely apart from baseline issues
  -- DIV contententeditable -- some internal APIs but hope to tweak
  that as spec allows

  RS: open source

  CP: will send URIs to list -- open and runs on few diff environments
  -- details to follow

  RS: so -- group review needed to
  ... please review attachment
  ... CP will make proposal for baseline text, right?

  CP: yes

  RS: please modify attachment to do that

  CP: great to get this aired and worked on

  RS: eliminating elemtents in CANVAS sub-tree will help us
  ... mobile community -- talked about HTML profiles

  HTML WG TPAC 2010 F2F Canvas A11y Discussion:

  CP: done it -- documented what profile is as part of this RTE
  inquiry -- CANVAS has instrinsic link with CSS (subset of CSS) --
  will speak to that have a lot of experience in that area

  [ADJOURNED - next meeting next monday]

Summary of Action Items

  [End of minutes]

Received on Monday, 15 November 2010 21:24:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:47 UTC