[Accessibility] Re: KOffice screen readers
boud at valdyas.org
Mon May 15 09:50:04 PDT 2006
On Sunday 14 May 2006 15:32, Gary Cramblitt wrote:
> I received the following reply from Peter Korn when I asked about
> Accessible Documents and KOffice. Peter is someone whose expertise and
> judgement I highly respect.
> Given the Orca approach Peter mentions, it would appear that providing a
> rich scripting interface into document content might be a good way for
> KOffice to go.
Well, and we need that anyway, so that sounds like a good plan.
> Fundamentally all of the things we are thinking about for Accessible
> Document (the first two URLs below) are some time away before we expect
> to see them finished and implemented. The Firefox/Mozilla work
> (new-atk.html) - and specifically the last column in the table -
> describes the approach we are taking to apply the existing AT-SPI to
> rich the rich content of todays web pages, with the most minimal of
> additions to the API.
> For StarOffice/OpenOffice.org, we are looking at doing the same sort of
> "apply the existing stuff" approach in the short & medium term. Right
> now in SO/OOo the accessibility API info is provided by the user
> interface layer - important for those part of the API that return
> bounding rectangles of characters among other things - and not from the
> document model. As such, we have some challenges in figuring out a way
> to use Accessible Document for some things, and the rest of the AT-SPI
> APIs for others.
Ah, this makes things a bit clearer. I was thinking of exposing the document,
rather than the GUI. That should be a lot easier for us. And exposing the dom
through a scripting interface is necessary anyway for all kinds of other
> While in the Windows world direct access to the MS-Office DOM is key to
> the functionality that products like JAWS provide, we want to see how
> far we can get with Orca and the existing exposed APIs before concluding
> that we must implement Accessible Document to reach anything close to
> parity with Windows AT.
If access to the DOM is what makes things like JAWS possible, we should expose
our document model, too. But I guess that the "Accessible Document" is a kind
of meta-DOM? I wish I could google, but I'm on the train now :-(. I'll
> It would be good to know more about how the KOffice developers are
> thinking of implementing AT-SPI support (with the existing APIs), and
> whether their rendering model is sufficiently distinct from their
> document model that they would naturally come to the same decisions that
> the SO/OOo developers did.
The rendering and document model are completely separate in KWord (as far as I
know), for KSpread I'm not sure. In any case, we're working hard on a new
rendering model, and we'll keep the document model separate from that. As for
how we'll be going about implementing AT-SPI support -- I'm not sure at all.
It's what I'm trying to discover :-)
> In any case, unless the schedule for
> Qt4/KDE4 AT-SPI support remains a fair bit a off, I would recommend
> against waiting for Accessible Document before implementing
> accessibility API support in KOffice.
I'll investigate Accessible Document this week.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/accessibility/attachments/20060515/b86be007/attachment.pgp
More information about the Accessibility