- From: Dominic Mazzoni <dmazzoni@google.com>
- Date: Tue, 8 Mar 2011 13:45:48 -0800
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- Cc: public-html@w3.org, public-html-a11y@w3.org, Maciej Stachowiak <mjs@apple.com>, public-canvas-api@w3.org, Charles Pritchard <chuck@jumis.com>, david.bolter@gmail.com, franko@microsoft.com
On Tue, Mar 8, 2011 at 11:59 AM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote: > One of the challenges we still have with Canvas accessibility is computing a > bounding rectangle for the accessibility API mapped to each object in the > fallback content. We have looked at: > > - Use CSS positioning. This is inadequate as it only provides us with a > point and not the full rectangle, What's wrong with the width and height attributes in CSS? One advantage I can see to this approach is that authors could simple comment out the surrounding <canvas> tag to see what the fallback content looks like and how it lays out. Also, it looks like for WebKit at least, we might be laying out the fallback content offscreen, so those coordinates will already be available. Not sure if other user agents have chosen to implement it the same way. > We have had a number of discussions on this and we think the right way to do > this is to bind the element to a clipping region in canvas. This is also > consistent with how Windows and UNIX graphics subsystems started. You would > get a handle to a device context and apply a number of properties to it > including the bounding rectangle or clipping region. When assistive > technology first came out this device context was bound to an accessible > object and that is where the bounding rectangle would come from. It also > allowed the graphic subsystem to maintain the rectangle as things were moved > on the desktop. This same clipping rectangle was used in hit testing for the > mouse. I'm totally open to this too, will be easier to understand if I could see a complete code sample of how it'd be used. - Dominic
Received on Tuesday, 8 March 2011 22:36:56 UTC