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

On Tue, 18 Feb 2014, Dominic Mazzoni wrote:
> On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson <ian@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?

Well for example, is the use case one of the controls on Bugzilla's 
advanced search page?:

   https://www.w3.org/Bugs/Public/query.cgi?format=advanced

If so, I feel comfortable saying that we don't need to make <canvas> 
support that, since that use case is already handled very well by the 
<select> element.


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

Just because people do it doesn't mean we need to design our APIs around 
it, or otherwise endorse it. For example, people use <table> elements for 
layout purposes, but this is expressively against the <table> conformance 
requirements. People use <blockquote> for indenting, but instead of 
providing a <blockquote indent-depth> attribute, we improve CSS to support 
indenting. And so on.


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

Sure, but that misses the point a little. We are developing technologies 
for custom controls -- Web components. To support a <select> drop-down, 
you need much more than just a canvas: you need a way to show a popup 
window, you need a way to draw shadows over underlying content, etc.

So this is why I ask for the precise use cases. We can only evaluate if 
the technologies are actually addressing needs by going through and seeing 
how they do with precise use cases. If the use cases are very vague, we 
can at best guess, and we might guess poorly.


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

Are Web Components and CSS unable to get the effects you need? Maybe we 
should be improving those rather than <canvas>. It's hard to tell without 
knowing precisely what you want to do.


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

Well we wouldn't want to expose a non-multiple size=1 <select> in the 
canvas fallback for that kind of thing, because such a <select> allows you 
to do things like open the popup, and then we'd be in a horrible situation 
for AT users (and indeed keyboard users), where you could be navigating 
something you can't see, the AT would be describing things that don't 
match the screen, and the script would have no idea what was going on.

If what you wanted was just a series of menu items to cycle through, you 
can do that with addHitRegion() pretty easily. That's just the menu item 
case I described earlier.


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

Why wouldn't you just use <select> and <option>?

If we want to support list boxes in canvases (which is unclear to me; I 
don't understand what the use case is), I don't think it would make sense 
to support it with <div>s when we have a perfectly good control for it 
already.


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

We shouldn't ignore it; we should provide better solutions that make it so 
they don't feel the need to do it.

If a region has a car theft problem, you don't solve it by giving all the 
thieves the car keys. You solve it by improving the economy so that 
thieves have better things to do (like get an interesting job), and you 
solve the remainder by improving law enforcement. The same applies here. 
We solve it by providing better tools for custom text editing controls 
(e.g. better contenteditable APIs), and by making it non-conforming to 
abuse <canvas> for this purpose.


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

It's exactly the right question to ask. What is insufficiently powerful 
about the tools we've provided that is forcing people to use <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.

We can only support so much. We can't support everything. Given that, we 
have to prioritise, and it seems to be that prioritising things that have 
valid use cases is a good way to pick what to do first.


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

What are the answers?


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

Not sure what you mean. What's the difference between a region and a hit 
region, in this context?


> If a web author only had the proposed addHitRegion API available

If we want to support this case, we should support it properly. That means 
we're not limited to the current APIs; we should introduce new ones as 
needed.


> One [option] would be to simply not represent non-focusable content in 
> the fallback content.

I don't understand how one would do this if one had a grid. How do you not 
expose a cell in between two focusable cells?


> Another would be to give those items tabindex=-1 and allow all users to 
> focus them but keep them out of the tab order.

That would allow the user to click on it, too, which would be wrong, 
presumably (at least in the Google Doodle case, the black squares aren't 
focusable at all, they're not just missing from 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.

"magnifier users might get temporarily lost" is presumably very bad, so I 
presume that's not a valid option.


> > 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 would such an API need? Do we need an event that fires on the 
<canvas> indicating that the AT focus has moved to a specific region, the 
same way we handle mouse events? (Should we just support this for all 
elements, not just canvas, while we're at it?)


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

Ok, interesting. That supports the suggestion that we need an event for 
this.


Are there other questions we should be asking to support this grid use 
case?


So far it seems like to support grids in canvas, we need:

 - enable focusable <td> elements to be hit region controls
 - fire an event on an element when the AT focus moves to that element
 - when this event is fired on a canvas, include the region information

Anything else?

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

Received on Tuesday, 18 February 2014 21:17:47 UTC