Minutes: HTML 5 Canvas Accessibility Call

http://www.w3.org/2010/01/18-html-a11y-minutes.html

- DRAFT -
HTML Accessibility Task Force Teleconference
18 Jan 2010


See also: IRC log


Attendees
Present
Regrets
Chair
      Rich
Scribe
      davidb
Contents
      Topics
         1. Use of Input controls in a shadow DOM
      Summary of Action Items





<trackbot> Date: 18 January 2010


<richardschwerdtfe> Meeting: HTML Canvas Accessibility Caucus


passcode?:


<richardschwerdtfe> 92473


ah finally worked


<richardschwerdtfe>
http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0044.html


<richardschwerdtfe> scribe: davidb


rs: use of input controls in shadow dom


Use of Input controls in a shadow DOM


<richardschwerdtfe> http://www.w3.org/WAI/PF/HTML/track/actions/4


db: not sure about shadow dom


<richardschwerdtfe> david: The concern I have is the amount of resource
that will go into this solution


<richardschwerdtfe> david: Is anyone going to do this


<dbb> sf: devs want to add interaction to canvas


sf: if we combine a solution that happens to make it accessible, then win
win


all: discussion of canvas use cases


rs: pushing on alternative content for tricky cases
... if you can do it via shadow dom great, if not, provide alt content, and
way to select it via media query
... in bespin you have a toolbar, no reason that same toolbar can't be
implemented as html5 toolbar
... in shadow dom as we navigate toolbar we render it on screen via canvas,
but actually have a11y tree populated using html markup (shadow dom)


sf: dave do you see alternatives?


db: i don't have a great answer


all: more discussion of canvas examples


rs: consider subway map
... you need a vehicle to select what version you want
... some people want fallback content rendered
... how does user choose
... any technical reason you couldn't insert interactive controls in
'shadow dom'


db: unsure about how this works if not rendered.


<richardschwerdtfe> db: could move the shadow dom to -5000, -5000


<richardschwerdtfe> sf: yes but then magnifiers will not work


<richardschwerdtfe> db: yes that is the problem


<richardschwerdtfe> db: so focus for users would be on the shadow DOM?


<richardschwerdtfe> rs: yes but rendering would be on the visual canvas


<richardschwerdtfe> db: this is going to require evangelization


<richardschwerdtfe> sf: why?


<richardschwerdtfe> db: what answer I got. I like the canvas API but I
don't like the DOM API


<richardschwerdtfe> db: I thin for people used to working in a toolkit
where they have something like a canvas and they do all themselves then
they are in that mind set.


<richardschwerdtfe> SF: we need to be able to draw a focus rectangle


<richardschwerdtfe> db: for the user interaction is focus and all the event
handlers are on the shadow dom


<richardschwerdtfe> rich: you could have the keyboard and mouse handlers on
the canvas element


<richardschwerdtfe> db: so it is up to the web developer


<richardschwerdtfe> rs: we are not requiring people to do the shadow DOM


sf: some people are concerned about slowing down canvas rendering
... don't see this happening


rs: no


db: what do other browser devs thing?


<richardschwerdtfe> db: this shadow DOM idea does not strike me as
something that has to be spoken in the same breath as canvas


<richardschwerdtfe> http://www.w3.org/WAI/PF/HTML/track/actions/4


db: not 100% sure


<richardschwerdtfe> http://www.w3.org/WAI/PF/HTML/track/actions/5


db: i don't see another way


<Stevef> Canvas Focus management
http://dev.w3.org/html5/2dcontext/Overview.html#focus-management


<Stevef> "When a canvas is interactive, authors should include focusable
elements in the element's fallback content corresponding to each focusable
part of the canvas."


<richardschwerdtfe>
http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0044.html


<Stevef> i don't thinkit is correct now


<richardschwerdtfe> Resolution: Close Action items 4 and 5. Mozilla
supports the use of input controls in the shadow DOM at thi stime


rs: we are going to have situations where we need to choose alt content
... there is no vehicle to choose fallback content


sf: if it is included in the tab order and can be interacted with by any
user, it is no longer 'fallback' is it?
... you might want the canvas or something else to be displayed


rs: i've been looking at use of media queries
... we would essentially be adding additional modality tags
... consider audio and visual tags
... visual with properties xyz
... AT interoperable
... currently html5 spec says you can put content inside canvas tags, and
if browser cannot support canvas, then content would be rendered in its
place
... you need a selection mechanism for rendering. having as fallback
doesn't necessary work.
... if you support the html5 spec, must you support canvas?


sf: yes


db: sorry i gotta go


<Stevef> Canvas Focus management
http://dev.w3.org/html5/2dcontext/Overview.html#focus-management


