Rich Schwerdtfeger Distinguished Engineer, SWG Accessibility Architect/Strategist public-canvas-api-request@w3.org wrote on 01/20/2010 07:08:36 AM: > Henri Sivonen <hsivonen@iki.fi> > Sent by: public-canvas-api-request@w3.org > > 01/20/2010 07:08 AM > > To > > Steven Faulkner <faulkner.steve@gmail.com> > > cc > > Maciej Stachowiak <mjs@apple.com>, Ian Hickson <ian@hixie.ch>, > public-canvas-api@w3.org, HTML WG <public-html@w3.org> > > Subject > > Re: Proposal: Canvas accessibility and a media querries approach for > alternative content (Action Item 6 in the HTML Accessibility Task Force) > > On Jan 20, 2010, at 15:01, Steven Faulkner wrote: > > > OK, but I am trying to understand why one would do this? > > if you include a link in the canvas sub dom so it will be > accessible to users, why would you duplicate the functionality using > script instead of pointing the click event on the canvas to the link? > > The subdom isn't being rendered to the visual medium, so presumably > it doesn't have CSS boxes generated for it, so it doesn't exist in a > coordinate space where click hit testing could be performed against > boxes that correspond to DOM nodes. > > > in the end if a single method is suitable for all users its a win > for all no? > > Yeah. I'd expect SVG+ARIA to provide that. Can't put the <canvas> > cat back in the bag at this point, though. I don't see any of this to be a problem. GUI systems associate drawing areas with objects all the time. The author simply needs to maintain an association between the accessible object's view in the canvas and the shadow DOM element. The shadow DOM is not expected to have any CSS boxes, etc. So, there will be time when the shadow DOM approach may be too hard or impractical and an alternative HTML solution is required. This is why we would need an alterative visual that can be rendered. In this case it may require the use of CSS to do the rendering. > > -- > Henri Sivonen > hsivonen@iki.fi > http://hsivonen.iki.fi/ > > >
Received on Friday, 22 January 2010 22:36:59 UTC