Re: [whatwg] Outline style to use for drawSystemFocusRing

On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson <ian@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.

Received on Wednesday, 8 January 2014 07:02:58 UTC