[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: KOffice screen readers
From:       Gary Cramblitt <garycramblitt () comcast ! net>
Date:       2006-05-14 13:32:43
Message-ID: 200605140932.43437.garycramblitt () comcast ! net
[Download RAW message or body]

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.

------

From: Peter Korn <Peter.Korn@sun.com>
 To: Gary Cramblitt <garycramblitt@comcast.net>
 CC: accessibility@freestandards.org
 
Hi Gary,

Great to hear about the plans and developments around KOffice and Qt4/KDE4.

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. 

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.


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


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> The KOffice developers are currently beginning a major redesign and 
> refactoring effort as they adapt KOffice to the Qt4/KDE4 libraries.  As most 
> of you aware, KDE plans to adapt the AT-SPI for exposing accessible content.
>
> Since KOffice applications are "document" processors, an important 
> consideration is exposing the internal content of documents in an accessible 
> way.  I am seeking advice and guidance from this group on how we should go 
> about this.
>
> I have found the following documents that discuss exposing document content 
> via AT-SPI.
>
> http://accessibility.freestandards.org/a11yspecs/atspi/adoc/ADOC_ATSPI.htm
> http://accessibility.freestandards.org/a11yspecs/atspi/adoc/ADOC_ATK.htm
> http://www.mozilla.org/access/unix/new-atk.html
>
> The last one is HTML only and the middle one is for the ATK, which KDE won't 
> be using.   Discussions on these documents seem to have died out on this 
> list.  How relevant are they to KOffice today?
>
> What advice would you offer the KOffice devs for making documents accessible 
> via AT-SPI?

-- 
Gary Cramblitt (aka PhantomsDad)
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

[prev in list] [next in list] [prev in thread] [next in thread]