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

[Nils Dagsson Moskopp]

Steve Faulkner  writes:

> Nils Dagsson Moskopp wrote:
>
>> But still, people (with the exception of Paul Graham) stopped using  
>> for layouts
>
> if only that were true, take a look at https://www.google.co.uk or grep the
> html data available from http://webdevdata.org

Thanks for pointing out that my assumption was unfounded. I am
downloading one of the data sets right now.

>>Also, Faulkner wanting "an example of canvas to make accessible" ... seems
> like circular reasoning to me to use that as an example why >we need an
> accessible canvas.
>
> ?

1. A wants to demonstrate how technology X can do Y.
2. B: „because A wants to demonstrate how X does Y, we need X to do Y“.

reduces to:

3. “X should do Y because someone wants to show how X can do Y.”

Am I misunderstanding the argument by a large margin?

?Btw, I have actually read some of your posts regarding 
accessability and am aware you list quite a lot of arguments.)

-- 
Nils Dagsson Moskopp // erlehmann

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

[Steve Faulkner]

Nils Dagsson Moskopp wrote:

> But still, people (with the exception of Paul Graham) stopped using  
> for layouts

if only that were true, take a look at https://www.google.co.uk or grep the
html data available from http://webdevdata.org

>Also, Faulkner wanting "an example of canvas to make accessible" ... seems
like circular reasoning to me to use that as an example why >we need an
accessible canvas.

?

--
stevef

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

[Nils Dagsson Moskopp]

Charles McCathie Nevile  writes:

> On Thu, 20 Feb 2014 22:38:18 +0100, Nils Dagsson Moskopp  
>  wrote:
>
>> Dominic Mazzoni  writes:
>>
>>> First a high-level thought.
>>>
>>> I'm happy to keep chasing after "legitimate" use-cases instead of  
>>> contrived ones, but just because we can't think of one, doesn't mean it
>>> doesn't exist... Maybe the
>>> vast majority of web apps that use canvas for a grid, or a slider, or a
>>> list box would be better off using standard html5 objects. But what if
>>> there's one app that can't, for some reason we haven't anticipated?
>>> If we wait until that app appears to allow that control to have a hit
>>> region, then it will be months or years before that app can be
>>> accessible.
>
> Which is why I think the "but it shouldn't be done that way" argument  
> needs to be viewed through the prism of the question "but will it"?
>
> History strongly suggests that people will use canvas because it suits  
> them, whatever "experts" like us say they *should* do.

People also used  for layout and created unskippable flash
intros. Web programming might resemble pop culture – it has trends like
visitor counters that came and thankfully went away (but then were hip
again to show the number of likes or retweets). But still, people (with
the exception of Paul Graham) stopped using  for layouts and also
do rely less on flash for video content than they did seven years ago.

>>> More below:
>>>
>>> On Tue, Feb 18, 2014 at 1:16 PM, Ian Hickson  wrote:
>>>
 On Tue, 18 Feb 2014, Dominic Mazzoni wrote:
 > On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson  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 
 support that, since that use case is already handled very well by the
  element.
>
> It probably is for bugzilla.
>
> It isn't for the case where somebody wants a dropdown menu for selecting  
> things, that matches the particularities of their site design.
>
> Nor does  work for the case where the site is being built by  
> someone who wants to ensure that their CSS can't be overridden; I don't  
> know why people think this, but many still do.

The user should *always* have control. People who “want to ensure that
their CSS can't be overridden” are enemies of usability, accessability,
by extension also enemies of security and – ultimately – proponents of
Digital Restrictions Management.

Btw, I use a fixed font and a high contrast GTK+ theme myself – both
apply to form controls to make them more usable.

> It apparently isn't for search suggestions. Whatever the reason, Yandex  
> search doesn't use it for their suggestions. While they don't use canvas  
> either, it seems that select is not sufficient for Yandex. Nor is it used  
> by Google, Yahoo, Bing or Baidu for the task. And none of them have a  
> complicated layout to work with. But they all use styled text elements.

Please elaborate: What do you think you can infer from this? Maybe I
have not understood the problem these search engines all seem to have.

>>> I'll try, though: what if I had a list of choices displayed as a pie  
>>> chart?
>>> Each slice of the pie is a focusable object that, when you click on it,
>>> allows you to take an action on that pie slice.
>>
>> What if I look at that page in a textual user agent?
>
> Where the hit regions are based on a list as 'fallback content'? You get a  
> list. With links that match the actions. If the developer got  
> accessibility right.

If. Contrast the CSS solution, where just removing the obnoxious styling
(or visiting the page in a w3m) shows a perfectly usable form – without
any additional work from the developer.

