W3C home > Mailing lists > Public > public-html@w3.org > April 2011

Re: Bug 11239

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
Message-ID: <Pine.LNX.4.64.1104290720100.25791@ps20323.dreamhostps.com>
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

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:37 UTC