See also: IRC log
<trackbot> Date: 10 January 2011
<richardschwerdtfe> Meeting: HTML Canvas Accessibility subteam meeting
<richardschwerdtfe> can you call in Gregory?
i'm on the phone
<scribe> scribe: Gregory_Rosmaita
<scribe> scribenick: oedipus
Tim Lalor: senior engineer, AISquared (make ZoomText)
Shawn Warren from AI Squared
CP: magnification brings unique challanges -- doing zoom doesn't garuntee magnification
RS: what canvas is in HTML5
... canvas isn't a lot different from windows -- drawing to canvas in windows environment -- big issue for a11y -- how to convey info to an accessibility API on any given platform
... got fairly long way along
... inside of CANVAS to make accessible, created sub-tree in UA so that can create HTML elements representative of objects drawn to canvas can be mapped to a11y API -- could alos markup with ARIA -- all would populate a11y API
... no a11y API where js can do stuff like that
... what info is absolutely essential for screen magnification?
... proposal - FocusRing would be trackable from a11y APIs
... caret positioning proposal -- is this enough for magnification?
... clipping of text and exposition of clipped text -- issue for magnification if no positioning info -- other strategies?
... move focus position to content -- moves focus position on screen?
... trying to walk fine line: what is necessary for author to do and AT to have
TL: looks like CANVAS is opaque
to us right now
... few pieces: focus events are key -- need to know where to track the view -- if can capture focus event, will help us understand where viewport of magnifier should focus on -- FocusRing
... caret tracking also fundamental for screen mag -- maintain in view and wrap in locator
RS: have to get WG sign-off on
FocusRing proposal -- waiting for MS feedback
... changes to spec that refer to that -- example of 2 checkboxes (don't have FocusRing drawing in API)
TL: used ARIA-selection of "no-width" for caret
RS: for caret istelf, yes --
proposal is caret selection would know if RTE
... added API to 2D Canvas context http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0002/HTML_Canvas_2DContext120910.html
... use actual textfield or checkbox in subtree -- process as usual, provide positioning info
TL: scrolling into view as
content consumed and presented to user, need to highlight
... imagine canvas a single sentence clipped by bounding rectange; need to drive presentation of canvas (scroll to left) -- 2 parts: position info; being able to drive viewport of canvas itself
RS: charles is our resident
... can't markup position of text in sub-tree
CP: can't do with textarea -- no API for this
SW: have ScroolTo -- API not
there -- nothing to model on to write in standards
... done RTE with scroll bars; know where cursor is; TEXTAREA element is quite basic; contenteditable also very basic
RS: question: if have ability to move caret position thorugh a11y APIs, would that be picked up by app for positioning
SW: will work if trying to
navigate between text; but if want to scroll down 20 pixels,
how does one do that?
... single-line text editing with input box laid over picture -- if type a lot, shifts to left -- HTML forms a "bit" deficient in this area
TL: static content and dynamic
... is there way to scroll data content so can use highlight as march across section; scroll when reach right edge
SW: setting caret position good
enough for most of that -- can be recalculated before scroll --
automatic word-wrapping a BIG problem
... looking at windows API -- magnifier is a sub-window that accesses same content at diff zoom level and may have diff selection objects
... another issue: when zoom in using UA zoom, CANVAS doesn't know how to handle content -- ensure not blurry -- pixel offset needs to be tackled
TL: selection and caret location:
1 distinct case is diff controls and selection events for
multiple characters and words selected
... raised as events? caret move with selection? or mouse selection across text
CP: have OnSelectStart
... related to input method edititors
... onSelectStart only selection event -- more would be helpful
... some push-back on input method editinig -- should it be up to OS, browser vendor? when UA vendor hasn't implemented, what to do?
... this is a good use case -- can't get anywhere without additions to APIs
... will help counter push-back
... bare essentials necessary
... need scroll events and selection events that work in TEXTAREA
TL: help us in dynamic area -
-when user typing to know what selected -- could span more than
is visible -- helps to know what user is actually selecting so
can keep scrolling view and can tell user what is
... watch text and background colors
... when API available, use it; when not available, have heuristics
CP: list of API holes?
... or incomplete implementation of API
RS: AT immunity -- have to be cognizant of propritary methods
TL: use open standards -- focus on APIs not heuristics
CP: heuristics too hairy for me -- you guys know the standards -- if anything you can share for input method would be appreciated
TL: using MSAA standard Windows
events and UIA
... evaluating UIA's integrity
TL: playing with it--in roadmap -- other higher priorities
RS: can you post what window events and APIs you are using?
TL: window events is a kind of
... other APIs pretty self-explanatory
RS: use MSAA standard windows events for showing/hiding?
TL: selection: MSAA provides data on current selection, comparison to cached version,
RS: IA2 does selcetion
... selection change events at high level -- how tell if something scrolled off screen?
TL: those are used in some
scenarios, but use API to compute visability
... couple of levels of visability: visible on page; rendered but clipped; not rendered anywhere (on or off screen)
... where heuristics come into play -- if user scrolls, then render
... what would the API be if one were available?
... API that reduces need for heuristics?
... UA devs need to know what needs to be there
RS: take content and select it --
aria-selected -- could mark area -- receive notification events
under the covers
... positioning info
CP: what positioning info is needed?
TL: CANVAS completely contains text, would like to highlight each word inside of canvas in a sequence -- speak word and highlight even if not editable -- positioning critical to displaying highlight
CP: can you get away with next word?
TL: if way to enumerate can wrap rectangle around it
CP: as long as going word-to-word
... problem with older verions of IE -- but enumerating works
RS: suggesting notification from AT to enumerate words?
CP: getNextElement or getNextChild --- from current position go to next word
RS: how AT call into UA to get
CP: when highlighting interacting with DOM or IME
TL: when highlighting may leave UA rendering alone before write anything to screen
RS: canvas author draws pre-rasterized text
CP: optimized to be pre-rastorized
RS: how to highlight once happens?
CP: going to need to determine if caret moves
TL: know where next word is or
next sentence -- in our own way, can do highlighting as goes to
screen -- flatten image, so canvas not effective -- can't use
canvas to do stuff inside canvas -- have own tech to highlight
... hesistant to move cursor around -- prefer to not move cursor
CP: FF allows multiple selection
... 2 people may have 2 diff cursors moving -- virtual or secondary cursor use case?
... like concept of bringing that in -- here is virtual cursor, what is next word?
... need L,W,H for same purpose?
RS: each a11y API on windows has
notion of bounding recatangles -- can compute rectangle and
then highlight it
... can't expect author to write in position info for all text -- need to have second virtual cursor?
CP: for best case, need virtual window to do scroll and adjust to new pixel ratio -- make sense if virtual window had cursor, scrolling and own DPI ratio
RS: how to do for spec?
CP: got to go all the way to
... none of this has to do strictly with canvas, right?
... using AbstractView with CANVAS, but isn't "of canvas"
RS: 1-to-1 mapping in a11y
... 1-to-1 mapping tying into layout engine -- canvas is seperate
... view of canvas is separate from DOM -- not wired together -- can forsee problem with SVG as well
... when deal with MS Office, most AT vendors access office through proprietary DOM --- does AISquared do that?
TL: use Word Object Model to get
content -- have to use others to get application support
... toolbars, etc. reflected in MSAA
... if object model too slow, then might do own analysis -- a lot of techs to get same info -- can talk to object model, subscribe to MSSAA event or graphics stack
... use "content model" to get content of document
RS: how map through layers?
... if select text, how map positioning info -- look at cached drawing calls or OSM?
TL: in Excel had to do
translations and calculations based on mapping mode
... convert between object model and pixels -- may have to go through hoops to get to screen
RS: similar situation with CANVAS
-- providing a DOM
... does Office object model provide positioning? device context?
TL: have had challenges with PDF document -- depending on how query, may get "page relevant" -- each DOM needs a bit of massaging
RS: what do we need to do in canvas -- how to get info to AT dev
TL: if there is a virtual canvas, real-life canvas may only be a portion of that -- don't want author to provide positioning -- coordinates on virtual canvas and calculate to render in viewport
RS: is that consistent mapping?
CP: larger bitmap area or virtual coordinate system?
TL: can think of it both ways --
CP: optimal not to have
... AbstactView for canvas seems a good fit
... coordinate is x,y in virtual canvas (may be outside of bitmap)
RS: with canvas sub-tree how to give abstract coordinates?
CP: top left of any canvas is 0,0; after that, best model is SVG coordination -- what need in CANVAS
TL: use virtual for topmost level
RS: dev pushback?
CP: AbstactView for canvas may be politically tricky but needed; already in SVG, but can't zoom into SVG with magnifier
TL: seems that this is right solution
<Downchuck> somewhat interesting link on word selection
RS: would like to get AISquared feedback at meetings - email is ok, but being on call is very helpful
<Downchuck> i just used that one for quick access
RS: CP please float AbstactView by WG?
CP: may be best to float before SVG WG before going to HTML WG
RS: alternate proposals for caret
and FocusRing proposals
... FrankO says "drop"
... IME stuff happening at google --people will use canvas for this (editing)
CP: guy working on IME not dropping it
RS: concern: don't want to have HTML5 go out and say "we'll fix in next point release"
CP: good to get methods for
canvas in there -- IME in canvas drives people nuts
... APIs for canvas are simple -- bit of tweaking and feedback should work
... treading warily in WHAT WG space
RS: FocusRing a no-brainer
TL: can't mange input="text" -- scrolls itself
RS: thanks to TL and SW for attending
<scribe> meeting: CANVAS Subteam of HTML A11y TF
meeting+ CANVAS Subteam of HTML A11y TF
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/TL: coordinate is x,y in virtual canvas (may be outside of bitmap)/CP: coordinate is x,y in virtual canvas (may be outside of bitmap)/ Succeeded: s/TL: top left of any canvas is 0,0; after that, best model is SVG coordination -- what need in CANVAS/CP: top left of any canvas is 0,0; after that, best model is SVG coordination -- what need in CANVAS/ Succeeded: s/TL: AbstactView for canvas may be politically tricky but needed; already in SVG, but can't zoom into SVG with magnifier/CP: AbstactView for canvas may be politically tricky but needed; already in SVG, but can't zoom into SVG with magnifier/ Succeeded: i/TL: used ARIA-selection of "no-width" for caret/TOPIC: What is needed for Screen Magnification Support for CANVAS? Found Scribe: Gregory_Rosmaita Found ScribeNick: oedipus Default Present: +1.802.362.aaaa, Rich, +1.802.362.aabb, +1.949.637.aacc, Gregory_Rosmaita, Chuck_Pritchard, Tim_Lalor, Shawn_Warren Present: Chuck_Pritchard Gregory_Rosmaita Rich Shawn_Warren Tim_Lalor Regrets: Frank_Oliver Agenda: http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0002.html Found Date: 10 Jan 2011 Guessing minutes URL: http://www.w3.org/2011/01/10-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]