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

On Tue, 18 Feb 2014, Dominic Mazzoni wrote:
> 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?

What's the concrete use case?

Right now, this is intentionally not possible, since it seems that if you 
want a select, you really should be using a <select>, not a <canvas>. But 
if there's a valid reason to have a list box or other select control in a 
<canvas>, then we should examine that reason and see what precisely is 
needed to make it possible. (It's probably a lot more than just exposing a 
<select>, since you'd need some way to map the open <select> popup's focus 
to canvas, and there's no API to do that currently.)


> 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>

Why would you use <div>s in the canvas fallback? Just use the real 
control, like a <select>.

But see above for the case of <select> specifically; it's not that simple 
in practice.


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

We can make anything work if we want to; the question is what do we need 
to make 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?

No, canvas would be a disaster for implementing a spreadsheet. You'd have 
all of the problems already described for text controls:

   http://whatwg.org/html#best-practices

...plus a whole new set of problems relating to how to expose navigating a 
grid (right now there's no API for determining where the AT focus on a 
table is, so you couldn't just map a fallback <table> to a <canvas> 
rendering, it wouldn't work).


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

The spreadsheet use case is already handled by <table>.

If the problem is that we need something more performant than DOM+CSS, 
then we should provide something for that. Providing a pixel pushing 
interface is no real solution (see the #best-practices link above for a 
long list of reasons why not). This is the same reason that a spreadsheet 
is not a good use case for introducing a mechanism to do underlining:

   http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jan/0068.html


> 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?

Why would you use a <canvas> for a cross-word puzzle, rather than a 
<table>?


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

For 2D versions, why wouldn't you use a table? I don't understand what the 
<cavnas> is bringing to the table here.

For 3D versions, the addHitRegion() API doesn't apply, so that seems like 
a separate issue.


But ok, let's look at a 2D grid like chess or a cross-word. What would you 
actually need to make that work? 

<canvas>
 <table onkeypress="handleKeyInput">
  <tr>
   <td tabindex=0> I <td tabindex=0> N
  <tr>
   <td tabindex=0> F <td class=black aria-readonly=false> 
 </table>
</canvas>

What happens if the user navigates the table with their AT and moves the 
AT focus to the fourth cell?

It's not focusable, but do we still need to be telling the AT where the 
cell is?

What happens if we haven't told it where the cell is?

Where is the keyboard focus while the AT focus is on the black cell?

Imagine the crossword is so large that it doesn't fit on the canvas, and 
so the script scrolls the canvas around as the user tabs from cell to 
cell. Now what happens when the user moves AT focus to a black cell that 
isn't currently being rendered? Do we have some way to find out that a 
region is being AT focused?

What happens if the keyboard focus and the AT focus get so far from each 
other that we can't render both at the same time? Which should we be 
rendering?

How do native apps handle these cases?

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

Received on Tuesday, 18 February 2014 18:52:11 UTC