minutes: Canvas Accessibility Subteam meeting, 2011-01-31 [draft]

aloha!

minutes from the 2011-01-31 Canvas 2D Context Accessibility subteam
of the HTML5 A11y Task Force can be accessed as hypertext from:

http://www.w3.org/2011/01/31-html-a11y-minutes.html

as an IRC log at:

http://www.w3.org/2011/01/31-html-a11y-irc

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

please note that the following RESOLUTION was recorded at the 
2011-01-31 telecon:

   RESOLUTION: Canvas 2D Context - position must be programmatically
   determinable via API, based on UA supporting a11y services to drive
   caret tracking; need to do selection tracking as well; on mobile
   devices no vehicle to capture -- all need programmatic access

     _________________________________________________________

                               - DRAFT -

             HTML Accessibility Task Force Teleconference

31 Jan 2011

Agenda
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0054.html

   See also: IRC log -  http://www.w3.org/2011/01/31-html-a11y-irc

Attendees

   Present
          Gregory_Rosmaita, Charles_Pritchard, Rich

   Regrets
   Chair
          Rich

   Scribe
          Gregory_Rosmaita

Contents

     * Topics
         1. Status Report
         2. Caret Blink Rate
         3. TextExtent
         4. Canvas: Initialization of resources (such as IFrame) in
            canvas
         5. Positioning Information
     * Summary of Action Items
     _________________________________________________________

   <trackbot> Date: 31 January 2011

   <richardschwerdtfe> Meeting: HTML Canvas Accessibility Working Group

   <scribe> scribe: Gregory_Rosmaita

   <scribe> scribenick: oedipus

   * latest draft of CanvasEditor.html:
  
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0054/CanvasEditor.html

   * latest draft of HTML_Canvas_Element.html:
  
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0054/HTML_Canvas_Element.html

   * latest draft of HTML_Canvas_2DContext20110123.html:
  
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0054/HTML_Canvas_2DContext20110123.html