<richardschwerdtfe> ACTION: SteveF ensure there is a dependency between the
HTML5 specification and the HTML 5 2D Context specification to ensure that
the author has the ability to set the visible focus, for <canvas>, to
ensure that a magnifier may follow the visual focus. This would be driven
by the shadow DOM. [recorded in
http://www.w3.org/2010/01/18-html-a11y-minutes.html#action01]


<trackbot> Sorry, couldn't find user - SteveF


<richardschwerdtfe> ction: member:SteveFf ensure there is a dependency
between the HTML5 specification and the HTML 5 2D Context specification to
ensure that the author has the ability to set the visible focus, for
<canvas>, to ensure that a magnifier may follow the visual focus. This
would be driven by the shadow DOM.


<richardschwerdtfe> ACTION: member:SteveFf ensure there is a dependency
between the HTML5 specification and the HTML 5 2D Context specification to
ensure that the author has the ability to set the visible focus, for
<canvas>, to ensure that a magnifier may follow the visual focus. This
would be driven by the shadow DOM. [recorded in
http://www.w3.org/2010/01/18-html-a11y-minutes.html#action02]


<trackbot> Sorry, bad ACTION syntax


<richardschwerdtfe> ACTION: Stevef ensure there is a dependency between the
HTML5 specification and the HTML 5 2D Context specification to ensure that
the author has the ability to set the visible focus, for <canvas>, to
ensure that a magnifier may follow the visual focus. This would be driven
by the shadow DOM. [recorded in
http://www.w3.org/2010/01/18-html-a11y-minutes.html#action03]


<trackbot> Sorry, couldn't find user - Stevef


<richardschwerdtfe> ACTION: RichS ensure there is a dependency between the
HTML5 specification and the HTML 5 2D Context specification to ensure that
the author has the ability to set the visible focus, for <canvas>, to
ensure that a magnifier may follow the visual focus. This would be driven
by the shadow DOM. [recorded in
http://www.w3.org/2010/01/18-html-a11y-minutes.html#action04]


<trackbot> Sorry, couldn't find user - RichS


<richardschwerdtfe> ACTION: Rich ensure there is a dependency between the
HTML5 specification and the HTML 5 2D Context specification to ensure that
the author has the ability to set the visible focus, for <canvas>, to
ensure that a magnifier may follow the visual focus. This would be driven
by the shadow DOM. [recorded in
http://www.w3.org/2010/01/18-html-a11y-minutes.html#action05]


<trackbot> Created ACTION-12 - Ensure there is a dependency between the
HTML5 specification and the HTML 5 2D Context specification to ensure that
the author has the ability to set the visible focus, for <canvas>, to
ensure that a magnifier may follow the visual focus. This would be driven
by the shadow DOM. [on Richard Schwerdtfeger - due 2010-01-25].


<richardschwerdtfe> made Steve Faulkner the owner


Summary of Action Items
[NEW] ACTION: member:SteveFf ensure there is a dependency between the HTML5
specification and the HTML 5 2D Context specification to ensure that the
author has the ability to set the visible focus, for <canvas>, to ensure
that a magnifier may follow the visual focus. This would be driven by the
shadow DOM. [recorded in
http://www.w3.org/2010/01/18-html-a11y-minutes.html#action02]
[NEW] ACTION: Rich ensure there is a dependency between the HTML5
specification and the HTML 5 2D Context specification to ensure that the
author has the ability to set the visible focus, for <canvas>, to ensure
that a magnifier may follow the visual focus. This would be driven by the
shadow DOM. [recorded in
http://www.w3.org/2010/01/18-html-a11y-minutes.html#action05]
[NEW] ACTION: RichS ensure there is a dependency between the HTML5
specification and the HTML 5 2D Context specification to ensure that the
author has the ability to set the visible focus, for <canvas>, to ensure
that a magnifier may follow the visual focus. This would be driven by the
shadow DOM. [recorded in
http://www.w3.org/2010/01/18-html-a11y-minutes.html#action04]
[NEW] ACTION: SteveF ensure there is a dependency between the HTML5
specification and the HTML 5 2D Context specification to ensure that the
author has the ability to set the visible focus, for <canvas>, to ensure
that a magnifier may follow the visual focus. This would be driven by the
shadow DOM. [recorded in
http://www.w3.org/2010/01/18-html-a11y-minutes.html#action01]
[NEW] ACTION: Stevef ensure there is a dependency between the HTML5
specification and the HTML 5 2D Context specification to ensure that the
author has the ability to set the visible focus, for <canvas>, to ensure
that a magnifier may follow the visual focus. This would be driven by the
shadow DOM. [recorded in
http://www.w3.org/2010/01/18-html-a11y-minutes.html#action03]

[End of minutes]