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

[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 

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

[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

[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

[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] Outline style to use for drawSystemFocusRing

[Dominic Mazzoni]

On Tue, Jan 7, 2014 at 9:18 PM, Rik Cabanier  wrote:

>
> On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson  wrote:
>
>>
>> > I don't see that as an argument against caching the last known location
>> > of an object too.
>>
>> If you want to store state, that's what addHitRegion() is for. It's the
>> retained mode API for canvas. The draw*FocusRing() methods are direct-mode
>> APIs. There's no expiry logic, there's no API contract that implies that
>> the calls will be made, or made correctly, if the element isn't focused.
>>
>
> I believe this is where part of our confusion/disagreements come from.
> The draw*FocusRing methods are NOT direct-mode APIs for *a11y*.
>
> By calling draw*FocusRing on a fallback element, the a11y software will
> now associate that element (and its aria rules) with the path that was in
> the canvas' state.
> This HAS to be stateful because the a11y software queries the browser for
> the bounds of the fallback element to draw its own focus rectangle.
>

Yes.

A11y APIs on every platform I'm familiar with (Windows, Mac, Linux/ATK,
Android, iOS) are essentially retained-mode. When focus changes, the
application notifies the system and gives it an ID or reference that
identifies the focused object. Assistive technology may query the bounds of
this object immediately, or at any time in the future. If you restart or
load a magnifier while the browser is already running, it will explore the
tree, discover the object that has focus, and zoom the screen and/or draw
its own ring around it at that time.

Re: [whatwg] Outline style to use for drawSystemFocusRing

[Dominic Mazzoni]

On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson  wrote:

> If the user needs a big ring, it seems bad for us not to render one.
>  Especially since we can know this.
>

Yes, there are users who need extra high-contrast focus rings. But no, they
don't get that from an operating system setting that the app queries, I
think that's the source of the confusion.

Try checking the "Make the focus rectangle thicker" checkbox in Windows.
Any time where a single-pixel dotted outline was shown before, you'll now
see a 2-pixel dotted outline. However, in every application I tried, when
previously you saw a custom focus highlight (which is the majority of the
time - the dotted outline looks very dated), there's no change - including
in Windows explorer, Office, IE, Firefox, etc. - I just don't see any
precedent for applications that already provide custom focus highlighting
to do something different when the "Make the focus rectangle thicker"
option is checked.

A number of third-party accessibility tools for Windows draw their own
highlight around the current focused object for users who need it. They
usually draw it in a transparent floating window above the current app - so
it doesn't matter what the app does.

If you want to give the AT position information when there's no visible
> focus ring, that's what addHitRegion() is for.
>

For the record, I like addHitRegion and I'd like to go forward with
implementing it too. Do you consider it ready for implementation? Have any
other browsers expressed interest? The impression I got a while back was
that there were still concerns from some people.

We should probably start a new thread on addHitRegion if there's anything
to discuss, and keep this one focused on drawSystemFocusRing, since that's
the one that it appears three browsers have implemented now. (I'm assuming
IE is implementing it, given that Microsoft has publicly commented on the
spec.)

As a meta-point: when you, as an implementor, disagree with the spec, the
> right way to approach this is to report the problem, describe the use
> cases, and so forth. If you want to implement something different, the way
> to do that is to design a coherent API, and make sure this new API doesn't
> conflict with the specced API, and then implement that new API.
> Implementing something that is "inspired by", and conflicts with, what the
> spec proposal suggests, is not going to lead to a coherent platform,
> because it is is essentially just mixing in multiple people's designs and
> goals without coming up with a coherent single vision.
>
> To clarify, I'm not saying "implement what the spec says". I'm just
> saying, if you don't want to implement what the spec says, please do
> actually design a coherent complete solution. Otherwise we'll end up with
> things like a direct-mode API that acts like a retained-mode API but lacks
> core retained-mode features like expunging expired data.
>

It wasn't my intent to implement something different than the spec. The
spec only talks about the accessibility part of the implementation in a
Note explaining the meaning of "Inform the user", which I didn't think was
normative. I took the language in that note as a guide but ultimately tried
to implement something that actually works. I made a simple demo app to
demonstrate the use of this API, and tested it with three screen magnifiers
while developing it.

If we can come up with another implementation strategy that's more in line
with you intended that actually works, that's great, I'm happy to change
the implementation, it's not too late. Alternatively, I'd be happy to help
draft normative language that more precisely spells out how it needs to be
implemented in order to work in practice.

Re: [whatwg] Outline style to use for drawSystemFocusRing

[Dominic Mazzoni]

On Mon, Jan 6, 2014 at 10:54 PM, Ian Hickson  wrote:

> On Mon, 6 Jan 2014, Dominic Mazzoni wrote:
> >
> > I understand that the addHitRegion APIs are the intended way to specify
> > the permanent location of a fallback content element. But practically
> > speaking, it makes far more sense to "cache" the bounding box of each
> > element when you call draw*FocusRing, otherwise you end up with a timing
> > problem, because as soon as you focus the fallback element, the screen
> > magnifier immediately wants to know its bounding box - but
> > drawSystemFocusRing may not get called until sometime later, when the
> > app decides to repaint - and by then it's already drawn the bounding box
> > in the wrong location. Some magnifiers respond to a "location change"
> > event, but others don't, requiring an ugly hack like sending a second
> > focus event, or delaying the first one.
>
> The paint is going to come within 16ms (unless the app has high latency,
> in which case it'll be unusable anyway). That's when the magnifier should
> be updated, not when the focus moves in the HTML document.
>

We don't currently delay accessibility events until paint. It'd actually be
a lot of extra work to do this and I can't see any benefit outside of this
one corner case.

> The simplest implementation of the current spec to cache the bounding
> > box when you call drawSystemFocusRing and return whenever the assistive
> > technology requests the bounding box of that fallback element, whether
> > it's focused or not. I know it isn't exactly what was intended, and
> > addHitRegion will be a more powerful solution, but I don't see the harm
> > in implementing it this way.
>
> The harm is what I described in the earlier e-mails. You are likely to end
> up zooming on the wrong thing. For example, if the app only renders the
> focused element, and puts it in a random place when it's focused, you'll
> draw the bounding box wherever the control was last time it was rendered,
> which may have nothing to do with where it'll be this time. Similarly, if
> the control is moving, but you only update the bounding box when the
> control is first focused, then you'll leave the magnifier behind.
>

I think that's a good argument that we need to handle the case where the
app updates the focus ring after it's been focused, which I agree with.
There's no reason to assume the app would update the location before the
first paint - it could just as easily begin a transition on the element
once it's focused, so it doesn't reach its 'final' location until 1 second
later. We should handle this case as well as possible.

I don't see that as an argument against caching the last known location of
an object too.

- Dominic

Re: [whatwg] Outline style to use for drawSystemFocusRing

[Dominic Mazzoni]

On Mon, Jan 6, 2014 at 9:43 PM, Ian Hickson  wrote:

> On Mon, 6 Jan 2014, Rik Cabanier wrote:
> > > >
> > > > Yes, the browser backend remembers the update region of the fallback
> > > > content. Otherwise, screen readers would not be able to access it.
> > >
> > > Why would screen readers need to access it?
> >
> > I'm not an expert on the subject, but the way Dominic implemented this,
> > once you call drawSystemFocusRing, you can hover over a region and the
> > a11y software will know the fallback element (and its aria rules).
>
> That's not what draw*FocusRing() are for. If you want that to be possible,
> you should use the addHitRegion API. Using draw*FocusRing() for this
> doesn't work, since there's no way to set the label or role for
> non-controls, and there's no way to remove regions.
>

I understand that the addHitRegion APIs are the intended way to specify the
permanent location of a fallback content element. But practically speaking,
it makes far more sense to "cache" the bounding box of each element when
you call draw*FocusRing, otherwise you end up with a timing problem,
because as soon as you focus the fallback element, the screen magnifier
immediately wants to know its bounding box - but drawSystemFocusRing may
not get called until sometime later, when the app decides to repaint - and
by then it's already drawn the bounding box in the wrong location. Some
magnifiers respond to a "location change" event, but others don't,
requiring an ugly hack like sending a second focus event, or delaying the
first one.

The simplest implementation of the current spec to cache the bounding box
when you call drawSystemFocusRing and return whenever the assistive
technology requests the bounding box of that fallback element, whether it's
focused or not. I know it isn't exactly what was intended, and addHitRegion
will be a more powerful solution, but I don't see the harm in implementing
it this way.

Re: [whatwg] Outline style to use for drawSystemFocusRing

[Dominic Mazzoni]

On Wed, Oct 16, 2013 at 12:46 PM, Ian Hickson  wrote:

> WCAG 2.0 claims that "many platforms allow the user to customize the
> rendering of this focus indicator", though I admit that I don't see any
> references for this claim:
>
>http://www.w3.org/TR/WCAG-TECHS/G165.html
>
> IBM similarly claims "users may customize the default indicator in Windows
> to a brighter color":
>
>http://www-03.ibm.com/able/guidelines/web/webfocusvisible_aa.html#tech3
>
> I haven't been able to support those claims. However, Win32 in particular
> has some APIs for changing focus rings (see below for references).
>

If the user changes the focus ring's color and/or width, then
drawSystemFocusRing should draw using that style.

The issue is when the application wants to draw its own focus ring - should
the system sometimes override that and draw its own focus ring instead?
That's the argument I don't buy.

Respecting the system focus ring color but ignoring the rest of the system
palette makes no sense. Suppose the user has chosen white-on-black text
with a yellow focus ring. The canvas normally draws a black-on-white GUI
with red focus rings that are really easy to see. If the canvas calls
drawCustomFocusRing and the system draws its yellow focus ring instead, it
will actually be worse. So drawing the custom focus ring, in the absence of
the rest of the information about the system palette, is not necessarily an
improvement at all.

I think this feature was proposed with the best of intentions by people who
misinterpreted how Windows system colors and styles work, and didn't think
through all of the implications.

I am totally in favor of trying to provide a better experience for users
who want a high-contrast theme and custom focus rings - I just don't think
this API is the way to achieve that goal, and I think it would actually
make things worse if user agents implemented it as specified.

Perhaps this shouldn't even be solved as part of canvas. Maybe we should
add web apis to indicate that the user prefers a custom color scheme that
could be used for rendering the whole page, not just canvas.

The name isn't ideal, it's true. I don't know what a better name should
> be, though. It's really "let me know if I should draw a focus ring, and if
> I should, then take the opportunity to also notify the accessibility
> tools", which doesn't make for a very pithy method name.
>

What would you call it if it never draws, but just notifies the UI? I think
we could call it notifyFocusRingPath or something like that. Or we go with
the scrollPathIntoView idea.

It's canvas-specific because in the non-canvas state, the browser already
> does this, in theory. The focus in the non-canvas case is drawn by the
> browser using the :focus rules, which, in principle, are set to the user's
> preferred state.
>

In practice this doesn't necessarily work for the same reason I gave above:
the system focus ring might look terrible in particular UIs.

> If we added a canvas fallback element as a parameter to
> > scrollPathIntoView, I don't think we'd need drawCustomFocusRing.
>
> I don't understand how this would work.
>
> Suppose you have a control that is floating around the screen. You need
> the keyboard-focus-driven magnification to follow this control while it's
> focused. You don't want to scroll to that control every time it moves, you
> only want to scroll to it when it's focused.
>
> So what you do is when it's focused, you scrollPathIntoView(), and then
> every 16 milliseconds you move the control and redraw its focus ring, by
> calling drawCustomFocusRing() (or drawSystemFocusRing() if you don't care
> exactly what it looks like), and that updates the AT.
>

Wait, so what's wrong with calling scrollPathIntoView on it every 16
milliseconds, only when it's focused?

drawCustomFocusRing() and drawSystemFocusRing() shouldn't cause anything
> to scroll. That would be very confusing, IMHO. (When would you scroll?
> Consider the case of the control originally being off-screen on purpose,
> and animating into position. You want the focus ring drawn the whole time,
> and the zoom to follow it maybe, but you only want to scroll once, at the
> start, to the location that it will have at the end.)
>

OK, that seems like a reasonable argument. Let's keep scrolling separate.

It would appear that on Win32, the SystemParametersInfo function has
> SPI_GETFOCUSBORDERHEIGHT, SPI_GETFOCUSBORDERWIDTH, and SPI_GETHIGHCONTRAST
> options that may be relevant here.
>

Agreed that those should change the appearance of the focus ring drawn by
drawSystemFocusRing.

I don't think it should override an app that wants to draw its own focus
ring for the reasons given above - if the canvas author doesn't have any
way to query the system foreground and background color, or if the user has
explicitly chosen a color palette specific to this web app, then using the
system focus ring could look much worse.


> > Windows has a system setting for high-contrast mode. When

Re: [whatwg] Outline style to use for drawSystemFocusRing

[Dominic Mazzoni]

>
> if as a web author I call drawCustomFocusRing and it returns false, I'm
>> not supposed to draw anything according to the spec. That's what doesn't
>> make sense to me.
>
>
Why not?
> It means that either the element was not focused or the user selected high
> contrast focus rings.
> The return value of true means that you as an author can draw the focus
> ring in any style.


Yes, I agree that's exactly what the spec says.

What I don't understand is how a browser is supposed to implement the high
contrast focus ring support on a real operating system that exists today.
Are there other apps that do this? Are there published guidelines anywhere?

Windows has a system setting for high-contrast mode. When you turn on high
contrast mode, it changes the default color palette. There's no other
effect on the focus ring that I know of.

Windows also has settings for the focus ring width. I agree those should
affect the system focus ring, but I don't think users would expect that to
override a canvas author's focus ring.

High contrast mode may affect the system focus ring color, it's true - but
there's no reason to believe that this system focus ring would look better
on a canvas when high contrast mode is on, and in fact it might look much
worse.

Third-party accessibility tools that draw focus rings aren't relevant here.
They draw independently of applications; applications like browsers are not
supposed to draw anything different.

Or, here's another argument: a canvas can contain absolutely anything. It
might contain a wild and crazy color palette. Only the canvas author knows
what focus ring is going to be visible on top of that canvas. If the canvas
is white text on a black background, then a dark-colored focus ring is
going to be practically invisible, and vice versa.

It just doesn't make any sense to me that we're providing an API that says,
if you want to draw your own focus ring, use this - BUT, under some
circumstances we're going to tell you not to draw it and the browser or
operating system is going to draw it for you, even though the browser has
no idea what colors are on your canvas and what type of focus ring would be
visible against it.

If the author wants to draw their own focus ring, it's probably for a good
reason. We should let them.

We may also want to give web authors visibility into the system color
palette so they can adjust the entire canvas - and not just focus rings -
for high contrast mode. But that's out of the scope of this discussion.

On Wed, Oct 2, 2013 at 8:20 PM, Rik Cabanier  wrote:

> I just tried this with canary and your demo file, and it is not scrolling
> to the focus ring. Is this what you are asking for?
>

Yes.


> If so, I agree that we should update the spec. There is not much point
> that you can tab into fallback content but the browser doesn't scroll to
> the path.
>

Agreed.

Re: [whatwg] Outline style to use for drawSystemFocusRing

[Dominic Mazzoni]

On Mon, Sep 30, 2013 at 5:42 PM, Rik Cabanier  wrote:

> Where does it say in the spec that if you have assistive technology
> enabled, focus rings should not be drawn?
>

if as a web author I call drawCustomFocusRing and it returns false, I'm not
supposed to draw anything according to the spec. That's what doesn't make
sense to me.

It would take an element in fallback content as an argument. That would
>> allow assistive technology to be notified.
>>
>
> As Ian pointed out, the accessibility software could do that.
>

scrollPathIntoView can't be used to notify accessibility software of the
focused object location as-is because it doesn't have an element to fire
on, and it doesn't know if the scrolling is because of focus or not.

If we added a canvas fallback element as a parameter to scrollPathIntoView,
I don't think we'd need drawCustomFocusRing.

Re: [whatwg] Outline style to use for drawSystemFocusRing

[Dominic Mazzoni]

On Mon, Sep 30, 2013 at 4:12 PM, Ian Hickson  wrote:
>
> Some users have great trouble seeing the default focus rings.
> ...
> It's certainly true that if we don't want to support users with poor
> vision, the API would be simpler. But I don't think that's an option. We
> don't get to arbitrarily ignore some users.


Of course not! I'm not arguing against supporting those users. The correct
thing to do for those users is to use accessibility APIs to make the
operating system aware of the focused object and its bounds. If users have
ZoomText or MAGic installed, or if they're using VoiceOver or Orca, their
assistive technology will draw its own focus ring *in addition* to the
application's focus ring.

No other application hides its focus ring just because, e.g., ZoomText is
drawing a focus ring. The rest of the web doesn't do it. Why do we need it
for canvas?

On Mon, 30 Sep 2013, Dominic Mazzoni wrote:
> >
> > I don't think that drawCustomFocusRing should switch to the system focus
> > rectangle style just because that preference was set - it might look
> > horrible on a particular canvas.
>
> It's the whole point of the feature. Draw the focus ring the way the user
> needs it to be drawn, if there's a special need, otherwise, let me draw it
> my fancy hard-to-see way.
>

The problem is that there aren't existing operating system or browser
settings that specifies that the user wants better focus rings. There are
tools that draw additional focus rings, and preferences that control the
appearance of the default focus ring, but no toggle that says
*applications* should or shouldn't draw focus rings.

Finally, as a meta-argument, if we really want a preference for custom
focus rings, then wouldn't we want that for the rest of the web? If I'm
building a custom form control and I need to choose a drawing style when
focused, wouldn't I want to know if the user wanted custom focus rings,
too? In other words, what makes this need canvas-specific?


> How would this differ from scrollPathIntoView() ?


It would take an element in fallback content as an argument. That would
allow assistive technology to be notified.

- Dominic

Re: [whatwg] Outline style to use for drawSystemFocusRing

[Dominic Mazzoni]

On Mon, Sep 30, 2013 at 3:21 PM, Rik Cabanier  wrote:

> I just checked Windows and they offer the option "Make the focus rectangle
> thicker". I checked IE and it honors that setting.
> It's too bad that we didn't get feedback from them but it does look like
> this is something IE would implement.
>

Yes, and drawSystemFocusRing should respect the thicker focus rectangle.

I don't think that drawCustomFocusRing should switch to the system focus
rectangle style just because that preference was set - it might look
horrible on a particular canvas. Plus, Rich's original argument wasn't
about the "make the focus rectangle thicker", it was about handling Windows
high contrast mode correctly - but again, I still don't think that the
system is going to do a better job at drawing a focus ring on a canvas just
because high contrast mode is on. What we really need is an API for web
developers to know if high contrast mode is on, and that's orthogonal to
canvas.

Here's my alternative idea, though: how about calling it something like
>> scrollFocusedObjectIntoView, and have the *primary* purpose of the API be
>> to make the browser scroll the viewport, if needed to make sure that the
>> bounding box of the path is visible, if that object is focused. The
>> drawFocusRing spec would be modified to specify that scrolling the viewport
>> is part of the spec, too.
>>
>
> That sounds very much like 'scrollPathIntoView'.
> I think that this is changing the API too much.
>

I still don't understand why we're in a situation where we can't change it
too much. If the choice is ship drawCustomFocusRing with flaws or delay it
until the next revision so we can get it right, my vote is firmly for the
latter. I do not support shipping it as-is.

- Dominic

Re: [whatwg] Outline style to use for drawSystemFocusRing

[Dominic Mazzoni]

On Mon, Sep 30, 2013 at 1:25 PM, Rik Cabanier  wrote:

> Ian pointed out on IRC that 'drawCustomFocusRing' *could* draw if the
> user requested high contrast rings. (Since I prototyped it in Firefox which
> does not have this feature, I forgot about that case)
>

Yes, but I'm arguing that the high contrast rings is not a good idea and we
should drop that part of the spec. Once that part is gone (or once no
browser has plans to implement that part), drawCustomFocusRing no longer
makes sense.


> In light of that, maybe it's OK to leave the spec as-is. '
> notifyFocusLocation' is just as confusing...
>

I don't think notifyFocusLocation is just as confusing as having a
drawCustomFocusRing
API that never actually draws. I do agree that most web developers might
not realize who is being notified and why, but they can at least surmise
that *someone* cares about the focus location and wants to be told where it
is.

Here's my alternative idea, though: how about calling it something like
scrollFocusedObjectIntoView, and have the *primary* purpose of the API be
to make the browser scroll the viewport, if needed to make sure that the
bounding box of the path is visible, if that object is focused. The
drawFocusRing spec would be modified to specify that scrolling the viewport
is part of the spec, too.

Both APIs would also have accessibility implications, of course - but the
average web developer who doesn't know much about accessibility would have
two useful APIs for handling focused controls in a canvas, that are easy to
test if they're working in any browser.

- Dominic


>
>
>
> On Mon, Sep 30, 2013 at 10:15 AM, Rik Cabanier  wrote:
>
>>
>>
>>
>> On Thu, Sep 12, 2013 at 9:32 AM, Dominic Mazzoni wrote:
>>
>>> On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson  wrote:
>>>
>>> > On Tue, 10 Sep 2013, Dominic Mazzoni wrote:
>>> > >
>>> > > We've finished implementing drawSystemFocusRing and
>>> drawCustomFocusRing
>>> > > in Chrome. Try it in Chrome 31 or higher (either canary or dev
>>> channel
>>> > > should work today). You'll need to go to chrome://flags and enable
>>> > > *experimental canvas features*, then restart the browser.
>>> > >
>>> > > Here's a demo I built that uses drawSystemFocusRing:
>>> > > http://dmazzoni-google.github.io/canvas-focus-ring-demo/
>>> >
>>> > Looks good. Was your conclusion that the spec was ok as is, or did you
>>> > deviate from the spec in some way that needs a spec change
>>> >
>>>
>>> I think drawSystemFocusRing is good to go. If you want, you can update
>>> the
>>> spec to reflect that an implementation is available (behind a flag).
>>>
>>> Only one minor issue for clarification: if the current path is a line or
>>> unclosed polygon, should it be closed (or otherwise outlined) when
>>> drawing
>>> the focus ring? Currently we're not doing so in Chrome, but it might help
>>> to clarify. For example, if the path is a line, what's drawn is just an
>>> additional stroke on that line, not a "ring".
>>>
>>> I'm not as sure about drawCustomFocusRing. The spec says "If the user has
>>> requested the use of particular focus rings", but I'm not aware of any
>>> platform API we could use to query that. To the best of my knowledge,
>>> assistive technology that draws its own focus rings, like ZoomText,
>>> normally draws an additional focus ring with extra padding, rather than
>>> replacing the system one. (Example:
>>> http://www.aisquared.com/zoomtext/tour/enhancements#focus_enhancements)
>>>
>>> So, I'm not sure how I'd implement that part of the spec. Chrome
>>> definitely
>>> has no plans to give users an additional preference for focus rings as a
>>> browser setting.
>>>
>>> So, what we implemented in Chrome for drawCustomFocusRing is basically
>>> just
>>> a function that notifies assistive technology of the bounding rect of the
>>> focused region within the canvas. It's still useful, but if that's all it
>>> does, then drawCustomFocusRing is a poor name. Perhaps it should be
>>> called
>>> something like notifyFocusLocation or something like that.
>>>
>>
>>  'drawCustomFocusRing' returns a boolean that signals the author that he
>> is supposed to draw the focus ring.
>>  If you want to rename it, then maybe 'needsFocusRing' is better.
>>
>> 'drawSystemFocusRing' could then be simplified to 'drawFocusRing'
>>
>
>

Re: [whatwg] Outline style to use for drawSystemFocusRing

[Dominic Mazzoni]

On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson  wrote:

> On Tue, 10 Sep 2013, Dominic Mazzoni wrote:
> >
> > We've finished implementing drawSystemFocusRing and drawCustomFocusRing
> > in Chrome. Try it in Chrome 31 or higher (either canary or dev channel
> > should work today). You'll need to go to chrome://flags and enable
> > *experimental canvas features*, then restart the browser.
> >
> > Here's a demo I built that uses drawSystemFocusRing:
> > http://dmazzoni-google.github.io/canvas-focus-ring-demo/
>
> Looks good. Was your conclusion that the spec was ok as is, or did you
> deviate from the spec in some way that needs a spec change
>

I think drawSystemFocusRing is good to go. If you want, you can update the
spec to reflect that an implementation is available (behind a flag).

Only one minor issue for clarification: if the current path is a line or
unclosed polygon, should it be closed (or otherwise outlined) when drawing
the focus ring? Currently we're not doing so in Chrome, but it might help
to clarify. For example, if the path is a line, what's drawn is just an
additional stroke on that line, not a "ring".

I'm not as sure about drawCustomFocusRing. The spec says "If the user has
requested the use of particular focus rings", but I'm not aware of any
platform API we could use to query that. To the best of my knowledge,
assistive technology that draws its own focus rings, like ZoomText,
normally draws an additional focus ring with extra padding, rather than
replacing the system one. (Example:
http://www.aisquared.com/zoomtext/tour/enhancements#focus_enhancements)

So, I'm not sure how I'd implement that part of the spec. Chrome definitely
has no plans to give users an additional preference for focus rings as a
browser setting.

So, what we implemented in Chrome for drawCustomFocusRing is basically just
a function that notifies assistive technology of the bounding rect of the
focused region within the canvas. It's still useful, but if that's all it
does, then drawCustomFocusRing is a poor name. Perhaps it should be called
something like notifyFocusLocation or something like that.

- Dominic

Re: [whatwg] Outline style to use for drawSystemFocusRing

[Dominic Mazzoni]

We've finished implementing drawSystemFocusRing and drawCustomFocusRing in
Chrome. Try it in Chrome 31 or higher (either canary or dev channel should
work today). You'll need to go to chrome://flags and enable *experimental
canvas features*, then restart the browser.

Here's a demo I built that uses drawSystemFocusRing:
http://dmazzoni-google.github.io/canvas-focus-ring-demo/

- Dominic

Re: [whatwg] Outline style to use for drawSystemFocusRing

[Dominic Mazzoni]

On Mon, Jul 29, 2013 at 7:51 PM, Rik Cabanier  wrote:

> Why not the style of the element? If the child element has a class of
> 'button' and the CSS has
>
> button:focus {
>
> color:red;
>
> }
>
> Shouldn't the focus be in red?
>

While I also think there should probably be some way to override at least
the color of the focus ring in order to match the rest of the UI, I also
think that at this stage it might make more sense to just get this out in
front of developers (behind a flag) and see what happens with some
real-world apps.

I know at least 3 developers who are interested in trying it out with their
apps.

- Dominic

Re: [whatwg] Outline style to use for drawSystemFocusRing

[Dominic Mazzoni]

On Fri, Jul 26, 2013 at 11:13 AM, Ian Hickson  wrote:

> Well we can't use the CSS styles, because you might not have an element
> (e.g. if you're drawing in a worker).


I'm not quite sure what you mean - doesn't drawSystemFocusRing require
an element as a parameter (so that it only draws if the element has focus)?

Also, while what you describe is true for Chrome, it doesn't appear to be
> uniformly true. For example, in Firefox, the focus outline of an 
> doesn't seem to have any relation to its CSS 'outline', since you can have
> both at once.


OK, that's a good argument to not get the focus style from the outline.

But before we do that, we should probably figure out how much demand there
> is for this. If people are happier to just draw their own rings entirely,
> then we probably don't need to bother providing this at all.
>

Fair enough. I'll implement drawSystemFocusRing with the default style and
we can
start getting feedback from web developers.

Thanks,
- Dominic

Re: [whatwg] Outline style to use for drawSystemFocusRing

[Dominic Mazzoni]

On Wed, Jul 24, 2013 at 4:14 PM, Ian Hickson  wrote:

> The idea is it's supposed to be the system style (hence the name of the
> method, draw _system_ focus ring), and that if the authors wants a special
> style, they use drawCustomFocusRing() and if it returns true they draw it
> themselves (using strokeStyle and stroke(), or whatever).
>

Every html element already gets a system focus ring by default if you add
tabindex=0 and focus it - however, you can use CSS to change just one
property - like just the color, or just the outline width - while
inheriting everything else from the system style (border radius, line
style, etc). Why not allow for the same flexibility in canvas?

If you want the system focus ring, that's what you get by default when you
call drawSystemFocusRing. If you want to draw something totally unique, use
drawCustomFocusRing. However, you could also have the option of overriding
part of the system focus ring style using the element's outline style.

If that still sounds ridiculous, I'll drop this idea. Thanks.

- Dominic

[whatwg] Outline style to use for drawSystemFocusRing

[Dominic Mazzoni]

I'm looking into implementing
drawSystemFocusRingin
Blink, but it's unclear what style to use when drawing the focus ring
-
i.e. the color, thickness, etc., assuming that the user hasn't overridden
it for accessibility. Here are some possible interpretations:

1. Hard-code default values. I don't think this would be ideal, since it
wouldn't necessarily match the focus color of other elements that get the
focus color from the system.
2. Get them from the default style of a generic element (which may match
the system focus style). This could work, but I think this is less flexible
for developers - if they picked a custom outline color for every other
element in their site but would have no way to override it for canvas
(other than using drawCustomFocusRing).
3. Get them from the outline style of the canvas element. This means every
focus ring within the canvas would be the same, but otherwise I have no
objection.
4. Get them from the outline style ofelement passed to drawSystemFocusRing.
This is my preference.

- Dominic