GNOME Bugzilla – Bug 120730
help text is not read by the screen reader.
Last modified: 2004-12-22 21:47:04 UTC
With the following steps problem can be reproduced. 1. start gnome session, start terminal window, start gnopernicus on terminal window, wait till you hear the sound from the screen reader. 2. Open gcaltool help contents page. Help contents page opens. 3. But, screen reader do not read the help page text.
This does not sound like a gcalctool bug. Reassigning to gnopernicus.
I am not able to reproduce this bug. On my computer all focusable items are read by gnopernicus. Can you try the same thing with other apps?
I am using a gcaltool version 4.3.2. Following are the observations. 1. Screen reader reads the focussed items like hyper linked items. but, it will not read the text in the opened page.
I have used magnifier, PDF file viewer, gedit & gnopernicus applications. Screen reader reads all the focused items, like push buttons, hyper links etc. I am not able to read the text other than the focused items. Pls. revert back to me for more information. I will try to provide to as much as possible.
Chandrashekar: this sounds like a gnopernicus issue. Since there is no way to 'keyboard navigate' an HTML document other then from link to link, a gnopernicus user needs some other way to read help text. "Screen review" mode allows this, but I think it may be appropriate to provide another way of doing it as well (i.e. allowing gnopernicus users to navigate by word, sentence, line, etc.) From reading the gnopernicus user documenation at www.baum.ro/gnopernicus.html, it doesn't seem that this is possible except via "flat review" which reads all the text found in the current window along a horizontal line (but which does NOT navigate 'by line' via the AccessibleText "line" mechanisms). So for the moment it seems that flat screen review is the only way to read help text from gnopernicus; it may be that other navigation modes (next/prev, etc. paragraph-by-paragraph) can be used also, but it's not obvious.
There are certainly ways we can consider improving the gnopernicus screen review functionality. However, another solution to this particular problem is to provide caret movement/navigation within the GNOME help application. This is done in Mozilla (press F7 to turn it on). Providing this functionality in the help tool also enables something else very important: the ability to copy text without using the mouse. As mouseless operation of all functionality is a core accessibility requirement, it seems like this is a necessary solution to this bug.
I have logged bug #123008 against yelp to request the feature Peter suggested.
changing summary since all help contents are affected.
*** Bug 129948 has been marked as a duplicate of this bug. ***
In yelp with cursor on (after pressing F7) seems that when current object is a link, the text has state SPI_STATE_FOCUSED, but when the object is not a link no object (even in parent hierarchy) has state SPI_STATE_FOCUSED. Padraig, can you add state FOCUSED for "static texts" too?
I am not convinced that this is the correct thing to do. Why do you want it? The state FOCUSED is used to indicate which link has focus so we can acitvate it.
In case when caret in a "static text" , that object has the focus (it reacts to user actions), so it should has this state. In general case, in my oppinion, in any moment an object from the desktop should have this state because it receives the input.
I am not sure I agree with Remus either; focussing static (i.e. non-focussable) text may break a number of things. If the link is FOCUSSED as it now it, marking the containing text as also FOCUSSED seems problematic. Did we agree in today's meeting (Remus) that 'FOCUSSED' should not be required for responding to caret events?
Yes. From our meeting today: Gnopernicus shall respond to all caret move and text selection events in everything that implements AccessibleText, whether or not that objects is FOCUSED. However, Gnopernicus shall NOT respond to any other text events (especially text-insert/delete) on objects that are NOT FOCUSED. Note: other bug notes from our meeting today will be updated before I finish my work day.
Gnopernicus reacts to caret-moved and selection-changed for a text object which has a parent ( an object in parent line) with role SPI_ROLE_HTML_CONTAINER. This is because changes in behaviour for other situation should be minimum.
Created attachment 25033 [details] [review] proposed patch
Increase severity, because this is same bug as 135485.
*** Bug 135485 has been marked as a duplicate of this bug. ***
Created attachment 25085 [details] [review] a new proposed patch
The patch above will report all caret-moved and selection-changed event even for non-focused object. Patch doesn't handle selections across multiple text objects.
Dealing with selections over more than one object is very difficult because the hierarchy is very different for one application to another. In SO, all paragraphs are children of same object, but in yelp a visible text object can be the the child of the child of brother of parent of previous visible text object. Example for yelp: html-container panel panel panel text panel text panel panel panel text text Example for SO canvas text text text All objects with interest for gnopernicus have role text, but is very hard to say which is previous or next object for user.
Patch commited to CVS.
The remaining issue (report only a part of selected text) is subject of bug 136161.