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

Charles McCathie Nevile <chaals@yandex-team.ru> writes:

> On Thu, 20 Feb 2014 22:38:18 +0100, Nils Dagsson Moskopp  
> <nils@dieweltistgarnichtso.net> wrote:
>
>> Dominic Mazzoni <dmazzoni@google.com> 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 <table> 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 <table> 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 <ian@hixie.ch> wrote:
>>>
>>>> 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.
>
> 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 <select> 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 for lazy developers. People do
accept that some problems can not be solved given specific constraints.

>>> 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:
>> <http://daten.dieweltistgarnichtso.net/src/css-pie-chart-form.html>
>>
>> (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.

I might not be scalable, but the code to generate pie chart CSS is:
<http://mistercss.blogspot.de/p/pie-chart-generator.html>
<https://github.com/AliBassam/css-pie>

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.

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

More results from Yandex:

- ~519k answers for “"rm -rf /"”
- ~772k answers for “xml parser regex”
- ~136k answers for “html table "for layout"”
- ~127k answers for “bitcoin javascript mining”

> 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 consider this line of reasoning — “people think X is natural, so I
consider X morally good” — a naturalistic fallacy. Do you disagree?

That said, I really consider it easier to write markup first and then
decorate that using CSS later. It guarantees accessability and prevents
me building poor “solutions” filled to the brim with leaky abstractions.

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

I actually do consider a limited set of widgets a good thing, because it
makes learnable – usable – interfaces possible. On every web page, any
<input type=text> has the same key bindings – I find that useful.

Accessible web development entails caring about limitations – a web site
might be read in bright sunlight on a smartphone with a tiny screen, be
projected onto a wall or read aloud with a fast computer voice. What it
does not entail is explaining bad design away with “people unable to see
low-contrast text are not our target group”.

Incidentally, if I had to herd “front-end developers”, I would give them
five year old laptops and an internet dongle throttled to GRPS speeds.

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

Then we shall provide a technique to make it helpful – like showing them
how to do such things using a standard HTML form styled using CSS or
providing easily included JavaScript libraries for these purposes.

>> May I ask if you have designed
>> human-computer interfaces. If so, may you provide examples?
>
> I'm not sure how that is relevant.

I'd like to see human-computer interfaces developed under the approach
that you advocate, as I might understand your reasoning better through
that. (They do not necessarily have to be yours.)

>>>> > 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.
>>
>> This requests reminds me of customers wanting “page intro in flash.”.
>
> And the response reminds me of http://xkcd.com/1319/

Maybe you misunderstood me. I consider advocating a specific solution
for a poorly-defined problem a sure way to accumulate technical debt.

>>>> 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.
>
> Only if that actually stops people using canvas for this purpose.

We will have to try and see.

>>> 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.
>
> Actually, our role here is to aniticipate what the insulation suppliers of  
> Shenzhen, Minneapolis, Alberta, Yakutsk, and Badaginnie would do, and try  
> to make sure it works out OK.

I really like that analogy. Better not make toxit pipe insulation, then!

> And while we might disagree about what they *should* do, in practice it  
> seems that some developers will use canvas for almost any kind of  
> rendering, probably including things we can't even imagine.

They might stop if <canvas> is known to be the hard way to achieve
something. Look how easy it is for developers to embed videos using
<video> instead of using flash. The success of @font-face lead to
noticeable less headlines provided as images or flash applets.


-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

Received on Friday, 21 February 2014 20:24:00 UTC