GNOME Bugzilla – Bug 527646
When reading table cells, the associated headers and row/column information need to be obtainable in braille
Last modified: 2018-02-08 12:55:31 UTC
While navigating and reading tables in Firefox (and possibly similar applications), Orca speaks the headers associated with each data cell as it receives focus. Orca also announces the row/column coordinates of the current data cell. This information is currently not available in braille: the braille output gives only the content of the data cell. It is proposed that a BRLTTY command be mapped to a function that retrieves and displays the headers associated with the focused data cell. The same, or a separate, command should also present the row/column coordinates of the focused data cell. While the headers are displayed, the next/previous window commands should move the braille display within the logical "line" that comprises the table headers. Any other BRLTTY navigation command should return the braille window to the associated data cell. It is also suggested that the BRLTTY TOP command could be used for this purpose, as moving to the associated headers is analogous to moving to the top line of the screen whilst retaining the current column position, which is how this command operates outside of Orca. Of course, outside a table, this command could serve the same purpose as it does at the BRLTTY console level. Doubtless the design of this feature is in need of discussion and refinement; the most important objective is to provide the braille user with the same information that is presently available to the speech user.
Putting my name on this so I'll remember to spec it out.
Putting summary back on (oops!). In addition, Mike and I chatted a while back about the idea of putting the header information in as part of the context. So, pan left and you'd get to the header. Just a thought that I wanted to make sure we didn't lose.
(In reply to comment #2) > Putting summary back on (oops!). In addition, Mike and I chatted a while back > about the idea of putting the header information in as part of the context. > So, pan left and you'd get to the header. Just a thought that I wanted to make > sure we didn't lose. Mike, can you confirm this is the desired presentation? If so, where should the row and column header information be with respect to everything else?
The row header followed by the column header should be presented just before the actual cell data. The actual cell should be presented on the display when one navigates to the cell
There is already code in getBrailleContext() in default.py (lines 1705-1758), to add in the row and column header context (if present), if the parent of the object has a table interface. This seems to already nicely work for the gtk-demo Tree View -> Tree Store demonstration (for column headers). Joanie (or Jason), can you point me at an example Firefox document or URL with tables in it, so I can try to find out why we aren't calling that code and/or it isn't working? Thanks.
If the tables are in HTML, it's a whole different ballgame.... updateBraille() puts the line together in that case. If that's indeed what this bug is about, feel free to reassign to me. At least the non brltty bit. :-)
Well I'll assign it to you for now, as that's the bit that Mike has spec'ed, and I'm fairly confident we are talking HTML here. It's still unclear what (if anything) we are doing on the Brltty side. Hopefully Mike or Will will be able to provide that information at a later date. Thanks.
It's actually in braillegenerator.py, not default.py. The Gecko braille_generator.py module subclasses braillegenerator.BrailleGenerator, but it doesn't override getBrailleContext(). Thus, the desired functionality, which is in that method, should be invoked, and should work. I have prepared a simple HTML document which shows that this is not the case. Incidentally, is there any way to obtain a listing of the full accessibility hierarchy in a debug file? This would make it easy to check whether the code in getBrailleContext() should find the table and its headers.
Created attachment 112724 [details] HTML test case.
Thanks Jason. > Incidentally, is there any way to obtain a listing of the full accessibility > hierarchy in a debug file? Do you mean a stack trace at a particular point? If so, then when I want this to happen, I add in: debug.printStack(debug.LEVEL_OFF) to do it. Or do you mean the accessibility hierarchy of a particular accessible object? I.e. all it's parents all the way up to the application object. For this (assuming you are doing it from a script class), you can use: self.printAncestry(obj) If you want the full hierarchy of the complete application, then you can do: self.printHierarchy(obj.getApplication(), obj) Again, it assumes you are in a script application. If you are doing is from a braille generator class, then you'd need to use: self._script.printHierarchy(obj.getApplication(), obj) Hope that helps.
> The Gecko braille_generator.py module subclasses > braillegenerator.BrailleGenerator, but it doesn't override > getBrailleContext(). True... But... I just did a grep for getBrailleContext(). The only time I see it being called is in default.py in updateBraille(). The Gecko script.py *does* override updateBraille(). At the top of that method you'll find: if not self.inDocumentContent(): default.Script.updateBraille(self, obj, extraRegion) return For HTML content (e.g. your test case) we *are* inDocumentContent() so the Gecko updateBraille() proceeds to do it's own thing -- and that doesn't include calling getBrailleContext(). But just to be darned sure, I added a print statement to the top of the default.py updateBraille(), another one to the top of the Gecko script.py updateBraille(), and a third to the top of getBrailleContext(). Then I navigated in your test case. The default updateBraille() was not invoked, nor was the braillegenerator's getBrailleContext(). Only the Gecko updateBraille() method was. Granted, I'm rather sleep deprived at the moment, so I may be missing something obvious. If so, feel free to point it out (and wake me up if possible *grin*). That said.... Because of the issue you raise here along with one raised in another bug, methinks we need a Gecko-specific getBrailleContext(). I'll open a bug for that.
Bug 542840 has been opened for the Gecko-specific getBrailleContext()
We are late in the 2.28 release cycle and I want to focus on "high impact"/"low risk" items that also fall within the release team's restrictions in place. Regretfully, this bug doesn't fit well within those constraints and we'll review it for the 2.29 release cycle.
Bulk reassigning Will's bugs to the default assignee. (Sorry for the spam!)
Given everything else on the to-do list, non-critical Gecko-related bugs are going to have to wait until after 3.0, unless someone volunteers to do them.