Making the presenter console extension accessible is complicated by a number of
things:

1. It is an extension.  At the moment there is no way for an extension to inject
its tree of XAccessible objects into the tree of the main application.

2. It is doing its own rendering of all controls.  Together with the fact that
all accessibility related tooling and helper classes are not available (because
extensions only have access to the ODK) everything has to be created from scratch.

3. The notes are displayed as bitmaps that are created in the application code
and are then sent to the extension.  This is necessary because there is no API
for the edit engine that lets it render into an XCanvas.  This will make it hard
or even impossible to provide positions and sizes for individual characters.

Finished with making the Presenter Console accessible.

Targeted the points mentioned above like this:
1) Added new interface com/sun/star/drawing/framework/XPane2 that allows the
setting of accessibility objects for panes of the drawing framework.

2) It was a lot of work (see below).

3) The notes view is now rendered directly via the canvas.  With the help of the
XBreakIterator text is broken into words and lines.  Missing implementations
where provided to the vcl canvas that give access to font dimensions and
bounding boxes of characters.


Changes where made in these modules:

offapi, SVN revision 276133
Added interface XPane2

sd, revision 276136
Added implementation of new XPane2 interface to existing panes.  The code for
providing bitmaps of the notes text is still present and active in order to
support older versions of the extension.

sdext, revision 276139
Implementation of a text view for the notes text.  Implementation of the
accessibility interfaces.
Many small changes, including that the view mode is now stored persistently.

canvas, revision 276142
Added missing implementation regarding font dimensions and bounding boxes of
characters.

We need a change in one of the OpenOffice.org specific scripts of Orca in order
to have the notes text read.  Orca does recognize caret events only when they
were caused by the arrow keys.  In the slide show and therefore in the Presenter
Console, too, the arrow keys are already bound.  The change the current slide to
the next or previous slide.  Therefore I used VI like keys h and l to move the
caret backward or forward.  These, however, do not trigger the screen reader of
Orca.
There is a comment regarding this in orca/src/orca/default.py in
_presentTextAtNewCaretPosition near line 3412:

        # Guess why the caret moved and say something appropriate.
        # [[[TODO: WDW - this motion assumes traditional GUI
        # navigation gestures.  In an editor such as vi, line up and
        # down is done via other actions such as "i" or "j".  We may
        # need to think about this a little harder.]]]
        #

I attach a diff that translates the h and l keys to arrow left and right.  Note
that this is more a proof of concept.  I do not have the knowledge of Orca or
Python to make this fix.

diff --git a/src/orca/scripts/apps/soffice/script.py
b/src/orca/scripts/apps/soffice/script.py
index 96fd86d..c9700c2 100644
--- a/src/orca/scripts/apps/soffice/script.py
+++ b/src/orca/scripts/apps/soffice/script.py
@@ -2281,6 +2281,27 @@ class Script(default.Script):
             self._speakWriterText(event, textToSpeak)
             braille.displayRegions( \
                 self.brailleGenerator.generateBraille(event.source))
+        elif event_string in ["h", "H", "l", "L"] \
+                 and event.source.name.startswith("Paragraph") \
+                 and event.source.parent.name == "Presenter Notes":
+            # The presenter console can not use the left and right arrow keys
+            # for moving the caret (the arrow keys jump to the next or previous
+            # slide.)  It uses VI-like keys instead.
+            # Because the speaking of characters and words is triggered only by
+            # the arrow keys, we have to do a replacement of the key codes here.
+            # Additionally we translate between shift and control modifiers
+            # (plain key presesses move word wise and therefore have to be
+            # translated to CTRL, while the shift modifier moves the caret
+            # character wise and has to be removed.)
+            if event_string in ["h", "l"]:
+                orca_state.lastInputEvent.modifiers |= settings.CTRL_MODIFIER_MASK
+            else:
+                orca_state.lastInputEvent.modifiers &= ~settings.CTRL_MODIFIER_MASK
+            if event_string in ["H", "L"]:
+                orca_state.lastNonModifierKeyEvent.event_string = "Left"
+            else:
+                orca_state.lastNonModifierKeyEvent.event_string = "Right"
+            default.Script.onCaretMoved(self, event)
         else:
             # The lists and combo boxes in the Formatting toolbar emit
             # object:active-descendant-changed events which cause us

@es: Please verify.

Some documentation here:

http://wiki.services.openoffice.org/wiki/Accessibility

=> "AT support while giving a presentation "

Verified in CWS impressaccessibility3

.

Fixed and integrated => closing now..