> But if they would only get it a bit right, it seems stupid to suggest that  
> we should gratuitously deny them the option - letting perfect be the enemy  
> of good here is an extremely effective way to reduce accessibility, which  
> is very rarely done perfectly.

There are already quite easy options to build accessible web forms. If
an author chooses to not make a web page beautiful and sacrifices
accessability, that person is certainly optimizing for style and not
particularly caring about accessability.

I consider this a social problem that may partially be overcome by
designing standards (like document formats or protocols) in a way that
there exists a way of least resistance

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

[Charles McCathie Nevile]

On Thu, 20 Feb 2014 22:38:18 +0100, Nils Dagsson Moskopp  
 wrote:



Dominic Mazzoni  writes:


First a high-level thought.

I'm happy to keep chasing after "legitimate" use-cases instead of  
contrived ones, but just because we can't think of one, doesn't mean it

doesn't exist... Maybe the
vast majority of web apps that use canvas for a grid, or a slider, or a
list box would be better off using standard html5 objects. But what if
there's one app that can't, for some reason we haven't anticipated?
If we wait until that app appears to allow that control to have a hit
region, then it will be months or years before that app can be
accessible.


Which is why I think the "but it shouldn't be done that way" argument  
needs to be viewed through the prism of the question "but will it"?


History strongly suggests that people will use canvas because it suits  
them, whatever "experts" like us say they *should* do.



More below:

On Tue, Feb 18, 2014 at 1:16 PM, Ian Hickson  wrote:


On Tue, 18 Feb 2014, Dominic Mazzoni wrote:
> On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson  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 
support that, since that use case is already handled very well by the
 element.


It probably is for bugzilla.

It isn't for the case where somebody wants a dropdown menu for selecting  
things, that matches the particularities of their site design.


Nor does  work for the case where the site is being built by  
someone who wants to ensure that their CSS can't be overridden; I don't  
know why people think this, but many still do.


It apparently isn't for search suggestions. Whatever the reason, Yandex  
search doesn't use it for their suggestions. While they don't use canvas  
either, it seems that select is not sufficient for Yandex. Nor is it used  
by Google, Yahoo, Bing or Baidu for the task. And none of them have a  
complicated layout to work with. But they all use styled text elements.


I'll try, though: what if I had a list of choices displayed as a pie  
chart?

Each slice of the pie is a focusable object that, when you click on it,
allows you to take an action on that pie slice.


What if I look at that page in a textual user agent?


Where the hit regions are based on a list as 'fallback content'? You get a  
list. With links that match the actions. If the developer got  
accessibility right.


But if they would only get it a bit right, it seems stupid to suggest that  
we should gratuitously deny them the option - letting perfect be the enemy  
of good here is an extremely effective way to reduce accessibility, which  
is very rarely done perfectly.


Surely you'd agree that rendering a pie chart is a natural use-case for  
the canvas element.


Nope. If it is just decoration, you should use CSS. Look at source code:


(For pages like these, I have a hotkey for “disable CSS”.)


But you are not a scalable resource, just an anecdotal data point. When  
Opera wanted to publish statistical tables in their "State of the Mobile  
Web" reports, their Web designers felt that canvas was the obvious way to  
do so. When accessibility expert Steve Faulkner wanted an example of  
canvas to make accessible he used an interactive pie chart.


http://yandex.com/yandsearch?text=pie%20chart%20canvas suggests that a lot  
of people appear to think it is a natural thing to do. I got ~310k  
answers, and while not all of them will be about using canvas to make pie  
charts the overwhelming majority of the first few pages are.


So it appears that there *are* use cases for this, and that people go to  
the effort of doing it, whether or not it is a good idea.



I know it's technically possible in css, but it's quite
tricky - whereas it's simple and natural in canvas. And there are  
plenty of shapes that are basically impossible in pure CSS.


I might consider that a good thing.


You may do. Many front-end developers I work with find it a limitation.  
Beyond all these anecdotes, rounded corners offers plenty of evidence that  
designers will use all manner of techniques that you and I probably agree  
are unhelpful, to achieve their visual design goals.



May I ask if you have designed
human-computer interfaces. If so, may you provide examples?


I'm not sure how that is relevant.


> What if I do want a , but I just want a canvas to render it
> v

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

[Ian Hickson]

On Fri, 21 Feb 2014, Steve Faulkner wrote:
> 
>> But there's plenty of things which make zero sense as fallback content. 
>> , for example, simply cannot be sanely implemented in 
>> canvas
> 
> as implemented input type=color is a button that when activated pops up 
> a picker dialog.

Only on some platforms.


