- From: Gregory J. Rosmaita <oedipus@hicom.net>
- Date: Mon, 21 Feb 2011 21:05:10 +0000
- To: public-canvas-api@w3.org
- Cc: david.bolter@gmail.com, dmazzoni@google.com, chuck@jumis.com, franko@microsoft.com, bhawkeslewis@googlemail.com, public-html-a11y@w3.org
aloha!
minutes from the Canvas Subteam of the HTML Accessibility Task Force's
21 February 2011 weekly meeting can be accessed as hypertext from:
http://www.w3.org/2011/02/21-html-a11y-minutes.html
as an IRC log from:
http://www.w3.org/2011/02/21-html-a11y-irc
and as plain text following this announcement -- as usual, please log
any errors, omissions, clarifications and the like by replyiing-to
this announcement on-list...
note that the following RESOLUTION was agreed to at today's Canvas
meeting:
RESOLUTION: Submit
http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection
Change Proposal to HTML WG as it has been available for review
and individuals have been asked to review it specifically
_________________________________________________________
- DRAFT -
HTML Accessibility Task Force Teleconference
21 Feb 2011
Agenda
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0071.html
See also: IRC log - http://www.w3.org/2011/02/21-html-a11y-irc
Attendees
Present
Chuck_Pritchard, Rich, Gregory_Rosmaita
Regrets
Chair
Rich
Scribe
Gregory_Rosmaita
Contents
* Topics
1. Getting Started/Updates
2. Outstanding Bugs
3. Strategy for positioning fallback content relative to
corresponding canvas UI drawing counterparts.
* Summary of Action Items
_________________________________________________________
<trackbot> Date: 21 February 2011
<richardschwerdtfe> Meeting: HTML Canvas Accessibility Subteam
<scribe> scribe: Gregory_Rosmaita
<scribe> scribenick: oedipus
Google Web Toolkit (GWT) 2.2 released this week now includes support
for the HTML5 Canvas tag, which enables building "dynamic
images/animations/transitions all in HTML with GWT."
<richardschwerdtfe> Agenda is here:
<richardschwerdtfe>
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0071.html
Getting Started/Updates
RS: if FrankO doesn't join, will submit proposal as last circulated
to the list
<Downchuck> http://mugtug.com/darkroom/
RS: chuck, do you have an example?
CP: still bug-fixing
canvas 2d API change proposal cover letter:
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0070.html
canvas 2d API change proposal:
http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection
CanvasEditor.html:
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0071/CanvasEditor.html
HTML_Canvas_2DContext20110217.html:
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0071/HTML_Canvas_2DContext20110217.html
http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection
Outstanding Bugs
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11328
RS: pixel resolutoin -- what happened with that?
CP: hixie and mozilla against that kind of work -- is a problem --
MS already exposes it
... hixie handed over to CSS WG where it sits
RS: what to do?
CP: "slip in" via CSS
... for FF can do collectoin of media queries
... problem because vetoed by mozilla -- do have a workaround, but
don't know what to do other than to bring to webkit'
RS: close this bug?
CP: assigned to CSS OM
... CSS resopnse "backlog is huge" -- sitting for at least a month
resize event during zoom:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11329
CP: everyone in agreement -- needs to be added to specs
<richardschwerdtfe>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11329
<Downchuck> #canvas.CompatibilityMozScreen { width: 1px; } @media
all and (min--moz-device-pixel-ratio: .3) {
#canvas.CompatibilityMozScreen { width: .3px; } }
<Downchuck> that's the trick for Firefox zoom
CP: asignee in bug tracker, don't need to do ourselves
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11342
RS: addressed in latest drafts and change proposal
... in change proposal under "Positive Effects"
... text metrics in Canvas 2D API
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0071/HTML_Canvas_2DContext20110217.html
CP: setCaretSelection API -- if selection not in focus, still works
RS: changed that to accomodate that
Strategy for positioning fallback content relative to corresponding
canvas UI drawing counterparts.
RS: will take a lot longer than we have -- create issue for LC next
step -- either accept or not
... strategies for positioning content
... first, imagemap provides coordinate info -- can do that or use
javascript according to FrankO
CP: imagemap proposal been struck down
RS: not doing imagemap, but interesting that elements with imagemap
can take coordinates, so can fallback content for CANVAS provide
coordinates through fallback
CP: might be able to track positions via jscript object or can stick
directly into DOM -- doesn't harm anything
... may have an effect --- no one uses fallback content to toggle on
and off -- not available, but supposed to be a long-term option
RS: reasonable strategy for doing this? get width and height, right?
CP: yes, full CSS spectrum of adding info to elements
... keeping eye out for use case for exposing all of that data --
\CP: not addressed yet in CSS Transformations
CP: CSS Transformations don't provide AT with updates that screen
has moved; if canvas animated, as soon as move over few pixels, have
to update a lot of elements -- complexity we need to keep in mind
RS: imagemap -- coordinates relative to context they are in?
CP: yes
RS: if UA moved, UA would update coordinates; app author only has to
worry to extent that are visible on screen
... can't scroll and imagemap
CP: could get same using SVG to define all shapes and z-index in
relation to each other
... allowed to use transparent SVG elements to do these things (get
a whole lot of data to AT) -- use DrawFocusRing and CaretSelection
and telling it only what caret is on
RS: could use x,y coordinate to move magnifier to whereever one
wants -- not tied to caret in A11y API -- could position wherever
one wants -- zoom to drawning object, put caret there
... second issue: what other ways can we set positioning other than
x,y coordinates -- javascript?
CP: not sure what FrankO means just by "javascript"
RS: can do via CSS
CP: may be referring to CSS absolute positioning
... in demo i have on darkroom site, am able to use our semantics
(DrawFocusRing and CaretSelection) -- have TTS via google translate
API running -- alternating via Mac and PC so can recreate each step
on each platform -- works as well in my browser as in their apps --
when scroll, some events don't get set up the way they should so
accessibiolity focus ring gets stuck until type something in
RS: if scroll window, position moves -- drawFocusRing around object
is necessary step for retaining focus when scrolled
CP: doesn't actually update where FocusRingSelection is on element
-- does update in some cases, but only if change between 2 elements
... if send focus event on same element, will ignore repeated calls
to update x,y position
... using our semantics, trying to get same result as apple
note: CP referring to http://mugtug.com/darkroom/
http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection
RS: add something to references in Chanqe Proposal so that
http://mugtug.com/darkroom/ cited
... what to call this? canvas focus tracking simulation?
CP: good -- focus management too
RS: put under "development"
CP: fine with me
RS: now under "references" in change proposal
CP: JAWS doesn't work as well in IE9
GJR: RC beta of IE9 very sporadic with speech--problem updating info
when switch tab to tab; forms controls often don't respond to
keyboard input, but need routing of JAWS cursor to PC cursor, etc.
-- very unstable
CP: shift-based part necessary at moment -- every UA has different
method to get focus
... working through a lot of quirks to get same result on the
software combos we discussed
GJR: am running FF so can use Chatzilla so can't check using IE9
right now -- will do when CP alerts us that bug-fixing de-quirking
done for testing
<Downchuck> I'm using "shift+space" to turn a11y on the app at the
moment
<Downchuck> yes, will dequirk
<richardschwerdtfe>
http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection#References
RS: propose we adjourn
CP: ok
GJR: ok
ISSUE-131: Should we add a caret location API to canvas, or is the
focus API sufficient?
http://www.w3.org/html/wg/tracker/issues/131
GJR: we have done our due dilligence in notifiying others
RS: barring no objections at this time from Microsoft or Mozilla
does Canvas Subgroup agree to submit change proposal for HTML WG
ISSUE-131?
CP: no objection
GJR: no objection
proposed RESOLUTION: Submit
http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection
Change Proposal to HTML WG as has been available for review
RESOLUTION: Submit
http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection
Change Proposal to HTML WG as it has been available for review and
individuals have been asked to review it specifically
RS: will send email to Sam Ruby, Paul Cotton and Maciej to alert
that change proposal for HTML WG Issue 131 complete and vetted by
subteam
[adjournded]
Summary of Action Items
[End of minutes]
_________________________________________________________
Received on Monday, 21 February 2011 21:06:50 UTC