- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 29 Apr 2011 07:22:21 +0000 (UTC)
- To: Maciej Stachowiak <mjs@apple.com>
- cc: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, public-html@w3.org
On Fri, 29 Apr 2011, Maciej Stachowiak wrote: > On Apr 28, 2011, at 11:25 AM, Ian Hickson wrote: > >> > >> Ian: could we perhaps specify to return -1 in this case? > > > > What case is this case, exactly? An example would be most helpful. > > Could we get at least temporary agreement on -1 so we can get the > decision applied, and pursue the discussion of whether the "no setting" > case should return -1 or a hardcoded UA-chosen value? It seems like the > no setting case is likely to be an edge case, so we can take our time > refining it. The decision doesn't mention a case where one needs to return -1. As far as I can tell the "no setting" case doesn't exist, so I don't see why we would add it to the spec. > >> * Ian's patch is less detailed in its suggestion of how focus notification > >> should be approached, whereas your list suggests that a best fit > >> rectangle on > >> screen should be created and surfaced in the accessibility tree. I suppose > >> vagueness provides for accessibility APIs that can understand > >> non-rectangular > >> areas. Ian, could we perhaps include the best fit rectangle approach as just > >> as an example? > > > > The best-fit approach text in the proposed patch is completely > > meaningless. I have no idea what was even _intended_ by the text. If > > someone could explain what it means, I would be happy to make sure the > > spec fully defines whatever is appropriate. > > After thinking about it, I believe the intent is as follows: > > - Many screen magnifiers are driven by a general-purpose accessibility API. > - From the point of view of a system accessibility API, when drawFocusRing() is called, the accessibility tree object that is marked as focused is the relevant backing element. > - In order for a magnifier hooked up to the accessibility API mechanism to properly drive magnification based on a focus change, it needs the bounds for the newly focused object. > - A good way to do that is to alter the accessibility object representing the element to have bounds matching the path for the focus ring. > > In theory it is possible that UAs might drive a magnifier more directly, but in practice this is how it will happen. I believe describing it that way would be more useful to implementors. I can certainly add a non-normative note describing this in more detail if that would be helpful to implementors. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 29 April 2011 07:22:45 UTC