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

[Rik Cabanier]

On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Tue, 18 Feb 2014, Dominic Mazzoni wrote:
> > On Mon, Feb 17, 2014 at 11:02 PM, Ian Hickson <ian at 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>?


Because it is easier to code a nice interface.
See this Google doodle:
http://www.google.com/logos/2013/crossword/crossword13.html

It's fully keyboard navigable but inaccessible since the grid is drawn with
canvas.


> > 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.   `._.-(,_..'--(,_..'`-.;.'
>