- 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:37 UTC