> So the following code (as a simple example)
> 
>  style="border:1px solid #00;"
> onclick="document.getElementById('button').click();">
> 
> 
> 
> in Firefox 30/windows when the canvas is clicked the color picker is 
> displayed. likewise if the the input receives focus via the keyboard and 
> the enter/spacebar key is pressed the picker dialog is displayed. --

And that's great if you happen to have that exact implementation. But what 
about implementations where a colour palette drops down or is shown inline?


On Fri, 21 Feb 2014, Charles McCathie Nevile wrote:
> 
> I don't want to pronounce on sanity, but I don't think it has ever been 
> a major criterion for whether people *will* do something on the Web.

Sure. What we're talking about here is just how to guide people into what 
is more sane. This is a big part of what language design, especially 
opinionated language design, is all about.


> And it seems pretty easy to make a colour picker in canvas. I can 
> imagine that anyone who wanted a specific-purpose color picker (styled 
> to match the site, or customising the options, or...) would do it in 
> canvas or SVG, and my guess is the former would be more common...

Building a colour picked in canvas would be easy. Making it accessible 
using a backing logic based on radio buttons, a list box, or regular 
buttons, would be easy. Making it acessible based on  
would not work at all.

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

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

[Charles McCathie Nevile]

On Fri, 21 Feb 2014 09:47:51 +0100, Steve Faulkner  
 wrote:



hixie wrote:


But there's plenty of things which make zero sense as fallback content.
, for example, simply cannot be sanely implemented in
canvas


I don't want to pronounce on sanity, but I don't think it has ever been a  
major criterion for whether people *will* do something on the Web.


And it seems pretty easy to make a colour picker in canvas. I can imagine  
that anyone who wanted a specific-purpose color picker (styled to match  
the site, or customising the options, or...) would do it in canvas or SVG,  
and my guess is the former would be more common...


cheers

Chaals


as implemented input type=color is a button that when activated pops up a
picker dialog. So the following code (as a simple example)





in Firefox 30/windows when the canvas is clicked the color picker is
displayed., likewise if the the input receives focus via the keyboard and
the enter/spacebar key is pressed the picker dialog is displayed.
--

Regards

SteveF
HTML 5.1 



--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru Find more at http://yandex.com

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

[Steve Faulkner]

hixie wrote:

But there's plenty of things which make zero sense as fallback content.
, for example, simply cannot be sanely implemented in
canvas

as implemented input type=color is a button that when activated pops up a
picker dialog. So the following code (as a simple example)





in Firefox 30/windows when the canvas is clicked the color picker is
displayed., likewise if the the input receives focus via the keyboard and
the enter/spacebar key is pressed the picker dialog is displayed.
--

Regards

SteveF
HTML 5.1 

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

[Nils Dagsson Moskopp]

Dominic Mazzoni  writes:

> First a high-level thought.
>
> I'm happy to keep chasing after "legitimate" use-cases instead of contrived
> ones, but just because we can't think of one, doesn't mean it doesn't
> exist. As Alan Perlis said, "Every program has (at least) two purposes: the
> one for which it was written and another for which it wasn't. Maybe the
> vast majority of web apps that use canvas for a grid, or a slider, or a
> list box would be better off using standard html5 objects. But what if
> there's one app that can't, for some reason we haven't anticipated? If we
> wait until that app appears to allow that control to have a hit region,
> then it will be months or years before that app can be accessible.
>
> More below:
>
> On Tue, Feb 18, 2014 at 1:16 PM, Ian Hickson  wrote:
>
>> On Tue, 18 Feb 2014, Dominic Mazzoni wrote:
>> > On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson  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 
>> support that, since that use case is already handled very well by the
>>  element.
>>
>
> As I argued above, maybe we can't come up with a really good use-case, but
> that doesn't mean one doesn't exist.

Absence of evidence is at least weak evidence of absence.
Quote :

You hear some rustling noises in your backyard, and you want to figure
out if the noises were caused by your neighbor's dog or by some other
intruder. Fortunately, you know what your neighbor's dog is like - he's
rambunctious and he barks constantly. So you listen closely, and after
20 minutes you don't hear any barking. What should you conclude?

> I'll try, though: what if I had a list of choices displayed as a pie chart?
> Each slice of the pie is a focusable object that, when you click on it,
> allows you to take an action on that pie slice.

What if I look at that page in a textual user agent?

> Surely you'd agree that rendering a pie chart is a natural use-case for the
> canvas element.

Nope. If it is just decoration, you should use CSS. Look at source code:


(For pages like these, I have a hotkey for “disable CSS”.)

> I know it's technically possible in css, but it's quite
> tricky - whereas it's simple and natural in canvas. And there are plenty of
> shapes that are basically impossible in pure CSS.

I might consider that a good thing. May I ask if you have designed
human-computer interfaces. If so, may you provide examples?

