Re: [whatwg] Outline style to use for drawSystemFocusRing
On Tue, 7 Jan 2014, Dominic Mazzoni wrote: On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson i...@hixie.ch 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. Why isn't this just a widespread accessibility bug? 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? Yeah, I'm not aware of any outstanding work for it right now. Have any other browsers expressed interest? I do not recall specific comments from browser vendors one way or the other. The impression I got a while back was that there were still concerns from some people. I'm not aware of any outstanding concerns. 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.) The reason I think it's relevant is that if what people want drawSystemFocusRing() to do is in fact what addHitRegion() does, then we should not do both. 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. I apologise that the spec was misleading in its note. I've tried to update the spec to remove this confusion (and made the new paragraph normative.) I think in practice it may be that for accessibility the right thing is for authors to use addHitRegion(), and the focus ring drawing APIs should only draw the focus ring and do nothing else. On Tue, 7 Jan 2014, Rik Cabanier wrote: On Tue, Jan 7, 2014 at 9:45 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 7 Jan 2014, Rik Cabanier wrote: I believe this is where part of our confusion/disagreements come from. The draw*FocusRing methods are NOT direct-mode APIs for *a11y*. Right. They're not really APIs for accessibility at all. They're about drawing focus rings. No. The only reason for this API is accessibility. That was not the primary intent of the APIs. (Accessibility, like security, performance, or internationalisation, is almost never the primary intent of a well-designed API, since accessibility, like security, performance, and internationalisation, are concerns that permeate _every_ API and well-designed APIs make them non-issues.) An author could just check the focused state and draw the ring himself; there's no need for an API to do this. There's no way to draw a focus ring that has the appearance of the platform's focus rings without an API for it. 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 is non-conforming behaviour that is incompatible with the API design. Doing this will cause harm, because the API is incapable, as designed, of being used in this manner correctly without causing bugs. For example, if, when an element is not focused, it's split into four parts, there's no way to draw a single focus ring around it. Thus the data about that control's position _will be incorrect_ if the UA relies on this method for this data. I don't understand. The path for the focus ring can be anything, including multiple closed paths. The data for the a11y software won't be wrong, it will be the boundingbox of those paths. Right. If the intent, however, is for one part of the element to be magnified, and the other parts to just be decorative, then this would result in the
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Tue, Jan 7, 2014 at 11:12 PM, Dominic Mazzoni dmazz...@google.comwrote: On Tue, Jan 7, 2014 at 9:18 PM, Rik Cabanier caban...@gmail.com wrote: On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson i...@hixie.ch 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. agreed. Note that the draw*FocusRing functions don't update the a11y of the canvas. Instead, they update the fallback element's region. This element is part of the HTML DOM and as such, is retained.
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Wed, 16 Oct 2013, Dominic Mazzoni wrote: On Wed, Oct 16, 2013 at 12:46 PM, Ian Hickson i...@hixie.ch 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. Right. As far as I can tell, it's not generally the precise colour that a user picks. It's the dimension, and the rendering mode (high contrast vs normal). 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. If the user needs a big ring, it seems bad for us not to render one. Especially since we can know this. Respecting the system focus ring color but ignoring the rest of the system palette makes no sense. A single solid-colour focus ring does have that problem, yes. This is the case even without canvas; if you change your page colour scheme and don't override the focus outline colours, and the operating system's default focus rings are solid colour, then you can have this problem. The solution is for the focus rings not to be a solid colour. Mac OS, for example, makes them a gradient. Some vesions of Windows draw the focus ring using xor (I haven't checked modern Windows behaviour). Mouse cursors are commonly drawn using two levels of outlines to avoid the equivalent problem with mouse cursors. A high contrast focus ring should be visible regardless of the background. 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. I don't understand why it would make things worse, but I'm certainly open to better suggestions. What's a better way to get authors who don't care about accessibility to honour high-contrast focus ring preferences? 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. Most authors will just ignore this. That's why we have user style sheets that can override author sheets, for example. 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? At that point, it would just be the addHitRegion() API, with a check for whether the control is focused. Not much point having that as a single rolled-up API, IMHO. 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. The point isn't for it to be aesthetically pleasing, the point is for it to be more obviously visible to the user. 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? It would prevent the user from scrolling the page, which seems like a pretty serious problem. drawCustomFocusRing() and drawSystemFocusRing() shouldn't cause anything to scroll. That would be very confusing, IMHO. (When would you
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson i...@hixie.ch 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. For the blink and firefox implementations (and the webkit patch) informing the user [1] means telling the DOM about the region of the fallback element so the a11y software can query it later. Because of this, there also needs to be a way to disassociate the region from the fallback element (ie by having no current path when you call draw*FocusRing) 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. I completely agree. I *think* I'm on the same page as Rich and Dominic but we're all a bit fuzzy on the details/edge cases. 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#inform
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Tue, 7 Jan 2014, Rik Cabanier wrote: On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson i...@hixie.ch 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*. Right. They're not really APIs for accessibility at all. They're about drawing focus rings. 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 is non-conforming behaviour that is incompatible with the API design. Doing this will cause harm, because the API is incapable, as designed, of being used in this manner correctly without causing bugs. For example, if, when an element is not focused, it's split into four parts, there's no way to draw a single focus ring around it. Thus the data about that control's position _will be incorrect_ if the UA relies on this method for this data. This is why addHitRegion() exists; it provides this data in a usable manner. 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. The paths provided by the draw*FocusRing() methods aren't useful for this purpose. Using them for this purpose is bogus. The paths provided to those methods are only useful for direct-mode painting and direct-mode notification to an AT API if such an API accepts direct-mode notifications. If it doesn't, then the addHitRegion() API is what should be used to send the notifications. For the blink and firefox implementations (and the webkit patch) informing the user [1] means telling the DOM about the region of the fallback element so the a11y software can query it later. That's not conformant, and will lead to accessibility problems. Informing the user is an imperative action, not an indirect action involving caching state over multiple frames. Because of this, there also needs to be a way to disassociate the region from the fallback element (ie by having no current path when you call draw*FocusRing) Yes, if draw*FocusRing() were the API you describe, we would need such a thing. The API you describe, however, is not draw*FocusRing(), it's addHitRegion(), and it already has such a thing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson i...@hixie.ch 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
On Tue, Jan 7, 2014 at 9:45 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 7 Jan 2014, Rik Cabanier wrote: On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson i...@hixie.ch 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*. Right. They're not really APIs for accessibility at all. They're about drawing focus rings. No. The only reason for this API is accessibility. An author could just check the focused state and draw the ring himself; there's no need for an API to do this. 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 is non-conforming behaviour that is incompatible with the API design. Doing this will cause harm, because the API is incapable, as designed, of being used in this manner correctly without causing bugs. For example, if, when an element is not focused, it's split into four parts, there's no way to draw a single focus ring around it. Thus the data about that control's position _will be incorrect_ if the UA relies on this method for this data. I don't understand. The path for the focus ring can be anything, including multiple closed paths. The data for the a11y software won't be wrong, it will be the boundingbox of those paths. This is why addHitRegion() exists; it provides this data in a usable manner. 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. The paths provided by the draw*FocusRing() methods aren't useful for this purpose. Using them for this purpose is bogus. The paths provided to those methods are only useful for direct-mode painting and direct-mode notification to an AT API if such an API accepts direct-mode notifications. If it doesn't, then the addHitRegion() API is what should be used to send the notifications. No, the AT API is not direct mode. For the blink and firefox implementations (and the webkit patch) informing the user [1] means telling the DOM about the region of the fallback element so the a11y software can query it later. That's not conformant, and will lead to accessibility problems. Informing the user is an imperative action, not an indirect action involving caching state over multiple frames. If that is the case, we should drop focus ring support. There's no point to just draw rings. Because of this, there also needs to be a way to disassociate the region from the fallback element (ie by having no current path when you call draw*FocusRing) Yes, if draw*FocusRing() were the API you describe, we would need such a thing. The API you describe, however, is not draw*FocusRing(), it's addHitRegion(), and it already has such a thing. addHitRegion is a much bigger implementation burden for authors and browser vendors. My fear is that given their complexity, authors will not provide a11y support.
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Tue, Jan 7, 2014 at 9:18 PM, Rik Cabanier caban...@gmail.com wrote: On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson i...@hixie.ch 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
On Wed, Oct 16, 2013 at 12:46 PM, Ian Hickson i...@hixie.ch wrote: ... On Wed, 2 Oct 2013, Rik Cabanier wrote: I don't understand. If the path that is active during drawCustom/SystemFocusRing is off screen and the element is focused, the browser will scroll to that area. 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.) I think you misunderstood. The drawCustomFocusRing() and drawSystemFocusRing() don't cause scrolling, it's when you focus the fallback element that the browser should scroll. This does mean that the spec should be updated. Right now, step 1 [1] states that if the element is not focused, drawSystemFocusRing will abort. Instead, the browser should update the region of the fallback content and then continue with step 1. With some pseudo code: a. call drawSystemFocusRing ctx.moveto(...); ctx.lineTo(...); // draw the region of the path ctx.drawSystemFocusRing(hiddenElement); // element is not focused but update the region of hiddenElement b. focus the element (either by tabbing or hiddenElement.focus()) - browser should scroll so the focus ring is visible on screen. I was told the current implementation in Blink already does this. The Firefox implementation currently does not; however, once an element was focused, the browser knows about the region of the fallback content and will do the scrolling. (Webkit would do so as well, but that patch didn't land over objections from Ryosuke) 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-drawsystemfocusring
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, 6 Jan 2014, Rik Cabanier wrote: I think you misunderstood. The drawCustomFocusRing() and drawSystemFocusRing() don't cause scrolling, it's when you focus the fallback element that the browser should scroll. Doing this would imply remembering where the control was the last time the focusing ring was rendered, which would cause all kinds of problems for authors. Since the last time the control was rendered, maybe the rendering stopped showing the control, or maybe when it was last rendered, the control was rendered just off-screen on purpose so that it could be animated onto the center of the screen when focused... we simply can't know what the author is doing. This is why there's a separate dedicated API for scrolling. If the author thinks that the user will want to scroll to the control when the control is focused, then it's trivial to do. But we should not force this behaviour. That's terrible API design. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, Jan 6, 2014 at 9:16 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 6 Jan 2014, Rik Cabanier wrote: On Mon, Jan 6, 2014 at 8:41 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 6 Jan 2014, Rik Cabanier wrote: I think you misunderstood. The drawCustomFocusRing() and drawSystemFocusRing() don't cause scrolling, it's when you focus the fallback element that the browser should scroll. Doing this would imply remembering where the control was the last time the focusing ring was rendered, 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). (For my own debugging purposes, once the regions are known, you can use firefox's web inspector and see the focus areas when you hover over the fallback content. This information is likely available to web authors as well which could be nice to have.) which would cause all kinds of problems for authors. Since the last time the control was rendered, maybe the rendering stopped showing the control, or maybe when it was last rendered, the control was rendered just off-screen on purpose so that it could be animated onto the center of the screen when focused... we simply can't know what the author is doing. I'm not sure I understand the problem. If the author moves the control somewhere else on the canvas, he's supposed to call drawFocusRing again which will update the region. If the control is anywhere on the canvas. It might not be. If it isn't on the canvas anymore, what you propose would randomly scroll to where it was last seen. That would only happen if the author didn't call drawFocusRing again (which he is supposed to do to update the region of the fallback content) But even if the control _is_ on the canvas, that's no guarantee that the location it's at is where the author wants to scroll to, as described in the examples above. There are (as described above) simple legitimate cases where scrolling to the focus position when the control is first focused is unambiguously the _wrong_ thing to do. A more elaborate one which I've described before would be where all the controls are initially just off-screen, visible just on the edge, but when focused, the control moves to the center of the screen. No scrolling should ever happen, because the author's script is taking care of making the controls visible. But all the controls, when initially focused, would have their focus ring first drawn on the edge of the canvas, and if we scrolled there, it would be very jarring and would be terrible UI. Forcing such behaviour on the author is bad API design. But once again, it would be consistent. If you were to do this in HTML, the window would scroll to the initial location of the control. I'm unsure what happens when you manually move a focused element offscreen. Is the browser supposed to scroll so it stays visible? If so, maybe drawSystemFocusRing should scroll as well. If an author didn't want this behavior, he could locate the controls off-canvas which would disable the focus ring (or not draw the control at all and not call drawSystemFocusRing). Then when the fallback content gets the focus, he can animate the control in place and call scrollPathIntoView once the animation is done. This is why there's a separate dedicated API for scrolling. If the author thinks that the user will want to scroll to the control when the control is focused, then it's trivial to do. But we should not force this behaviour. That's terrible API design. Every other control in HTML that gets the focus will cause scrolling. Sure. Every other control in HTML also has built-in focus ring rendering, built-in control rendering, built-in hit testing, etc. But we're not talking about built-in controls, we're talking about canvas, where the whole point is that the author is building the control from scratch. It's terrible design that this would act differently. It would certainly be bad UI, sure. But we're not designing the UI here. We're designing the API with which the author is going to implement the UI that _they_ have designed. Drawing a ring but not scrolling feels very unnatural. I agree, but it's not our place to make this call for the author. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, Jan 6, 2014 at 9:43 PM, Ian Hickson i...@hixie.ch 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
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. 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, Jan 6, 2014 at 10:54 PM, Ian Hickson i...@hixie.ch 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
Thanks for taking this to the group! Dominic's patch for Chrome is almost identical to the one I provided for WebKit, including the synchronous drawing of the ring. see: https://codereview.chromium.org/19786002/ The accessibility backed of chrome doesn't scroll like the one in WebKit and FireFox which is why we're seeing a difference in behavior. On Thu, Oct 17, 2013 at 9:55 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 16, 2013, at 1:36 PM, Dominic Mazzoni dmazz...@google.com wrote: On Wed, Oct 16, 2013 at 12:46 PM, Ian Hickson i...@hixie.ch 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. or something like defineFocusableRegion/defineFocusableArea. I'd much refer names that signify the fact these functions define focusable area/region than the fact it may draw the focus ring if the element is already focused since authors need to call this function on all focusable elements that are currently visible on the canvas. If we were to implement this API in WebKit, I don't think we'll draw the focus ring synchronously either (i.e. our implementation will be similar to what Dominic said Chrome does). - R. Niwa
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Oct 16, 2013, at 1:36 PM, Dominic Mazzoni dmazz...@google.com wrote: On Wed, Oct 16, 2013 at 12:46 PM, Ian Hickson i...@hixie.ch 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. or something like defineFocusableRegion/defineFocusableArea. I'd much refer names that signify the fact these functions define focusable area/region than the fact it may draw the focus ring if the element is already focused since authors need to call this function on all focusable elements that are currently visible on the canvas. If we were to implement this API in WebKit, I don't think we'll draw the focus ring synchronously either (i.e. our implementation will be similar to what Dominic said Chrome does). - R. Niwa
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Thu, Oct 17, 2013 at 9:55 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 16, 2013, at 1:36 PM, Dominic Mazzoni dmazz...@google.com wrote: On Wed, Oct 16, 2013 at 12:46 PM, Ian Hickson i...@hixie.ch 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. or something like defineFocusableRegion/defineFocusableArea. I'd much refer names that signify the fact these functions define focusable area/region than the fact it may draw the focus ring if the element is already focused since authors need to call this function on all focusable elements that are currently visible on the canvas. If we were to implement this API in WebKit, I don't think we'll draw the focus ring synchronously either (i.e. our implementation will be similar to what Dominic said Chrome does). Dominic's implementation draws the focus ring synchronously.
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Thu, 12 Sep 2013, Dominic Mazzoni wrote: On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson i...@hixie.ch 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). Anyone can update the spec's annotations, actually -- just alt+double-click on the annotation box or the relevant part of the spec, and it'll bring up an editor. (You may have to log in first; see the UI at the very top right of the spec.) 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. Done. 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. It may be that on some platforms there is no such API. 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). 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. 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. On Mon, 30 Sep 2013, Dominic Mazzoni wrote: 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? If it's the case that the OS ring can't be customised, and that what people refer to when they talk about customised rings is having the ring drawn again by ATs, then you're right -- drawCustomFocusRing() would never draw anything. However, it's not clear to me that that is the case. The problem is that there aren't existing operating system or browser settings that specifies that the user wants better focus rings. Are we sure? That isn't clear to me. If it was true, why would WCAG 2.0 say that authors shouldn't fiddle with the focus ring style, for example? 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? 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. On Mon, 30 Sep 2013, Dominic Mazzoni wrote: 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
On Wed, Oct 16, 2013 at 12:46 PM, Ian Hickson i...@hixie.ch 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 you turn on high contrast mode, it
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Wed, Oct 16, 2013 at 12:46 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 12 Sep 2013, Dominic Mazzoni wrote: On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson i...@hixie.ch 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). Anyone can update the spec's annotations, actually -- just alt+double-click on the annotation box or the relevant part of the spec, and it'll bring up an editor. (You may have to log in first; see the UI at the very top right of the spec.) 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. Done. 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. It may be that on some platforms there is no such API. 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). 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. 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. On Mon, 30 Sep 2013, Dominic Mazzoni wrote: 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? If it's the case that the OS ring can't be customised, and that what people refer to when they talk about customised rings is having the ring drawn again by ATs, then you're right -- drawCustomFocusRing() would never draw anything. However, it's not clear to me that that is the case. The problem is that there aren't existing operating system or browser settings that specifies that the user wants better focus rings. Are we sure? That isn't clear to me. If it was true, why would WCAG 2.0 say that authors shouldn't fiddle with the focus ring style, for example? 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? 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. On Mon, 30 Sep 2013, Dominic Mazzoni wrote: 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
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Fri, Oct 4, 2013 at 1:56 AM, Dominic Mazzoni dmazz...@google.com wrote: 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? Well, I assume that there was a good reason that this was added to the spec. It's too bad that Rich is on vacation since he is most familiar with this. 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. It is possible that this is designed for an in-house application that uses the canvas APIs. It doesn't have to be a browser. 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. A focus ring could use blending modes or other graphical features that would ensure that it's always visible. 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. No, since the author doesn't know that special focus rings are required, it's reasonable to let the UA handle that case. 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. Yes On Wed, Oct 2, 2013 at 8:20 PM, Rik Cabanier caban...@gmail.com 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. Great. This means that the steps from 'scrollPathIntoView' [1] should go into the focus ring steps too. 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-scrollpathintoview
Re: [whatwg] Outline style to use for drawSystemFocusRing
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 caban...@gmail.com 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, it would be great if we could resolve this soon since I'm trying to land this in mozilla and webkit. I think the spec is good as-is, and Rich and Hixie (right?) believe so as well. On Mon, Sep 30, 2013 at 11:48 PM, Dominic Mazzoni dmazz...@google.comwrote: On Mon, Sep 30, 2013 at 5:42 PM, Rik Cabanier caban...@gmail.com 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
Sorry for some reason this message didn't make it to my inbox On Mon, Sep 30, 2013 at 11:48 PM, Dominic Mazzoni dmazz...@google.comwrote: On Mon, Sep 30, 2013 at 5:42 PM, Rik Cabanier caban...@gmail.com 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. 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. 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. I don't understand. If the path that is active during drawCustom/SystemFocusRing is off screen and the element is focused, the browser will scroll to that area.
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Wed, Oct 2, 2013 at 7:42 PM, Rik Cabanier caban...@gmail.com wrote: Sorry for some reason this message didn't make it to my inbox On Mon, Sep 30, 2013 at 11:48 PM, Dominic Mazzoni dmazz...@google.comwrote: On Mon, Sep 30, 2013 at 5:42 PM, Rik Cabanier caban...@gmail.com 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. 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. 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. I don't understand. If the path that is active during drawCustom/SystemFocusRing is off screen and the element is focused, the browser will scroll to that area. 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? 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.
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, Sep 30, 2013 at 5:42 PM, Rik Cabanier caban...@gmail.com 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
On Thu, Sep 12, 2013 at 9:32 AM, Dominic Mazzoni dmazz...@google.comwrote: On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson i...@hixie.ch 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
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) In light of that, maybe it's OK to leave the spec as-is. ' notifyFocusLocation' is just as confusing... On Mon, Sep 30, 2013 at 10:15 AM, Rik Cabanier caban...@gmail.com wrote: On Thu, Sep 12, 2013 at 9:32 AM, Dominic Mazzoni dmazz...@google.comwrote: On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson i...@hixie.ch 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
On Mon, Sep 30, 2013 at 1:25 PM, Rik Cabanier caban...@gmail.com 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 caban...@gmail.com wrote: On Thu, Sep 12, 2013 at 9:32 AM, Dominic Mazzoni dmazz...@google.comwrote: On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson i...@hixie.ch 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
On Mon, Sep 30, 2013 at 1:48 PM, Dominic Mazzoni dmazz...@google.comwrote: On Mon, Sep 30, 2013 at 1:25 PM, Rik Cabanier caban...@gmail.com 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. 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. 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. But it's not a 'notify' action though. You're basically asking the browser if the author should draw the focus area (while also telling the browser about the region) 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. 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 caban...@gmail.comwrote: On Thu, Sep 12, 2013 at 9:32 AM, Dominic Mazzoni dmazz...@google.comwrote: On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson i...@hixie.ch 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
On Mon, Sep 30, 2013 at 3:21 PM, Rik Cabanier caban...@gmail.com 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
On Mon, 30 Sep 2013, Rik Cabanier wrote: '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' On Mon, 30 Sep 2013, 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) In light of that, maybe it's OK to leave the spec as-is. ' notifyFocusLocation' is just as confusing... Yeah... The current name isn't great, but I don't know what would be better (without making its name an essay or something). On Mon, 30 Sep 2013, Dominic Mazzoni wrote: Yes, but I'm arguing that the high contrast rings is not a good idea and we should drop that part of the spec. Some users have great trouble seeing the default focus rings. Once that part is gone (or once no browser has plans to implement that part), drawCustomFocusRing no longer makes sense. 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. But drawCustomFocusRing() does more than just draw high-contrast focus rings. It also moves the magnification, moves the screen-reader focus, etc. It does everything drawSystemFocusRing() does other than draw the actual focus ring. 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. How would this differ from scrollPathIntoView() ? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Outline style to use for drawSystemFocusRing
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. 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. I don't understand what the problem is with the current API, but I agree that if it's broken it should be fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Tue, 01 Oct 2013 01:10:25 +0200, Ian Hickson i...@hixie.ch wrote: On Mon, 30 Sep 2013, Rik Cabanier wrote: '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' On Mon, 30 Sep 2013, 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) In light of that, maybe it's OK to leave the spec as-is. ' notifyFocusLocation' is just as confusing... Yeah... The current name isn't great, but I don't know what would be better (without making its name an essay or something). Right... On Mon, 30 Sep 2013, Dominic Mazzoni wrote: Yes, but I'm arguing that the high contrast rings is not a good idea and we should drop that part of the spec. Some users have great trouble seeing the default focus rings. yeah. Once that part is gone (or once no browser has plans to implement that part), drawCustomFocusRing no longer makes sense. 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. Yes, I hope not :) But drawCustomFocusRing() does more than just draw high-contrast focus rings. It also moves the magnification, moves the screen-reader focus, etc. It does everything drawSystemFocusRing() does other than draw the actual focus ring. So it seems that a real question is whether browsers prefer to deal with two APIs, or allow customisation of the focus ring. which comes down to a question of implementation strategy - do browsers rely on a system focus style, or draw it themselves, feeding from a system default style? 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. How would this differ from scrollPathIntoView() ? cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, Sep 30, 2013 at 4:12 PM, Ian Hickson i...@hixie.ch 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
On Mon, Sep 30, 2013 at 4:51 PM, Dominic Mazzoni dmazz...@google.comwrote: On Mon, Sep 30, 2013 at 4:12 PM, Ian Hickson i...@hixie.ch 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? Where does it say in the spec that if you have assistive technology enabled, focus rings should not be drawn? 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. As Ian pointed out, the accessibility software could do that. Actually, I just tried this with my patched version of Firefox and your example: http://dmazzoni-google.github.io/canvas-focus-ring-demo/ If I tab into the hidden canvas elements, the browser automatically scrolls to the region. So, it seems that this is not needed.
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson i...@hixie.ch 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
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? (Apologies if you've already reported some feedback that I've lost track of; I didn't see any when I looked just now.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Outline style to use for drawSystemFocusRing
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
On Mon, 29 Jul 2013, Rik Cabanier wrote:
On Mon, Jul 29, 2013 at 5:26 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 29 Jul 2013, Rik Cabanier wrote:
Does that mean it should be stroked along the path?
That depends on the platform. Some platforms render the focus as a
highlight, some as a dotted line around the exact path of the control,
some as a box around the bounding box of the focused control, etc.
The idea of this API is to let the user agent render the focus ring
however it is appropriate for the platform.
I see. So the user agent can decided if it closes the path, use end
caps, round joins, etc. Maybe the spec should be more specific and say
that nothing in the graphics state (except clipping) should affect the
focus ring.
Ok, done.
As for the color of the focus ring, shouldn't it come from the
':focus' style of the element that is passed in?
It should come from the platform.
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?
The button is likely to be invisible, so it's likely to not have computed
style, so I don't think this works.
On Mon, 29 Jul 2013, Dominic Mazzoni wrote:
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
Yeah, I think on the medium to long term we'll add something as suggested
in this e-mail:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0345.html
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Wed, Jul 24, 2013 at 4:14 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 24 Jul 2013, Dominic Mazzoni wrote: I'm looking into implementing drawSystemFocusRing http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-drawsystemfocusring in 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. 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). There's an example in the spec -- search for couple of checkboxes. That example doesn't show how the focus rings are supposed to render. The spec says: ... draws a focus ring *around *the current default path or the given path ... and: ... draw a focus ring of the appropriate style along the intended path... Which way should it be drawn? It seems that the focus ring should be around the path and drawn in accordance to the browser's algorithm of focus regions.
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, 29 Jul 2013, Rik Cabanier 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). There's an example in the spec -- search for couple of checkboxes. That example doesn't show how the focus rings are supposed to render. The spec says: ... draws a focus ring *around *the current default path or the given path ... Note that that text is non-normative. There's a big box to that effect just above the text itself. and: ... draw a focus ring of the appropriate style along the intended path... That one is normative. Which way should it be drawn? The way the normative one says it is to be drawn. It seems that the focus ring should be around the path and drawn in accordance to the browser's algorithm of focus regions. Not really should what you're asking. Can you elaborate? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, Jul 29, 2013 at 2:48 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 29 Jul 2013, Rik Cabanier 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). There's an example in the spec -- search for couple of checkboxes. That example doesn't show how the focus rings are supposed to render. The spec says: ... draws a focus ring *around *the current default path or the given path ... Note that that text is non-normative. There's a big box to that effect just above the text itself. and: ... draw a focus ring of the appropriate style along the intended path... That one is normative. Which way should it be drawn? The way the normative one says it is to be drawn. Does that mean it should be stroked along the path? It seems that the focus ring should be around the path and drawn in accordance to the browser's algorithm of focus regions. Not really should what you're asking. Can you elaborate? How is the focus ring usually calculated? Does the UA know about the shape of the focused objects and then draws a box around it? As for the color of the focus ring, shouldn't it come from the ':focus' style of the element that is passed in?
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, 29 Jul 2013, Rik Cabanier wrote: Does that mean it should be stroked along the path? That depends on the platform. Some platforms render the focus as a highlight, some as a dotted line around the exact path of the control, some as a box around the bounding box of the focused control, etc. The idea of this API is to let the user agent render the focus ring however it is appropriate for the platform. How is the focus ring usually calculated? Does the UA know about the shape of the focused objects and then draws a box around it? It depends on the platform. As for the color of the focus ring, shouldn't it come from the ':focus' style of the element that is passed in? It should come from the platform. See also this recent discussion: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0345.html -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, Jul 29, 2013 at 5:26 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 29 Jul 2013, Rik Cabanier wrote:
Does that mean it should be stroked along the path?
That depends on the platform. Some platforms render the focus as a
highlight, some as a dotted line around the exact path of the control,
some as a box around the bounding box of the focused control, etc.
The idea of this API is to let the user agent render the focus ring
however it is appropriate for the platform.
I see. So the user agent can decided if it closes the path, use end caps,
round joins, etc.
Maybe the spec should be more specific and say that nothing in the graphics
state (except clipping) should affect the focus ring.
How is the focus ring usually calculated? Does the UA know about the
shape of the focused objects and then draws a box around it?
It depends on the platform.
As for the color of the focus ring, shouldn't it come from the ':focus'
style of the element that is passed in?
It should come from the platform.
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?
See also this recent discussion:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0345.html
Yes, we're still in that thread :-)
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, Jul 29, 2013 at 7:51 PM, Rik Cabanier caban...@gmail.com 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
On Mon, Jul 29, 2013 at 9:21 PM, Dominic Mazzoni dmazz...@google.comwrote:
On Mon, Jul 29, 2013 at 7:51 PM, Rik Cabanier caban...@gmail.com 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.
That sounds like good plan. Keep us posted on your findings!
I know at least 3 developers who are interested in trying it out with
their apps.
- Dominic
