- From: Rik Cabanier <cabanier@gmail.com>
- Date: Tue, 18 Feb 2014 11:17:19 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: Dominic Mazzoni <dmazzoni@google.com>, "whatwg@whatwg.org" <whatwg@whatwg.org>
On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson <ian@hixie.ch> wrote: > 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>? 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. `._.-(,_..'--(,_..'`-.;.' >
Received on Tuesday, 18 February 2014 19:17:46 UTC