>> > What if I do want a , 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 . It's hard to tell without
>> knowing precisely what you want to do.

This requests reminds me of customers wanting “page intro in flash.”.

>> 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  for this purpose.
>>
>
> I'd suggest a different analogy: suppose your company makes foam pipe
> insulation and you discover people are buying your product and using it as
> a swimming pool flotation device. Do you try to stop them from using your
> product and try to get them to purchase other pool toys, or do you start
> selling your pipe insulation directly to the sporting goods stores?

You might check if the pipe insulation is toxic, first.

-- 
Nils Dagsson Moskopp // erlehmann

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

[Ian Hickson]

On Thu, 20 Feb 2014, Dominic Mazzoni wrote:
> On Thu, Feb 20, 2014 at 10:37 AM, Ian Hickson  wrote:
> > 
> > So far, it seems like to support grids in canvas, we need:
> >
> >  - enable table-related elements (table, td, tfoot, etc) to be hit region
> >controls. (exclude col and colgroup)

Filed this as: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24750

> >  - fire an event on an element when the user agent (possibly because of a
> >request from the AT, but not necessarily) wants to scroll to an
> >element; default action is to actually scroll.
> >  - when this event is fired on a canvas, include the region information.

Filed this as: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24748

> > ...and to support list boxes, we need:
> >
> >  - enable  elements to be hit region controls.
> >  - enable  eements where N>1 to be hit region controls.
> >  - enable  to be hit region controls.
> >  - optionally, if implementors are on board:
> > - make  in  act like size=N where N>1.
> > - enable  elements to be hit region controls.

Filed this as: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24749


> > What's your take on the  thing; should we have a special case 
> > in browsers for size=1, or should we require size>1?
> 
> I can't think of a way to make size=1 work, so requiring size>1 may be 
> the only option. It seems ugly, though.

The way we could make it work would be to change the logic in the  
so that when it's in a canvas, it's a list box and not a drop-down. But 
that might be more confusing than requiring that people set size=2? I 
guess I'll just punt on this for now and we'll see whether authors get 
confused or not.

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

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

[Dominic Mazzoni]

On Thu, Feb 20, 2014 at 10:37 AM, Ian Hickson  wrote:

> So far, it seems like to support grids in canvas, we need:
>
>  - enable table-related elements (table, td, tfoot, etc) to be hit region
>controls. (exclude col and colgroup)
>  - fire an event on an element when the user agent (possibly because of a
>request from the AT, but not necessarily) wants to scroll to an
>element; default action is to actually scroll.
>  - when this event is fired on a canvas, include the region information.
>
> ...and to support list boxes, we need:
>
>  - enable  elements to be hit region controls.
>  - enable  eements where N>1 to be hit region controls.
>  - enable  to be hit region controls.
>  - optionally, if implementors are on board:
> - make  in  act like size=N where N>1.
> - enable  elements to be hit region controls.
>

This all sounds great.

Are there any other use cases we should address?
>

Possibly, but this is a great start for now. I'll post more use cases as I
uncover them or think of them.


> What's your take on the  thing; should we have a special case in
> browsers for size=1, or should we require size>1?
>

I can't think of a way to make size=1 work, so requiring size>1 may be the
only option. It seems ugly, though.

- Dominic


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

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

[Ian Hickson]

On Thu, 20 Feb 2014, Dominic Mazzoni wrote:
> 
> I'm happy to keep chasing after "legitimate" use-cases instead of 
> contrived ones, but just because we can't think of one, doesn't mean it 
> doesn't exist. As Alan Perlis said, "Every program has (at least) two 
> purposes: the one for which it was written and another for which it 
> wasn't. Maybe the vast majority of web apps that use canvas for a grid, 
> or a slider, or a list box would be better off using standard html5 
> objects. But what if there's one app that can't, for some reason we 
> haven't anticipated? If we wait until that app appears to allow that 
> control to have a hit region, then it will be months or years before 
> that app can be accessible.

The problem is that without knowing what the unanticipated app is, we 
can't possibly design for it. Trying to design APIs blindly results in 
poor APIs.


> As I argued above, maybe we can't come up with a really good use-case, 
> but that doesn't mean one doesn't exist.

But it _does_ mean we can't possibly design for it.


> I'll try, though: what if I had a list of choices displayed as a pie 
> chart? Each slice of the pie is a focusable object that, when you click 
> on it, allows you to take an action on that pie slice.

Isn't that handled by just a series of buttons corresponding to each 
slice? I don't really understand why you'd need a list box here.


> But how should the list of pie slices behave if you were interacting 
> with the pie chart using the keyboard? Why not a list box? Conceptually 
> you just have a list of elements, one of which can be selected at a 
> time.

I think conceptually you have a series of buttons.

