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

[Dominic Mazzoni]

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

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

How can I get more concrete than there's a list box inside a canvas?

Whether or not we think it's a good idea, people are building entire UIs
using canvas. Sometimes it's in order to achieve pixel-perfect rendering
accuracy across browsers and platforms, sometimes it's for speed, sometimes
it's for visual effects that aren't possible in HTML, sometimes it's
because they're building a cross-platform UI.

Asking web developers not to build UIs in canvas is like asking Windows,
Mac, iOS, or Android developers to not build custom controls. It's not
going to happen. Some developers are going to reinvent the wheel poorly
when they should be leveraging the appropriate native controls. But some of
the best developers are going to build a fantastic custom control using
more low-level primitives because they can make something more awesome -
and it should be possible to make that accessible too.

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


What if I do want a <select>, but I just want a canvas to render it
visually?


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

Agreed about the open select, which is why I was thinking about the subset
of cases that could work - like a <select> that doesn't open but just lets
you change its value with up/down buttons or with arrow keys.

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

Because when I do it this way, I can make each (visible) option a hit
region, rather than the entire control being one hit region.

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

Yes, but people are implementing text controls in canvas too. We can't
ignore that.

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

I think that's the wrong question to ask. Lots of people have already made
versions of these game using <canvas>.

I don't accept that we shouldn't allow for accessibility because they
shouldn't have used canvas in the first place. People are using canvas for
all sorts of things.

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

That's a perfectly valid question. That suggests we also need a lower-level
API that associates an element in fallback content with a region in canvas,
even without making it a "hit" region. I don't see how that's an argument
against hit regions, though.

If a web author only had the proposed addHitRegion API available, they
would have several options available. One would be to simply not represent
non-focusable content in the fallback content. Another would be to give
those items tabindex=-1 and allow all users to focus them but keep them out
of the tab order. Finally another option would be to keep those cells in
the fallback content but not map them to their correct path in the canvas,
so magnifier users might get temporarily lost.


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

This is no different for a canvas or anything else - AT focus can be on any
element, focusable or not.


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

Browsers don't currently know what element has AT focus, but the browser
tells the AT if the coordinates of an element make it offscreen, and AT can
send a command telling the browser to scroll an element on-screen.
Currently browsers implement this automatically, without involving the web
author - but for completeness we may want canvas authors to have the option
to respond to a request to scroll a fallback content element into view.


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

The AT is in control of this. We render whatever has keyboard focus unless
the AT explicitly asks us to scroll.


> How do native apps handle these cases?
>

Native apps communicate when an element is offscreen, and AT requests to
scroll it into view.

- Dominic


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