20:01:36 RRSAgent has joined #html-a11y 20:01:36 logging to http://www.w3.org/2011/01/31-html-a11y-irc 20:01:38 RRSAgent, make logs world 20:01:38 Zakim has joined #html-a11y 20:01:40 Zakim, this will be 2119 20:01:40 ok, trackbot; I see WAI_PFWG(A11Y)3:00PM scheduled to start now 20:01:41 Meeting: HTML Accessibility Task Force Teleconference 20:01:41 Date: 31 January 2011 20:01:45 chair: Rich 20:02:05 agenda: http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0054.html 20:02:10 Meeting: HTML Canvas Accessibility Working Group 20:02:11 WAI_PFWG(A11Y)3:00PM has now started 20:02:19 +Gregory_Rosmaita 20:02:25 +Charles_Pritchard 20:02:54 +Rich 20:04:06 scribe: Gregory_Rosmaita 20:04:10 scribenick: oedipus 20:04:21 * latest draft of CanvasEditor.html: http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0054/CanvasEditor.html 20:04:24 * latest draft of HTML_Canvas_Element.html: http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0054/HTML_Canvas_Element.html 20:04:27 * latest draft of HTML_Canvas_2DContext20110123.html: http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0054/HTML_Canvas_2DContext20110123.html 20:04:34 TOPIC 1: Status Report 20:05:00 RS: filed big bug against chromium that kept from accessing the DOM -- FSci got a "drop" with that progress 20:05:12 RS: DavidB trying to get feedbaack from mozilla this week 20:05:18 RS: contact Ben about API proposal? 20:05:29 CP: Benjamin Hawkes-Lewis -- replied to his email 20:05:36 http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0052.html 20:05:57 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?" 20:06:27 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 20:07:06 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 20:07:27 RS: "adjust caret or selection position" rather than upper lefthand corner 20:08:00 RS: our API is only for Canvas 2D API -- not for SVG or other rendering strategies 20:08:21 RS: so question is does this sync with James Craig's UI Independence Proposal 20:08:37 RS: take out of this spec and put into JCraig's proposal or leave in draft text 20:09:14 CP: not sure -- canvas does exist independently outside of HTML -- would help of APIs directly acessible 20:09:28 CP: other proposals based on SVG schemes or HTML where outline more visible 20:09:34 RS: which proposals? 20:09:41 CP: diff between canvas rendering content? 20:09:46 RS: context associated with canvas 20:09:53 http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0054/HTML_Canvas_2DContext20110123.html 20:10:07 CP: 2D spec something more "independent" of HTML 20:10:19 CP: where boundaries are has yet to be defined 20:10:34 RS: listed under HTML5 -- under dev.w3.org/html5 20:11:16 http://www.w3.org/html/wg/ 20:11:27 CP: in canvas+javascript model needs a firm definition of canvas -- a lot of integration necessary 20:11:53 RS: at the moment, 2D context still listed as deliverable of HTML WG -- 20 january 2011 draft 20:12:20 CP: will email Doug S -- will be able to inform me 20:12:36 RS: see where adobe would want this -- rendering engine could run canvas on diff platforms 20:13:10 RS: have until 28 February 2011 to get proposals for caret stuff done for HTML5 20:13:24 TOPIC 1: Discuss Canvas 2D API caret positioning, blink rate, text extent 20:13:46 RS: ben's comment not applicable as long as canvas 2d api context is part of HTML5 20:14:14 RS: canvas element subjected to warping using CSS 3D warping -- seems a bit off topic 20:14:29 CP: noted that -- focus on what is in canvas 2d context api only 20:14:52 CP: maybe some text or phrase that integrates well with CSS specs -- terminology issue 20:15:08 RS: how to compute rectangle 20:15:33 RS: explained how to get positioning in reply to BHL's post 20:15:57 RS: explained best fit for drawing path -- seems basic -- do we actually need more text? 20:16:23 CP: will reply to rest of BHL's email to keep conversation going 20:16:28 RS: what does BHL want? 20:16:37 CP: DOM minor additions for clarification 20:17:09 CP: 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 20:18:14 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 20:18:34 RS: need someone to implement that -- google plans? add canvas sub-tree when works with JAWS? 20:18:53 CP: that was my understanding; posted to Webkit -- no issues on this -- everyone wants shadow DOM 20:19:07 CP: implementing shadow DOM method is a VERY QUICK INEXPENSIVE thing 20:19:23 CP: can get patch to google with method once get thorugh first steps 20:20:53 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 20:21:15 proposed RESOLUTION: Canvas 2D Context - position must be programmatically determinable via API 20:21:36 proposed RESOLUTION: Canvas 2D Context - position must be programmatically determinable via API, based on UA supporting a11y services to drive caret tracking 20:22:20 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 20:23:10 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 20:23:19 I have made the request to generate http://www.w3.org/2011/01/31-html-a11y-minutes.html oedipus 20:24:14 RS: if app draws to windows hardware directly will be invisible to SR and ScreenMag unless using AT services 20:24:51 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 20:25:13 CP: graphic rendering on CPU if API exposed, performance dramatically increased 20:25:59 CP: 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 20:26:32 CP: main issue isn't how define caret, but whether we do 20:27:08 CP: 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 20:27:48 CP: 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 20:27:59 RS: set drawing tab, and... 20:28:11 CP: so far haven't heard "yes, we want selection rectangles" 20:28:24 RS: want to do based on a drawing path that exists? 20:28:58 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 20:29:15 CP: why do you need this? what is use case? 20:29:35 CP: if get mozilla on board to say "yes" to rectangle... 20:30:27 CP: right now, IE9 is ahead of the game -- 20:30:43 RS: need 2 implementations -- IE9 is one, if get chromium to support, then have 2 20:31:02 RS: if get chrome to say they support before 28 february 2011 20:31:33 TOPIC: Caret Blink Rate 20:32:03 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 20:32:12 RS: do we want blink rate in spec? 20:32:38 RS: getting implementation so don't want to push things off until june timeframe (when JCraig can work on DI Independence proposal with DougS) 20:32:44 RS: property verus method 20:32:51 RS: properties in 2D api? 20:33:16 CP: no, not really -- has centers on all of its properties -- this will not have center -- canvas API follows CANVAS not DOM 20:33:39 RS: at this point do we want to have it return a value? 20:33:56 CP: leave as function for ease of implementation in many environments easier to do function call 20:34:06 CP: minor point -- important, but minor 20:34:27 CP: need accept caret point with height -- after that the rest is relatively easy 20:34:44 GJR: plus 1 to get/function 20:34:55 CP: prefer "get" function 20:35:02 [we 3 are in accord] 20:35:19 RS: BHL wants to avoid profiling and hard coding 20:35:27 RS: default value of 500 milliseconds? 20:36:02 CP: don't see problem with author defining blink rate if not set by user -- user setting of blink rate lost if use default 20:36:07 CP: don't think necessary 20:36:18 plus 1 to CP -- user control, not default setting 20:36:24 RS: leave as-is 20:36:48 RS: if anything below twice a second, can introduce a seizure, hence request for 500 mpbs 20:36:54 CP: is something for UAAG 20:37:18 RS: can modify section to start with user agent directive to default to 500 milliseconds 20:37:29 CP: UA might have minimum -- can return -1 20:37:36 RS: author doing drawing 20:37:48 CP: point for implementors to know about (seizure info( 20:37:55 RS: will modify section 20:38:18 RS: move into JCraig's proposal? don't know how will be accepted or by whom 20:38:32 CP: this needs to be stand alone canvas support 20:38:48 CP: address magnification in context of canvas accessibility -- no brainer 20:38:57 TOPIC: TextExtent 20:39:05 Benjamin's comment: http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0050.html 20:39:30 RS: looks like an attempt to explain the need for text extent 20:39:44 RS: text extent versus caret position -- he is confused 20:39:57 RS: bug regarding TextExtent - -hixie asked for use case 20:40:09 CP: tried to post text to get reply 20:40:13 CP: no one bit 20:41:03 CP: 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 20:41:12 RS: when you move to menu, focus disappears 20:41:22 CP: will try again 20:41:31 CP: was using ZoomText at time 20:42:13 CP: 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 20:42:29 RS: address point of why need TextExtent for canvas? 20:42:52 CP: need so that i can position elements within a box -- can use 2 differently sized fonts on 1 single baseline 20:43:06 RS: need some text from CP -- where baseline is reference? 20:43:27 CP: not how i groked it, but can get text together 20:43:58 CP: 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 20:44:06 CP: will try again 20:44:16 RS: need to put response into bug itself 20:44:25 CP: will write some text for thwat 20:44:38 RS: if get text to me today, can make change today 20:45:06 TOPIC: Canvas: Initialization of resources (such as IFrame) in canvas 20:45:12 RS: waiting to hear from FrankO about that 20:45:32 CP: need consensus from Webkit and Mozilla 20:46:17 noVNC - VNC client using HTML5 Canvas: http://kanaka.github.com/noVNC/ 20:47:25 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 20:47:55 RS: can't process without services 20:48:01 CP: gain if used 20:48:24 RS: other way to do is have AT running on remote host 20:48:54 GTK client on HTML5 canvas: http://blogs.gnome.org/alexl/2010/11/23/gtk3-vs-html5/ 20:48:55 have AT running on the web service, such as terminal or vnc 20:49:01 TOPIC: Positioning Information 20:49:17 RS: magnifiers need to know where text is on screen -- need for braille device, as well 20:49:57 RS: 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) 20:50:04 RS: problem for text wrapping 20:50:52 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 20:51:02 CP: when go through DOM know where canvas object is 20:51:14 CP: might work without recourse to IMAGEMAP 20:51:21 CP: drawFocusRing and mark 20:51:42 CP: brialle devices are a next step after address magnification 20:51:50 s/brialle/braille/ 20:51:54 GJR: which CSS? 20:54:14 https://developer.mozilla.org/en/drawing_text_using_a_canvas 20:54:51 http://dl.dropbox.com/u/17337752/text-legibility-crop.png 20:54:55 http://www.w3.org/WAI/PF/wiki/CSS/tactile_braille_and_haptic 20:55:40 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 20:55:52 RS: apply media types to content? 20:56:00 RS: do something to shadow DOM? 20:56:09 CP: need to tie in shadow DOM -- 20:56:17 CP: need to enable select, too 20:56:41 RS: will follow up in bugzilla 20:57:10 RS: will look at blink rate and glossary stuff -- follow up on bug -- see what can do with google 20:57:22 RS: timeline for shadow DOM implementation by chrome? 20:57:36 CP: no definite timeline -- 28 February 2011 tight deadline 20:57:43 I have made the request to generate http://www.w3.org/2011/01/31-html-a11y-minutes.html oedipus 20:57:55 RS: DavidB promised feedback from mozilla 20:58:06 CP: extensive use of shadow DOM being contemplated by Mozilla 20:58:19 RS: a11y has so many cross-cutting applications that help everytone 20:58:39 -Charles_Pritchard 21:02:36 -Gregory_Rosmaita 21:02:38 -Rich 21:02:38 WAI_PFWG(A11Y)3:00PM has ended 21:02:40 Attendees were Gregory_Rosmaita, Charles_Pritchard, Rich 21:02:42 zakim, please part 21:02:42 Zakim has left #html-a11y 21:02:49 I have made the request to generate http://www.w3.org/2011/01/31-html-a11y-minutes.html oedipus 21:04:29 s/TOPIC 1: Status Report/TOPIC: Status Report/ 21:04:32 I have made the request to generate http://www.w3.org/2011/01/31-html-a11y-minutes.html oedipus 21:05:42 s/Ben about API/Benjamin Hawkes-Lewis (hereafter BHL) about API/ 21:05:44 I have made the request to generate http://www.w3.org/2011/01/31-html-a11y-minutes.html oedipus 21:55:35 MichaelC_ has joined #html-a11y 23:18:50 MichaelC_ has joined #html-a11y