Apache OpenOffice (AOO) Bugzilla – Issue 87261
No accessibility events generated when viewing a presentation (workaround available)
Last modified: 2017-05-20 11:08:33 UTC
See Orca bug #523228 which is blocked by this problem. http://bugzilla.gnome.org/show_bug.cgi?id=523228 Steps to reproduce: 1. View a presentation in Impress 2. Press F5 for Slide Show 3. Move among slides with Page Up/Page Down Expected results: Orca would speak and display the text on each slide. Actual results: Orca does nothing. (The need for this support was raised at CSUN) See attachment to Orca bug: http://bugzilla.gnome.org/attachment.cgi?id=107633&action=view From this you can see we are getting no accessibility events as you Page-Down through the presentation slides.
Reassigned to WG
Reassigned.
MT: We should evaluate if everything is available and accessible in the new presenter console. Then that should be enough, IMHO. I doubt that the blind presenter has any need to get text positions in the slide show mode. All pages can be "evaluated" in normal mode, so in slide show mode only the content should be critical. And he can also rely on his notes there. I will ask Orca team for opinions.
I happen to be talking to Mike on the phone about this right now and we're not clear on what you mean by "text positions". i.e. exactly what is it that we won't have access to in slide show mode?
Presenter console seems to have the same issue wrt to AT support :( We need to evaluate how best to fix it, and what exactly to expose. e.g. when giving a presentation, someone might be more interested in getting the notes instead of 1:1 content. Maybe as a accessible description? To be discussed...
The problem of the presenter console and AT support mentioned above is this: The presenter console is an extension and therefore can only use the UNO API to provide any AT support. However, the API does not allow this. One has to derive from the vcl Window class and overload CreateAccessible() and that is not possible for an extension. One possible fix, specific to the presenter console, would be to provide some sort of loop hole by e.g. providing a private API, using a tunnel, or by using some generic interface to pass an XAccessible implementation from extension to the full screen window in which the presenter console is displayed. This would be, clearly, a hack. A better approach, one that would be usable by other extensions as well, would be an extension to the API that would provide something like a XWindow3::setAccessible() method to set the accessible object for any window.
As discussed earlier, we are convinced that full AT support in an active presentation view doesn't help much, and that the presenter console is much more helpful to the user. The presenter console was made accessible in # i102525#, so I will downgrade priority and target of this issue.
P4, OOo later
Some documentation here: http://wiki.services.openoffice.org/wiki/Accessibility => "AT support while giving a presentation "
ww->mt: "As discussed earlier, we are convinced that full AT support in an active presentation view doesn't help much, and that the presenter console is much more helpful to the user." A common interaction style users have on Windows is that they bring the full screen mode up and the screen reader will then read the entire slide as the user pages up/down. This behavior is highly desired and highly helpful because the user only needs to know the page up/down keys. So, some sort of event(s) when the slide changes would be highly desirable so that a screen can then do a "SayAll" of the slide content.
joaniediggs->mt, all: Just in case it wasn't clear from other comments about why this bug was filed.... There are plenty of people who are blind who have excellent skills using presentation software. They can use the presenter console. But we're not talking about them. There are plenty of people who are blind who, though they may lack familiarity with presentation software, have excellent computer skills and can figure things out. But we're not talking about them either. Not in this bug.... :-) In this bug, we're talking about folks who are blind and only have basic computer skills and have just been given a presentation as an alternative and supposedly-accessible format. They have no clue whatsoever what to do with it. At all. None. Not even if their very lives depended upon it. Seriously. But they want to read the content. So they press Return on the file's icon and find themselves in PowerPoint or Impress. Based on my 14 years of DayJob as an assistive technology specialist working with folks who are blind, including woefully under-skilled users, here's what happens next: They start Tabbing. And eventually they get to an object with text. How do you read a text object? Well, heck, you arrow. So they start arrowing. But the text isn't getting read to them. And to make matters worse, the text object is now moving. And if their screen reader announces this fact, which they typically do in Windows -- and which Orca will hopefully start doing very, very soon -- these users are even more confused and frustrated. All they wanted to do in the first place was read this stupid presentation they received at this stupid conference and why isn't their stupid screen reader letting them do that? For this particular class of user, what you tell them to do is: 1. Press F5 2. Press Page Up/Down to read the previous/next slide 3. Press Escape when you're done Problem solved. Presentation gets read. The user is happy. It's all good. At least for PowerPoint users.... We want to be able to provide that same, headache-free, just-open-the-file-and-read access to the occasional presentation for *nix users. ===================================== joaniediggs->af: Having (finally) had the opportunity to sit down and work with your fix for issue 90690, I'm happy to announce that Orca (git master) is now presenting a lot more information than it was before to *nix Impress users who are blind. Thanks for your work on that! Given the P4 status of this bug, I'm going to see if I can use the accessibility goodness you provided for 90690 to accomplish what I describe wanting above, but via the slide pane. At least that way, users could arrow Up/Down to read slides, and not be in danger of moving objects around accidentally. Nonetheless, it would still be nice (really, really nice) if there can be found some way for y'all to emit enough information to us when the user is moving amongst slides in regular, extension-free slide show mode. After all, folks coming to us from Windows are bringing with them what they learned there.... They will be trying the "F5, Page Up/Page Down, Escape" thang. And they will be expecting it to work. I'm very sorry to be a pain. Much appreciation in advance for anything that can be done on this one.
Best-laid plans.... Turns out that I cannot currently provide easy, just-read-the-slide access in Orca via Slide pane navigation as I'm not seeing any events. Just opened issue 111667 for that.
Reset assigne to the default "issues@openoffice.apache.org".