It would be more like a list box if instead of each slice being 
activatable, the slices were selectable, maybe multiple slices being 
selectable such that you can then operate on them as a group.

That does seem like a reasonable use case.

It would argue for allowing  where n>1, and for . It's a bit weird to require that we explicitly give the size 
for a fallback , so maybe we should instead just say that any 
 that's in canvas fallback is automatically assumed to have 
a non-1 size? Would that be reasonable to implement?


> Even though you're not supposed to use  for layout, is there any
> part of the HTML spec that forbids placing a certain element inside a table
> cell because the only legitimate reason to do so would be if it was a
> layout table?

We've made lots of elements non-conforming, e.g. . Looking at tables 
specifically, there's no element that was previously only allowed in 
tables that has since been disallowed (all the elements we've disallowed 
from  were also allowed elsewhere before and are disallowed 
everywhere now), but there's lots of _attributes_ on , , etc, 
that we've made non-conforming for the same reason:

  
  
  
  
  
  
  
  

...etc.

Plus of course we don't allow any elements that aren't currently in HTML.


> Similarly, I think it'd be simplest to just allow any element to be the 
> target of a hit region. We can still discourage it, but fail gracefully 
> if authors decide to abuse it.

I'm all for allowing things which have reasonable use cases. But there's 
plenty of things which make zero sense as fallback content. , for example, simply cannot be sanely implemented in canvas, 
because we don't provide the right hooks. Similarly for , 
in its normal form (i.e. assuming we don't special-case it to turn it 
into a listbox rather than a drop-down widget).


> > Sure, but that misses the point a little. We are developing 
> > technologies for custom controls -- Web components. To support a 
> >  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.
> 
> Yes, and people are building replacements for  using web 
> components now, like polymer-ui-menu: 
> http://www.polymer-project.org/components/polymer-ui-menu/smoke.html

(Loading that page shows why it's terrible to design new widgets from 
scratch instead of building them on existing fallback elements, by the 
way. It's a completely unusable page with near zero semantics. Completely 
inaccessible, even to non-AT users, all because the scripts can't load.)


> It should be easy to make something like polymer-ui-menu accessible 
> using role=listbox and role=option under the hood.
> The question is, why shouldn't it be possible to implement a
> polymer-ui-canvas-menu that works the same way but uses a canvas to render?

I think it's a fine use case that we should enable. We just need to work 
out what to do regarding , as discussed above.


> I'd suggest a different analogy: suppose your company makes foam pipe 
> insulation and you discover people are buying your product and using it 
> as a swimming pool flotation device. Do you try to stop them from using 
> your product and try to get them to purchase other pool toys, or do you 
> start selling your pipe insulation d

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

[Dominic Mazzoni]

First a high-level thought.

I'm happy to keep chasing after "legitimate" use-cases instead of contrived
ones, but just because we can't think of one, doesn't mean it doesn't
exist. As Alan Perlis said, "Every program has (at least) two purposes: the
one for which it was written and another for which it wasn't. Maybe the
vast majority of web apps that use canvas for a grid, or a slider, or a
list box would be better off using standard html5 objects. But what if
there's one app that can't, for some reason we haven't anticipated? If we
wait until that app appears to allow that control to have a hit region,
then it will be months or years before that app can be accessible.

More below:

On Tue, Feb 18, 2014 at 1:16 PM, Ian Hickson  wrote:

> On Tue, 18 Feb 2014, Dominic Mazzoni wrote:
> > On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson  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 
> support that, since that use case is already handled very well by the
>  element.
>

As I argued above, maybe we can't come up with a really good use-case, but
that doesn't mean one doesn't exist.

I'll try, though: what if I had a list of choices displayed as a pie chart?
Each slice of the pie is a focusable object that, when you click on it,
allows you to take an action on that pie slice.

Surely you'd agree that rendering a pie chart is a natural use-case for the
canvas element. I know it's technically possible in css, but it's quite
tricky - whereas it's simple and natural in canvas. And there are plenty of
shapes that are basically impossible in pure CSS.

But how should the list of pie slices behave if you were interacting with
the pie chart using the keyboard? Why not a list box? Conceptually you just
have a list of elements, one of which can be selected at a time.

> 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  elements for
> layout purposes, but this is expressively against the  conformance
> requirements. People use  for indenting, but instead of
> providing a  attribute, we improve CSS to support
> indenting. And so on.
>

Even though you're not supposed to use  for layout, is there any
part of the HTML spec that forbids placing a certain element inside a table
cell because the only legitimate reason to do so would be if it was a
layout table? I'm not aware of one. Similarly, I think it'd be simplest to
just allow any element to be the target of a hit region. We can still
discourage it, but fail gracefully if authors decide to abuse it.

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

Yes, and people are building replacements for  using web components
now, like polymer-ui-menu:
http://www.polymer-project.org/components/polymer-ui-menu/smoke.html

It should be easy to make something like polymer-ui-menu accessible using
role=listbox and role=option under the hood.

The question is, why shouldn't it be possible to implement a
polymer-ui-canvas-menu that works the same way but uses a canvas to render?

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 , 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 . It's hard to tell without
> knowing precisely what you want to do.
>

Is my pie chart example good? We can keep brains

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

[Ian Hickson]

On Tue, 18 Feb 2014, Dominic Mazzoni wrote:
> On Tue, Feb 18, 2014 at 11:39 AM, Ian Hickson  wrote:
> >
> > 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.)
> 
> I don't think multiple things are focused at once. Rather, certain 
> composite controls have a notion of which cell is "active", that becomes 
> the focused cell when you focus it. If you have a  
> control on your page, you can tell which items are selected even when it 
> isn't focused, and I think this is the same thing.

