GNOME Bugzilla – Bug 143201
gnopernicus needs to work well with gnome-terminal/yast (ui-ncurses)
Last modified: 2008-08-22 20:23:08 UTC
There is a need for accessibility that configuration editors using gnome-terminal/ui-ncurses are adequately usable, as there is no guarantee that the X versions of these apps e.g. yast2(motif) will be accessible. Currently there is some functionality with gnopernicus and yast - gnopernicus does report some information but it is not sufficient. It is difficult to focus on particular issues as there are so many, but for example gnopernicus often reads the entire window when simply moving up and down in a menu. It also reports the previous menu item in a menu if changing from scrolling down to scrolling up. There is probably a lot of work involved in this, but I'm just raising the issue.
Correction, yast2 is qt..
The first issue that needs to be resolved is to use vte tarball 0.11.11 instead of 0.11.10 which dates from last June.
Marking AP1 as no actual data loss or system crash occurs.
The Sun Accessibility Program Office has determined that ncurses apps do NOT meet accessibility criteria. It should be an AP1 bug if gnopernicus fails with a non-ncurses app, but not if it fails with one based on ncurses.
How does an accessible user change system settings, add/remove packages, add/remove hardware.. ? This is difficult as it is enough for a normal user who hasn't access to a program such as yast2 or redhat's configurator.
One interpretation of Section 508 is that OS installation aren't required to be accessible in order for them to be procured. Anything a user might want to do that s/he cannot because of accessibility *is* a bug; but the priority of that bug must be informed by the frequency of the action, and whether existing laws that cover accessibility require it. Also, what we do about these issues is informed by what we know is coming in the YaST2 domain -> that we expect KDE 4 and the Qt associated with it will implement ATK and thus a new edition of YaST2 should be accessible. So... my suggestion/request: please flag all "core" apps (installation excepted) that require ncurses as P1/P2 accessibility bugs; please flag all installation apps that require ncurses as P3 accessibility bugs.
Peter: the KDE/yast2 stuff is quite a long way off I think. I think your suggestion regarding installation makes sense. From there we need a clearer definition of what is meant by "installation". When it comes to user tasks, there are some tasks which are not reasonably the sole role of an admin. If the "average non-expert user" (we'll imagine that such a user exists ;-) does not require sysadmin assistance to carry out a task, we may need to treat that task as "core" functionality. I believe there are a number of tasks which fall into that category, for which the proposed accessibility solution is a command-line-based one. We need to assess which of those tasks require ncurses.
David/test team: After discussion, we're requesting that significant terminal accessibility bugs (for non-ncurses uses of the terminal) be logged separately. The ncurses support is something we will deal with as a lower priority RFE, and something we're not supporting right away. So please file separate bugs regarding other uses of the terminal.
This is fine. Just remember that at such a low priority this will most likely get lost from radar.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
This bug belongs to ncurses. Bill, Peter to what module should be it assigned?
This bug should be assigned to lib-vte (as decided in a phone meeting on 13rd of February). Is this the correct assign?
I don't see why this bug was reassigned to vte, certainly as currently described it does not sound like a vte RFE to me. I think it needs to go back to gnopernicus. Perhaps gnopernicus will determine that ncurses support will require vte to implement the AtkTerminal interface, in which case a separate RFE against vte should be filed.
I disagree that this belongs to Gnopernicus. Gnopernicus is a client of AT-SPI. The AT-SPI implementation from vte is not providing what Gnopernicus needs for an ncurses app. That means either the AT-SPI implementation from vte isn't correct, or the AT-SPI itself is insufficient. As the maintainers of the API, I think it is up to us (with input from AT vendors and application writers and other interested parties) to figure out what API is needed and get it into AT-SPI. I don't think that is specifically the job of a single AT vendor.
Exactly what information, as defined by the current AT-SPI API, is vte failing to provide? This information has not been supplied. The plan of action with respect to ncurses has been, if we address it at all, to use AtkTerminal. That is a vte RFE, but it does not solve the problem, since gnopernicus doesn't yet use Terminal; the two issues go hand-in-hand. If on the other hand gnopernicus feels that vte is failing to give _specific_ information for ncurses apps which the AT-SPI specifies _should_ be provided, then those issues should be filed as specific bugs against vte. Keeping this as a catch-all vte bug makes no sense.
OK. Maybe the right answer is a change in the title of this bug: "Gnopernicus should work well with gnome-terminal with ncurses, at such time as it implements AccessibleTerminal". Will that satisfy? What should be clear is that there is nothing for Gnopernicus to do until more information is available from gnome-terminal.
Peter: I have just confirmed on my system that use of yast in gnome-terminal results in a full complement of AT-SPI text-change events. So I think there is a valid gnopernicus bug here, not a vte bug; the events are being sent to gnopernicus, but the end-user presentation is not as expected. I think the Terminal interface stuff should be a separate vte RFE. Whether this bug needs to depend on it depends on BAUM's findings as they investigate the current problems with gnopernicus' response to the gnome-terminal ncurses event stream.
BTW, it's curious to me that braille-monitor reports nothing when yast is used, even though "at-spi/test/event-listener-test -m" reports a stream of change events.
Bill, yast is a UI tool, even if it is run in a terminal. Gnopernicus receives indeed some events, but if has no ideea how text is arranged on the screen, what is "focus", etc. For gnopernicus is no difference between "yast" and "cat" program.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Just dropping a note: brltty is able to read gnome-terminal just like it reads the linux text console. That can be a nice bargain: use brltty for what it's good at (reading a terminal), and gnopernicus for what it's good at (browsing in guis).
Mmm, what happened to AccessibleTerminal? Some time ago, there was an interface proposal which looked quite fine to me, but I can't find it any more. I've been trying to use the selection mecanism for highlighting some parts of the terminal, and the scrollback nature of terminals makes it very difficult to achieve (because the selection offset includes scrollback history, while the text provided through AccessibleText_GetText() doesn't, and there is no easy way to get the amount of scrollback history).
BTW, there's something that should be implemented here: when a program requests for a password, it disables ECHO in the tty layer. The terminal emulator should notice that and expose it in AT-SPI so that keyboard echo speakers can automatically know that they shouldn't speak the password loud :)
Ah, the AccessibleTerminal interface draft is available here: http://www.gnome.org/~billh/at-spi-new-idl/html/html/interfaceAccessibility_1_1Terminal.html
I'm not sure you're going to get much activity on a gnopernicus bug since gnopernicus has been replaced by Orca. In addition, this seems like it has to do with both AT-SPI infrastructure issues (e.g., is AccessibleTerminal supported by gnome-terminal/vte?) as well as assistive technology issues (does the assistive technology make use of AccessibleTerminal). To see progress on this, I'd would suggest filing a bug against the vte component (to support AccessibleTerminal) and a bug against Orca requesting that it work better with gnome-terminal and give specific examples of the user experience that you'd like to see improved.
Ah, I didn't pay attention that this bug was still in the gnopernicus package. AccessibleTerminal was just never actually implemented in at/spi (I don't have the time/knowledge/... to do it), hence even less in vte or brltty
Ah, actually there's a bug entry for that already: #344421.
and #326538.
There have not been any code commits to Gnopernicus for more than two years, and Gnopernicus has been superseded by Orca in GNOME. Gnopernicus has been moved to the SVN archives today, and the developers did not respond to any emails. Hence I'm closing all remaining 25 open bug reports as WONTFIX.