Status Report

   RS: filed big bug against chromium that kept from accessing the DOM
   -- FSci got a "drop" with that progress
   ... DavidB trying to get feedbaack from mozilla this week
   ... contact Benjamin Hawkes-Lewis (hereafter BHL) about API
   proposal?

   CP: Benjamin Hawkes-Lewis -- replied to his email

   http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0052.html

   from agenda: "Note: Benjamin appears to want to separate out caret
   and place it in James Craig's proposal so that it caret positioning
   (for magnification) can be used more broadly such as for SVG. Is
   this something we need to do?"

   RS: sounds like he would like us to take caret and positioning out
   and separate -- can do if group decides that is path to follow

   CP: need to review proposal more thuroughly -- some items could be
   taken care of with additional language -- integration with other
   docs are good, but don't want to swell proposal

   RS: "adjust caret or selection position" rather than upper lefthand
   corner
   ... our API is only for Canvas 2D API -- not for SVG or other
   rendering strategies
   ... so question is does this sync with James Craig's UI Independence
   Proposal
   ... take out of this spec and put into JCraig's proposal or leave in
   draft text

   CP: not sure -- canvas does exist independently outside of HTML --
   would help of APIs directly acessible
   ... other proposals based on SVG schemes or HTML where outline more
   visible

   RS: which proposals?

   CP: diff between canvas rendering content?

   RS: context associated with canvas

  
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0054/HTML_Canvas_2DContext20110123.html

   CP: 2D spec something more "independent" of HTML
   ... where boundaries are has yet to be defined

   RS: listed under HTML5 -- under dev.w3.org/html5

   <richardschwerdtfe> http://www.w3.org/html/wg/

   CP: in canvas+javascript model needs a firm definition of canvas --
   a lot of integration necessary

   RS: at the moment, 2D context still listed as deliverable of HTML WG
   -- 20 january 2011 draft

   CP: will email Doug S -- will be able to inform me

   RS: see where adobe would want this -- rendering engine could run
   canvas on diff platforms
   ... have until 28 February 2011 to get proposals for caret stuff
   done for HTML5

   TOPIC 1: Discuss Canvas 2D API caret positioning, blink rate, text
   extent

   RS: ben's comment not applicable as long as canvas 2d api context is
   part of HTML5
   ... canvas element subjected to warping using CSS 3D warping --
   seems a bit off topic

   CP: noted that -- focus on what is in canvas 2d context api only
   ... maybe some text or phrase that integrates well with CSS specs --
   terminology issue

   RS: how to compute rectangle
   ... explained how to get positioning in reply to BHL's post
   ... explained best fit for drawing path -- seems basic -- do we
   actually need more text?

   CP: will reply to rest of BHL's email to keep conversation going

   RS: what does BHL want?

   CP: DOM minor additions for clarification
   ... want to avoid defining a lot of things -- should be up to AT and
   UA implementation to decide what to do with info we are providing --
   we provide the basic info to the AT so that AT can do better job

   RS: ZoomText - magnifiers not able to detect when browser running
   directly to hardware -- no hooking for AT to see this -- sent of
   sample to Sean from AISquared and did not work (as expected) -- need
   second caret position -- programmatic API
   ... need someone to implement that -- google plans? add canvas
   sub-tree when works with JAWS?

   CP: that was my understanding; posted to Webkit -- no issues on this
   -- everyone wants shadow DOM
   ... implementing shadow DOM method is a VERY QUICK INEXPENSIVE thing
   ... can get patch to google with method once get thorugh first steps

   RS: magnifier vendors used to track bit blips and polylines from
   graphics engines -- due to way browsers now draw to screen, unable
   to capture drawing calls to fract the carets

   proposed RESOLUTION: Canvas 2D Context - position must be
   programmatically determinable via API

   proposed RESOLUTION: Canvas 2D Context - position must be
   programmatically determinable via API, based on UA supporting a11y
   services to drive caret tracking

   proposed RESOLUTION: Canvas 2D Context - position must be
   programmatically determinable via API, based on UA supporting a11y
   services to drive caret tracking; need to do selection tracking as
   well; on mobile devices no vehicle to capture -- all need
   programmatic access

   RESOLUTION: Canvas 2D Context - position must be programmatically
   determinable via API, based on UA supporting a11y services to drive
   caret tracking; need to do selection tracking as well; on mobile
   devices no vehicle to capture -- all need programmatic access

   RS: if app draws to windows hardware directly will be invisible to
   SR and ScreenMag unless using AT services

   CP: wanted to note that there is a reason to have CANVAS element in
   fallback -- show higher rez canvas element so not burry -- applies
   to "normal" browsers as well
   ... graphic rendering on CPU if API exposed, performance
   dramatically increased
   ... going to be pushback on stuff like "zoom" because they think in
   the CSS box -- apply a scale to get "perfect" zooming -- anything
   that exists outside of that from AT vendor not well received
   ... main issue isn't how define caret, but whether we do
   ... do we have an argument that works/consensus on caret tracking in
   canvas? drawFocusRing removes x,y tracking, so need caret to move
   proposal forward
   ... problem explaining why useful, more efficient -- put up use
   cases and scrreen shots but no feedback from mozilla or MS --that is
   a sticking point -- how to procede if that need isn't recognized

   RS: set drawing tab, and...

   CP: so far haven't heard "yes, we want selection rectangles"

   RS: want to do based on a drawing path that exists?

   CP: not exactly -- haven't expressed willingness to do at all -- i
   like the rectangle -- easy to implement and works -- only feedbackk
   so far from BHL
   ... why do you need this? what is use case?
   ... if get mozilla on board to say "yes" to rectangle...
   ... right now, IE9 is ahead of the game --

   RS: need 2 implementations -- IE9 is one, if get chromium to
   support, then have 2
   ... if get chrome to say they support before 28 february 2011