Yeah, it's not clear exactly what is focused, per se. It could be the 
cell, or it could be the clue. I'm not sure how to tell. Tab jumps through 
the clues, the arrows keys jump through the cells. Clicking either has the 
same/equivalent effect. Both need to be called out when you focus either.


> > Do we expose the way each cell can be focused in two different 
> > directions?
> 
> I don't see how that would translate into an accessibility API, even in 
> a native app. I think the author would have to semantically convey that 
> via some other means.

Right, but, what other means? That's what I'm trying to work out.

How would we actually solve this specific use case?

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

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

[Ian Hickson]

On Tue, 18 Feb 2014, Dominic Mazzoni wrote:
> On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson  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  
support that, since that use case is already handled very well by the 
 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  elements for 
layout purposes, but this is expressively against the  conformance 
requirements. People use  for indenting, but instead of 
providing a  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  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 , 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 . 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 , 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 , since you'd need some way to map the 
> > open  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  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  in the 
canvas fallback for that kind of thing, because such a  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?
> > >
> > > 
> > >   
> > > First option
> > > Second option
> > > Third option
> > >   
> > > 
> >
> > Why would you use s in the canvas fallback? Just use the real
> > control, like a .
> 
> 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  and ?

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

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

[Dominic Mazzoni]

On Tue, Feb 18, 2014 at 11:39 AM, Ian Hickson  wrote:

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

I don't think multiple things are focused at once. Rather, certain
composite controls have a notion of which cell is "active", that becomes
the focused cell when you focus it. If you have a  control
on your page, you can tell which items are selected even when it isn't
focused, and I think this is the same thing.


> Do we expose the way each cell can be focused in two different directions?
>

I don't see how that would translate into an accessibility API, even in a
native app. I think the author would have to semantically convey that via
some other means.

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

[Ian Hickson]

On Tue, 18 Feb 2014, Rik Cabanier wrote:
> >
> > Why would you use a  for a cross-word puzzle, rather than a 
> > ?
> 
> 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.

I don't see anything there that really needs . In fact, it seems 
like it would be substantially easier to implement without .

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.   `._.-(,_..'--(,_..'`-.;.'

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

[Dominic Mazzoni]

On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson  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 , not a .


What if I do want a , 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
> , 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
> , since you'd need some way to map the open  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  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?
> >
> > 
> >   
> > First option
> > Second option
> > Third option
> >   
> > 
>
> Why would you use s in the canvas fallback? Just use the real
> control, like a .
>

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  for a cross-word puzzle, rather than a
> ?
>
> > 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
>  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 .

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?
>
> 
>  
>   
> I  N
>   
> F 
>  
> 
>
> 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 

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

[Rik Cabanier]

On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson  wrote:

> On Tue, 18 Feb 2014, Dominic Mazzoni wrote:
> > On Mon, Feb 17, 2014 at 11:02 PM, Ian Hickson  wrote:
> > > >
> > > > What about ?
> > >
> > > 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 , not a . But
> if there's a valid reason to have a list box or other select control in a
> , 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
> , since you'd need some way to map the open  popup's focus
> to canvas, and there's no API to do that currently.)
>
>
> > What about a list box using ARIA instead?
> >
> > 
> >   
> > First option
> > Second option
> > Third option
> >   
> > 
>
> Why would you use s in the canvas fallback? Just use the real
> control, like a .
>
> But see above for the case of  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 , 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  to a 
> 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 .
>
> 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  for a cross-word puzzle, rather than a
> ?


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
>  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?
>
> 
>  
>   
> I  N
>   
> F 
>  
> 
>
> 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.   `._.-(,_..'--(,_..'`-.;.'
>

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

[Ian Hickson]

