Re: [whatwg] hit regions: limited set of elements for fallback content

On Mon, Feb 17, 2014 at 11:02 PM, Ian Hickson <ian@hixie.ch> wrote:

> > What about <select>?
>
> What about it?


I'm curious if it's possible to implement an accessible list box or other
select control in a canvas. Wouldn't it be possible to make it accessible
if the canvas lets you focus the list box by clicking on its hit region,
and then change the selection using the arrow keys?

Sure. addHitRegion() supports roles like menuitem this in two ways: If
> you're doing something like a straight-forward menu item, you can just add
> the text and the role directly. If you're doing something more elaborate
> (e.g. a menu with disabled items), you can add appropriate elements (e.g.
> <button>) representing the menu into the <canvas> fallback content, and
> use ARIA roles and properties to override <button>'s defaults.
>

That sounds fine.


> Once you get to more elaborate compound controls like spin buttons, you
> really shouldn't be using <canvas> in the first place, and so those aren't
> supported (spinbutton in particular would be impossible to correctly
> support in a canvas, since it's a compound control with multiple
> subregions, all corresponding to a single DOM node on the ARIA side).
>

Spinbutton is probably a bad example. What about a list box using ARIA
instead?

<canvas>
  <div role="listbox">
    <div role="option" tabindex="0">First option</div>
    <div role="option" tabindex="-1">Second option</div>
    <div role="option" tabindex="-1">Third option</div>
  </div>
</canvas>

It seems to me that I could make each visible option a hit region - why
couldn't we make this work?

Simple grids are supported the same way that simple menuitems are
> supported; again, though, once you get to elaborate grids with cells that
> can be marked invalid, marked as having popups, etc, you really shouldn't
> be using <canvas>, so those aren't supported.


So you don't think people are going to implement something like a
spreadsheet using canvas?


> That's what <table> is for.
> If you want a table with graphics inside, the way to do that is to have a
> <table> with each <td> containing a <canvas>, not a single <canvas>. This
> is relatively important because users really don't want authors
> reimplementing table navigation themselves -- indeed I'm not even sure
> it's technically possible for an author to track the AT focus as the user
> navigates a table using AT commands, so it would be incredibly difficult
> for an author to do a good reimplementation of a grid on canvas.
>
> If there are specific use cases for why you'd want to recreate a table
> using <canvas>, please do describe it. If we need to support this, then we
> should make sure we do a good job (as noted, the current APIs aren't
> sufficient, even if we just make addHitRegion() support pointing to <td>
> elements in the canvas fallback content).
>

A spreadsheet is one possible use-case, though I agree it's complicated.

How about a crossword puzzle game as a more realistic example, where the
author wants to draw the whole puzzle in a canvas, not put a canvas inside
each cell? The accessible fallback content could use a table, and but each
cell would be focusable and have a role of gridcell.

Games like tic-tac-toe, chess, or reversi would also be reasonable
use-cases to consider for this.

- Dominic



>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Received on Tuesday, 18 February 2014 17:53:54 UTC