Rich,
I look forward to hearing from Shawn on this, but at first blush, I
wouldn't expect a performance issue to ATs. You get some event from
the text object (e.g. focus change, or caret move, or text added), you
go up one level to the parent to get it's rectangle/bounds, and then
you only show that rectangle within the magnified region. That's what,
3 API calls?
But perhaps I don't fully understand the use case(s). Shawn - can you
describe the scenario(s) you are working in in detail?
Regards,
Peter Korn
Accessibility Principal
Oracle
Peter,
I would think so but it would be a performance hit to ATs. Also, I am
not sure how readily available the clipping regions are where they
would do the clipping.
Perhaps Shawn could weigh in on his thoughts here? Shawn?
Rich
Rich Schwerdtfeger
CTO Accessibility Software Group
 Peter Korn
---05/17/2010 12:38:49 PM---Rich,
Rich,
The particular use case here is around text, yes? IA2/ATK/JA-API should
all expose character boundary information (the bounding rectangle of
every character in every accessible object). Likewise, the boundary of
whatever the text is contained in is likewise exposed. So it should be
a fairly trivial operation for a screen magnifier to do this clipping
operation - just by clipping to the object containing the text.
No?
Regards,
Peter Korn
Accessibility Principal
Oracle
Hi Alex,
Exposing clipped content is great for screen readers. What AI Squared
is saying is that they would like to know something is not visible (
due to clipping) as they are trying to magnify what is visible. Imagine
you have low vision and are reading a text and magnifying that part of
the scree but it is partially obscured. So, you are magnifying a part
of the screen that does not exist visually.
Having access to the offscreen information is essential for a screen
reader user who may be searching for content and does no care if
something is obscured but for a magnifier users this is a problem. AI
Squared has had to resort to using their offscreen model which
represents only visual information to magnify as things are being read
to the user.
I would like to reduce the dependency on having to use screen scraping
technology. It is invasive to systems and is less accurate than
accessibility APIs.
Rich
Rich Schwerdtfeger
CTO Accessibility Software Group
Hi, Rich.
Clipped and scrolled off elements operable, for example, keyboard
shortcuts works. So I would say they should be accessible, expose
offscreen state, attached to accessible tree and as consequence no new
API is needed. At least this is how it works in Firefox.
Thank you.
Alex.
On Sat, May 15, 2010 at 6:47 AM, Richard Schwerdtfeger
<[email protected]> wrote:
> I was speaking with Shawn Warren of AI Squared and he indicated
that he
> would like to have IA2 be able to hid access to content that is
not visible.
> In particular it appears Shawn was referring to content and
componentry that
> was clipped out due to window size and other windows obscuring the
content.
>
> I was thinking about this and perhaps the right way to do this
would be have
> an API feature that would turn on clipping for at least documents.
What do
> others think?
>
>
> Rich Schwerdtfeger
> CTO Accessibility Software Group
>
> _______________________________________________
> Accessibility-ia2 mailing list
> [email protected]
> https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
>
>
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
|