On Tue, 18 Feb 2014, Dominic Mazzoni wrote:
> On Mon, Feb 17, 2014 at 11:02 PM, Ian Hickson  wrote:
> > > 
> > > What about ?
> >
> > 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 , not a . But 
if there's a valid reason to have a list box or other select control in a 
, 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 
, since you'd need some way to map the open  popup's focus 
to canvas, and there's no API to do that currently.)


> What about a list box using ARIA instead?
> 
> 
>   
> First option
> Second option
> Third option
>   
> 

Why would you use s in the canvas fallback? Just use the real 
control, like a .

But see above for the case of  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 , 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  to a  
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 .

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  for a cross-word puzzle, rather than a 
?


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


 
  
I  N
  
F  
 


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.   `._.-(,_..'--(,_..'`-.;.'

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

[Dominic Mazzoni]

On Mon, Feb 17, 2014 at 11:02 PM, Ian Hickson  wrote:

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

Sure. addHitRegion() supports roles like menuitem this in two ways: If
> you're doing something like a straight-forward menu item, you can just add
> the text and the role directly. If you're doing something more elaborate
> (e.g. a menu with disabled items), you can add appropriate elements (e.g.
> ) representing the menu into the  fallback content, and
> use ARIA roles and properties to override 's defaults.
>

That sounds fine.


> Once you get to more elaborate compound controls like spin buttons, you
> really shouldn't be using  in the first place, and so those aren't
> supported (spinbutton in particular would be impossible to correctly
> support in a canvas, since it's a compound control with multiple
> subregions, all corresponding to a single DOM node on the ARIA side).
>

Spinbutton is probably a bad example. What about a list box using ARIA
instead?


  
First option
Second option
Third option
  


It seems to me that I could make each visible option a hit region - why
couldn't we make this 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 , so those aren't supported.


So you don't think people are going to implement something like a
spreadsheet using canvas?


> That's what  is for.
> If you want a table with graphics inside, the way to do that is to have a
>  with each  containing a , not a single . This
> is relatively important because users really don't want authors
> reimplementing table navigation themselves -- indeed I'm not even sure
> it's technically possible for an author to track the AT focus as the user
> navigates a table using AT commands, so it would be incredibly difficult
> for an author to do a good reimplementation of a grid on canvas.
>
> If there are specific use cases for why you'd want to recreate a table
> using , please do describe it. If we need to support this, then we
> should make sure we do a good job (as noted, the current APIs aren't
> sufficient, even if we just make addHitRegion() support pointing to 
> elements in the canvas fallback content).
>

A spreadsheet is one possible use-case, though I agree it's complicated.

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? The accessible fallback content could use a table, and but each
cell would be focusable and have a role of gridcell.

Games like tic-tac-toe, chess, or reversi would also be reasonable
use-cases to consider for this.

- Dominic



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

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

[Ian Hickson]

On Mon, 17 Feb 2014, Dominic Mazzoni wrote:
> On Mon, Feb 17, 2014 at 8:20 PM, Ian Hickson  wrote:
> > 
> > If there are specific use cases that can't be done given the current 
> > restrictions, please let me know;
> 
> What about ?

What about it?


> What about an element with a tabindex and an ARIA role that corresponds 
> to a control?

Can you elaborate?


> Note that there are a few ARIA roles for interactive controls that don't 
> have matching HTML counterparts, like gridcell, menuitem, or spinbutton.

Sure. addHitRegion() supports roles like menuitem this in two ways: If 
you're doing something like a straight-forward menu item, you can just add 
the text and the role directly. If you're doing something more elaborate 
(e.g. a menu with disabled items), you can add appropriate elements (e.g. 
) representing the menu into the  fallback content, and 
use ARIA roles and properties to override 's defaults.

Once you get to more elaborate compound controls like spin buttons, you 
really shouldn't be using  in the first place, and so those aren't 
supported (spinbutton in particular would be impossible to correctly 
support in a canvas, since it's a compound control with multiple 
subregions, all corresponding to a single DOM node on the ARIA side).

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 , so those aren't supported. That's what  is for. 
If you want a table with graphics inside, the way to do that is to have a 
 with each  containing a , not a single . This 
is relatively important because users really don't want authors 
reimplementing table navigation themselves -- indeed I'm not even sure 
it's technically possible for an author to track the AT focus as the user 
navigates a table using AT commands, so it would be incredibly difficult 
for an author to do a good reimplementation of a grid on canvas.

If there are specific use cases for why you'd want to recreate a table 
using , please do describe it. If we need to support this, then we 
should make sure we do a good job (as noted, the current APIs aren't 
sufficient, even if we just make addHitRegion() support pointing to  
elements in the canvas fallback content).

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

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

