Re: Ease of testing canvas accessible subtree

Ian Hickson wrote:
> On Fri, 5 Feb 2010, Ian Hickson wrote:
>> On Fri, 5 Feb 2010, Philip Taylor wrote:
>>> To develop and test an accessible canvas application with focus 
>>> management, I'd expect it would be much easier if the author could see 
>>> the bitmap and the fallback content simultaneously, using their normal 
>>> mouse and keyboard input to interact with either version, and check 
>>> that both representations stay in sync and that the focus highlighting 
>>> is handled correctly. Once they've finished testing, they would want 
>>> the published version to work like it currently does (i.e. users are 
>>> shown the bitmap if possible, else the fallback content is shown 
>>> instead).
>>>
>>> Is this possible with the current spec? If not, I think there should 
>>> be a way to make the fallback content and bitmap visible together, 
>>> e.g. <canvas showfallback>...</canvas> (and authors can add some CSS 
>>> to the fallback content so it's rendered in a sensible position), to 
>>> help with this kind of testing.
>> 
>> That's a good point. I'm skeptical about allowing elements outside of 
>> <canvas> be focused while drawFocusRing() renders, because that means 
>> the screen would have two focus rings... but maybe that's ok?
> 
> (It would be a disaster while a magnifying AT is present, since the AT 
> would be jumping back and forth trying to magnify both at once.)

In the showfallback case (or the equivalent development-tool-provided 
debug mode), the UA could render the focus ring on the bitmap without 
sending focus messages to the AT, to avoid that problem.

I think rendering the focus ring at the same time as really focusing the 
elements in the (now-visible) fallback content is important to help 
people write correct code. I'm imagining a simplified situation like:

   <h1>Fancy decorative heading generator with interactive preview</h1>
   <canvas>
    <form>
     <label>Heading text: <input name="heading-text"></label>
     <input type="submit">
    </form>
   </canvas>
   <script>
   /* draw the heading text in a fancy decorative font using canvas 
features, with the canvas element intercepting key/mouse events to 
implement the editing UI and to trigger form submission, with the 
<input>s kept in sync with the displayed text for non-graphical UAs, and 
with a focus ring drawn in the canvas bitmap when a keyboard user tabs 
through the page */
   </script>

and the author wants to test:

  a) The graphical version looks good and functions correctly
  b) The fallback version looks good and functions correctly
  c) Keyboard-focusing the fallback content displays the correct 
corresponding focus rings on the bitmap
  d) Keyboard-focusing the fallback content and entering text updates 
the  bitmap
  e) Interacting with the script's special editing UI updates the 
fallback content, so switching back to keyboard navigation doesn't 
result in a self-inconsistent state

and the author is using fairly standard web development tools (graphical 
web browser etc) and doesn't have any specialist AT tools available.

Case (a) is what everybody does anyway. Case (b) needs some way to see 
the fallback content with standard development tools, but it could be a 
simple "disable canvas" switch.

Case (e) can only reasonably be tested by seeing both the bitmap (so you 
can interact with it) and the fallback content (so you can verify it's 
being updated in sync) simultaneously.

Cases (c) and (d) can roughly be tested when fallback is invisible, by 
viewing the bitmap and trying to interact via the keyboard, but I think 
it would be much easier if you could see both versions simultaneously - 
rather than blindly navigating through the hidden fallback, you could 
see the real fallback elements and verify that there's the correct 
one-to-one correspondence with the bitmap. That's the case where you 
really need to see focus rings on the bitmap while the fallback controls 
are also focused.

-- 
Philip Taylor
pjt47@cam.ac.uk

Received on Friday, 5 February 2010 20:39:03 UTC