Caret Blink Rate

   RS: resistence to this -- privacy concerns? blink rate doesn't
   really reveal a lot about user and capabilitites -- don't see any
   issues with that
   ... do we want blink rate in spec?
   ... getting implementation so don't want to push things off until
   june timeframe (when JCraig can work on DI Independence proposal
   with DougS)
   ... property verus method
   ... properties in 2D api?

   CP: no, not really -- has centers on all of its properties -- this
   will not have center -- canvas API follows CANVAS not DOM

   RS: at this point do we want to have it return a value?

   CP: leave as function for ease of implementation in many
   environments easier to do function call
   ... minor point -- important, but minor
   ... need accept caret point with height -- after that the rest is
   relatively easy

   GJR: plus 1 to get/function

   CP: prefer "get" function

   [we 3 are in accord]

   RS: BHL wants to avoid profiling and hard coding
   ... default value of 500 milliseconds?

   CP: don't see problem with author defining blink rate if not set by
   user -- user setting of blink rate lost if use default
   ... don't think necessary

   plus 1 to CP -- user control, not default setting

   RS: leave as-is
   ... if anything below twice a second, can introduce a seizure, hence
   request for 500 mpbs

   CP: is something for UAAG

   RS: can modify section to start with user agent directive to default
   to 500 milliseconds

   CP: UA might have minimum -- can return -1

   RS: author doing drawing

   CP: point for implementors to know about (seizure info(

   RS: will modify section
   ... move into JCraig's proposal? don't know how will be accepted or
   by whom

   CP: this needs to be stand alone canvas support
   ... address magnification in context of canvas accessibility -- no
   brainer

TextExtent

   Benjamin's comment:
   http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0050.html

   RS: looks like an attempt to explain the need for text extent
   ... text extent versus caret position -- he is confused
   ... bug regarding TextExtent - -hixie asked for use case

   CP: tried to post text to get reply
   ... no one bit
   ... tried to submit use case to BHL -- links to 2 span elements on
   first line, canvas on second line with fixes; and canvas on 3rd line
   without fixes to show all the items we are proposing -- can't
   caputre FocusRing in windows the way i wanted to do

   RS: when you move to menu, focus disappears

   CP: will try again
   ... was using ZoomText at time
   ... meant to be use case example -- if have idea hixie won't knock
   down out-of-hand, then can write any UI widget needed, but text is
   where pushback comes -- rebuttal, not argument

   RS: address point of why need TextExtent for canvas?

   CP: need so that i can position elements within a box -- can use 2
   differently sized fonts on 1 single baseline

   RS: need some text from CP -- where baseline is reference?

   CP: not how i groked it, but can get text together
   ... when baseline info brought up in standards doc, have to use PNG
   file -- can't use code to show where baselines are -- when info not
   available VERY difficult
   ... will try again

   RS: need to put response into bug itself

   CP: will write some text for thwat

   RS: if get text to me today, can make change today

Canvas: Initialization of resources (such as IFrame) in canvas

   RS: waiting to hear from FrankO about that

   CP: need consensus from Webkit and Mozilla

   noVNC - VNC client using HTML5 Canvas:
   http://kanaka.github.com/noVNC/

   RS: web based VM tied to web services -- getting all low level
   drawing calls being passed to canvas -- the only way to do is
   windows Terminal Serivces has no semantic info such as "here is the
   caret" -- not enough semaqntics to support A11Y
   ... can't process without services

   CP: gain if used

   RS: other way to do is have AT running on remote host

   GTK client on HTML5 canvas:
   http://blogs.gnome.org/alexl/2010/11/23/gtk3-vs-html5/

   <Downchuck> have AT running on the web service, such as terminal or
   vnc


Positioning Information

   RS: magnifiers need to know where text is on screen -- need for
   braille device, as well
   ... approaches: 1) use CSS to position things in shadow DOM or 2)
   layout engine map to a11y services layer; or 3) what IMAP does (X,Y
   positioning info on each DOM node)
   ... problem for text wrapping

   CP: search for text on screen -- finds that upstream -- use
   selection API and modify shadow DOM with mark elements -- solid use
   case for mark elements
   ... when go through DOM know where canvas object is
   ... might work without recourse to IMAGEMAP
   ... drawFocusRing and mark
   ... braille devices are a next step after address magnification

   GJR: which CSS?

   <richardschwerdtfe>
   https://developer.mozilla.org/en/drawing_text_using_a_canvas

   <Downchuck>
   http://dl.dropbox.com/u/17337752/text-legibility-crop.png

   http://www.w3.org/WAI/PF/wiki/CSS/tactile_braille_and_haptic

   CP: horizontal select box illustrated in
   http://dl.dropbox.com/u/17337752/text-legibility-crop.png -- UI
   widget in canvas that required a LOT of work to make look acceptable

   RS: apply media types to content?
   ... do something to shadow DOM?

   CP: need to tie in shadow DOM --
   ... need to enable select, too

   RS: will follow up in bugzilla
   ... will look at blink rate and glossary stuff -- follow up on bug
   -- see what can do with google
   ... timeline for shadow DOM implementation by chrome?

   CP: no definite timeline -- 28 February 2011 tight deadline

   RS: DavidB promised feedback from mozilla

   CP: extensive use of shadow DOM being contemplated by Mozilla

   RS: a11y has so many cross-cutting applications that help everytone

Summary of Action Items

   [End of minutes]
     _________________________________________________________

Received on Monday, 31 January 2011 21:42:29 UTC