[Ian Hickson]

On Mon, 17 Feb 2014, Rik Cabanier wrote:
>
> Were those use cases posted to this list?

I'm sure some were. Your typical use case would be something like a graph, 
a game menu, a fractal explorer, and so on.


> So, you wouldn't want the same limitations as for regular HTML elements?

Not sure what you mean. The rules for addHitRegion() match the regular 
 content model.


> http://www.whatwg.org/specs/web-apps/current-work/#wai-aria

This seems orthogonal to the issue of addHitRegion()... I'm not sure I 
follow the relevance here.


> The canvas fallback content could be what is exposed to the user so it 
> might be painful for the author to match it up with hit regions.

Not sure what you mean here. Can you elaborate? Maybe an example would 
help.


> I agree that relaxing it to any element could allow non-sense. Is there 
> a clear definition of what is disallowed or allowed in HTML? I couldn't 
> find it in the spec.

Allowed or disallowed in what sense? If you mean the content models, the 
specification has elaborate text describing the rules; you can find the 
introduction to content models here:

   http://whatwg.org/html#content-models

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

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

[Dominic Mazzoni]

On Mon, Feb 17, 2014 at 8:20 PM, Ian Hickson  wrote:

> If there are specific use cases that can't be done given the current
> restrictions, please let me know;
>

What about ? What about an element with a tabindex and an ARIA role
that corresponds to a control? Note that there are a few ARIA roles for
interactive controls that don't have matching HTML counterparts, like
gridcell, menuitem, or spinbutton.

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

[Rik Cabanier]

On Mon, Feb 17, 2014 at 8:20 PM, Ian Hickson  wrote:

> On Mon, 17 Feb 2014, Rik Cabanier wrote:
> >
> > The current spec for hit regions restricts what elements can be used as
> > fallback content [1]:
> >
> > [...]
> >
> > Why is there this limitation?
>
> It supports the content model restrictions, which are there to avoid
> authors making mistakes that harm accessibility (amongst other things).
> Reasons for content model restrictions are discussed in more detail in the
> introduction to the spec:
>
>
> http://whatwg.org/html#restrictions-on-content-models-and-on-attribute-values
>
> If there are specific use cases that can't be done given the current
> restrictions, please let me know; we can definitely consider relaxing some
> of the restrictions. (It's very hard to tighten restrictions, but
> comparatively easy to relax them, which is why we start them on the strict
> side rather than on the relaxed side.) So far, all the use cases that
> people have brought up for things that can't be done within the current
> restrictions also happen to be things that canvas is actually really bad
> at doing at all.


Thanks.
Were those use cases posted to this list?

So, you wouldn't want the same limitations as for regular HTML elements?
http://www.whatwg.org/specs/web-apps/current-work/#wai-aria
The canvas fallback content could be what is exposed to the user so it
might be painful for the author to match it up with hit regions.

I agree that relaxing it to any element could allow non-sense. Is there a
clear definition of what is disallowed or allowed in HTML? I couldn't find
it in the spec.


> There's another non-normative section that goes into more
> detail about these kinds of things:
>
>http://whatwg.org/html#best-practices
>

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

[Ian Hickson]

On Mon, 17 Feb 2014, Rik Cabanier wrote:
>
> The current spec for hit regions restricts what elements can be used as 
> fallback content [1]:
>
> [...]
> 
> Why is there this limitation?

It supports the content model restrictions, which are there to avoid 
authors making mistakes that harm accessibility (amongst other things). 
Reasons for content model restrictions are discussed in more detail in the 
introduction to the spec:

   http://whatwg.org/html#restrictions-on-content-models-and-on-attribute-values

If there are specific use cases that can't be done given the current 
restrictions, please let me know; we can definitely consider relaxing some 
of the restrictions. (It's very hard to tighten restrictions, but 
comparatively easy to relax them, which is why we start them on the strict 
side rather than on the relaxed side.) So far, all the use cases that 
people have brought up for things that can't be done within the current 
restrictions also happen to be things that canvas is actually really bad 
at doing at all. There's another non-normative section that goes into more 
detail about these kinds of things:

   http://whatwg.org/html#best-practices

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

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

[Rik Cabanier]

The current spec for hit regions restricts what elements can be used as
fallback content [1]:

If any of the following conditions are met, throw a
NotSupportedError
exception
and abort these steps.


   - ...
  - The arguments object's control member is not null but is neither an
  
a
element
  that 
represents
   a 
hyperlink,
  a 
button
element,
  an 
inputelement
  whose 
type
attribute
  is in one of the
Checkbox
   or Radio
Button
states,
  nor an 
input
element
  that is a
button
  .

Why is there this limitation?


1:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#hit-regions