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

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 <select size=n> where n>1, and for <select 
multiple>. It's a bit weird to require that we explicitly give the size 
for a fallback <select>, so maybe we should instead just say that any 
<select size=1> 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 <table> 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. <font>. 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 <table> were also allowed elsewhere before and are disallowed 
everywhere now), but there's lots of _attributes_ on <table>, <td>, etc, 
that we've made non-conforming for the same reason:

  <table bgcolor>
  <table border>
  <table bordercolor>
  <table cellpadding>
  <table cellspacing>
  <table width>
  <td align>
  <td bgcolor>

...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. <input 
type=color>, for example, simply cannot be sanely implemented in canvas, 
because we don't provide the right hooks. Similarly for <select size=1>, 
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 
> > <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.
> 
> Yes, and people are building replacements for <select> 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 <select size=1>, 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 directly to the sporting goods 
> stores?

In reality? You try to stop them using your product, that's a huge 
liability! There's a reason even pool noodles have a warning on the side 
that says "WARNING: THIS IS NOT A LIFESAVING DEVICE".

And then, if you think it's worth it, you make a device that is intended 
for the purpose, and sell that.


> Of course we should improve contenteditable APIs so that people who just 
> want basic text editing don't write their own poor replacement. But I 
> don't see why we shouldn't also allow people to build feature-complete 
> alternative text editing controls with features that might never make it 
> into contenteditable - like discontiguous selections, or complex 
> wrapping around objects.

I think you vastly underestimate the complexity of writing a text editing 
control, let alone an accessible one.

People have tried to use canvas for this before, and it usually results in 
them wasting months of time before realising their mistake and backing out 
of it. We can save them that time by making it non-conforming.


> A hit region is one that passes mouse events through to the element in 
> fallback content.
> 
> Instead, this would be a region that simply associates a region in the 
> canvas with an element in fallback content to indicate its accessible 
> bounds, not to propagate events.
>
> Suppose you have some static text in your canvas. Associating the 
> bounding box of that text it with a <p> element containing an accessible 
> version of the same text could be very useful to screen magnifiers - 
> ZoomText, for example, lets you navigate to content that isn't 
> focusable, and it will optionally speak the text, even though it's not 
> intended for totally blind users.

addHitRegion() already supports this, no need for a backing DOM node even:

   c.addHitRegion({
     label: 'Hello World',
   });

Is there any particular reason we'd want to associate the text with a 
specific non-interactive element?


> I think what's needed is a new event - "scrollToMakeVisible". Perhaps 
> whenever an element gets focus, this event could fire on that element, 
> and the default implementation would do what's done now - but an author 
> could choose to preventDefault and implement their own scrolling logic.

That seems reasonable.


> I think AT would like to know the region corresponding to the <table> 
> element too, not just the focusable <td>.

I guess for roles like grid the hierarchy is important, so it does have to 
be in the fallback.

I guess col and colgroup should be exluded from this since they don't have 
corresponding ARIA roles.


> [...] it's not uncommon on the web for objects to do something on hover, 
> even if they're not focusable or clickable. For example, a static image 
> might have a caption that appears on hover, or a static paragraph that's 
> partially truncated might grow to show its full content on hover.
> 
> Allowing hit regions to map to any element would allow for the same type 
> of thing to happen within a canvas. An author might simply want to track 
> what region the mouse cursor is over, *even when that region isn't 
> focusable or clickable*.

Sure. Hit regions support that already. But that's got nothing to do with 
fallback controls.

(Don't forget that hit regions don't _have_ to have a fallback control. 
The fallback control is actually the rare case -- the common case is for 
the canvas just to have text and buttons, and you can make that accessible 
with addHitRegion() without any fallback canvas at all.)


> Now I wonder if it wouldn't be simplest to just allow *any* fallback 
> content element to be the target of a hit region . It would be simpler 
> to spec.

Simpler to spec is the least of our concerns (literally; our concerns are 
first the user, then authors, then implementors, and only then spec 
writers).


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 <select multiple> elements to be hit region controls.
 - enable <select size=N> eements where N>1 to be hit region controls.
 - enable <option> to be hit region controls.
 - optionally, if implementors are on board:
    - make <select size=1> in <canvas> act like size=N where N>1.
    - enable <select size=1> elements to be hit region controls.

Are there any other use cases we should address?

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

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

Received on Thursday, 20 February 2014 18:38:54 UTC