See also: IRC log
<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
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
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
... 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
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
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
... 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
... 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
... 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
... 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
... 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
... 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
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
... 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
... address magnification in context of canvas accessibility -- no brainer
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
... 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
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
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?
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
... do something to shadow DOM?
CP: need to tie in shadow DOM
... need to enable select, too
RS: will follow up in
... 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
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/brialle/braille/ Succeeded: s/TOPIC 1: Status Report/TOPIC: Status Report/ Succeeded: s/Ben about API/Benjamin Hawkes-Lewis (hereafter BHL) about API/ Found Scribe: Gregory_Rosmaita Found ScribeNick: oedipus Default Present: Gregory_Rosmaita, Charles_Pritchard, Rich Present: Gregory_Rosmaita Charles_Pritchard Rich Agenda: http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0054.html Found Date: 31 Jan 2011 Guessing minutes URL: http://www.w3.org/2011/01/31-html-a11y-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]