[whatwg] hit regions: limited set of elements for fallback content
cabanier at gmail.com
Tue Feb 18 11:17:19 PST 2014
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:
> ...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:
> > 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
Because it is easier to code a nice interface.
See this Google doodle:
It's fully keyboard navigable but inaccessible since the grid is drawn with
> > 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?
> <table onkeypress="handleKeyInput">
> <td tabindex=0> I <td tabindex=0> N
> <td tabindex=0> F <td class=black aria-readonly=false>
> 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
> 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg