[whatwg] hit regions: limited set of elements for fallback content
ian at hixie.ch
Tue Feb 18 11:39:31 PST 2014
On Tue, 18 Feb 2014, Rik Cabanier wrote:
> > 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:
> It's fully keyboard navigable but inaccessible since the grid is drawn with
I don't see anything there that really needs <canvas>. In fact, it seems
like it would be substantially easier to implement without <canvas>.
But it is a good example of why we need to answer the questions in my last
e-mail before we can properly support it:
> > 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?
This example actually adds more questions:
How do we handle the multiple focus case? (There's focus in the crossword
and in the clue list at the same time.)
Do we expose the way each cell can be focused in two different directions?
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg