- 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>
aloha! minutes from today's meeting of the Canvas Sub-team of the HTML Accessibility Task force are available as hypertext from: http://www.w3.org/2010/11/15-html-a11y-minutes.html as an IRC log from: http://www.w3.org/2010/11/15-html-a11y-irc 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: http://www.w3.org/WAI/PF/HTML/wiki/Canvas/Meetings minutes from past meetings are also available: http://www.w3.org/WAI/PF/HTML/wiki/Canvas/Meetings/Minutes 2. PLEASE review the latest canvas proposal from rich, archived at: http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/att-0179/HTML_Canvas_2D_Context.html 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 Agenda http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/0179.html See also: IRC log -- http://www.w3.org/2010/11/15-html-a11y-irc Attendees Present Charles_Pritchard, Gregory_Rosmaita, Rich, frankolivier Regrets Chair Rich Scribe Gregory_Rosmaita Contents * 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: https://lists.linux-foundation.org/pipermail/accessibility-ia2/2010-November/001235.html <scribe> scribe: Gregory_Rosmaita <scribe> scribenick: oedipus http://www.w3.org/WAI/PF/HTML/wiki/Canvas http://www.w3.org/WAI/PF/HTML/wiki/Canvas/Meetings http://www.w3.org/WAI/PF/HTML/wiki/Canvas/Meetings/Minutes 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: http://www.w3.org/2010/11/04-html-wg-minutes.html#item15 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: http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/att-0179/HTML_Canvas_2D_Context.html 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: http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/att-0179/HTML_Canvas_2D_Context.html RS: modification based on feedback from James Grahame about rocus ring ... 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 sub-tree? ... 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 TEXTAREA ... 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 IFRAME in CANVAS ... 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 measurement RS: change in zooming level should be accurate CP: just peeking into window.screen to get pixel coordinates RS: have MS app? <frankolivier> http://msdn.microsoft.com/en-us/library/ms533721(VS.85).aspx - devicexdpi 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 drawing 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 device-dpi http://friendfeed.com/mbrubeck/605bf526/target-densitydpi-in-android-webkit 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: http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/att-0179/HTML_Canvas_2D_Context.html 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 texty RS: want to propose a modification and post to public-html-a11y and public-canvas-api ... 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 list so far: CANVAS, FRAME, IFRAME, SCRIPT 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 ranges ... prototype in IE? don't see FF working on CANVAS before 4.0 released ... 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 http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/att-0179/HTML_Canvas_2D_Context.html ... 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: http://www.w3.org/2010/11/04-html-wg-minutes.html#item15 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