HTML Accessibility Task Force Teleconference -- 15 Nov 2010

<trackbot> Date: 15 November 2010

rich, when you have the time: https://lists.linux-foundation.org/pipermail/accessibility-ia2/2010-November/001235.html IA2_ROLE_NOTE aria role note and HTML5 aside

<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_from_Canvas_Accessibility_Sub-Group_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]

<Downchuck> I'm the 949 number (And Charles)

- DRAFT -

HTML Accessibility Task Force Teleconference

15 Nov 2010

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output