Re: Bug 11239

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.

> 
>>  * 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.

Regards,
Maciej

Received on Friday, 29 April 2011 07:11:11 UTC