Re: [whatwg] Outline style to use for drawSystemFocusRing

On Oct 16, 2013, at 1:36 PM, Dominic Mazzoni <dmazzoni@google.com> wrote:

> On Wed, Oct 16, 2013 at 12:46 PM, Ian Hickson <ian@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

Received on Friday, 18 October 2013 04:55:42 UTC