- From: Dominic Mazzoni <dmazzoni@google.com>
- Date: Tue, 7 Jan 2014 23:02:32 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, Rik Cabanier <cabanier@gmail.com>, Ryosuke Niwa <rniwa@apple.com>
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