Re: Today's meeting, the log.
Hi Folks; I cannot attend at 21:00 UTC today, but would gladly attend at 21:00 UTC Friday to discuss magnification. Will, if the meeting goes ahead on Friday please forward the concall number(s) if possible, thanks! Bill Willie Walker wrote: Thanks Luke! The turnout yesterday was amazing, with everyone asking a lot of really good questions, making a lot of great suggestions, and people just plain connecting with each other. We had some really good discussions around: 1) Evince accessibility. The cool thing here is that Brian Cameron, who has considerable experience with implementing accessible text support, is willing to mentor this and Behdad Esfahbod, aka Mr. Pango, is willing to answer questions as well. This is cool. 2) Documentation. We had good discussion about the overall need for documentation for users, developers/testers, and integrators. I think we were close to concluding that the user-oriented documentation and the more technical documentation might be separate tasks. 3) Testing. While this one is going to be an interesting challenge, the great thing is that everyone agrees it is really needed. We've already started a discussion on http://mail.gnome.org/archives/desktop-devel-list/2008-February/msg00103.html, and people are encouraged to join it. 4) Speech. We touched on this briefly. Speech Dispatcher is among the obvious choices, but we need to have more discussion about this. Before jumping on speech dispatcher completely, we need to make sure it can help address audio issues while simultaneously supporting screen readers, AAC technology, self-voicing applications, etc. It also needs to be capable of behaving properly in shared-server environments such as the Sun Ray and smaller devices such as OLPC and OpenMoko. We should probably also discuss this with the KDE and Open A11y folks to see if they would be on board with it. In other words, if we're going to do this, we need to do it right and we need to do it with the larger community in mind. 5) Magnification. We didn't get to this at all. Post meeting, Eitan (eeejay) and Bryen (suseROCKs) also talked about ideas along the lines of a Hall of Fame and Certification Logo. Neat stuff, and they will write more about it when they work up details. Given all the great questions and participation, the meeting went longer than expected. So, we discussed continuing the conversation tomorrow (Thu) at the same time. The main topics will be speech and magnification. I just want to be sure, though, that the needed players will be there tomorrow: Tomas Cerha for discussing speech dispatcher (hittsjunk and Kajarii would also be very helpful), Carlos Eduardo Rodrigues Diogenes and Kristian Lyngstøl for magnification. Will you be able to make it? If not, would Friday at the same time work better for people? Thanks again, everyone! Will Luke Yelavich wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey folks. Here is the log of today's meeting. Note that this meeting will continue on Thursday at the same time. Enjoy. http://irclogs.themuso.com/a11y/2008/#a11y.02-20.log Thanks to all who were there, it was a great session. Luke -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHu1wzjVefwtBjIM4RAp1xAJ4nCzOGU8ZaWyFO41UGlQRxT2CWGQCfcEVS yP3rxKQb33ZgWjJdZodkqVs= =WSWm -END PGP SIGNATURE- ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Forming an Accessibility Steering Committee
Hi Brian, all... My time is a bit more limited than in the past, for reviewing email, etc. However I would be honored to be part of the Committee in a 'less than central' role. I'd try and stay out of the way of the movers and shakers, but would be happy to lend suggestions on request. Would this be helpful to you guys? Best regards Bill Brian Cameron wrote: The GNOME Foundation Board of Directors recognizes the importance of Accessibility in the GNOME desktop. To help foster a more clear and positive vision, the board thinks it would be helpful to form an Accessibility Steering Committee. The purpose of this committee would be (in general terms) - Help oversee a11y issues with the GNOME desktop - Identify ways that the GNOME Foundation can better promote a11y - Recommend actions to the GNOME Foundation board. - Serve as a more clear a11y leadership team - Help to standardize free a11y interfaces so that a11y solutions can be best shared across desktops. I am wondering who in the GNOME a11y community would be interested in being a part of this Committee. Being involved would mean having time to engage in discussions and related tasks. It also may make sense to meet for a phone conference on a regular schedule (perhaps once or twice a month) if possible. Once we have identified who would like to participate in such a Committee, we can work out the details. Please respond if you would like to be involved with the GNOME community in this capacity, and any ideas you have on how this committee could work best. Thanks, Brian ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [g-a-devel] Status of IBM a11y
Peter Korn wrote: Hi Jason, As someone working for one of those small number of companies working on GNOME, Mozilla, etc. accessibility, I couldn't agree with you more. I am appreciative of the contributions IBM has made to our work - perhaps in the future we will see a resumption of their effort. ... I'd just like to echo what Peter and Jason said. I certainly appreciate the work of IBM and the individual contributors whose work has been done under IBM's sponsorship, and hope to see more of it in the future. Best regards, Bill ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [g-a-devel] Status of IBM a11y
Henrik Nilsen Omma wrote: Ariel Rios wrote: I am not very familiar with the ATK/AT-SPI implementations but I am aware that these implementations are not compatible with the KDE architecture, and a general move to DBUS has been often mentioned. The GNOME Mobile Embedded Initative could be the opportunity to implement ATK / AT-SPI over DBUS and finaly offer a general solution. Please be aware that moving into dbus might be a very hard task. Currently GNOME has a working a11y architecture while KDE has none. Do we want to move to an non existant architecture from one that works actually really well? That is the risk of moving things forward. Maintaining functionality on top of an aging framework that everyone else is migrating away from (seeing this in a 5 year perspective, say) will also be hard. The difference is there is no real reward from that kind of effort. In the 5-year timeframe I think a move to dbus makes sense. However, to do this, dbus needs to grow. If these sorts of extensions to dbus are deemed undesirable by the dbus team, another technology could of course be considered. To reply to Ariel (and to Janina, who replied later on), I think the key here is not to move to a non existant or sub-optimal solution, but instead to move to a mature framework which supports all of AT-SPI's important features. As it stands now, this implies changes not only to AT-SPI but to dbus. The big issue is finding resources/people with the right mix of time and expertise to bridge the gaps, while keeping the existing technology up and running during the transition period. I feel that it's technically possible, but it's also important that the migration be done with an eye to the big picture, to avoid disrupting the currently existing framework and minimize inconvenience to existing ATs and end-users. Best regards, Bill Henrik ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Name of Accessible (Not the Label Name)
Hi Udayan and Evan; In the case you mention below, the assistive technology should check for the presence of the Accessibility_Text interface. In most cases (i.e. other than text entry fields, for instance), the assistive technology should expose the contents of the Text interface to the end-user, not the 'name' property. This would solve your problem/issue. I agree that widget accessible-name properties should be end-user-usable as well. regards Bill Evan Yan wrote: Udayan Singh wrote: Hi All, I have been using cspi (i.e. at-spi) library in my application. Scenario is that I am using HTML programming on web page and the application is executing in GNOME environment (GTK+ is for UI and C Programming). So the web page has something like this : . p label for=Label2Label2:/label input type=text name=Lb2 id=Label2 value=Some Text / /p [...] Now if i click on the text box that Label2 will have then the output that I get is : Name of event's source : Label2 I think that's the correct behavior. Lb2 is the programming name of the textfield, not visible to users, while Label2 labeled the textfield, is just what's meaningful to end users. So from accessibility's aspect, we should expose Label2 but not Lb2 to users. -Evan But I want to get the name i.e. Lb2. Which API should I use to get this done ? Any inputs would be great. Thanks in advance.. Regards, Udayan ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [g-a-devel] Accerciser 0.1.0 (stretch)
Hi Peter; This is really cool, thanks a bunch. I can hardly wait to try it (sorry I didn't get a chance this week). Bill Peter Parente wrote: Accerciser is an interactive Python accessibility explorer for the GNOME desktop. It uses AT-SPI to inspect and control widgets, allowing you to check if an application is providing correct information to assistive technologies and automated test frameworks. Accerciser has a simple plugin framework which you can use to create custom views of accessibility information. In essence, Accerciser is a next generation at-poke tool. ... ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Multilingual synthesis
Hi Tomas, all; At this point in the conversation perhaps it would be useful to mention the existing ATK , AT-SPI, and gnome-speech API features which might be used to handle automatic language switching. AtkDocument and AT-SPI's Document interface include a 'documentLocale' property, which can be used by AT clients to determine the 'default' locale of a document. Similarly, AtkApplication has a locale property which applies to the application instance (and thus the user interface). AtkApplication's locale is almost always known, via the POSIX locale setting. However as Tomas notes below, for Document instances the user agent cannot always determine the document locale reliably. If it can, then AtkDocument.getDocumentLocale should work fine. For those rare instances where UI components are in a different locale or lang from their host application, AtkObject.getAttributes() can be used to return either a lang or locale attribute for that object; AT clients should probably begin to check for the presence of such attributes. Within a document or textual element, AtkText provides text attribution and markup. Individual ranges of text can be marked with a lang attribute/value pair; this allows, for instance, the use of embedded foreign language expressions or words, or the proper TTS output for dictionaries or other mixed-language texts. I am not sure about what SpeechDispatcher provides in the way of language/locale capabilities for its various engines and voices, but gnome-speech has API which associates a voice with one or more locales for which it was designed. An AT client can query a gnome-speech service for voices matching a particular locale. VoiceXML/JSSAPI provide additional client APIs which may be useful for passing marked-up text to a TTS service; such text could include embedded language markup. Best regards Bill Tomas Cerha wrote: juan rafael fernández wrote: The scenario: --- A teacher of languages wants TTS in English, Spanish, German, French and Italian. Uses Spanish UTF-8 locale. I believe that such user requirement makes much sense even if you are not a language teacher. Many people read and write emails, documents or browse the web in more than just one language. As you noted, this is not a problem to use multiple speech engines on one system and speech APIs, such as Speech Dispatcher support switching languages on the fly. The question is, however, how to use this functionality within the user interface programs, such as screen readers, since most of the time we don't have the information about the language of the text we are working on. We must distinguish two distinct areas: * User Interface (texts provided by the software in use) * The document (or more generally any textual data we work with) The situation is usually quite good with the user interface. The language may be determined from the current locale and a properly localized system will have all the user interface in just one language. Deviations to this rule exist, but I think it is reasonable to consider them marginal. Still the best situation in the area of documents is with web documents. The language may (and should) be specified in document headers. We can also determine the language of each piece of text within the page, which is good for multi-lingual documents. The situations with e-mails is notably worse. As far as I know, there no language header widely used by current user agents. I also can't find a way to set a language for a document in OpenOffice.org, but this may be just my fault. I believe that the solution to this would be to: 1. Use the language information wherever possible 2. Provide a mechanism to switch the language manually Well, this was all just a theory. I don't know how is this problem addresed by screen reader developers, so I would like to join the question. What is the current situation and what is the plan? I am especially interested if Orca currently performs any kind of language switching and if there is anything I can do to support it in the Speech Dispatcher backend. Any comments to this are greatly appreciated! Best regards, Tomas ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Orca and minimalist X environments (was Re: accessible routers)
Jason White wrote:... Does Orca work in an X environment that falls short of a full Gnome desktop? Hi Jason; orca should work OK without having a gnome session already running. However, with recent changes to at-spi there is one caveat. Since the 'atk-bridge' no longer uses bonobo-activation to start the AT-SPI registry on-demand, some process needs to manually start at-spi-registryd before running an ATK/AT-SPI application. On most systems, running /usr/libexec/at-spi-registryd in an xterm before starting a Gnome app should do the trick. The exact path to at-spi-registryd may vary depending on your distribution. Best regards, Bill ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: java access bridge
George Kraft IV wrote: From the Orca, OO writer and terminal thread regarding the java access bridge for GNOME... As far as I can tell, none of the distros are providing a package of the java access bridge for GNOME. I believe some folks are running a JVM that they have obtained from somewhere, but are not accessible because they don't have an access bridge. Is there a strong enough justification to convince the distros to provide this package? Hi George: I'm not sure. If the distros start shipping the Sun JVM, then I think the Java Access Bridge for Gnome (JABG) should also be shipped. But the JABG may not work for all VMs, for instance some VMs don't provide the javax.accessibility packages on which JABG depends. I don't know about all VMs - those that provide Swing and javax.accessibility should theoretically work with JABG, and apps do require JABG in order to be accessible to assistive technologies on Linux/Unix. In any case the JABG could do with some dusting off and maintenance - IF distros and users start to make use of it. The recent license announcements/changes for the Sun JVM may have given this issue new life. Bill George (gk4) ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Orca, OO writer and terminal
Hi: java-access-bridge is not required by recent OpenOffice versions. I believe the dependency was phased out nearly a year ago. You will need to update your gnome-session if you have updated at-spi from CVS HEAD or the unstable 2.17 Gnome series, however. HTH Bill Jan Buchal wrote: WvdW == Willem van der Walt [EMAIL PROTECTED] writes: WvdW Hi, I do not seem to get any joy from running any open-office WvdW applications. I have checked, again, the GTK_MODULES variable WvdW is set correctly after doing a text-based login. I might be WvdW sitting with an old java access bridge though. Is java access WvdW bridge still required? If so, which version and from where WvdW should i download it? TIA, Willem No, is not required but some openoffice gtk package or something similar on debian. I'm not sure. I installed, installed and installed and at a time it worked. :-) Best ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Orca, OO writer and terminal
Willie Walker wrote: if I run OO writer from terminal then OO writer is not accessible. If I run OO writer from menu then works. Where is problem? Sounds like the GTK_MODULES environment variable might not be set, which is what is needed to enable accessibility in OOo. The GTK_MODULES value should be gail:atk-bridge. Note: The GTK_MODULES environment variable should be set by gnome-session; if it is not set, and you are running a Gnome desktop, then please file a bug against your distro's session manager. Best regards Bill If it's there, you should also see the following message in gnome-terminal when you run OOo: GTK Accessibility Module initialized Will ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GDM accessibility sans AT-SPI
Brian Cameron wrote: ... Rather than supporting magnifier, supporting themes with larger fonts or being able to simply increase and decrease the font in the current them via hotkey is probably better than supporting the half-screen magnifier. This is because gdmgreeter is not designed to use a STRUTS enabled window manager and this would be harder to get working with gdmgreeter than just being able to modify the font size. With the recent/upcoming availability (patch now available in bugzilla) of COMPOSITE-based magnification, the STRUTS issue is about to become moot; thus, no modification to gdmgreeter will be required in order to use fullscreen magnification at login time. Best regards, Bill ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GDM accessibility sans AT-SPI
David Bolter wrote: Hi Henrik, Henrik Nilsen Omma wrote: Brian Cameron wrote: I suppose it might be possible to code an on-screen keyboard directly into GDM, but this might be more work than you think. Note GOK supports dwell mode so that it works for users who can only manipulate a single button. Making an on-screen keyboard that supports the same sorts of disabilities that GOK supports might be tricky. I'm not sure what you mean by dwell mode here. In AT terminology that usually means making mouse clicks by hovering over an area. As far as I know GOK does not have this feature built i, but you can use KmouseTool. We should really get this built into X IMO. You may be thinking of switch operation, of which GOK has a much more advanced implementation than onBoard. GOK has a dwell access method, where access method is an expression for a way of navigating and activating keys on the on-screen keyboard. Yes; dwell method's target users can point but cannot readily click. For instance, some head tracker and eye-gaze users fall into this category. It can also be useful for certain other mobility problems in which click, while possible, is inadvisable (this last category of users is similar to the primary target use of KMousetool). As David infers, GOK does have pointer control which can be used in dwell mode, allowing a pointer only user to move and click the core mouse pointer (and do drag-and-drop operations as well, albeit slowly). Since the assumption is that GOK users are using a non-core pointing device, off-keyboard mouse clicks are current done by driving the core mouse pointer around the desktop via specialized gok keyboard keys. I think it would be a valuable addition to add a good Dwell core-pointer user mode to GOK sometime in the future. This is possible via XEvie, whereas in the past it was not technically possible. Bill ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GDM accessibility sans AT-SPI
Henrik Nilsen Omma wrote: Hi all, Another controversial post to g-a ... I'm currently looking at GDM accessibility and it strikes me that there is a strong case for doing this without using AT-SPI. The themed version currently does not work properly with the AT-SPI features and on the plain greeter version there is still a fair amount of configuration required. Actually by themed version you are referring to branding-type themes; the existing gdmlogin screen DOES work quite well with accessibility-related themes, for instance large print, high contrast, inverse, etc. etc. Both the AT-SPI framework and the assistive apps are complex things that will need some work to get working Just Right at the login. It also takes some time to load. AT-SPI is great for global desktop access since adding access to every single app would be silly. However, GDM is *not a desktop app* and also has a simple and predictable interface so it makes sense to look at other options. I've written a spec describing a login system with built-in access support. https://wiki.ubuntu.com/Accessibility/Specs/GdmAccessLite This may not be the right way to go but I think we should consider it before starting work on fixing the current model. I don't know what needs to be fixed in the current model. I also don't think it practical to try to build accessibility into the GDM greeter without allowing the use of assistive technologies, and the latter functionality clearly requires AT-SPI. As I see it, the accessibility issues and use cases at login are largely the same as the ones that apply when the desktop is posted. Therefore, the same fix (i.e. AT-SPI) is appropriate. Bill Henrik ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: eSpeak support in Orca -- what is the best way?
Lukas Loehrer wrote: Willie Walker writes (Re: eSpeak support in Orca -- what is the best way?): We recently looked at making a gnome-speech driver for eSpeak, but the main problem is that the eSpeak libraries have no facilities for sending samples to the audio device. Instead, it relies upon the application to manage the audio. I guess this is exactly why something like speech-dispatcher is a very good idea in the long run because it spares implementers of tts engines from dealing with the quirks of audio output architectures. Having written code for speech output with Alsa myself, I know this is not easy to get right, partly because low latency and instance interruptibility of playback is important in the tts scenario. Having this problem solved once and for all in a layer like speech-dispatcher will give people more time to focus on actual tts code. Not sure I agree - the model where the TTS engine delivers its sample to a third party for dispatch to the audio subsystem can increase latency, rather than reduce it. I do agree that there are other problems which such an architecture can avoid (for instance audio device contention). A key requirement is the ability to quickly stop an utterance. This can be difficult with multiple processes in the mix. A corrollary to this is the need for good progress/speech marker support, since in many scenarios one needs to know how much was actually spoken before the interruption took place. Bill Best rgards, Lukas ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: eSpeak support in Orca -- what is the best way?
Hi Henrik: Perhaps the most expedient solution would be to write a basic driver layer for eSpeak, initially with gnome-speech wrapper interfaces, with the intention of moving it to Speech Dispatcher later on. The basic APIs are I hope similar enough that only a modest amount of code would have to be discarded in the migration. Maybe I am being naive about the reusability of such code, but I would hope that if the author of a gnome-speech eSpeak driver read and reviewed the Speech Dispatcher API first, you could end up with most of the code being reused when moving to SD, while not 'blocking' on the SD RFEs from the orca team. I, too, would like to see orca and the rest of Gnome move to Speech Dispatcher, once the orca team's concerns are met. Regards, Bill Henrik Nilsen Omma wrote: Hi all, I've been working with Gilles Casse of Oralux on a spec for better multilingual speech support in Ubuntu, and as it happens, the crux comes down to support for eSpeak in Orca. Let me explain ... The aim of the MultilingualSpeechSynthesis spec is to extend our current provision to synthesised speech in multiple languages right on the CD. That is not possible with Festival because the voices are too big, but should be possible with eSpeak. See: https://wiki.ubuntu.com/Accessibility/Specs/MultilingualSpeechSynthesis We also plan to improve the speakup support on default systems and Live CDs using eSpeak, which fits in well with the added language support. However, the main focus of the Live CD is still going to be the Gnome GUI. So we have to support both interfaces, and we want to do it with the same speech synth to avoid duplication. But we won't move the Live CD from Festival to eSpeak until we are confident that there is good support for eSpeak with Orca. (btw, many people will still prefer Festival or other synths and we should have good support for those and make sure installing and setting up is easy) I know I'm probably stirring up a old debate when I ask what the best way to do that is. I guess there are two options: * Write a gnome-speech driver for eSpeak -- How much work is involved with this? Gilles says he is willing to start on this. * Speech Dispacher support for Orca -- I know there have been issues raised about this before. Some missing features are mentioned here: http://live.gnome.org/Orca/SpeechDispatcher -- Using the Orca - gnome-speech - SpeechDispatcher - eSpeak chain is not really an option for a stable release I think. I'm not really technically qualified to have a firm opinion about which route is best or easier to implement. I simply note that a solution is a prerequisite for the multilingual Live CD and the enhanced speakup support. In principle I'm a fan of the speech dispatcher approach because I feel it open up more options for the future such as Orca running on KDE, but if the missing features there mean holding up a spec like multilingual support for a cycle or more then I'd like to consider alternatives. I've made a spec describing what we need and briefly mention the two options. https://wiki.ubuntu.com/Accessibility/Specs/OrcaEspeak Another question is whether eSpeak itself is feature complete enough (does not support asynchronous calls ATM AFAIK), but this is mediated by the ability to install Festival or something else post-install. I do wonder how the user community would react to a sudden switch of default synth though. Thoughts? Discuss :) Henrik ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: yelp gok hack?
David Bolter wrote: Hi All, Yelp has a function called timeout_update_gok. This sounds like a temporary stop-gap that might have been forgotten. Ideally should the fix should be in mozilla (if not already)? http://www.google.com/codesearch?q=file%3Ayelp+timeout_update_gokbtnG=Search+Code Can anyone shed any light on this? Yes - as the comment above the code indicates, there was a missing event from mozilla when yelp loaded new content into an existing mozembed widget. Basically mozilla wasn't emitting an event that gok could use to detect the fact that the onscreen help contents had changed. Without that event, gok didn't refresh its UI Grab keyboard when viewing help. I agree that this may have been forgotten - possibly the Firefox 3 work has fixed it, but I think we'd need to examine the event stream from a Firefox-3 gtkmozembed widget (i.e. from yelp) to be sure. regards Bill cheers, David ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Orca on laptops.
Hi Will; I think this is basically what I and other contributors meant by remapping CapsLock. I would consider using the XKB client API for this instead, in case xmodmap is not in the path (anyhow, I think XKB is the preferred interface for modifying the keyboard map on XKB-aware systems). Some of the XKB client settings also allow clients to tell the Xserver to reset to defaults when the client exist, which would make the restoration of 'normal' CapsLock behavior robust even if orca were killed with Ctrl-C or crashed - not sure if the key-remapping APIs are among those - perhaps you do, since I recall you having participated in the development of XKB :smile: Bill Willie Walker wrote: Hi All: I've been watching mostly from the sidelines because I wanted to hear from our users before injecting my opinions and such (except mainly for expressing the opinion that I want to hear from our users ;-)). What I'm hearing is that using the Caps_Lock key as the Orca modifier key is an absolute requirement and we should do what we can to make it happen. I believe the main problem with the Caps_Lock key is not if we can use it as the Orca modifier or not. We can. The main problem, however, is that once the user touches the Caps_Lock key, the Lock *modifier* will still be locked and unlocked. This presents a serious usability problem. I did little experimenting, and I believe we have a simple solution for this problem. Having worked on the X Window System since the late 1980's, I'm not sure why this didn't come to me earlier. The X Windows System offers a command called xmodmap that allows you to muck with modifier mappings. For example, the following command will prevent the Caps_Lock key from acting as a locking key: xmodmap -e clear Lock And, for those that want their Caps_Lock behavior back, the following command restores it: xmodmap -e add Lock = Caps_Lock We can use this to solve our problem. When Orca starts up, it can check the orcaModifierKeys setting. If the list includes Caps_Lock, Orca can execute the magic xmodmap command to clear its locking/unlocking behavior. The only issue here is cleanliness and restoring the xmodmap to what it was before Orca changed it. I'm not sure this is a big concern. The reason is that I assume Orca is going to be something that the user runs all the time to access their Desktop. Attached is a patch to orca.py from GNOME CVS HEAD for anyone wants to play around with this. You'll need to apply this patch (patch -p0 caplock.patch) and you'll need to add/edit the following line to your ~/.orca/user-settings.py (can get blown away) or your ~/.orca/orca-customizations.py (will not get blown away) file: orca.settings.orcaModifierKeys = ['Caps_Lock'] Btw, you can also do the following if you want both Insert and Caps_Lock as the Orca modifier key: orca.settings.orcaModifierKeys = ['Caps_Lock', 'Insert', 'KP_Insert'] Let me know if this works for you. If it does, we can make it a permanent part of Orca. Will On Thu, 2006-11-09 at 09:48 +, Bill Haneman wrote: Makes sense, with the caveat that if we remap CapsLock to achieve this (as we probably must, to avoid the latching behavior), then the end user will no longer be able to use CapsLock in the normal way. Probably that is not a significant issue for 99% of the users. I agree with Will's point that we should be thinking user-centrically in most of our discussion; however the point I made about remapping being more intrusive as a technique still applies. The use of CapsLock is, as Will pointed out in an earlier email, somewhat less clean and ideal technically than using some other modifier key. This is because, unlike the other keys, use of CapsLock is inherently modal (changes the X keyboard state in a sticky way) unless the CapsLock key is re-mapped to some other X keyboard symbol. Bill Janina Sajka wrote: Bill Haneman writes: Thanks Will. That clarifies things somewhat - we're using the term modifier key differently. Maybe I'll contact you offlist for info on the internal details. So does that basically mean this whole discussion of orca on laptops is moot, or at least addressed fully via orca.settings.orcaModifierKeys (possibly with a UI for changing it easily) ? Bill I shouldn't think so. This discussion has already pointed out that CapsLock is the established default modifier for JFW users on Windows and for Speakup users on Linux. Furthermore, it is reasonable to expect that no new application is likely to adopt CapsLock for it's own uses, i.e. we run the least risk of conflict both today and tomorrow by defaulting to CapsLock as the default Orca laptop modifier. Of course, the fact that this is established practice and widely expected by users both on Windows and Linux should really end this discussion, from the user point of view
Re: Orca on laptops.
lazzaro wrote: I use the Capslock key as a modifyer instead of insert all the time with Jaws on laptops, and I like how it's implemented there. It appears to work with the capslock key latched or unlatched. CapsLock always latches, in every keyboard I've encountered (i.e. that's why it's called Lock) - not sure what you mean here by an 'unlatched' CapsLock key? Bill ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Accessability Interfaces
Ian Pascoe wrote: Hi all Some thoughts that have been kind of troubling me over the past. There have been various postings in the past about compatability , or lack of it, with various applications. The most notable being that of Firefox just recently. In my ignorance, should the community be aiming to get those projects that run and maintain development languages to provide the necessary interfaces in the output so that the wheel doesn't need to be re-invented each time for the application development projects? Firefox is using ATK as its accessibility interface (or, rather, it is including ATK as its exported accessibility interface on Linux/Unix/Solaris). Because Firefox is cross-platform, and also needs to speak MSAA on the Windows platform, is uses a different accessibility interface based on something called nsiAccessible internally. However, by design, nsiAccessible maps rather well onto ATK, and ATK has been a major influence in the evolution of the mozilla-specific nsiAccessible interface. To clarify - ATK itself is available on Windows, but it not a standard part of a Windows installation, so in that respect ATK is already cross-platform. However, existing Windows assistive technologies use a mixture of Microsoft's MSAA and proprietary interfaces to do their job, so Firefox needs handle the export of its accessibility info differently on the two platforms. On Linux/Unix/Solaris, the information is exported via ATK. OpenOffice.org also uses ATK as its accessibility interface now. ATK is an in process interface, so in order for the ATK information to be available to assistive technologies it must be exported via some interprocess communication technology. AT-SPI is the standard interface for this, and a component called atk-bridge takes care of the details of turning in-process ATK calls into their equivalent AT-SPI equivalents. I am aware that this is a GNOME list, but is the basic API used to drive accessability the same that other projects are using or is it GNOME specific? In the above sense, this technology is not Gnome specific, since the same technique is used for Firefox, OpenOffice.org, and some other components such as recent RealPlayer and (I believe) recent versions of the Acrobat PDF reader. However, the existing atk-bridge does rely on some gnome technologies, i.e. it uses Gnome libraries which are present on most distributions but may be missing from some distros, for instance some KDE-centric distros. KDE 4 is planning to support AT-SPI, but they wish to do so without using Gnome libraries or CORBA. This will take some effort to sort out, since it means sacrificing binary compatibility with existing AT-SPI implementations. I know they wish to do this in a way that preserves the functionality of existing AT-SPI clients like orca, LSR, GOK, Dasher, gnopernicus, as much as possible, but it is not clear when this work will be readily available. Lastly, are the accessability modules like Orca specific to GNOME or will they work cross GUIs? I ask only out of curiosity as I'd like to try out a few of the mainstream, and some of the backwater distros that are out there. In theory orca could work with any distro which provides the necessary dependencies, and can work with other GUIs as well; however the distros need to do the work to make sure the necessary components are bundled and tested. ATK is not bound to any specific GUI toolkit - while it is a dependency of GTK+, it does not require GTK+ in order to work, so any GUI toolkit is free to implement ATK as Firefox and OpenOffice.org have done. Best regards, Bill Ian ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Orca on laptops.
Luke Yelavich wrote: ... In Windows, Jaws manages to prevent the capslock key from being latched or unlatched. To latch/unlatch, you press shift + Capslock, or press capslock twice quickly. I see. I expect that would be a hazardous and/or fragile thing to attempt on X, especially if, as I believe, the latching behavior is a hardware feature on some (most?) keyboards. On Windows you could circumvent this by meddling with the keyboard drivers, but I think we want to avoid getting that intrusive. So we should probably consider CapsLock to be an always-latching key, IMO. Bill ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Accessability Interfaces
Steve Lee wrote: Out of interest do assistive technologies (AT) get to use an API or library (similar to ATK for the server applications) or do they use direct CORBA calls? They use CORBA bindings, which on the client side are usually fairly straightforward. For instance, the python AT-SPI bindings are just python methods on python objects.The only place where the client needs to implement any CORBA methods is in the event listener interface, which is pretty small (one method). AT is very unlikely to use a particular GUI for any UI they present as that UI has to be accessible. What do you mean by this statement? Most ATs are using the same mechanism for enabling the accessibility of their own APIs as other apps on the desktop; e.g. orca's GUI uses pygtk, and thus appears like any other accessible app. Bill -- Steve Lee www.oatsoft.org http://www.oatsoft.org www.fullmeasure.co.uk http://www.fullmeasure.co.uk On 11/8/06, *Bill Haneman* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Ian Pascoe wrote: Hi all Some thoughts that have been kind of troubling me over the past. There have been various postings in the past about compatability , or lack of it, with various applications. The most notable being that of Firefox just recently. In my ignorance, should the community be aiming to get those projects that run and maintain development languages to provide the necessary interfaces in the output so that the wheel doesn't need to be re-invented each time for the application development projects? Firefox is using ATK as its accessibility interface (or, rather, it is including ATK as its exported accessibility interface on Linux/Unix/Solaris). Because Firefox is cross-platform, and also needs to speak MSAA on the Windows platform, is uses a different accessibility interface based on something called nsiAccessible internally. However, by design, nsiAccessible maps rather well onto ATK, and ATK has been a major influence in the evolution of the mozilla-specific nsiAccessible interface. To clarify - ATK itself is available on Windows, but it not a standard part of a Windows installation, so in that respect ATK is already cross-platform. However, existing Windows assistive technologies use a mixture of Microsoft's MSAA and proprietary interfaces to do their job, so Firefox needs handle the export of its accessibility info differently on the two platforms. On Linux/Unix/Solaris, the information is exported via ATK. OpenOffice.org also uses ATK as its accessibility interface now. ATK is an in process interface, so in order for the ATK information to be available to assistive technologies it must be exported via some interprocess communication technology. AT-SPI is the standard interface for this, and a component called atk-bridge takes care of the details of turning in-process ATK calls into their equivalent AT-SPI equivalents. I am aware that this is a GNOME list, but is the basic API used to drive accessability the same that other projects are using or is it GNOME specific? In the above sense, this technology is not Gnome specific, since the same technique is used for Firefox, OpenOffice.org, and some other components such as recent RealPlayer and (I believe) recent versions of the Acrobat PDF reader. However, the existing atk-bridge does rely on some gnome technologies, i.e. it uses Gnome libraries which are present on most distributions but may be missing from some distros, for instance some KDE-centric distros. KDE 4 is planning to support AT-SPI, but they wish to do so without using Gnome libraries or CORBA. This will take some effort to sort out, since it means sacrificing binary compatibility with existing AT-SPI implementations. I know they wish to do this in a way that preserves the functionality of existing AT-SPI clients like orca, LSR, GOK, Dasher, gnopernicus, as much as possible, but it is not clear when this work will be readily available. Lastly, are the accessability modules like Orca specific to GNOME or will they work cross GUIs? I ask only out of curiosity as I'd like to try out a few of the mainstream, and some of the backwater distros that are out there. In theory orca could work with any distro which provides the necessary dependencies, and can work with other GUIs as well; however the distros need to do the work to make sure the necessary components are bundled and tested. ATK is not bound to any specific GUI toolkit - while it is a dependency of GTK+, it does not require GTK+ in order to work, so
Re: Accessability Interfaces
Hi David, Steve: I think there are two aspects to Steve's question. One aspect has to do with the exact API call syntax that the client uses to access AT-SPI, which I think is what you are referring to. The raw C CORBA bindings are a bit ugly (while the python ones are elegant) but don't actually require the client to add any CORBA-specific code. The second aspect of the question is the one I was addressing - whether the client needs to know much about CORBA details. That also depends a little on the client's programming language, but mostly the answer is no, the only place where the AT-SPI client has to write any CORBA code is when it's implementing the AT-SPI EventListener interface which it passes to the AT-SPI Registry, via which the client receives event notifications from running applications. best regards Bill David Bolter wrote: Hi Steve, The at-spi hides nasty stuff like CORBA behind an API. In early days we used the cspi bindings (for C), but we should all now use the normative C library libspi. I imagine you are most interested in python bindings -- which I haven't used (yet). Note, gok hasn't migrated from cspi to libspi yet (blush). cheers, David GOK Maintainer Steve Lee wrote: Out of interest do assistive technologies (AT) get to use an API or library (similar to ATK for the server applications) or do they use direct CORBA calls? ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Orca on laptops.
Hi Benjamin: I see, you're talking about a different thing from what I was referring to - I thought you were talking about the CapsLock behavior settings, which are all latching. What you have done, as far as I can tell, is re-map the CapsLock key to be a different key altogether - so it's no longer CapsLock from the Xserver or keymap point of view. Using XKB and similar APIs we can alter an existing keymap, remapping pretty much any key to pretty much any other keysym; similarly, there are pieces of the XKB API that would allow us to implement almost any behavior we want; however, this would be at the cost of complexity both in orca and in testing/verification. I think we should be careful to distinguish between using/adapting the behaviors of the existing key symbols in existing keymaps, and altering those keymaps fundamentally. In your example of re-mapping CapsLock to Compose, I would suggest that CapsLock no longer exists in the keymap and so it is potentially confusing to refer to this key as CapsLock in our discussions. It does, however, point out the potential for using remapping to create any key via remapping, even for physical keyboards that don't include that key in their default printed key set. For instance, the keymap alteration technique above could be used to provide AltGr on Calum's iBook even though the default keyboard map doesn't include it, and there is no key labelled AltGr on the physical keyboard. So for instance if we decide that right shift should do something special in orca, we could use remapping to assign XK_shift_right to any physical key we chose. This means of course that the original use of the key in question would no longer be available, just as in Benjamin's example the CapsLock key no longer affects the 'ShiftLock' modifier; in effect CapsLock ceases to be available in such a scenario. Best regards, Bill Benjamin Hawkes-Lewis wrote: On 11/8/06, Bill Haneman [EMAIL PROTECTED] wrote: I don't see that option in the preferences dialog - you can indeed alter the way CapsLock works, and whether the Shift key cancels CapsLock or not, but it seems to be a latching key in all cases, as far as I can tell. Just tested it on my Ubuntu Edgy box, and as far I can tell you're mistaken. In Keyboard preferences, look for the Layout Options, then Compose key position. Now I have a British Thinkpad keyboard. If I tick Right alt is compose then pressing [AltGr] + ['] (that's apostrophe) then [e] outputs an e acute. But let's say I tick Caps Lock is Compose. Now two things happen. First Caps Lock no longer affects capitalization. And second, it acts just like [AltGr] before. If I press [Caps Lock] + ['] then [e], it outputs an e acute. But pressing [Caps Lock] then ['] then [e] outputs an apostrophe then a normal e. Doesn't that imply it is no longer latching? -- Benjamin Hawkes-Lewis ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Orca on laptops.
Rich Burridge wrote: Orca doesn't care what kind of key it uses for its modifier key. It can be anything. Yes, but I think there is some agreement that finding a reasonable default modifier is a worthwhile goal. Bill If anybody wants to try using CapsLock to see if they are more comfortable with it, then you can adjust the orca.settings.orcaModifierKeys line in ~/.orca/user-settings.py to: orca.settings.orcaModifierKeys = ['Caps_Lock'] ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Orca on laptops.
Thanks Will. That clarifies things somewhat - we're using the term modifier key differently. Maybe I'll contact you offlist for info on the internal details. So does that basically mean this whole discussion of orca on laptops is moot, or at least addressed fully via orca.settings.orcaModifierKeys (possibly with a UI for changing it easily) ? Bill Willie Walker wrote: Hi All: I don't think there's a need to map an existing X modifier to the Orca modifier. Orca invents its own modifier internally and allows any key to act as the Orca modifier. That's why Insert and KP_Insert can act as the Orca modifier key. As such, I'm not sure which modifier is an important discussion to have. Will ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Orca on laptops.
Samuel Thibault wrote:
Bill Haneman, le Tue 07 Nov 2006 20:15:53 +, a écrit :
AltGr is one that often gets forgotten; what about that? It does appear
to be a modifier key on all the systems I am aware of.
Yes, but it's widely used for typing ~, #, {, [, |, `, \, ^, @, ], },
€, «, », œ, æ, ß, ...
Agreed, but doesn't orca use arrow keys for many of its functions?
I know there are lots of keys which AltGr doesn't appear to do
anything with.
Bill
Samuel
___
gnome-accessibility-list mailing list
gnome-accessibility-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Orca on laptops.
Luke Yelavich wrote: ... Well I don't think that will be an option, as some laptops don't have a right Alt, as far as I am aware, or I could be getting that mixed up with the right control key. I think you might have that confused, yes. Any non-English laptop would need AltGr for the reasons Samuel mentioned. I think it might be worth looking at a few examples key layouts for AltGr in different european languages, to see how significant the potential conflict Samuel mentions actually is. We do have the reality, currently, that orca only really works in languages for which we have text-to-speech voices and/or braille tables (and I think we have more of the latter than the former, at the moment). (I think GOK can be used as a quick check for this, BTW; if you change your keyboard layout, bring up the 'Compose' keyboard, and press AltGr, GOK should display the relevant characters.) Bill ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Orca on laptops.
Joanmarie Diggs wrote: Hi Bill. I am not sure I understand your point - or perhaps you are misunderstanding me. I suspect it's the former, but we'll see. :-) What I am suggesting is that we specifically _avoid_ using ShiftLock And what I am suggesting is that we specifically _allow_ using it (if possible). (which is generally a troublesome 'modifier' anyhow, because it always has latch behavior, i.e. toggles between on/off with successive keypresses). I did wonder about this. I do know that in some Windows AT products, ShiftLock is used as a modifier key. How they went about accomplishing this, however, I couldn't tell you. Sorry if this sounds complicated, I am not sure how to put it more straightforwardly. I think you're putting it quite straightforwardly, and I apologize for not doing the same. If you'll permit me to try again: What I would like to avoid, if possible, is the need for loopholes and work arounds. I *very rarely* use ShiftLock when I type, and I *very frequently* rely upon shortcuts, access keys, etc. Therefore *for me*, having ShiftLock as a possible modifier makes sense. Having it become the additional key that I need to press in order to be able to use existing shortcuts, access keys, etc. sounds like an excellent reason to purchase an external keypad. :-) Hi Joanie: I understand your point now, and you made it clearly, thanks. I think it comes down to how one uses the orca modifier or shortcuts. If one's orca use is highly modal, i.e. one tends to stay in orca mode or pure keyboard mode, then the latching behavior of ShiftLock could be an advantage, and I agree that it would make a useful modifier in that scenario. On the other hand, if the user model is less modal, and the user is frequently interspersing single orca commands within a stream of normal application keynav, the ShiftLock latching behavior would be a big annoyance. I think that flat-review tends to be modal, i.e. you're either in review mode or you aren't, where as many of the other orca commands may be less so. I'll leave it to the orca designers and users to figure out where the balance lies. If you do find that some features are rather modal, there are two other latching keys available on many, but not all, keyboards, including laptop keyboard - NumLock and ScrollLock, so they may end up figuring into the discussion as well; in my experience NumLock can be either Mod3 or Mod4 in the Xserver modifier mask, depending on the X server implementation. (I am not sure ScrollLock actually appears in the modifier mask at all) regards, Bill Thanks much for your explanation! Take care. --Joanie ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [Kde-accessibility] Gnome-braille.
Samuel Thibault wrote: Bill Haneman, le Thu 19 Oct 2006 00:19:04 +0100, a écrit : Sorry, following up on my own email: The unicode methods we use (we need these or their functional equivalents): (easy ones first) g_ucs4_to_utf8 g_utf8_strlen g_utf8_offset_to_pointer g_utf8_get_char g_utf8_next_char g_unichar_to_utf8 g_utf8_validate iconv should be fine for this Actually, I don't think so - it doesn't include offset_to_pointer functionality AFAICT, nor character iteration. libicu has this I think (now the hard ones...) g_unichar_break_type g_unicode_canonical_decomposition libicu should be fine for this. I wasn't too impressed when I last used ICU but that was awhile back. We don't need great speed/performance here so it may work; I'll have a look. Bill Samuel ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Ubuntu 6.0.6.1 Install
Hi Ian! Ian Pascoe wrote: Secondly, and I think this relates to Gnupernicus as opposed to Orca although by this stage we were getting quite confused, there are lots of spin boxes relating to the different talk rates for different controls - could this be hidden behind an Advanced tab and have maybe one or two that effects all the options? Try using orca. I think you'll find the user interface less confusing. As for Orca, again I think, we noted that if the check box relating to key echo was unticked Orca stopped responding. More than likely, because you have used a Xubuntu base with self-installed orca and gnome, your assistive technology support is not turned on in your desktop. There's a GUI for this, but try (from a terminal window while running gnome, or from a console window, BEFORE gnome is started: gconftool-2 -type bool -s /desktop/gnome/interface/accessibility true This should allow orca (or gnopernicus) to do something besides echo keystrokes. The magnifier is usually intended for use with/by an integrated screen reader, i.e. gnome mag is a service which orca and gnopernicus use. Fullscreen magnification requires some rather messy reconfiguring of your X server (an upcoming version of gnome-mag will improve this situation). Directions for doing this and for using many accessibility features of the gnome desktop are found at the location below (note that the fullscreen mag directions are in an appendix at the end, I believe). The document is a little out of date since it talks about gnopernicus and not orca, but most of the information is still relevant and correct. http://www.gnome.org/learn/access-guide/latest/ Lastly, note that Firefox 2 accessibility is pretty limited with orca, but I have been told that Firefox 3 beta versions, while perhaps a bit unstable, are _much_ more accessible via orca. best regards, Bill Lastly, relating to Gnome Mag, can someone point me to the URL for directions on it's use please? In particular looking for activating full screen magnification, colour inversion to read white on black, together with associated keyboard shortcuts. It looks fun from what little I can see but at the moment frustration is high as I can't do anything much with anything! Many thanks Ian ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Gnome-braille.
Samuel Thibault wrote: As discussed a few months ago, gnome-braille depends on - libgobject for contraction/language module management - libglib for tricky stuff like unicode handling. I don't have any objection to reworking this to remove GObject, but it makes no sense to do that without removing the glib dependency as well. The problem with removing glib is that gnome-braille needs very sophisticated unicode support, which is much harder to come by that one would think. If we have a fully desktop-agnostic unicode library alternative then I'd be happy to work on swapping out glib/gobject. The other problem though is that gnome-braille is very modular/object-oriented and trying to do nice lifecycle management in C without something like GObject is not much fun. So what does gnome-braille do that BriAPI and libbraille don't already do? Well, it provides an extremely general pluggable/chainable conversion API (so that very complex braille conversions can be done, like all sorts of Grade2 and Asian language braille), multi-lang/multi-locale braille, optional braille context switching markers, and some other localization stuff. Also, it provides a bidirectional mapping between braille cell offsets and character/glyph offsets throughout, so you always know what braille cell corresponds to which character offset in the input string. As far as I know, these are things that the other APIs either don't offer or have difficulty with. gnome-braille also supports several sorts of hardware and software events, and both hardware and software regions within a braille display. This is all stuff that probably isn't urgent for our English braille users _yet_, but which I think will become increasingly important as we get the more fundamental platform stuff working well. While I wrote gnome-braille as a testbed initially, it'd be very nice if we could morph it into something everybody could make use of. It already has support for about 40 languages including some exotic stuff like Devanagari/Hindi and Kanji Japanese braille; it also has a simple Grade2 English engine. Best regards, Bill Else it can be used in any application, the output being done either via BrlAPI or libbraille (or a gtk fake braille device) Samuel ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [Kde-accessibility] Gnome-braille.
Sorry, following up on my own email: The unicode methods we use (we need these or their functional equivalents): (easy ones first) g_ucs4_to_utf8 g_utf8_strlen g_utf8_offset_to_pointer g_utf8_get_char g_utf8_next_char g_unichar_to_utf8 (now the hard ones...) g_unichar_break_type g_unicode_canonical_decomposition g_utf8_validate If anyone has a small library that we can use in common for this, I'm all ears. regards, Bill ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Open Source OCR
Luke Yelavich wrote: On Tue, Oct 17, 2006 at 03:21:17AM EST, Bill Haneman wrote: Hi Folks: I just downloaded, built, and tested this OCR engine. It is really pretty good, and it was very easy to build. At the moment it is a bit limited (requires TIFF format, 8 bit depth, and doesn't understand columns etc.) but the limitations don't seem to be in the engine, only in the bells and whistles. As far as I understand it, part of the source is not actually open source, so it can't be packaged for distribution afaik. The non-open-source part is no longer actually used, it's just dead code (according to docs). The aspirin/MIGRAINE directory is the one that contains this no-longer-used, non-free code, I am told. So it can be stripped out and the result redistributed at will. Bill ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Fwd: others?Fwd: Open Source OCR
Krister Ekstrom wrote: On Mon, 2006-10-16 at 15:26 -0400, David Poehlman wrote: there is also GOCR and Ocrad which are open source. I haven't tested any of those, but at least as it sounded from the description of GOcr, it didn't support columns nor fonts. I don't know how this affects for example the recognition of text documents and a11y and so on, but it doesn't sound ... ahem good. Please correct me if i'm wrong somewhere. and a question, is there any way to control OcrAD from within Gnome other than from a terminal? The ocr engine is the important thing. The gocr engine, at least, has been described as not sufficiently powerful for our needs - whereas the tesserect engine seems to be pretty good. If the engine is good, and freely licensed, then adding things like column support is not that difficult (compared to writing a new/better engine from scratch). While there may be some debate about the GPL-compatibility of the Apache license, it looks to be 'Debian-free' to me. There is some non-free code that needs to be removed, as Luke noted, but it seems not to be used at all in the existing tarball, it's just leftover vestigial code. regards Bill /Krister ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Linux desktop accessibility demo - which programs should I install
That's interesting Tomas; Will Walker of the orca team seemed to think the problem was in Speech Dispatcher itself (as of last week). Perhaps you would contact him about it? Bill Tomas Cerha wrote: Bill Haneman napsal(a): The SpeechDispatcher API has some limitations which make the user experience with orca a little less nice - as I understand it, SpeechDispatcher doesn't support completion/progress tags within an utterance, it can only tell you when an entire utterance is complete. Not really. This limitation only applies to the current Orca backend for Speech Dispatcher. Speech Dispatcher itself supports index marks which are exactly for this purpose. Best regards, Tomas. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Open Source OCR
Hi Folks: I just downloaded, built, and tested this OCR engine. It is really pretty good, and it was very easy to build. At the moment it is a bit limited (requires TIFF format, 8 bit depth, and doesn't understand columns etc.) but the limitations don't seem to be in the engine, only in the bells and whistles. I think it could prove to be very useful for certain accessibility applications. Of course in a more perfect world we would not need to do OCR at all... best regards, Bill Steve Lee wrote: It was noted at the Accessibility Summit, http://tinyurl.com/uqen3, that a high quality FOSS OCR is needed and I remember reading earlier that Google have OSed Tesseract. http://www.linux.com/article.pl?sid=06/09/18/191251 It's on a Apache 2.0 License. -- Steve Lee www.oatsoft.org www.fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Linux desktop accessibility demo - which programs should I install
The SpeechDispatcher API has some limitations which make the user experience with orca a little less nice - as I understand it, SpeechDispatcher doesn't support completion/progress tags within an utterance, it can only tell you when an entire utterance is complete. While I hear that espeak's quality is quite nice, that may be outweighed by this limitation. Many end-users seem to prefer DecTalk for quality of speech over our current free alternatives, and there's a gnome-speech driver for it that supports progress markers. Will Walker or Mike Pedersen will know more about the details. regards Bill Lorenzo Taylor wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rather than a commercial speech solution, I would recommend eSpeak at http://espeak.sourceforge.net It works with speech-dispatcher and is Free and Open Source. It also sounds a lot better than Festival and is in most cases better than either DECTalk or IBMTTS, especially the female voice. Unfortunately, Orca in Ubuntu doesn't currently support speech-dispatcher except through gnome-speech, and the speech-dispatcher driver for gnome-speech may or may not be available in Ubuntu. Someone clarify this for me. I'm not sure either if eSpeak is available in Edgy, although I did read something to indicate that it is. HTH, Lorenzo - -- I've always found anomalies to be very relaxing. It's a curse. - --Jadzia Dax: Star Trek Deep Space Nine (The Assignment) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFM/+NG9IpekrhBfIRAp/nAKDCN0nLYPlLCPZwsEjuCecYWaICsACfYTaX wG7CyrfFzylBZOCSSDi1YMA= =I0gK -END PGP SIGNATURE- ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Accessibilty module for colorblind people
Hi Daniel: Colorblindness is certainly one of the more common issues that impact the usability of our visual interfaces. It's great to have you onboard to help make our desktops more usable. Enhancements that support colorblindness usually work in one of two ways; firstly, themes are provided to select a color and contrast environment that suits a particular user's color perception. The second way that colorblindness can be addresses is via filtering the entire desktop - this is usually done in magnifier software, at least in the Windows world. The screen might be magnified at 1:1 ratio (i.e. no actual enlargement) but re-colored when presented onscreen. On the Gnome (and KDE) desktops we have a problem with using themes for this - we need more colors in our themes, so that applications don't hard code colors for things like pie charts and other graphics. (Hard-coding colors is already something that is considered an accessibility violation, but we need more colors in our themes in order to give applications a reasonable alternative). Once we do this, I think we would actually have better visual results that what we can easily achieve by re-coloring or transforming the color space of our user interface - for instance, color transformation which might work well to make a pie chart more readable could make a photo really awful and distorted. So in that respect I think enhancements in the theme space would be very beneficial and might be the top priority. Re-coloring the entire screen makes sense in some situations (but can produce ugly or unpleasant results sometimes). As Carlos has said, we have a magnification service built into Gnome already (KDE also has a magnification utility), and I tend to think this is the best place to put recoloring utilities for this second approach to color customization. The COMPOSITE extension looks to me like the best way to achieve this - which is another reason for doing it in the magnifier, since otherwise our colorblindness support would conflict with magnification. The idea of making recoloring and magnification both be modular compositing manager plug-ins makes a lot of sense; however I think it may take some time to come up with an API for it that actually works for all the kinds of transformations and rendering changes we will want to do. We also would want to avoid conflicts between, for instance, a theme for deutanopia and a compositing filter for the same. If the recoloring code was written as a plug in for gnome-mag, without explicit Gnome dependencies, then other projects like KDE could use it too, and it could also be applied to images instead of the whole screen, which seems like a good thing to me. Best regards, Bill Daniel Ruoso wrote: Hi, I am colorblind. This problem doesn't cause much trouble, so it's not something that really makes the computer useless without an accessibility software. It would be better if everyone could take that into consideration before drawing a chart, but unfortunally that isn't always true. Sometimes a chart uses brown-green, purple-blue combinations which are just useless for my type of colorblindness. Here is my plan so far: 1) Create a library with a set of predefined color filters usefull for colorblinds, for instance: * selective red saturation: This would take colors where red is one of the dominants (except gray) and would saturate it to the maximum. So people with problem in the red cones can differentiate brown from red and purple from blue. Example: #00 becomes #FF5500. * selective red dessaturation: This is the inverse of the above. Example: #00 becomes #005500. * Hue shift This would displace the hue, preserving saturation and value. Example: #00 becomes #00. * monocrome This would take a base color and turn all the others to greyscale. 2) Integrate it with the desktop in a way that I press a keystroke and activate my default filter with the default settings. Or use a window button (at the side of minimize, for instance) to get to a filters menu where I can activate any other filter at any time in any window. This way, when seeing a chart with dubious colors I could just press the keystroke to read the chart and then press the keystroke again to continue using the software (or continue to using it with the filter active). 3) Have a accessibility configuration which would perform the ishihara test for those who doesn't know which time of colorblindness they have indicating what filter would be the most usefull in most cases (for example, the selective red saturation for mine colorblindness but probably selective green saturation for other type and so on). Here is what I did so far: For now I have the base library (still not in some public place just because I still didn't found one. But the license will be public domain.). I already have 3 functional filters. The
Re: Accessibilty module for colorblind people
Hi Henrik: What he said You and Carlos put this very well. I agree with you both that this sounds like a great thing to add to gnome-mag. By the way, Carlos has recently done some very nice work to enable fullscreen magnification without requiring two X screens, so based on this new work (still in bugzilla, but soon to be in cvs we hope), this could be done pretty elegantly at 1:1 without noticeably changing the user experience. Best regards Bill p.s. - gnome-mag magnifies at '1x' if you run it with -z1. To use this in fullscreen mode without changing your Xorg.conf will require Carlos' patch to http://bugzilla.gnome.org/show_bug.cgi?id=348375. Henrik Nilsen Omma wrote: Daniel Ruoso wrote: I think that these filters could be implemented easily in gnome-mag. Probably Bill and Willie can give more advices about it. The question is that colorblindness filters aren't exactly related to screen magnifier. I'm colorblind, but I don't need a screen magnifier. Perhaps not in your case, but there is a lot of potential overlap. gnome-mag manipulates the screen image real time (and has a simple inverse mode) which the filters also do. I'm sure gnome-mag could be set to 'magnify' at 1x. Some people would want to use both magnification and a filter. Separate implementations may still be the best option for technical reasons or to have simpler configuration of each. But in that case they should at least work well together. Henrik ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Which programs are you using?
Peter Parente wrote: Hi Anna, Perhaps starting a page on the http://live.gnome.org wiki would be a good idea? I'd like to see an Accessibility wiki page (pages, but at least a starting page), particularly for projects like this. Great idea, and past time to do it I agree. Bill That way, as people use Orca, LSR, and other ATs/test tools, they can share what works and what doesn't for them. If people come up with workarounds, they can also post those and later remove them as accessibility problems are fixed. The nice thing about the wiki is that it's editable by anyone, unlike the developer.gnome.org pages. Pete ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Java-access-bridge-1.6.0 errors
Hi Luca:
Sorry not to have replied sooner. Thanks very much for the bug report.
The Text interface in at-spi/idl had a couple of methods added. It
looks as though one of the new interface methods wasn't added to the
java bridge wrapper set.
A simple solution should be to add a no-op implementation of
getDefaultAttributeSet to EditableTextImpl, but of course that's only to
fix the build issue - the right fix is to implement the new method.
Would you be able to file a bugzilla bug about this, against
at-spi/javabridge?
If not, please email me directly and I'll file the bug and have a look
at fixing it.
best regards
Bill
Luca wrote:
Hi all!
I'm compiling java-access-bridge-1.6.0 in top of a Gnome-2.16.0 desktop,
however I receive this error:
Making all in Accessibility
make[4]: Entering directory
`/sources/Gnome-2.16/java-access-bridge-1.6.0/impl/org/GNOME/Accessibility'
CLASSPATH=../../../../idlgen:../../../../impl:../../../../bridge:../../../../util
/opt/jdk/jdk/bin/javac EditableTextImpl.java
EditableTextImpl.java:29: org.GNOME.Accessibility.EditableTextImpl is
not abstract and does not override abstract method
getDefaultAttributeSet() in org.GNOME.Accessibility.TextOperations
public class EditableTextImpl extends TextImpl implements
EditableTextOperations {
^
Note: ../../../../idlgen/org/GNOME/Accessibility/EditableTextPOA.java
uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error
make[4]: *** [EditableTextImpl.class] Error 1
make[4]: Leaving directory
`/sources/Gnome-2.16/java-access-bridge-1.6.0/impl/org/GNOME/Accessibility'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/sources/Gnome-2.16/java-access-bridge-1.6.0/impl/org/GNOME'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/sources/Gnome-2.16/java-access-bridge-1.6.0/impl/org'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/sources/Gnome-2.16/java-access-bridge-1.6.0/impl'
make: *** [all-recursive] Error 1
Java version I use is JDK-1.5.0_07 from Sun Microsystems.
Bye,
Luca
___
gnome-accessibility-list mailing list
gnome-accessibility-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
___
gnome-accessibility-list mailing list
gnome-accessibility-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Straw man agenda
Brian Cameron wrote: Willie: This agenda looks good, but here are some things I'd like to see more focus on: + There are many a11y components, and it seems like not many people understand some of them. java-access-bridge, the registry daemon, etc. It would be nice to get an overview of how all the components fit together, I intend to focus on the above in my intro slot. and how to approach mapping a bug to the responsible component, and how to debug each component. That would probably be a useful topic too, if we can find time somewhere. + I think a *lot* of a11y bugs are really the same sort of problems that you see over and over again. Programs that do not have accessible labels for widgets, for example. Perhaps it would be useful to pick a few bugs that are examples of the common a11y bugs that exist and do an exercise where we demonstrate the bug (how to see that the bug exists), and then actually fix the bug. Probably lots of these kinds of bugs are simple 1-line fixes, and if we showed people that it is actually easy to identify and fix these sorts of bugs (if you know how), then perhaps we would find more community involvement in getting these sorts of issues addressed. I believe our current documents address these issues in some detail (see the various articles posted in http://developer.gnome.org/projects/gap/Testing and on the intro GAP page); a good question would be how to better highlight the existance of those documents and improve them. I think it would be more useful to have two tracks instead of just one. One track for people interested in doing development in a11y and one for people interested in making their application(s) better support a11y. I think only people interested in doing active a11y development would be interested in current a11y gaps. Probably most people's time would be better spent helping to get them to understand how to get more involved with fixing existing bugs, and what they should be doing to make sure their applications are reasonably accessible. If we only do 1 track, I think we should minimze the time we spend talking about future pie-in-the-sky things when there is so much work to do just getting what already has been implemented to actually work. I think this is perhaps the most important thing, and isn't reflected at all in your 3-bullet breakdown of the day... I empathize with your point but there do seem to be different perspectives about what the a11y summit should be about. I am not sure that a tutorial focus is in line with what the contributors to the a11y summit wiki have posted so far. I think such a track would be a great thing to have at GUADEC 2007 however... regards Bill * What do we have? * What do we need? * How do we get there? Brian After consideration of all the suggestions from the community (THANKS!), I've put together a straw man agenda for the Accessibility Summit for October 8, 2006, as part of the GNOME Boston 2006 Summit: http://live.gnome.org/Boston2006/AccessibilitySummit The agenda is still up for discussion, so please send your comments. Thanks! Will (Your happy chair) ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Orca now running on AMD64 with latest Edgy installation
Willie Walker wrote: Hi Roland: Glad to hear the gnome-speech thing just worked itself out without requiring mods to gnome-speech. :-) Dynamic language detection/switching is definitely an interesting thing to consider adding to Orca. Right now, however, it's not really on the core team's radar screen - we're still going to be busy fleshing out the really important stuff, such as access to the web via Firefox 3. In addition, we don't have much experience with simultaneously handling multiple locales, so we might not be qualified to do the work. If someone in the community were so inclined, however, to create a patch to allow this, I think I'd be happy to review it. ;-) In case someone gets motivated, I think the relevant AT-SPI methods (for determining the language/locale of UI components), and gnome-speech methods (for determining the locales/langs which a TTS engine can speak) are these: Accessibility::Application:getLocale (the locale of the running app) Accessibility::Image:imageLocale (useful for determining the locale of ALT text/imageDescription) Accessibility::Document:getLocale (for when the document specifies a locale different from the viewing app) Accessibility::Text:getAttributeRun (text tagged with a different LANG will have an explicit LANG attribute) GNOME::Speech:SynthesisDriver:getVoices(in VoiceInfo) - see GNOME::Speech:VoiceInfo.language The latter call to gnome-speech can be used to find a speaker suitable for a particular locale/lang. Best regards, Bill Thanks! Will On Fri, 2006-09-08 at 09:50 +0200, Roland Zitzke wrote: Hi, just wanted to report that I managed to run Orca, Gnopernicus and gnome-speech (the former trouble maker) on an AMD64 Edgy system by simply using the latest installation packages - great work. By the way: is there any (planned) facility to dynamically change localisation in Orca? The rational behind it is that people like me who work with more than one language would like to use different TTS systems for different languages. There is for instance a German version of the Festival speech system but I couldn't find any means to change it from within a running Orca session. Would this be left to scripts? /Roland ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Orca now running on AMD64 with latest Edgy installation
Roland Zitzke wrote: Hi Bill, In case someone gets motivated, I think the relevant AT-SPI methods (for determining the language/locale of UI components), and gnome-speech methods (for determining the locales/langs which a TTS engine can speak) are these: Accessibility::Application:getLocale (the locale of the running app) Accessibility::Image:imageLocale (useful for determining the locale of ALT text/imageDescription) Accessibility::Document:getLocale (for when the document specifies a locale different from the viewing app) Accessibility::Text:getAttributeRun (text tagged with a different LANG will have an explicit LANG attribute) this might be neither useful nor necessary. I guess it would be acceptable if the user switches languages using a key combination. The reason I am saying this is that most multilingual users have a default locale which they don't change when working in another language temporarily. That may be true when composing content, but other kinds of mixed-locale usage will need the above APIs. For instance if a warning dialog from an English app comes up while you're working in German, you want it to be intelligible. Also, if you're viewing a French web page you don't necessarily want to switch locales manually just to use the File menu, etc. Lastly, individual words need to be tagged if they are outside the document's main language, in order for a mixed lang document to be readable via text-to-speech. The underlying accessibility system doesn't know you're writing in English, but it knows if the currently focussed application is in a German locale even if the desktop session as a whole is in English. If you are writing a mixed-language document, or even just composing a new document, just like any other content creator you should me indicating the locale of the document. While it's true that many existing documents don't indicate their locale or language, language tags do exist for many document types, and using them makes the documents more accessible for the above reasons. best regards Bill On Windows for instance I work in German 95% of the time and when having to write in English I just change the speech manually by pressing a couple of keys, not the locale as such. There's absolutely no way for the underlaying accessibility system to figure out that I currently write an english text. GNOME::Speech:SynthesisDriver:getVoices(in VoiceInfo) - see GNOME::Speech:VoiceInfo.language The latter call to gnome-speech can be used to find a speaker suitable for a particular locale/lang. This is something we'll definitely need i.e. get a choice of english voices when English is chosen as the syntehsizer language etc. Btw: I am not a braille user but I do know that there are also locale considerations for Braille, not just for speech. I will have a look at the API on one of the upcoming rainy weekends ;-) /Roland ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: selecting text in a gnome terminal
See bug http://bugzilla.gnome.org/show_bug.cgi?id=78291 The short answer is it isn't possible, mostly because no one can agree on what the keyboard navigation sequence should be. Pretty much any key sequence will clash with some terminal-based application. However, AtkText's selection API does work with vte and gnome-terminal. So a simple at-spi client which hooks into this, or even an orca script, should not be difficult to write. The script would install some global key listeners (again, care would be required to avoid clashing with other uses for the same key sequences) which would turn on selection. If anyone wants to write a patch for vte which implements Calum's suggestion for using F7 to toggle caret mode on and off in vte, and which uses shift-arrow semantics for selecting text in caret mode, it would be worth trying to get it approved by the vte maintainers. I think that's about the best suggested approach we have at this time. regards Bill Keith Watson wrote: I would also dearly love to know how to do this. I need it bad. Keith On 05:06 PM, Kenny Hitt wrote: Hi. Would someone please point me to info on selecting text for cut and paste in the gnome terminal app? I've read the gnome accessibility docs and didn't find anything about it. Thanks in advance. Kenny ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: audacity: was Ubuntu on my desktop
Mike/All: I think audacity uses WxWindows and not gtk+ directly. Thus stock gtk+ widgets are not being used, as I understand it, and the app is not accessible. regards Bill Mike Pedersen wrote: Hi all, Audacity offers some higher end features and is written in gtk, so it should be somewhat accessible if the authors have been thoughtful enough... have never tried it (for accessibility), though. I just tried audacity with orca and saddly the whole thing seems to show up as inaccessible. Orca must not be getting any events for the application. It's good to know that this is written in gtk+ so hopefully we could interest the authors in solving the problems. Mike ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Software that works with Orca? - was Re: Ubuntu on my desktop
Hi Krister: I don't know why you would need or want OCR for reading your email (unless you are talking about printed mail, through your letterbox). Thunderbird ought to be fairly good for mail reading by the time Firefox 3 ships... I think evolution is already usable with orca. best regards Bill Krister Ekstrom wrote: When speaking of software that works with Orca, firstly, is the Firefox 2.0 included with Edgy or do i have to fetch it? Firefox 2.0 comes on the Edgy live cd. I've been told it will be shipping with the latest version of Firefox 2 when 6.10 is out for release in October. An OCR program so i can read my mail and i could say bye bye to Windows. Well, there are a few OCR solutions. I haven't played around with them much but there is GOCR, clara, and there is a commercial OCR program for Linux as well based on Omnipages engine. Hth. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Can't get edgy to boot; also, Orca from powerpc cd?
Hi Henrik: Regarding knot-2, did you pick up the recent new release of gok? We put in some exception handling to catch the XInput device error (from the wacom driver, apparently) that was making gok DOA in many 6.06 installations. best regards Bill Henrik Nilsen Omma wrote: Cheryl Homiak wrote: I appear to have created nice coasters instead of bootable cds as the iso seems to start up and then reboots my machine; this happens forever until I remove the iso. The md5sums are ok. Just checking: are you sure you are burning the ISOs correctly? You might want to check this page: https://help.ubuntu.com/community/BurningIsoHowto Also, some recent ISOs have been over-sized, but i386 should be ok from the 28th onward. Today or tomorrow we'll likely release 'knot-2', our second alpha, which will at least be tested for bootability ;) - Henrik ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: gnome-mag's memory usage
Hi Aurelian Although I am not aware of any big memory leaks in gnome-mag, this sounds like a bug. Opening a bug in gnome bugzilla would be best, then you can post your attachments. For finding memory leaks on Linux, I highly recommend using valgrind. If you can run gnome-mag in valgrind it's likely to provide excellent diagnostics. Carlos, perhaps you could help investigate this issue? Bill On Sat, 2006-08-19 at 10:13, Aurelian Radu wrote: Hello, lists, After half an hour of using gnome-mag, memory usage for the magnifier process increased to around 625 MB, as seen in the attached screenshots. Is this a memory leak or is it a feature? Is this huge cache really necessary? It is true that the magnifier process releases some memory when needed by other applications, but the system becomes really slow. Thanks, Aurelian Radu __ ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [Kde-accessibility] KDE Accessibility - sorry, off topic.
Hi Chris: Zero-conf is of course the ideal, glad you've achieved it for SOK. I am hoping that by using Xevie (via at-spi-registryd - since Xevie only allows ONE client per session :-( and at-spi-registryd needs XEvie for its own purposes), we can change GOK so that the default out-of-the-box configuration just works. For some users we'll still want to allow specialty configuration but I agree that at the moment it acts broken in the default config for many distros. Not good. Grabbing the pointer after a key press is indeed ugly. It will of course cause other apps' pointer grabs to fail, which will result in menus working oddly etc. as Chris notes. We tried this with GOK a long time ago and gave it up. We then tried grabbing the pointer only when it entered the GOK window and releasing the grab when it exited - this worked a little better but still produced too many side-effects. Actually as I recall it seems as though we tried _everything_ with GOK :-D before arriving at the current XInput-dependent situation which requires manual reconfiguration of XOrg.conf in order to work (not good). To give a couple of other examples of typical onscreen keyboard problems with pointers: 1) onscreen keyboards must reject focus, to keep the foreground app in front. That's not so hard, but it requires a bit of specialist X code. 2) if you use an onscreen keyboard to activate a menu, or a menu is otherwise posted by an app, the app probably has grabbed the pointer, so the next click will go to the app and not the keyboard. This means that the onscreen keyboard acts differently from the physical keyboard, and means that it goes dead when certain things happen (modal dialogs, menus posted, and many other common scenarios). Besides being inconsistent, it means that point and click style onscreen keyboards are mostly useless for keyboard navigation. For some users this is OK, but if the user has trouble hitting small mouse targets it means the OSK can't be used as a convenient way of making this job easier. 3) in 'dwell mode' (for users who cannot click, only point, i.e. some head tracker users), the menu grabs above result in what seems like a hang, while the grab client waits for a click that can never come. This is a lockout scenario, clearly bad. 4) for users who can 'click' but not accurately point (for instance, users of wheelchair mounted switches, etc.), mouse grabs mean that the clicks don't reach the OSK, so you have a problem similar to #3 (though at least the whole desktop doesn't appear to hang). There are other oddities, like the fact that a few apps behave strangely if a click occurs while the pointer is outside their window, etc. Olaf implied that there was a concern with XEvie interfering with the core pointer. I would suggest that a certain kind of interference is desirable - i.e. don't let a grab client 'see' the pointer if it's inside the OSK's window. XEvie (and at-spi, via its keyboard listener APIs) allows a client to do just this - clients can consume keyboard and/or mouse events before they ever reach the normal XNextEvent loop, or they can pass them through. So for the typical default point and click style of OSK interaction (what GOK calls direct selection), pointer events would be passed through normally except when the pointer was inside the OSK's window. When the pointer is inside the OSK window, the events are consumed by the OSK (even though it doesn't technically 'have focus'), and thus don't produce other visible side-effects. If anyone wants some suggestions/recommendations for using the existing AT-SPI APIs for getting XEvie-based events, I'll be happy to help, just ask. By doing this, instead of using the normal click events from the host toolkit's buttons, it allows another nice thing - you can 'average' the pointer position to make it easier for someone with poor pointing accuracy to click on a button (so that the 'wrong' OSK key isn't chosen if your pointer slips at the last moment). Since many people with physical disabilities can find that clicking a trackball key causes the pointer to slip a little, this feature would be very useful. All the best, Bill On Thu, 2006-08-17 at 03:42, Chris Jones wrote: I'm the developer of SOK, which is now being rebranded to onBoard. I have come across the issues that Bill has mentioned and I think he is right that XEvie is the only proper solution. That said it is possible to work around the grabbing issues simply by grabbing the pointer for a while after every key press. This is messy and breaks things like alt-tab and alt-f for the file menu etc. For a lot of users this is not a major flaw. With SOK I have been following a zero configuration policy. A user should be able to fire up SOK and use it straight away. I havn't yet examined XEvie in detail. If it is not possible to use it with zero configuration it shall not be used in SOK. A KDE port of SOK should be possible. I know cairo can be
Re: [Kde-accessibility] KDE Accessibility - sorry, off topic.
On Thu, 2006-08-17 at 11:40, Olaf Jan Schmidt wrote: [ Bill Haneman ] Olaf implied that there was a concern with XEvie interfering with the core pointer. No, I meant to say that interfering with the core pointer is the intended behaviour for most use cases of on-screen keyboards - but not for all. Actually, my point is that this affects ALL use cases of on-screen keyboards. So yes, 'interfering' in this way is desirable for all OSKs, not just a few specialized ones. Even the 'simple' use cases will exhibit user-visible bugs if you use the core pointer in the 'usual' way. Bill It is perfectly fine if you do not target those simpler use cases with GOK - it just won't make it a solution for everything. Olaf -- Olaf Jan Schmidt, KDE Accessibility co-maintainer, open standards accessibility networker, Protestant theology student and webmaster of http://accessibility.kde.org/ and http://www.amen-online.de/ ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [Kde-accessibility] KDE Accessibility - sorry, off topic.
On Thu, 2006-08-17 at 12:05, Olaf Jan Schmidt wrote: [ Bill Haneman ] Actually, my point is that this affects ALL use cases of on-screen keyboards. I don't see why this should be the case. Imagine a case where an on-screen keyboard is used for entering text in another language - not as a keyboard replacement, and without need to work within menus. The case above, if you're really talking _only_ about entering text in an alternate language, is technically an input method. Input methods have their own architecture and requirements. Normally one would not use an onscreen keyboard to do this, though there are probably exceptions (and in fact GOK has such an experimental keyboard for Mandarin). If on the other hand the user expects the onscreen keyboard to be used as if it were an alternate keyboard (with a different language/layout), the menu problem cannot be ignored. Most onscreen keyboard users will complain if they are expected to switch back and forth between the virtual and real keyboards, and in some situations the physical keyboard is unavailable or cannot be used. Thus, the OSK needs some basic modifier keys like Alt. But if that is the case, you would have to tell the OSK user that the onscreen keyboard cannot be used for keyboard navigation, or the TAB and arrow keys will work in many situations, except when menus are posted... etc. See the problem? Here's an example: your simple OSK doesn't provide modifier keys (because it's for text entry). Users complain, because some things really require 'Alt' even if you don't use keyboard navigation much. So you add 'Alt'. The user presses Alt-f, a file menu posts, but then the o key on the OSK doesn't do anything. How do you explain to the user that this is normal ? Or a case where the on-screen keyboard simulates neither key presses nor mouse events, but is only used for starting applications or scripts. Such an OSK would look to the user like a launcher or button-box, and not a keyboard at all. I think the 'simple' or 'common' cases you are thinking about are mostly text entry. For text entry you are right that the 'normal' use of the pointer (plus focus rejection logic) would work, but it would not work correctly from the user's point of view for any keyboard navigation features. These inconsistencies are always going to be viewed as bugs from the user's perspective, no matter how you explain them... Bill Olaf -- Olaf Jan Schmidt, KDE Accessibility co-maintainer, open standards accessibility networker, Protestant theology student and webmaster of http://accessibility.kde.org/ and http://www.amen-online.de/ ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [Kde-accessibility] KDE Accessibility - sorry, off topic.
Hi Olaf: On Wed, 2006-08-16 at 21:23, Olaf Jan Schmidt wrote: [ Bill Haneman ] That strikes me as a surprising statement. Of course it depends on what you mean by partially sighted. The people I am familiar with for example have light allergy. Large bright areas on the screen hurts their eyes (e.g. selected text in the GNOME dark background colour scheme). We designed our 'Inverse' themes with this condition in mind. We avoid large bright areas except for the case of 'select all' within a document. In actual practice, many users almost never do a select all. Some additional, intelligent false colour modes would be needed to invert only those parts of the screen with bright colours. But as far as I know, no existing screen magnifier that can this. Hopefully Gunnar will be able to come up with a solution. This isn't really required - it's easy to modify the colors of an existing GTK+ theme or create a new one. We have a low contrast theme for use by folks for whom it's best to have no bright areas at all (this theme should be used with lowered monitor brightness, in most cases). But realize that many people with light sensitivity problems like the one you describe also have reduced visual acuity, and thus need higher than normal contrast. It's a trade-off between providing high contrast and avoiding large bright areas. In the case of the HighContrastInverse theme, we manage to avoid bright areas except in the specific case where a large area is selected. The inverting of selected text is not built-in to gtk+, but is intentionally part of the HighContrast themes, in order to provide maximum visibility. Our own tests and study of previous research and practice informed this choice. I really wonder where you got this data, it is at odds with the information I have received from domain experts. It was one result of our usability test with partially sighted users, but I need to mention that the group was very small. I have never encountered a complaint about the brightness of the selected area in the HighContrastInverse theme. Our sample size was fairly small too, but we did consult with folks who had experience in this area. The fact is that no single theme will be perfect for a large population of users, as you point out. I think it might be fairly simple to create a light sensitive theme from the existing HighContrastInverse one, by making the 'SELECTED' foreground color less bright. (To do just this, modify the following line in the HighContrastInverse gtkrc file, under 'style default' : ... - base[SELECTED]= #ff + base[SELECTED]= #9988aa You could also make this change for multiline-text widgets only, if you prefer) Doing this requires some sort of re-rendering or overlay feature. Until the recent introduction of XComposite this sort of thing was technically not very feasible on XWindows. Gunnar's magnifier will include something based on XComposite and AT-SPI, and I suggested to make it also useful without the magnification. Magnifiers without magnification are used for similar purposes on Windows platforms, I believe. The magnifier itself provides a convenient way of re-rendering anything that's put on screen. Theming is a very important issue and as you no doubt realize, it can be difficult to get applications to comply with themes, it seems that most applications want to define their own color schemes for at least some things. We are planning to extend the colour schemes in KDE4 to contain enough colour roles for the applications, and to provide them with suitable functions for gettign additional colours if they really need them. It would be great if we could get a common solution for KDE and GNOME. I agree. There has been discussion of moving the theme colors from the current .gtkrc files into XSettings, which would make it more toolkit-independent. I don't know the current status of that work. KDE can already apply its colour scheme to Gtk applications, but this is broken, and I have been unable to find a documentation of the Gtk theme settings. This might help a little: http://developer.gnome.org/doc/API/2.0/gtk/gtk-Resource-Files.html ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME Accessibility Team Meeting @ Boston Summit?
It's really great to have such broad interest in Accessibility at the Summit. I'd love to include the lab visit. I think it should be on a separate day, however, since it could take a lot of time and lead to rather wide-ranging discussions. Looks like our one day is already getting pretty full. regards, Bill On Thu, 2006-08-17 at 17:05, Anna Marie Dirks wrote: Hi Everyone, I have been working to setup various ATs to complement my usability lab, which is coincidentally about 200 meters from the Summit location. It would be fantastic to have you all over to the lab for a visit. I'd like to discuss the role of usability testing in the context of assessing and improving accessibility. I'd also welcome ideas about recruiting test subjects with a broad range of abilities. Please let me know if this sounds like an appropriate addition to the Accessibility Team Meeting, so that I may prepare the lab for visitors ahead of time. regards, Anna El jue, 17-08-2006 a las 11:57 -0400, Willie Walker escribió: Hey Aaron: I think this would be useful. From an OS platform standpoint, we're definitely lacking in compelling web accessibility. We all realize this and we all agreed earlier this year to center on Firefox 3 as our primary focus for web accessibility. You and the extended Firefox 3 teams from Sun and IBM have been very busy this summer revamping the Firefox 3 AT-SPI infrastructure (thank you!). The October time frame seems like a good time to share our experiences after we have a chance to take this new infrastructure for a test ride. Will On Thu, 2006-08-17 at 11:31 -0400, Aaron Leventhal wrote: What is the exact day for it? I only see one day event here: http://live.gnome.org/Boston2006/AccessibilitySummit I want to try and have a Mozilla hack fest tacked on to it as well, for a few days of coding together. Anyone who works on Mozilla or on an AT hooking into Mozilla is invited -- any platform. - Aaron Jeff Waugh wrote: quote who=Jeff Waugh The Boston Summit [1] is coming up in early October, and I thought it might be a good chance to bring together everyone working on GNOME accessibility, to talk through common goals, differing solutions, and how to get all of us on the same page and working to a master plan! Sound good? Hi all, I've received a lot of positive responses already, so I'm going to take the 'proposal' sticker off the box and call it the 'real thing'! :-) Please make sure to add your name to the following wiki page to indicate that you'll be coming to the Summit: http://live.gnome.org/Boston2006/TellUsYoureComing And don't forget to add your suggestions to the accessibility meeting page: http://live.gnome.org/Boston2006/AccessibilitySummit Finally, we need a volunteer to chair the meeting. Please step up. :-) Thanks, - Jeff ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME Accessibility Team Meeting @ Boston Summit?
On Thu, 2006-08-17 at 13:06, Willie Walker wrote: Hi All: We need to choose a day for the meeting, and develop an agenda - please log in to the wiki and add your suggestions. One think that I'd really like to present, and which fortunately I have extensive materials ready for, is a comprehensive overview of the accessibility architecture. I have slides ready with scads of diagrams for this purpose, which I think could be presented in a little over an hour, covering a lot of the topics which are necessary in order for Gnome developers to work within the existing a11y framework, diagnose problems, etc. regards Bill If there's enough support for this idea, we can dedicate a room to it - it might be useful to nominate a chair person to maintain the wiki page and run the meeting. I'm happy to volunteer to be chair for this meeting and have support from my management to spend time on it. I've been working on accessibility to the X Window System since the early 1990's and have most recently been leading the Orca screen reader effort. Ultimately the meeting will be based upon what people decide they want to discuss. Looking at what is emerging from the community input on the WIKI (http://live.gnome.org/Boston2006/AccessibilitySummit), I propose there might be at least three main themes for the summit: 1) Improving the accessibility of the base platform. This can include topics such as the a11y component to the icon theme, magnification, keyboard traversal, windows from multiple users on the same display, and the thought of getting SpeechDispatcher into the platform. Possibly also a discussion on AT-SPI futures: CORBA, DBUS? 2) Improving and providing multiple assistive technology offerings and how to manage their selection/configuration/setup. A concrete goal here could be to determine the appropriate user interface(s) that works within the GNOME highlander principle (i.e., there can be only one of any breed in the GNOME platform), yet easily supports distributions that ship more than one solution for a given disability (e.g., GOK and SOK/onBoard). Various people are giving some thought to this space and this summit could be a good way to reach a consensus and a plan of execution. 3) Brainstorming how to get the whole of the GNOME community more proactive in testing for accessibility. Prior to the release of GNOME 2.14 and now prior to GNOME 2.16, Sun spent considerable time chasing down and fixing a11y regressions in other people's modules. We need a better way for us (and ultimately the module owners themselves) to find and prevent these regressions. Related to this, we're working on an automated regression test harness for Orca, which I hope is ready by the summit. Given #3, I'd also like to try expose plain old non-a11y developers from the GNOME community to a11y. My experiences from doing these types of meetings many times in the past is that we tend to end up preaching to the choir when we often want the rest of the congregation to attend. Jeff has suggested that we can do a accessibility summit report to the larger conference the day after the summit. Finally, the Boston area is home to important and influential accessibility organizations such as the Carroll Center for the Blind and the Massachusetts Office on Disability. Basing your work on input from real live end users is always a good thing (I personally think it is mandatory). If the summit attendees find it appropriate, we can extend an invitation to our close contacts in these organizations. In any case, these are initial thoughts that can be twisted, contorted, and expanded as need be. :-) Will ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: KDE Accessibility - sorry, off topic.
Hi Olaf! I appreciate that kttsd can have many useful applications. I differ with your statement below, however: But screen readers do not help partially sighted users, users with learning difficulties, or people who simply love to have system notifications or IRC messages spoken. Actually in the Windows world all of those are frequent use cases for screen readers. In conjunction with magnification or onscreen highlighting, screen readers can be especially useful for partially sighted users and users with reading/cognitive difficulties. The partially sighted use case is the reason why both gnopernicus and orca have integrated magnification and screen reading into one system. I would like to discuss the German company's concerns, since I do not see gnopernicus, orca, or gok as special purpose. By their nature and design they are intended to be used for a wide variety of end-user needs. GOK's configuration difficulty is due to an inherent problem with core pointer grabs and onscreen keyboards. All modern toolkits, and many applications, assume that they entirely own the pointer when they are active, and this causes unsolveable conflicts with onscreen keyboards which are also trying to access the pointer. Now that the XEvie extension is widely available, I think there is a solution available which GOK can be modified to use, but SOK will run into these problems too unless they adopy a different design strategy. This is not to say that the existing general-purpose ATs are easy to configure so as to meet all user needs, and I don't mean to imply that they can or will solve all problems. However, I do think that the existing ATs are designed to handle most situations in theory, and feedback from people like this German company is what we need in order to improve the ATs, improve their documentation, and simplify their configuration. Best regards, Bill kttsd is being used successfully by all these user groups. For example, there is a German company that installs KDE-based computers in schools for people with learning difficulties. They are making extensive use of kttsd and the other KDE accessibility aids. The big GNOME technologies such as GOK, Gnopernicus, Dasher and Orca are far too special-purpose to address their needs. They could use a simple on-screen keyboard that responds to mouse clicks, but it is very difficult to set up GOK in a way that supports this. I hope the new on-screen keyboard (SOK) will be fill this gap. Our strategy for KDE accessibiilty therefore contains two parts: 1. Help the GNOME accessibility team to extend their assistive technologies for KDE applications 2. Write modular accessibility aids that can be combined to help all those users that are not sufficiently addressed by the GNOME technologies, such as most partially sighted users. Olaf [ Darragh ] Hello, I'm sorry but out of curiosity I have a quick question. From looking at the KDETTS page shown below it looks like the plan is not to necessarily have a screen reader for KDE but to try to get indevidual application developers to include support for speech output via the KDETTS sub-system. I may be reading that wrong. If so, could someone enlighten me? It would seem like an absolutely crazy idea to go down that route so I'm sure I'm missing something. In case I'm not, How do the developers of KDETTS think that developers of applications will know what information needs to be spoken in their applications? Consistancy will go out the window! http://accessibility.kde.org/developer/kttsd/ Quote from page: It is hoped that more programmers will begin adding speech capabilities to their KDE programs using KTTS. Eventually, when Qt 4 is distributed, it is hoped that Screen Readers will be adapted to use KTTS. End of quote. Second quote: Provide a lightweight and easily usable interface for applications to generate speech output. End of quote. Quote 3: KTTS -- KDE Text-to-Speech -- is a subsystem within the KDE desktop for conversion of text to audible speech. KTTS is currently under development and aims to become the standard subsystem for all KDE applications to provide speech output. End of quote. Darragh Ó Héiligh Website development, Application and O/S Technical Support Website: http://www.digitaldarragh.com Email: [EMAIL PROTECTED] Tel: +353-87-767-0464 ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list -- Olaf Jan Schmidt, KDE Accessibility co-maintainer, open standards accessibility networker, Protestant theology student and webmaster of http://accessibility.kde.org/ and http://www.amen-online.de/ ___ gnome-accessibility-list mailing list
Re: [Kde-accessibility] KDE Accessibility - sorry, off topic.
On Wed, 2006-08-16 at 20:44, Olaf Jan Schmidt wrote: [ Bill Haneman ] Actually in the Windows world all of those are frequent use cases for screen readers. In conjunction with magnification or onscreen highlighting, screen readers can be especially useful for partially sighted users and users with reading/cognitive difficulties. Yes, I am aware of this. I should have written: The existing screen magnifiers on Windows fail to address the needs of the majority of partially sighted users. The existing screen magnifiers on Unix fail to address the needs of about 95% of partially sighted users (both according to my non-representative experience). That strikes me as a surprising statement. Of course it depends on what you mean by partially sighted. The partially sighted use case is the reason why both gnopernicus and orca have integrated magnification and screen reading into one system. The usability test we conducted with partially sighted users shows that no two partially sighted users are the same. Most of them do not want to use screen magnifiers for various reasons. For example, Gnopernicus does not offer all of the false colour modes available with Windows screen magnifiers, which is especially problematic since all of the predefined colour schemes in GNOME invert the colours for selected text. This makes the text unreadable for the majority of partially sighted users. I really wonder where you got this data, it is at odds with the information I have received from domain experts. It would not be difficult to add more false color modes to gnome-mag and by extension any gnome-mag client such as orca. However I don't think this is by any means our most pressing magnification need. I know partially sighted people who are using KDE with a user-defined colour scheme, very big font settings and different virtual screen resolutions. The problem with this is that focus tracking and highlighting is currently not available independent of screen magnifiers and screen readers. Doing this requires some sort of re-rendering or overlay feature. Until the recent introduction of XComposite this sort of thing was technically not very feasible on XWindows. Fortunately we have multiple ways of doing it now. But I still think that it may make sense to implement it as an orca add-on. Another problem is that not all applications follow the user-chosen colours, which we hope to address in KDE4. These users would benefit from speech feedback, focus highlighting, etc, even if a full-featured screen reader is the wrong solution for them. Theming is a very important issue and as you no doubt realize, it can be difficult to get applications to comply with themes, it seems that most applications want to define their own color schemes for at least some things. I would like to discuss the German company's concerns, since I do not see gnopernicus, orca, or gok as special purpose. By their nature and design they are intended to be used for a wide variety of end-user needs. We only touched on-screen keyboards very briefly. We were mainly talking about how they use existing KDE technologies, such as kttsd, and how small, modular accessibility aids serve them best. But let me summarise what I learned from other people who told me that a simply on-screen keyboard is missing in KDE: Can you configure GOK not to interfere with the core pointer, but to respond to it? Can you do so using the graphical configuration dialog alone? Why is this not the default setting? In general this is technically impossible for ANY onscreen keyboard in XWindows - at least, without XEvie. I think that we may be moving GOK to this sort of default setting now that properly-working versions of XEvie are more widely available. Is it possible to show different (or no) buttons depending on the active window? Can you configure this graphically? Yes, this can be done. But eventually an orca-like python scripting approach may make the most sense for this sort of application-dependent behavior. If you have only one mouse connected to your computer and start GOK in default mode, is it then possible to access the configuration dialog with your mouse? Yes. My experience is that this is typically completely broken on the demo points of GNOME during trade fairs, but maybe this was a bug in the distributions they use. That could be. The default configuration is pretty bad for GOK, and for technical reasons the necessary solution is to hand-edit the X configuration files. We have documented this process in the 'Gnome Accessibility Guide' but it's not pretty! Now that the XEvie extension is widely available, I think there is a solution available which GOK can be modified to use, but SOK will run into these problems too unless they adopy a different design strategy. I agree that SOK will not solve the use cases where core pointer emulation
Re: debian and gnopernicus
Hi Jude: Don't use twm or icewm as window managers - for best results you'll want to install and run the Gnome desktop env which includes the metacity window manager. Starting gnome-session after startx may work for you. regards Bill On Fri, 2006-07-28 at 01:00, Jude DaShiell wrote: So far earlier today I had a non-graphical system as a base line. After having done aptitude update and aptitude upgrade and installing all upgrades I decided to try installing xserver-xorg and gnopernicus to see if they'll play nicely together. So, aptitude install xserver-xorg --with-recommends then aptitude install gnopernicus --with-recommends got me a few megs worth of files installed. Upon rebooting I noticed speakup still comes up and whatever x environment may or may not be functional on this system did not attempt to start and fail. Much nicer than installing debian desktop from tasksel. Some other notes I chose isa:1 for monitor type and told the system to talk to the monitor for further information and not use the frame buffer to get its information. This is a pretty modern monitor and definitely not an rgb model either. So before I try running startx and then running gnopernicus -s to see if the X environment wants to talk is there anything else I neglected to do? The sound card is functional and plays podcasts fine and I ran alsa-conf and alsactl store against it earlier too. I've heard twm is a disaster and don't know if that is installed or not and can get icewm for this system too if it would work better for this level of accessibility. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Firefox accessiblity
Manish: Please check the recent list archives for info on firefox work. There is also a mozilla accessibility development mailing list, [EMAIL PROTECTED] Here's a quotation from a recent email thread on Firefox accessibility: Yes. Firefox 1.5 or 2.0 will work better if you set GTK_MODULES to empty. But it still can work with gnopernicus if you don't do so. On ubuntu 6.06, if you don't do so, Firefox 1.5 CANNOT work with gok and gnopernicus screen review. Because ubuntu 6.06 sets GTK_MODULES to gail and atk-bridge automatically, it will break Firefox's accessible tree. We fixed this issue in Firefox 2.0 and 3.0. The best accessibility results are expected with Firefox 3.0, and that's where most of the accessibility engineering work in Firefox is probably taking place now (in the tree that will lead to 3.0). Bill On Mon, 2006-07-24 at 07:38, Manish Sapariya wrote: Hi all, I am not sure whether I should be writing to this list of firefox/mozilla list. If this is not appropriate forum kindly let me know. I am trying to automate firefox using at-spi/dogtail. However, when I traverse the tree for Gecko app, it just gives me access to main application and the frame window. Most importantly I am trying to click on the dialog boxes poped up by javascript. The tree just gives me the frame of the dialog, but not access to the Ok/Cancel button or text of the dialog. Do I need to customize the firefox code to get the access to these elements? Is there some work already going on to make firefox accessible. Thanks and Regards, Manish ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: accessebility suggestion for Ubuntu 6.06 LiveCD
On Mon, 2006-07-24 at 11:21, Henrik Nilsen Omma wrote: Bill Haneman wrote: Hi Petra: In the most recent versions of Gnome, assistive technology support is on by default. The access keys idea is a reasonable one, and I think it would greatly improve the Ubuntu accessibility experience for screen reader and onscreen keyboard users. Agreed. For the on-screen keyboard we can even do this now because our new on-screen keyboard does not need AT-SPI to run. The new onscreen keyboard does not meet the needs of many mobility-impaired users. GOK should be bundled with the LiveCD - once some configuration issues are dealt with. Orca will also run without AT-SPI but only with a very limited set of applications (like itself). Having a way to dynamically load AT-SPI would be great! I am not sure this is the best technical way to solve the problem. IMO for anything other than shared use kiosks, it makes more sense to put the access keys in the login screen such that the AT-SPI support is automatically loaded in the user's session. We have something similar in the gdm login screen (though it requires configuring when the system is first set up), which allows certain gestures to start assistive technologies. I clearly need to look more closely at this. It's a very cool feature. I'd be interested to know what your primary complaints with gnopernicus magnification are. It is possible to configure a system for fullscreen magnification using gnopernicus, and although the results aren't as snappy for mouse use as some commercial Windows magnifiers, it is basically functional and follows both mouse and keyboard focus (at least when properly configured). We are also working on a compiz-based magnifier which would improve performance, but unfortunately work is slow on this. Henrik - Carlos Diogenes is working on adding Composite to gnome-mag, which would make it work as a drop-in enhancement. You probably should ping him about this, it makes little sense to duplicate work. regards Bill - Henrik ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: accessebility suggestion for Ubuntu 6.06 LiveCD
On Mon, 2006-07-24 at 11:58, Henrik Nilsen Omma wrote: Bill Haneman wrote: The new onscreen keyboard does not meet the needs of many mobility-impaired users. GOK should be bundled with the LiveCD - once some configuration issues are dealt with. Do you have any specific use cases that GOK supports but SOK does not? The only one I can think of is users of scanning devices who need to perform actions on the desktop that cannot be achieved with standard keyboard shortcuts (but in my view that's a bug in those applications). SOK doesn't support any kind of switch-only user, nor does it support scanning users. It can only support users who can both point with high accuracy, and click. SOK currently works well with head pointing devices and we are adding scanning device support. We currently do not have direct AT-SPI functionality but we are making a script feature that will let us control desktop functions via dog-tail. You will find that the pointer-grab problem will defeat many of your cases if you try to access menus and control programs via AT-SPI. Toolkit maintainers and authors argue very convincingly that the problematic behaviors regarding pointer grabs are NOT bugs. After years of dealing intimately with these problems I am 100% convinced that any OSK technology that doesn't use some alternative means of avoiding these pointer grabs is doomed to fail for these users. For a pointing-only user (who cannot perform a mouse click), these are lockout scenarios which effectively hang their desktop sessions, so these problems are very serious indeed. You can grab a copy for testing here: https://wiki.ubuntu.com/Accessibility/Projects/SOK I am not sure this is the best technical way to solve the problem. IMO for anything other than shared use kiosks, it makes more sense to put the access keys in the login screen such that the AT-SPI support is automatically loaded in the user's session. Yes that would also be good. Is there a standard set of such GDM access keys? This really is something that should be enabled by default, both in Gnome and in Ubuntu. There are some in the default gdm.conf file, but I am not sure they would be the best choices for cross-desktop defaults. If there's a will to standardize this I suggest we discuss it on [EMAIL PROTECTED] I like this idea. Making AT-SPI load dynamically is theoretically possible but there are some real feasibility issues; realistically I don't think it's going to happen anytime soon (though there has been an RFE open for years). But allowing a user to request assistive technologies (or detecting that need via 'gestures') at login time is very feasible. Henrik - Carlos Diogenes is working on adding Composite to gnome-mag, which would make it work as a drop-in enhancement. You probably should ping him about this, it makes little sense to duplicate work. Great, I will contact him. We just want to see this implemented, and don't care too much where or by whom. gnome-mag is probably the best place for it. It would probably be the fastest path to getting it integrated with Orca, etc. best regards Bill - Henrik ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: accessebility suggestion for Ubuntu 6.06 LiveCD
On Mon, 2006-07-24 at 12:41, Henrik Nilsen Omma wrote: Our plan is to go ahead with the new technology and deal with the problems as they arise. If by this you mean that you will ship SOK in preference to GOK in Ubuntu, I think you are making a mistake. Bill ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: accessebility suggestion for Ubuntu 6.06 LiveCD
On Mon, 2006-07-24 at 13:42, Henrik Nilsen Omma wrote: Bill Haneman wrote: On Mon, 2006-07-24 at 12:41, Henrik Nilsen Omma wrote: Our plan is to go ahead with the new technology and deal with the problems as they arise. If by this you mean that you will ship SOK in preference to GOK in Ubuntu, I think you are making a mistake. SOK will be installed by default and GOK will be an installable option. I still haven't seen a complete use case with a description of the users needs and an example of where it fails (like specific applications where a problem occurs and the hardware used). I'll try to follow up in later emails. There were tons of problems logged but they were all closed as NOTABUG if I recall correctly. Have you tried SOK yet? And specifically you should try running it next to GOK to experience the difference. SOK has a few limitations, but also a range of advantages over GOK: * More flexible layout - the layout files are quite easy to modify in Inkscape so you can have a range of different layouts. Switching between them is easy. By default GOK gets the physical keyboard's layout from the xserver and displays that. However GOK also has alternate physical layouts that you can use. They are XML files and straightforward to customize by editing the XML. There was a keyboard editor included with GOK but it has been unmaintained for some time - however I don't think it would be hard to * Scalable - Just grab the corner and change it to the size you want so you can optimise your screen usage. You can scale GOK's keyboards this way as well, if you turn off the dock and fill options (via either the GOK prefs dialog or via GOK's own configuration keyboard). * Less general clutter. Extra keys (like function keys) appear on a separate keyboard level so they do not take up valuable screen space. The window does not keep changing shape as you navigate the desktop or the keyboard itself. No scary warning boxes. Making GOK's function keys appear in a separate keyboard would not be difficult, nor would making GOK's window a fixed size. However a fixed size window will limit the options you can present to a user when using GOK's more advanced features. If you're using GOK as a more simple keyboard replacement this is trivial to do. The scary warning boxes are very necessary if the system is mis-configured. However they can easily be suppressed/turned off. * Works with tablet PCs - because it just uses the core pointer from X. I predict that these devices will increasingly be used as assistive technology. GOK can use tablet PCs as well, with proper configuration. * Non-latin input is more feasible because it has full unicode support (which I guess GOK has as well right?) and the more flexible layout allows you to have 50, 100 or even 200 hundred keys on the screen. Using multiple levels you can acomodate thousands of symbols. GOK was designed from the outset for non-latin input, full unicode support, and hundreds of keys in multiple levels. See for instance the demo Chinese branching keyboard which functions as an 'input method'... so this is an area where GOK is ahead. * Much simpler codebase, written in python. This makes it easier to fix bugs and add new features. A much smaller install size, which is good for Live CDs. There have been discussions regarding moving much of GOK to python. We invited you to help us when the SOK project was first announced :-( * We are adding a flexible macro and script system that lets you attach a simple text-entry macro or a more complicated python script to any key. Please see above. I think it's a terrible shame that we seem to be duplicating effort if not downright competing in this already-under-resourced space :-( * Looks nicer :) You can customize it in an SVG editor with the colours and layout you like. You can customize GOK's color scheme fully. And making it look nicer would merely be a matter of changing the implementation of GokButton's paint method. * Finally it just runs more smoothly IMO, most likely because of the Cairo rendering. ??? Because GOK uses GTK+ for its rendering it uses Cairo too. In my opinion sticking with old technology for too long is a mistake because you loose out on opportunities to innovate. You seem to have made decisions about old technology without understanding it very well, or taking the designers/developers up on their previous offers of more information :-( We haven't make any attempt get this into Gnome 2.16 as I could see that there would be strong opposition, but I think we can make a good case for Gnome 2.18. Absolutely not. - Bill - Henrik ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility
Re: accessebility suggestion for Ubuntu 6.06 LiveCD
On Mon, 2006-07-24 at 15:10, Chris Jones wrote: ... It is possible to detect when pointer grabbing occurs so work arounds are quite possible I should think. Not as far as I can tell. X just doesn't allow it. Since GOK can not be configured to work out of the box there seems little point installing it by default. I disagree - we went to a lot of trouble to make GOK work as well as possible out of the box. That said, we felt we needed to warn end-users of potential conflicts with the core pointer, thus the warning dialogs (easily suppressed, as I have pointed out before). Bill Bill Haneman wrote: For a pointing-only user (who cannot perform a mouse click), these are lockout scenarios which effectively hang their desktop sessions, so these problems are very serious indeed. I'm not sure I understand. Is this something that could be solved by desktop wide dwell support? ?? I don't think so, if I understand your question. The new onscreen keyboard does not meet the needs of many mobility-impaired users. GOK should be bundled with the LiveCD - once some configuration issues are dealt with. Are there plans afoot to deal with these configuration issues? Otherwise I think we need to explore alternative approaches. Imperfect though they may be, we need something that works. There is no point debating this on mailing lists. Please file bugs where the technical issues can be discussed thoroughly. I plan to follow up with a more detailed email about the pointer grab/core-pointer problems. But in short, because the trend for X server configurations is to multiplex all pointing devices together into core, and a number of problems with the way the current generation of XInput works, I agree that a different solution seems necessary. I think using Xevie (via AT-SPI, since there can only be one Xevie client on a desktop) for all GOK's input is the best approach, but we've been holding off on doing this since some distros have shipped with broken Xevie support (FC4 for instance). Now that FC5 is out it seems like a good time to require Xevie if that will break the logjam with regard to input devices. This would also make GOK's configuration very simple and allow it to work out of the box with all mouse-like or button-like input devices. ??? Because GOK uses GTK+ for its rendering it uses Cairo too. True. GOKs poor performance is a mystery to me, I have no idea why SOK seems faster. It does however. Have you or anyone filed a performance bug? By default GOK gets the physical keyboard's layout from the xserver and displays that. However GOK also has alternate physical layouts that you can use. They are XML files and straightforward to customize by editing the XML. I am also hoping to go down this route. It is much easier to personalise these layouts with SOK which many will want to do since a physical keyboard layout is not necessarily good as an on-screen keyboard. Henrik said: We haven't make any attempt get this into Gnome 2.16 as I could see that there would be strong opposition, but I think we can make a good case for Gnome 2.18. Absolutely not. In the beginning we tried to give guidance, but I got the distinct impression that it was going to /dev/null.This is why I am frustrated - lots of behind-the-scenes vague griping, without GOK bugs and seemingly without a willingness to engage cooperatively to improve the existing Gnome onscreen keyboard suite, which was designed by experts in the field of adaptive technologies. I would very much like to work cooperatively with you and with the rest of the Ubuntu team, but in the context of improving our existing OSKs. Bill It's this kind of attitude that discouraged me from asking you for advice. I can understand how my approach has riled you as a fair bit less work has gone in to SOK than GOK, and yet people talk of replacing it. However my program is more useful to some people. I hoped to bring new ideas to the area and you seemed determined to squash them from the start. I'm sorry to get personal about this, and your experience and knowledge would be very valuable to me only it seems impossible to enlist your help without this kind of prolonged heated debate breaking out. It needs to be accepted that there will be differences of opinion and to work together despite this. Chris Jones ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: accessebility suggestion for Ubuntu 6.06 LiveCD
Hi Chris: I think there have been misunderstandings of various sorts, probably on both sides. I don't recall ever refusing to fix any corepointer issues, for instance - at the time you asked, there were multiple research efforts under way to try and address them. I think you should understand why calling GOK unusable continues to irk, especially considering its strong points (it's a pioneering OSK in many ways and it has been said that it surpasses anything that's ever been created for mobility-impaired users, with regards to desktop integration and efficiency of keystrokes). All that said, if we can deliver an OSK that doesn't regress GOK's powerful features, I'm all for it, whether it's the GOK codebase or not. Until today I didn't see any indication that the SOK team was interested in providing those features; maybe this was a misunderstanding on my part. However if you want to provide them, then I would be eager to help you achieve that goal. A python codebase has obvious advantages, and often a rewrite is the best way of moving forward, if there's a consensus on the requirements. Best regards, Bill On Mon, 2006-07-24 at 15:51, Chris Jones wrote: It is a pity I was not aware of Xevie earlier in the project. It may have caused me to change my mind if I knew there was light at the end of the tunnel on the core pointer issue. I understand completely why the dialog boxes are there and why they are necessary. They are symptoms of the actual problems. Simply suppressing them would do little. My project as I saw it was not to improve but to fix. Gnome is in need of a usable OSK. The main gripe with it being the configuration problems. Since at the time you refused to consider addressing the configuration problems I was left with no choice. - Hide quoted text - On 24/07/06, Bill Haneman [EMAIL PROTECTED] wrote: On Mon, 2006-07-24 at 15:10, Chris Jones wrote: ... It is possible to detect when pointer grabbing occurs so work arounds are quite possible I should think. Not as far as I can tell. X just doesn't allow it. Since GOK can not be configured to work out of the box there seems little point installing it by default. I disagree - we went to a lot of trouble to make GOK work as well as possible out of the box. That said, we felt we needed to warn end-users of potential conflicts with the core pointer, thus the warning dialogs (easily suppressed, as I have pointed out before). Bill Bill Haneman wrote: For a pointing-only user (who cannot perform a mouse click), these are lockout scenarios which effectively hang their desktop sessions, so these problems are very serious indeed. I'm not sure I understand. Is this something that could be solved by desktop wide dwell support? ?? I don't think so, if I understand your question. The new onscreen keyboard does not meet the needs of many mobility-impaired users. GOK should be bundled with the LiveCD - once some configuration issues are dealt with. Are there plans afoot to deal with these configuration issues? Otherwise I think we need to explore alternative approaches. Imperfect though they may be, we need something that works. There is no point debating this on mailing lists. Please file bugs where the technical issues can be discussed thoroughly. I plan to follow up with a more detailed email about the pointer grab/core-pointer problems. But in short, because the trend for X server configurations is to multiplex all pointing devices together into core, and a number of problems with the way the current generation of XInput works, I agree that a different solution seems necessary. I think using Xevie (via AT-SPI, since there can only be one Xevie client on a desktop) for all GOK's input is the best approach, but we've been holding off on doing this since some distros have shipped with broken Xevie support (FC4 for instance). Now that FC5 is out it seems like a good time to require Xevie if that will break the logjam with regard to input devices. This would also make GOK's configuration very simple and allow it to work out of the box with all mouse-like or button-like input devices. ??? Because GOK uses GTK+ for its rendering it uses Cairo too. True. GOKs poor performance is a mystery to me, I have no idea why SOK seems faster. It does however. Have you or anyone filed a performance bug? By default GOK gets the physical keyboard's layout from the xserver and displays that. However GOK also has alternate physical layouts that you can use. They are XML files and straightforward to customize by editing the XML. I am also hoping to go down this route. It is much easier to personalise these layouts with SOK which many will want to do since a physical keyboard layout is not necessarily good as an on-screen keyboard. Henrik said: We haven't make
Re: Fwd: accessebility suggestion for Ubuntu 6.06 LiveCD
On Mon, 2006-07-24 at 16:38, Chris Jones wrote: Bill Haneman said: I don't recall ever refusing to fix any corepointer issues, for instance - at the time you asked, there were multiple research efforts under way to try and address them. Maybe I put that too strongly. You stated that the fix was to have a second input device and were unwilling to consider, or at least gave me the impression that there was not anything that could be done about it. This may have been a flaw in my own interpretation. My point was the using the corepointer, 'as is', was not acceptable from an accessibility point of view because of lockout scenarios and serious conflict with toolkit pointer behavior. I stand by that - the only reason I suggest it can be done with Xevie is because Xevie gives us a means of intercepting the pointer events before the toolkit or applications see them. I also count the dependence on sticky keys a configuration issue. StickyKeys is available on all recent x servers. So in that respect, it's not a configuration issue, since the OSK can programmatically set this (and should, for various reasons). No modification of the default Xserver configuration is necessary. As a general rule no application should be too dependent on the configuration of the underlying operating system be it Xorg configurations or a11y configuration. Completely aside from the inconvenience to the user, conflicts between applications with different configuration requirements could become quite likely. Of course. Simiilarly, applications must also not implement features that are too similar to existing platform features, because that can also result in conflicts from the end-user's point of view. This is especially important where accessibility is concerned, and in fact the Section 508 accessibility requirements explicitly require conforming applications not to conflict with the operation of existing platform accessibility features. This is one reason why applications that wish to use keyboard latching or locking must be very careful about how they implement it, and preferably they should use the existing StickyKeys services built in to the X server. Bill It's very easy for an application developer to think that his or her application is the most important thing running on a users machine, though it is not a fair assumption to make. -- Chris Jones ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: LSR demo and a11y tools at DDC 2006
On Mon, 2006-07-17 at 23:59, Brett Clippingdale wrote: Linux Screen Reader (LSR) was presented at the Linux Desktop Developers' Conference today as part of a talk titled Accessibility Enablement and Usability for GTK Applications. Of particular interest to all developers is a short accessible programming HOWTO. The document, Guidelines for Writing Accessible GNOME Applications: Using GTK+ and the Accessibility Toolkit (ATK), has examples in C and Python, and is available at: http://accessibility.freestandards.org/~gk4/a11y/ddc06/guide/atkguideddc06.html Thanks to Kathy Laws for helping put that document together. It's still in draft form and is under review, so bear that in mind. There are a few things in it, for instance the references to MSAA, which might be confusing to Gnome developers - the MSAA (Microsoft Active Accessibility) comparison table is for the convenience of assistive technology and application developers who are already familiar with MSAA, so that they can relate it to Gnome's ATK interface. There is no direct relationship between the two technologies (they actually have a number of significant differences), and non-MSAA developers should probably just ignore that section. I would also strongly encourage all Gnome developers to read the documents referenced at the Gnome Accessibility Project website http://developer.gnome.org/projects/gap/ under the heading Every GNOME Developer Should Read... * GNOME Accessibility for Developers : How to make GNOME 2.0 Applications Accessible * Testing GNOME Applications for Accessibility document, written by Wipro Technologies. * Making Applications Accessible (includes information on ATK support for custom widgets) Best regards, Bill The abstract, presentations, and example applications presented are available on LSR's DDC 2006 page: http://live.gnome.org/LSR/DDC06 A screencast of the LSR scripting example presented at DDC is also available: http://accessibility.freestandards.org/~gk4/a11y/ddc06/lsr-sc-ddc06.html The DDC main website for 2006 is: http://www.desktopcon.org/2006/ ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: docked window mode in GOk and SOK
On Thu, 2006-06-29 at 13:47, Chris Jones wrote: Agreed but it will do for now. Are there any plans for a new WM API. I don't think we can just leave this. The wm-spec-list@gnome.org is the place to take the discussion. Good luck convincing folks of the value of multiple docks on the same edge of the screen, though... seems like a usability misfeature. At least where GOK was concerned it seemed preferable to reduce the number of panels. The second panel in Gnome doesn't add much functionality that couldn't be achieved by just combining the two panels. Of course you can also work around this by putting both Gnome panels on the same edge of the screen, which arguably would result in better usability anyhow. I think there is value in having the onscreen keyboard sit on its own, having it share the edge with a panel means it's harder for the user to quickly scan for the desired characters. Bill On 29/06/06, Bill Haneman [EMAIL PROTECTED] wrote: Reading the gconf values isn't a fully robust solution, since the panel is not the only thing that might use _NET_WM_STRUTS. It's not apathy, it just that fixing this the right way would require new WM API. Bill On Thu, 2006-06-29 at 12:02, Chris Jones wrote: Well I think it is possible to detect if the panel is running through dbus, and it's location is stored in gconf. This should be easy to implement. I've already tested it by hardcoding an offset, all that remains to do is reading the gconf values. I don't quite understand this apathy. No other part of the desktop would put up with such an annoying bug. I don't see why it is acceptable here. On 29/06/06, Bill Haneman [EMAIL PROTECTED] wrote: Hi Chris: There's no good solution to the share a dock area problem. We recommend that you don't use both top and bottom panels when running an onscreen keyboard, for this reason. The straightforward solution is to remove either the top or bottom panel, and then use that edge to dock your keyboard. Otherwise you could waste^^H^H^spend a lot of time trying to work around this. I don't believe there's any way to put multiple docks on one edge reliably unless those docks share code (this is how gnome-panel manages this), or some new IPC is invented whereby the docks can share info (and then you have to convince all the users of _NET_WM_STRUT to implement that IPC - good luck!). The existing X API for struts just doesn't accommodate this scenario. regards, Bill On Wed, 2006-06-28 at 22:43, Chris Jones wrote: SOK is simple onscreen keyboard I am writing to compliment GOK. It is a summer of code project. I've been trying to implement a dock window mode for SOK like that which GOK has. Unfortunately my effort was met with a plethora of problems. Support for such docked windows is unpredictable under dual screens and can cause windows to get stuck or disappear etc. There's not much I can do about this but file bug reports. Attaching GOK or SOK to an edge which has a panel attached results in a focus war betwixt the two. I'm planning to work round this by reading the gconf keys for the panel and adjusting the placement of SOK accordingly. Does GOK have a solution in the pipeline? Can anyone think of a better way to go about this? -- Chris Jones jabber - [EMAIL PROTECTED] msn - [EMAIL PROTECTED] ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list -- Chris Jones jabber - [EMAIL PROTECTED] msn - [EMAIL PROTECTED] ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list -- Chris Jones jabber - [EMAIL PROTECTED] msn - [EMAIL PROTECTED] ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Fixing gnome-speech
Hi Hynek, All: I'm not sure I agree that speech engines should not do their own audio output. While I think you have identified some real problems with that approach, it's not clear that the .wav file approach has a low enough latency. If tests show that latency is not a problem, then passing the synthesized audio bits to the driver for processing (perhaps via multiplexing/mixing in most situations, or for pre-emptive audio in others) does seem to have advantages. Hynek, I think you've also identified a good reason for one of the many layers in our architecture... we don't really want a bug in the speech engine to crash our TTS service. Using a C API, even when licenses permit, usually means sharing process space with the driver, and for many drivers the code is closed-source, making diagnosis and recovery very difficult indeed. In such a situation we probably need to implement the process-space separation in our own TTS architecture, so that we can restart the engine when things go badly wrong. regards Bill On Wed, 2006-06-28 at 16:11, Hynek Hanke wrote: Festival is free software, so this is of course fixable. Having looked at the code, it's simple code and it wouldn't break if it'd be stretched a bit. But that's not improving a driver: that's improving festival (if the authors allow) and then having to depend on a very new version of it. Hi Enrico, also the problem with speech engines doing their own audio output (apart from what you said about Festival) is that this audio output needs to be configured at several places if several engines are used, many places where code needs to be updated if a new audio technology comes etc. [...] So the proper way to implement a festival driver seems to me to use the text-to-wave function and then do a proper handling of playing the resulting wave, hopefully using the audio playing technology that's trendy at the moment. Yes, I agree. Actually this is what both Speech Dispatcher and KTTSD are doing and I think I've heard Gnome Speech would also like to go this way in the future. I looked into esd without understanding if it is trendy anymore, and I look at gstreamer without understanding if it isn't a bit too complicated as a default way to play a waveform. This is fairly complicated. I've investigated into possibilities for audio output and I've ended up sumarizing our requirements if such a technology should eventually come in the future and writing my own small library for output to OSS, Alsa and NAS. Please see http://lists.freedesktop.org/archives/accessibility/2005-April/49.html and feel free to have comments. One of the problems is the latency we need. That ruled out both ESD and Gstreamer at that time, I'm not sure what is the state now with Gstreamer. Another thing is that if we are aiming for a desktop independent speech technology, we need desktop independent audio output. I don't know much about the APIs of other speech engines. If they all had a text-to-wave function Most of the engines do. Some don't, but this is their drawback (what if I want to have the audio synthesized and save to a file?). As you said, it is very desirable to retrieve the audio for those engines that support it. , then it can be a wise move to implement a proper audio scheduler to share among TTS drivers, which could then (reliably) support proper integration with the audio system of the day, progress report, interruption and whatever else is needed. This would ensure that all TTS drivers would have the same (hopefully high) level of reliability wrt audio output. Yes, that is mine dream too! Would you be wiling to help with this? I think we would first have to see what is new and consider the options again. Now, one of the big problems is that Festival doesn't offer proper logs. It would often refuse connection for a stupid typo in the configuration file and not give any clue to the user. This is something which should be fixed. This can probably be fixed: festival can be told not to load any config file This is not really useful. Configuration is really needed. , and log can be implemented adding a couple of printfs before calls to the C++ API. That is the log from the side of the speech api provider (Gnome Speech etc.). This already exists in Dispatcher and as I said is automatic from a TCP API. I was talking about logs on the side of Festival. You will never be able to discover why a particular voice was not loaded/doesn't work, why a sound icon is not playing, what is the typo in your configuration files, why is it not finding a module (wrong path) and such from just talking to Festival via its API (be it C++ or TCP). Currently the only way for the users to fix such problems is to run Festival from command line and hope it will write some cryptic message to stderr. Then what is left are guesses, past experiences with problems and
Re: docked window mode in GOk and SOK
Hi Chris: There's no good solution to the share a dock area problem. We recommend that you don't use both top and bottom panels when running an onscreen keyboard, for this reason. The straightforward solution is to remove either the top or bottom panel, and then use that edge to dock your keyboard. Otherwise you could waste^^H^H^spend a lot of time trying to work around this. I don't believe there's any way to put multiple docks on one edge reliably unless those docks share code (this is how gnome-panel manages this), or some new IPC is invented whereby the docks can share info (and then you have to convince all the users of _NET_WM_STRUT to implement that IPC - good luck!). The existing X API for struts just doesn't accommodate this scenario. regards, Bill On Wed, 2006-06-28 at 22:43, Chris Jones wrote: SOK is simple onscreen keyboard I am writing to compliment GOK. It is a summer of code project. I've been trying to implement a dock window mode for SOK like that which GOK has. Unfortunately my effort was met with a plethora of problems. Support for such docked windows is unpredictable under dual screens and can cause windows to get stuck or disappear etc. There's not much I can do about this but file bug reports. Attaching GOK or SOK to an edge which has a panel attached results in a focus war betwixt the two. I'm planning to work round this by reading the gconf keys for the panel and adjusting the placement of SOK accordingly. Does GOK have a solution in the pipeline? Can anyone think of a better way to go about this? -- Chris Jones jabber - [EMAIL PROTECTED] msn - [EMAIL PROTECTED] ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [g-a-devel] Slow keys dialog
Hi Chris: I'll try to respond to each of your points in turn: On Tue, 2006-06-27 at 00:51, Chris Jones wrote: But this very same thing makes it very awkward who want sticky keys on the keyboard and non-sticky on a physical. Which would be true for all non-a11y users and some a11y users. I don't understand what you are saying here, the very same thing. My suggestion to use XKB client API would make it quite feasible for the physical keyboard to be non-sticky and for the onscreen keyboard to be sticky. Please re-read my post and check the XKB APIs. If after investigating it you still can't find what you are looking for, email me and I will try to assist - but you should read section 10.6 of the XKBlib manual first. In the end though the only manner it interferes with my keyboard is the annoying dialogue that pops up, and the average gnome-ally user will probably be plenty used to seeing annoying dialogs anyway. The dialog pops up because you are indeed turning on SlowKeys. This is because of the way in which you are implementing sticky-keys in your application. What you should avoid is generating a key-press without a following key-release, since this triggers SlowKeys just as it does when you press and hold the Shift key on the physical keyboard. Perhaps you are talking about some other dialog as well? I'm afraid it's not clear from your messages. The slow keys dialogue however is another matter though. Normal operations are not resumed until it is dismissed. Which in itself incredibly annoying. Without it, the keyboard would silently begin to require long press and hold sequences in order to work; this is necessary for users with some types of disabilities, but it's essential that the end user be warned when the keyboard's behavior is being changed in this way (in response to end user action, which is the case here). When planning the SOK I wanted to stay away from the three odd dialogs that GOK pops up when it is started. The plain fact is I don't want any dialogs when starting SOK. At all. You can make GOK suppress those warnings I believe. If you do get them, READ THEM, they are telling you that your system has serious configuration issues which may make GOK unusable! Using the system wide sticky keys means I need to have at least one dialog box when my keyboard starts and is therefore completely unacceptable. This isn't at all true. You can easily programmatically turn this feature on when your keyboard starts, and turn it off when it exits - you can even turn the feature on and off when the mouse enters and leaves your keyboard, if that's what you want. Bear in mind that ANY onscreen keyboard that uses the mouse will fail to work properly when used to pop up menus, etc. via keyboard navigation, because of system toolkit pointer grabs. Are you aware of that fact? It will strike your onscreen keyboard as well. This is the reason for GOK's somewhat brittle configuration requirements, and the reason you are warned not to use GOK via the system core pointer. Bill On 26/06/06, Bill Haneman [EMAIL PROTECTED] wrote: On Mon, 2006-06-26 at 22:28, Henrik Nilsen Omma wrote Chris Jones wrote: ... In other words I cannot spend the summer making gnome-a11y suitable for my needs. What I need is a temporary work around until after the SoC when I could find time to work on this aspect of gnome-a11y and fix my program so it is not an accessibility violation. Chris, Can you not simply make SOK remember that shift was pressed and keep the state internally in SOK? IOW: We tried this with GOK at an early stage and it was not satisfactory. It also clashed badly with StickyKeys. It doesn't make sense to build an onscreen keyboard and then not expect disabled users to try and use it, and they will rightly complain if it conflicts with StickyKeys. If you really are unwilling to turn on the global StickyKeys gconf key while the onscreen keyboard is posted, or at least when the pointer is inside it... (and I really do not understand why this would be a problem) there is XKB ABI which you can use to change the latch/lock status of individual modifier keys. This should do exactly what you want without making StickyKeys active for the physical keyboard. google for XKBlib.pdf to find the XKB client manual, I believe it's section 10.6 that has the relevant client APIs. regards Bill 1. when the user clicks shift you set a flag. When a letter is clicked SOK sends shift+letter+unshift to X and removes the flag. 2. When shift is clicked twice you set a sticky flag. Again, each time the user clicks a letter, SOK sends shift+letter+unshift. When shift is clicked again you unset the flag. That way you avoid triggering slow keys and avoid making an 'accessibility violation'. Bill, is it an accessibility violation to have unusable accessibility tools? - Henrik
Re: [g-a-devel] Slow keys dialog
On Tue, 2006-06-27 at 01:42, Peter Korn wrote: Hi Chris, One more thing. You write: Using the system wide sticky keys means I need to have at least one dialog box when my keyboard starts and is therefore completely unacceptable. Have you filed an RFE on this issue (seeking a way to invoke the system-wide Sticky-Keys functionality programatically without the user dialog box), This is trivial to do. If you modify the key via gconf API, either by linking to gconf or just spawning a gconftool-2 command line, then you can change these settings without triggering the warning dialogs. If this has somehow regressed (it has worked on every system I know of, for several years), then a bug needs to be filed. Billy or are you simply trying to work around it? I would hope that part of a SoC project is to at least file bugs/RFEs for things you want, even if you work around them for the purposes of meeting a project deadline. I would hope that filing bugs/RFEs is part of the purview of SoC projects. Regards, Peter Korn Accessibility Architect, Sun Microsystems, Inc. Hi Chris, I think there are two issues here. Well, three: 1. Can an on-screen keyboard implement sticky modifiers without using the system support for sticky modifiers? 2. Can an on-screen keyboard circumvent/disable the system support for sticky modifiers (and slow keys, and...)? 3. Is the right way to fix what is broken in GOK doing another project rather than working with the existing GOK code to fix those broken things? I suggest that #3 may be somewhat religious at this point; I'm personally saddened that we aren't at least looking seriously at GOK improvements, but fundamentally a goal of UNIX accessibility is to foster the development of a rich accessibility ecosystem - and a rich ecosystem has room for multiple approaches to similar problems (cf. Orca and Gnopernicus and LSR). I have no issues with #1 - I see no reason why an on-screen keyboard cannot have its own way of making certain modifiers sticky on its own user interface *without* doing so through the system-wide setting mechanisms. Such a decision is I think a valid user-interface policy decision of an individual application. However, it is a direct Section 508 violation for an application to override or ignore system-wide accessibility settings. It is even more egregious for an application that claims to be at least in part for people with disabilities (and thus an 'enlightened' application) to do so. So, my suggestion is that if you simply cannot possible use the system-settings for sticky keys as part of your own UI, that you make things sticky your own way; however that if the system-wide settings are on that you use and respect those (complete with the dialog box that you seem to dislike). Regards, Peter Korn Accessibility Architect, Sun Microsystems, Inc. But this very same thing makes it very awkward who want sticky keys on the keyboard and non-sticky on a physical. Which would be true for all non-a11y users and some a11y users. In the end though the only manner it interferes with my keyboard is the annoying dialogue that pops up, and the average gnome-ally user will probably be plenty used to seeing annoying dialogs anyway. The slow keys dialogue however is another matter though. Normal operations are not resumed until it is dismissed. Which in itself incredibly annoying. When planning the SOK I wanted to stay away from the three odd dialogs that GOK pops up when it is started. The plain fact is I don't want any dialogs when starting SOK. At all. Using the system wide sticky keys means I need to have at least one dialog box when my keyboard starts and is therefore completely unacceptable. On 26/06/06, Bill Haneman [EMAIL PROTECTED] wrote: On Mon, 2006-06-26 at 22:28, Henrik Nilsen Omma wrote: Chris Jones wrote: ... In other words I cannot spend the summer making gnome-a11y suitable for my needs. What I need is a temporary work around until after the SoC when I could find time to work on this aspect of gnome-a11y and fix my program so it is not an accessibility violation. Chris, Can you not simply make SOK remember that shift was pressed and keep the state internally in SOK? IOW: We tried this with GOK at an early stage and it was not satisfactory. It also clashed badly with StickyKeys. It doesn't make sense to build an onscreen keyboard and then not expect disabled users to try and use it, and they will rightly complain if it conflicts with StickyKeys. If you really are unwilling to turn on the global StickyKeys gconf key while the onscreen keyboard is posted, or at least when the pointer is inside it... (and I really do not understand why
Re: Fixing gnome-speech
On Tue, 2006-06-27 at 10:57, Olivier BERT wrote: I'm currently working on Speech Dispatcher backend for Orca. This bypasses the Gnome Speech layer completely. Since Speech Dispatcher offers several speech synthesizers not supported by Gnome Speech, Does Speech Dispatcher support something other than Festival now? Gnome-speech has support for quite a few speech engines including some commercial ones with much clearer speech. Unfortunately one of the best values and clearest sounding options, 'Theta' from Cepstral, has been obsoleted by the new Cepstral Swift engine; we need someone to port the Theta support over the Cepstral. While free voices and engines are really important, for some users clarity of speech is paramount, so it's important to have support for at least the less expensive non-free TTS engines. I don't have any objection to using Speech Dispatcher as a common back-end, if there are more resources available to keep it up to date compared to gnome-speech. But we shouldn't move over entirely until we have comparable driver support. One area where Speech Dispatcher seems to be ahead is in support for non-English Festival voices, but I think that testing is the only impediment to using the non-Engish voices in gnome-speech as well (the Festival API is the same in either case). regards Bill this may be essential for some people and the Orca - Gnome Speech - Speech Dispatcher - synthesizer aproach has inherent problems. This might solve your problem too. Please, see also the common TTS API draft at http://www.freebsoft.org/tts-api. This is a common effort of Free Desktop and FSG. Very very good idea. Unfortunately, gnome-speech was not very stable, sometimes speech randomly stops. And it's true that it will optimize the speech chain. orca - gnome speech - speech-dispatcher - synthesis was quite long :) And so, it must be nearly impossible to debug it. So thanks very much Tomas for this work ! -- Olivier BERT e-mail: [EMAIL PROTECTED] Etudiant a l'E.P.I.T.A. (cycle ingenieur, 3eme annee) Tel: 06 07 69 79 71 ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [g-a-devel] Slow keys dialog
On Tue, 2006-06-27 at 16:03, Chris Jones wrote: The very same thing refers to where you say that disabled users will complain if the onscreen keyboard conflicts with sticky keys. What I am trying to say is that an onscreen keyboard should work whether sticky keys is on or not. By its very nature, an onscreen keyboard (which will be emulating physical keypresses) will interact with the physical keyboard driver and settings. This means that interoperability with things like XKB is just a requirement of the task at hand. Surely an application changing system wide settings just so it can run, is an accessibility violation as the user might rely on non-sticky behaviour on the physical keyboard. In other words one input device should not change the behaviour of all the others. I have suggested several alternatives. It is folly to create an onscreen keyboard which emulates physical keypresses and then pretend that it is independent of the physical keyboard - it's just not realistic, since you'll be using Xtest Fake API to fake key presses anyway. You keep referring to xkblib. To get this to work I would have to change the x config to have an extra keyboard device. That is not true! The XTest api I am currently using does not allow me to specify which keyboard device I am emulating either. I have difficulty seeing how I could use this. Have you read the document section which I recommended to you? It allows you to programmatically change the latch state of specific modifiers, WITHOUT simulating a press-and-hold. It allows you to do this in a way that does not change the way the physical keyboard works, and doesn't trigger any warning dialogs. XKB is available by default on the XOrg server, so you shouldn't need to change your X configuration at all. I understand the need for the dialogs. If the system-wide settings are changing then I agree a dialog is needed. This is yet another reason why I do not want to change the system wide settings. The dialog does not post anytime the system-wide settings change - it only posts in response to a change which it believes comes from the SlowKeys or StickyKeys keyboard gesture. As long as your keyboard latches keys by simulating a key press and then simulating a release at a later time in the future, you will collide with this dialog, because you are invoking the SlowKeys gesture. Period. If you don't like that you can turn off the keyboard shortcuts, i.e. make it so that holding the shift key down doesn't turn on SlowKeys; however you should not make that the default for new users. I can see why GOK behaves as it does. My opinion though is that it is not acceptable, another method must be found to solve the issue. We'll be able to help you better if you are a little more open to our suggestions. Bill Bill Haneman said: Bear in mind that ANY onscreen keyboard that uses the mouse will fail to work properly when used to pop up menus, etc. via keyboard navigation, because of system toolkit pointer grabs. Are you aware of that fact? It will strike your onscreen keyboard as well. This is the reason for GOK's somewhat brittle configuration requirements, and the reason you are warned not to use GOK via the system core pointer. I find this difficult to understand, surely pop up menus are a pointer operation to begin with, and that it is possible to emulate this with a physical keyboard. I fail to see the point of emulating this emulation with a pointer. Except if one was using a pointer to emulate a scanning device. Perhaps it would make more sense to disconnect the core pointer when GOK enters it's scanning mode? Maybe it is just impossible to design a one-size fits all onscreen keyboard. As evidenced by GOK, the result is a keyboard that is accessible to everyone but usable by no-one. On 27/06/06, Bill Haneman [EMAIL PROTECTED] wrote: On Tue, 2006-06-27 at 01:42, Peter Korn wrote: Hi Chris, One more thing. You write: Using the system wide sticky keys means I need to have at least one dialog box when my keyboard starts and is therefore completely unacceptable. Have you filed an RFE on this issue (seeking a way to invoke the system-wide Sticky-Keys functionality programatically without the user dialog box), This is trivial to do. If you modify the key via gconf API, either by linking to gconf or just spawning a gconftool-2 command line, then you can change these settings without triggering the warning dialogs. If this has somehow regressed (it has worked on every system I know of, for several years), then a bug needs to be filed. Billy or are you simply trying to work around it? I would hope that part of a SoC project is to at least file bugs/RFEs for things you want, even if you work around them for the purposes of meeting a project deadline. I would hope that filing bugs/RFEs is part of the purview of SoC projects
Re: [g-a-devel] Slow keys dialog
Hi Chris: The answer is, don't implement sticky keys in your keyboard. You should be using the system-wide StickyKeys settings and feature instead (as GOK does). Interfering with the normal operation of the system wide setting (i.e clashing with it as your app does), is itself an accessibility violation. (There are several gconf keys you can use to turn sticky keys on and off - see those under /desktop/gnome/accessibility/keyboard) Bill I've implemented sticky keys in my onscreen keyboard. When shift is stuck down it causes the slow keys dialogue to appear. Is there a way to suppress this dialog whilst my app is running? thanks -- Chris Jones ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [Kde-accessibility] Use of gconf key '/desktop/gnome/interface/accessibility' on KDE ?
Hi Ashu: Currently the state of KDE accessibility is somewhat limited. Other than some important theming and keyboard-navigation support, which does not require a complex interface such as AT-SPI, there are only a few useful utilities like KMag, KMouth, and KMousetool. While these are nice utilities, they aren't enough to allow users who cannot use a keyboard at all, or who are blind or have very limited vision, to use KDE. We have three working screen readers (for blind users) for the free desktop now; gnopernicus, orca, and LSR. For users who cannot use a keyboard, we have GOK and Dasher. All of these technologies require the full power of the AT-SPI interfaces, and thus require the ORBit2 CORBA stack in order to work. The gconf key you mention is for determining whether support for such full-features assistive technologies should be enabled or not. When KDE/Qt applications provide full-featured accessibility services, as is planned for Qt4, then those services can be bridged to AT-SPI, making those applications available to screen readers and other sorts of user interface adapting assistive technologies. While it would be possible to write a KDE screen reader or KDE onscreen keyboard for severely disable users (for instance users who cannot even 'point and click' reliably), I don't think it would be the best use of our resources. Technologies like Orca are intended to work with AT-SPI-enabled KDE apps just as they work with applications like OpenOffice, Java apps, Firefox, and other applications today, not just gnome. By writing Orca scripts for popular KDE applications, the KDE desktop, and by fixing the inevitable bugs in KDE's keyboard navigation and accessibility support, a modest amount of development effort can go further to benefit disabled users. best regards Bill On Mon, 2006-06-26 at 13:30, Ashu Sharma wrote: On 6/26/06, Bill Haneman [EMAIL PROTECTED] wrote: On Mon, 2006-06-26 at 08:19, Ashu Sharma wrote: Hi, There was discussion about making use of ATK on KDE, rather than putting in another CORBA implementation to talk to AT-SPI (to avoid dependency on GNOME-related libraries). I'm not quite clear as to what was finally decided. If KDE writes to ATK, it makes the job easier in a number of ways (at the cost of introducing a glib dependency, but hiding other gnome-ish dependencies). However, the AT-SPI layer requires CORBA in order to function, so in order to actually expose useful information to our assistive technologies, an application must LD_PRELOAD the atk-bridge module which bridges from ATK to AT-SPI's CORBA IPC. I think this is the most effective thing to do for the time being (preload atk-bridge), since it doesn't introduce a CORBA dependency on the KDE apps (only a soft runtime dependency). The AT-SPI assistive technology clients cannot work without the AT-SPI/ORBit2/etc. libraries being present on the system anyhow, so from a practical perspective this is the minimum current dependency situation. There's another environment variable you can look for if you don't want to use gconf; GTK_MODULES. Of course that's still quite a gnome/gtk+-ish variable and arguably not appropriate to KDE anyhow, so it might be cleaner just to spawn a gconf-client executable and parse the output, in order to detect whether assistive technology support is desired or not. Also, soon there will be a slightly different mechanism for detecting the presence of the AT-SPI registry - it will place an IOR as an Xatom on the root DISPLAY window. This means you can find it without using bonobo-activation. regards Bill On a related note, is the gconf key '/desktop/gnome/interface/accessibility' used on KDE too, to set or find if accessibility support is to be enabled on a system? Or, is it used only on GNOME? Thanks, Ashutosh __ ___ kde-accessibility mailing list [EMAIL PROTECTED] https://mail.kde.org/mailman/listinfo/kde-accessibility Bill, Thanks for these details. I am actually wondering about the current state of KDE accessibility - whether AT clients under KDE currently depend on gnome/gconf libraries (especially if they use the gconf key '/desktop/gnome/interface/accessibility
Re: [g-a-devel] Slow keys dialog
On Mon, 2006-06-26 at 21:43, Chris Jones wrote: Thanks for your reply. The system-wide StickyKeys is too inflexible for my needs. I have the following gripes: * A user might want the onscreen keyboard to be sticky but not the physical. I am not convinced that users will really want this, perhaps this is your opinion. It is still an accessibility violation to interfere with the way the built-in keyboard accessibility features work. * It does not allow me to implement the functionality in a way that is suitable for an onscreen keyboard. My implementations uses one click to set sticky for one click of a non sticky character, a further click sets sticky until a third click or the stuck key. The system dialog settings work this way on most systems. * The sticky keys dialogue is annoying. A far better way would be to enable it in the preferences, since you must to enable assistive technology support and be notified of it's act/deactivation by a notification bubble. You can already turn this off, but it needs to be the default for new desktops/new users, in order to allow users who need it to turn it on via the keyboard shortcuts. * This is not purely a a11y project. It has other uses, tablet PCs etc. Therefore I wanted a soft dependency on assistive technologies. The StickyKeys feature is not an assistive technology, per se. However it is a standard platform feature. * GOK's implementation is very unreliable on my system, and not something I particularly want to emulate. Have you filed any bug reports? ALL onscreen keyboards will suffer from problems if they use the system core pointer for input, because of pointer grabs which virtually every GUI toolkit does. I know I should fix these gripes instead of treading my own path. However, this is a Summer of Code project and so I need to produce the expected results before a deadline. In other words I cannot spend the summer making gnome-a11y suitable for my needs. What I need is a temporary work around until after the SoC when I could find time to work on this aspect of gnome-a11y and fix my program so it is not an accessibility violation. I suggest you use the system gconf keys for sticky keys. regards Bill On 26/06/06, Bill Haneman [EMAIL PROTECTED] wrote: Hi Chris: The answer is, don't implement sticky keys in your keyboard. You should be using the system-wide StickyKeys settings and feature instead (as GOK does). Interfering with the normal operation of the system wide setting (i.e clashing with it as your app does), is itself an accessibility violation. (There are several gconf keys you can use to turn sticky keys on and off - see those under /desktop/gnome/accessibility/keyboard) Bill I've implemented sticky keys in my onscreen keyboard. When shift is stuck down it causes the slow keys dialogue to appear. Is there a way to suppress this dialog whilst my app is running? thanks -- Chris Jones ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list -- Chris Jones jabber - [EMAIL PROTECTED] msn - [EMAIL PROTECTED] ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [g-a-devel] Slow keys dialog
On Mon, 2006-06-26 at 23:05, Henrik Nilsen Omma wrote: Bill Haneman wrote: On Mon, 2006-06-26 at 22:28, Henrik Nilsen Omma wrote: Bill, is it an accessibility violation to have unusable accessibility tools? Are you going to say something helpful? OK, I should have resisted that last line, sorry. But there is a valid point under the sarcasm, which is: we are trying to make new and better tools here and it is not very helpful to then always refer back to the existing tools which really don't work. You keep saying the existing tools don't work, but you don't seem to be helping to make them work. 90% of all GOK problems are configuration issues. This is documented in the Gnome Accessibility Guide - mostly it comes down to broken-ness in the way XInput works in most systems out-of-the box. I think in the end we will have to ditch XInput where GOK is concerned, but although several research projects have been carried out to try and identify alternatives, we haven't found one that really fits the bill. Henrik, I thought it was part of your job to do QA and testing of Ubuntu accessibility... so I would hope you would be interested in helping work towards solutions. Building a new onscreen keyboard that doesn't meet the needs of disabled users isn't the right solution in my opinion. Did you even investigate GOK's configurability? I really believe that there are multiple ways in which GOK could have been used to solve the problem you are apparently attempting to solve, but I know for a fact that you didn't have any in-depth discussions with the maintainers. Bill - Henrik ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [g-a-devel] Slow keys dialog
On Mon, 2006-06-26 at 22:28, Henrik Nilsen Omma wrote: Chris Jones wrote: ... In other words I cannot spend the summer making gnome-a11y suitable for my needs. What I need is a temporary work around until after the SoC when I could find time to work on this aspect of gnome-a11y and fix my program so it is not an accessibility violation. Chris, Can you not simply make SOK remember that shift was pressed and keep the state internally in SOK? IOW: We tried this with GOK at an early stage and it was not satisfactory. It also clashed badly with StickyKeys. It doesn't make sense to build an onscreen keyboard and then not expect disabled users to try and use it, and they will rightly complain if it conflicts with StickyKeys. If you really are unwilling to turn on the global StickyKeys gconf key while the onscreen keyboard is posted, or at least when the pointer is inside it... (and I really do not understand why this would be a problem) there is XKB ABI which you can use to change the latch/lock status of individual modifier keys. This should do exactly what you want without making StickyKeys active for the physical keyboard. google for XKBlib.pdf to find the XKB client manual, I believe it's section 10.6 that has the relevant client APIs. regards Bill 1. when the user clicks shift you set a flag. When a letter is clicked SOK sends shift+letter+unshift to X and removes the flag. 2. When shift is clicked twice you set a sticky flag. Again, each time the user clicks a letter, SOK sends shift+letter+unshift. When shift is clicked again you unset the flag. That way you avoid triggering slow keys and avoid making an 'accessibility violation'. Bill, is it an accessibility violation to have unusable accessibility tools? - Henrik ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Gnome Accessibility - Bill Haneman will be on leave from 1 April to 1 June, 2006
Hi Everyone: As a few of you may already be aware, I will be on a leave of absence for two months, starting immediately after today. In my absence, please direct questions regarding Gnome accessibility to the gnome-accessibility-list@gnome.org, and questions specific to accessibility development to [EMAIL PROTECTED] Patrick Wade of Sun will be helping facilitate during my absence, but I am sure that he would be very grateful of any technical assistance which other members of the community can provide in order to keep things on track for Gnome 2.14.1 and the upcoming 2.15 series. In preparation for my leave I have updated the Gnome Accessibility website (http://developer.gnome.org/projects/gap) to be a little more readable and, I hope, to point developers to the resources which we have available. We certainly hope to continue upgrading our developer documentation going forward. I have also updated the ATK and AT-SPI documentation in the just-released atk-1.11.4 and at-spi-1.7.7 releases, including doxygen HTML docs for the AT-SPI IDL. Links to online versions of these docs are available on the 'GAP' website above (though the latest ATK docs will probably still be found in the tarball, since the online docs are for the 1.11.0 version, which contained numerous documentation deficiencies). While I'll mostly be off the air during this period, and will unsubscribe from most mailing lists, I will occasionally check on status of any urgent matters, and will continue to attend meetings of the Free Standards Group which are aimed at moving the cause of desktop accessibility forward in a standards-based and readily shareable way. Thanks to everyone for their continued support, Best regards Bill ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Question about Orca and gnopernicus.
Hi Satyam: In the case of gnopernicus and orca (which are the two freely available screenreaders for our graphical platform today), as Samuel said, not every user prefers a given screen reader. One of the things which orca provides, which gnopernicus does not, is comprehensive application-specific scripting. Gnopernicus on the other hand offers some features, especially regarding magnification and a large configuration GUI, which orca does not have. Both screenreaders are under current development, so the gaps may narrow or widen. Best regards, Bill On Wed, 2006-03-29 at 07:33, Samuel Thibault wrote: Hi, satyam, le Wed 29 Mar 2006 06:46:37 +0530, a écrit : I have a question regarding gnopernicus, Orca and open office.org Why there should be many screen readers? One of the reasons is that people often find existing software not suited to their needs, and hence write their own software. Regards, Samuel ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Festival vs. F-lite disk space requirements
Henrik: I think Flite uses the same file format. ( Will, please correct me if I'm wrong). It also requires a Java JRE, are you planning to include Java in the live CD? BTW, in the past, Java was required for OpenOffice.org accessibility, but that's not true of the latest version. Bill On Fri, 2006-02-24 at 12:25, Henrik Nilsen Omma wrote: Hello, We are working on packaging screen reader support for the Ubuntu Live CD, but have gotten ourselves a little confused regarding file sizes ... Being a Live CD we are quite limited on disk space. We were thinking that we should use the smaller F-lite, rather than the full Festival, assuming it had smaller speech files. However, because gnome-speech doesn't have direct support for F-lite we also needed to include speech dispatcher (and gnome-speech from CVS), so it begins to grow. Can anyone shed some light on the relative space requirements of Festival vs. F-lite? Does Festival include all it's supported languages by default or are they packaged separately (as packaged in Debian)? We would be happy to settle for English-only support this time around. Thank you. Any advice will be greatly appreciated. - Henrik ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Festival vs. F-lite disk space requirements
On Fri, 2006-02-24 at 13:09, Henrik Nilsen Omma wrote: Bill Haneman wrote: Henrik: I think Flite uses the same file format. ( Will, please correct me if I'm wrong). By same format you mean the same speech files? So what is the main benefit of F-lite, a smaller memory footprint? (and java cross-platformness) It also requires a Java JRE, are you planning to include Java in the live CD? Arrgh, sorry, I was thinking of FreeTTS, which was a sort of direct descendant of Flite. The flite docs imply that you can use voices built with FestVox, but I guess you have to compile them into Flite somehow: http://www.speech.cs.cmu.edu/flite/index.html Uh, no. I though it compiled with gcj like OpenOffice. The accessible OpenOffice setup required a Sun JDK (I believe it doesn't anymore though, with latest bits). I think Flite has some performance optimizations, speed-wise, and a smaller footprint. The latest released version, 1.3, seems to be about a year old. Sorry for the confusion. Bill Looks like we were even farther afield with this than I first expected ... Thanks Bill. - Henrik ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Gnome question
On Tue, 2006-02-21 at 01:21, Davyd Madeley wrote: Quoting Dana Olson [EMAIL PROTECTED]: Will Gnome have some method to disable Slow Keys from constantly popping up when you hold down a key for a few seconds? You can turn this off from the Keyboard Accessibility preferences dialog. As you point out, this currently turns off MouseKeys as well, which is a mis-feature. I've already filed a bug about this http://bugzilla.gnome.org/show_bug.cgi?id=131339 but there seemed to be some resistance to implementing the change. The correct behavior would be to get rid of the Enable keyboard accessibility features checkbox, and instead, add a Enable keyboard shortcuts for SlowKeys and StickyKeys checkbutton to the Basic page of the dialog. That would map properly onto the XKB feature set, whereas the current dialog doesn't. Best regards, Bill The most annoying part about it is that it doesn't seem to remember that I set it to 0, and when it pops up, it activates automatically, and THEN asks me if I want it activated or not. In fact, I don't even want it to pop up at all. But I can't disable it, at least not without disabling Mouse Keys, which I currently rely on. Maybe I am missing something, but I think there are several design flaws with this feature, especially the shoot first, ask questions later part. I'm not entirely sure, I haven't got a lot of experience with the keyboard accessbility features built into GNOME. I have CC'ed your email to the GNOME A11y list, someone there should better be able to help you. --d ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Problem with gnopernicus and dectalk
On Sun, 2006-02-12 at 22:27, Luke Yelavich wrote: ... Did you specify the prefix for the gnopernicus configure script? For example ./configure --prefix=/usr? if you didn't, I have a feeling that is why it can't find the DECtalk server but test-speech can. Luke/all: gnopernicus doesn't use configure to find the dectalk server at all. If test-speech can find it, then gnopernicus can find it, unless it has died or something. Bill By the way, your reply did not go to the list, but was sent straight to me. Alastair Irving e-mail: [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Luke Yelavich Sent: 12 February 2006 22:14 To: gnome-accessibility-list@gnome.org Subject: Re: Problem with gnopernicus and dectalk On Mon, Feb 13, 2006 at 08:57:24AM EST, Alastair Irving wrote: I have just installed gnopernicus and software dectalk. However, I'm not getting any speech. The dectalk is working correctly, and when I do test-speech it also works correctly. However, when I go to change the synthesisor to dectalk, (by going preferences, speech, voices, select absolute voice), the only server listed is gnome speech festival. Does anyone have any idea why this is? Surely if test-speech sees the software dectalk, then so should gnopernicus, or do they search for servers differently? Would you mind telling us what distribution you are using, and what you did to get software DEctalk set up with gnome-speech and gnopernicus? -- Luke Yelavich GPG key: 0xD06320CE (http://www.themuso.com/themuso-gpg-key.txt) Email MSN: [EMAIL PROTECTED] ICQ: 18444344 -- Luke Yelavich GPG key: 0xD06320CE (http://www.themuso.com/themuso-gpg-key.txt) Email MSN: [EMAIL PROTECTED] ICQ: 18444344 __ ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: test-speech only works for root
Hi Don: This certainly 'smells' like a permissions problem. I believe the Festival gnome-speech server relies on the ability to write to a particular port, perhaps 7000? I am sure someone else on the list can provide that detail. My guess is that root has write access to that port, but not the normal user group. Perhaps someone else recalls offhand which port Festival uses and how to quickly check those permissions... normally non-root programs can access ports numbered above 1024, but perhaps your system is set up differently? regards, Bill Donald Raikes wrote: I just installed gnome-speech-0.3 on my fedora core 3 system as a part of garnome 2.12.2.1, and now when I run test-speech (either the newly created one, or the original from the os installation), it only works for root. If i use another user, I get the message: attempting to activate OFIID:Gnome_Speech_SynthesisDriver_Festival:proto0.3 and the system hangs. Any suggestions appreciated. TIA, Don Raikes http://www.draikes.com ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [Fwd: firefox error]
Hi Ginn: Thanks for answering Naveen. Could you make sure he knows that the solution of removing GTK_MODULES is a temporary one? We are still telling accessibility users to set this variable in the environment, since they need it in order to make other important applications accessible. Best regards, Bill Ginn Chen wrote: Hi Naveen, 1) Can you tell me where did you get the build? The stack looks strange to me. gtk_init_check+0x03CC [/usr/lib/libgtk-1.2.so.0 +0x0009FF8C] gtk_init+0x0026 [/usr/lib/libgtk-1.2.so.0 +0x000A0106] _Z8xre_mainiPPcPK12nsXREAppData+0x0515 [./firefox-bin +0x0001555D] Is it a gtk-1.2 build? Generally, only firefox gtk2 builds support ATK. You can get night builds from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ It should work. 2) Firefox/Mozilla doesn't like GTK_MODULES settings. See https://bugzilla.mozilla.org/show_bug.cgi?id=312092 You should not set GTK_MODULES. Anyway, with nightly builds, firefox will strip 'at-bridge' out from GTK_MODULES. For any questions, feel free to ask. Thanks, Ginn On Jan 24, 2006, at 3:50 AM, Peter Korn wrote: Greetings, This appeared today in gnome-accessibility-list@gnome.org mailto:gnome-accessibility-list@gnome.org. Anyone in Beijing care to answer it? Peter *From: *Naveen Kumar [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] *Date: *January 23, 2006 4:35:23 PM CST *To: [EMAIL PROTECTED] mailto:gnome-accessibility-list@gnome.org *Subject: **firefox error* Hi, After setting the GTK_MODULES environment variable using the command export GTK_MODULES=gail:atk-bridge I got the following error when I invoked firefox :- /**/ GTK Accessibility Module initialized GLib-GObject-CRITICAL **: gtype.c:2254: initialization assertion failed, use IA__g_type_init() prior to this function GLib-GObject-CRITICAL **: gtype.c:2254: initialization assertion failed, use IA__g_type_init() prior to this function GLib-GObject-CRITICAL **: gtype.c:2254: initialization assertion failed, use IA__g_type_init() prior to this function GLib-GObject-CRITICAL **: gtype.c:2254: initialization assertion failed, use IA__g_type_init() prior to this function (process:2167): GLib-GObject-CRITICAL **: g_type_add_interface_static: assertion `G_TYPE_IS_INSTANTIATABLE (instance_type)' failed GLib-GObject-CRITICAL **: gtype.c:2641: initialization assertion failed, use IA__g_type_init() prior to this function GLib-CRITICAL **: file gstrfuncs.c: line 186 (g_strconcat): assertion `string1 != NULL' failed. GLib-GObject-CRITICAL **: gtype.c:2254: initialization assertion failed, use IA__g_type_init() prior to this function GLib-GObject-CRITICAL **: gtype.c:2254: initialization assertion failed, use IA__g_type_init() prior to this function GLib-GObject-CRITICAL **: gtype.c:2254: initialization assertion failed, use IA__g_type_init() prior to this function (process:2167): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed GLib-GObject-CRITICAL **: gtype.c:2254: initialization assertion failed, use IA__g_type_init() prior to this function ** CRITICAL **: file atkregistry.c: line 100 (atk_registry_new): assertion `ATK_IS_REGISTRY (object)' failed GLib-GObject-CRITICAL **: gtype.c:2254: initialization assertion failed, use IA__g_type_init() prior to this function --- --- GLib-GObject-CRITICAL **: gtype.c:2254: initialization assertion failed, use IA__g_type_init() prior to this function ** CRITICAL **: file atkregistry.c: line 100 (atk_registry_new): assertion `ATK_IS_REGISTRY (object)' failed GLib-GObject-CRITICAL **: gtype.c:2254: initialization assertion failed, use IA__g_type_init() prior to this function ** CRITICAL **: file atkregistry.c: line 137 (atk_registry_set_factory_type): assertion `ATK_IS_REGISTRY (registry)' failed Program ./firefox-bin (pid = 2167) received signal 11. Stack: UNKNOWN [/lib/libpthread.so.0 +0xB825] UNKNOWN [/lib/libc.so.6 +0x000296F8] g_signal_lookup+0x0039 [/usr/lib/libgobject-2.0.so.0 +0x00014D29] UNKNOWN [/usr/lib/libgail.so +0x00013087] atk_add_focus_tracker+0x0084 [/usr/lib/libatk-1.0.so.0 +0x00015962] UNKNOWN [/usr/lib/libgail.so +0x00013C24] gtk_module_init+0x000B [/usr/lib/libgail.so +0x00013CB4] gtk_init_check+0x03CC [/usr/lib/libgtk-1.2.so.0 +0x0009FF8C] gtk_init+0x0026 [/usr/lib/libgtk-1.2.so.0 +0x000A0106] _Z8xre_mainiPPcPK12nsXREAppData+0x0515 [./firefox-bin +0x0001555D] main+0x0038 [./firefox-bin +0x000106AC] __libc_start_main+0x00C6 [/lib/libc.so.6 +0x00015E36] Sleeping for 5 minutes. Type 'gdb ./firefox-bin 2167'
Re: gnopernicus autogen.sh question
Hi Jude: Are you sure you have gnome-common installed? Looks to me as though you are missing the 'gnome-autogen.sh' script which I believe is provided with gnome-common. Gnome-common is a dependency of ALL gnome cvs builds. Bill Jude DaShiell wrote: After having checked gnopernicus and dependencies out of cvs repository, I ran autogen.sh and got an error on line 9 no such file found and this also happened with the at-spi script on line 10. I have automake1.8 with dependencies on this system now too. There is an earlier version of gnopernicus on this machine and if you're not careful available for downloadtoo from the debian repsitory. I decided to try and stack the deck with this approoach and am using kenel 2.4 x if that helps. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Dummy speech driver
Hi Pedro: While I think this has been suggested before, I think that it is a good idea; especially if it's designed to allow sending the output to a named pipe, serial port, or perhaps even convert to HTTP and send output that way. It would allow more ways to debug the speech output itself. If you need help creating such a speech driver, let me or Will Walker know and I'll try to send comments. Best regards, Bill Pedro de Medeiros wrote: Hi, I was wondering if it would be interesting to have a dummy speech driver in gnome-speech that sends text as output, so one could send it to a named pipe, a program or a line printer. Or one could use it to simplify debugging gnopernicus without recompiling, reinstalling, removing etc. What do you think? Cheers. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: At-SPI client and server running in different hosts
svs drozo wrote:
Hi,
I would need to set up an environment in which two different hosts have
the two parts of at-spi, I mean, the clients in one of them and the
server in the other, is that possible? How can I do it?
Hi:
If you only want the client to be on one host, and the applications and
the at-spi registry daemon on the other, then all you need is for your
AT client to have a reference to the remote registry. Instead of using
the usual way of obtaining the at-spi registry (which uses
bonobo-activation, and only finds registries on the local host), you can
obtain the registry instance by creating a stringified version of the
registry IOR, passing that string to your client's host somehow (how you
do this is up to you), and then calling the string_to_object() method
of your ORB. This means a little bit of extra coding on your part, but
not much.
In python for example, you couldd use something like this on the
at-spi-registry side to write the string to a file (shared over NFS
perhaps?):
f = file('echo.ref', 'w+')
print f, orb.object_to_string(registry)
f.close()
Of course any way of getting a string from one host to another could be used. So on the server side you must
write a small piece of code which does exactly this, obtains a reference (IOR) to the at-spi-registry in the
usual way, then exports it as a stringified IOR.
Then on the AT client side, you need to make a small change; instead of using the usual bonobo-activation-based
method for obtaining a reference to the at-spi-registryd Registry, you instead call a piece of code which
reads the string from the server-host and calls orb.string_to_object to get a
valid IOR from that string.
From there on, everything should work as normal (as long as the client always uses this cached IOR for the registry,
obtained via this alternate means.
Hope that helps,
Bill
Thx.
Best regards.
___
gnome-accessibility-list mailing list
gnome-accessibility-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
___
gnome-accessibility-list mailing list
gnome-accessibility-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Testing plan
Henrik/All: Sorry for re-posting the URI for the sanity-test documents, I see now that you referenced them inline. Thanks a bunch! I look forward to reading your test scheme. Bill ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: detailed review of GOK
Henrik Nilsen Omma wrote: Hi all, I've written up a fairly detailed review of GOK here: https://wiki.ubuntu.com/Accessibility/Reviews/GOK It is meant partially as an introduction to those who don't know the program, but mainly as a critical look that can hopefully stimulate discussion and further development. Hi Henrik! Thanks for that detailed review. I do agree that many of your problems seem to have stemmed from integration/configuration issues, or missing understanding of some issues unique to GOK. I disagree with some of your assessments, as no doubt you would anticipate. I look forward to clarifying some of them. In a number of cases, there are dependencies which no client program attempting to do what GOK is doing can avoid. StickyKeys is a case in point; it is not technically feasible to implement sticky-keys-like functionality in the client alone. Likewise, it is not technically possible to make a reliable point-and-click onscreen keyboard using the system core pointer, using today's X server and widget toolkits. Please contact me directly about how I can help with the Wiki. best regards, Bill - Henrik Ubuntu Accessibility Team ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: detailed review of GOK
Hi Henrik: The reason that StickyKeys is needed is not only because of general key combinations like the one you mention (Control-Alt-X) but also because of the interaction with CapsLock, etc. In general the only way to accurately reflect what the X server will do with key events is to ask the x server, so the client application can't do a good job of simulating the real physical keyboard without StickyKeys. I suppose a mostly works equivalent could be provided without StickyKeys, but it would not work with all applications and the resulting bugs would be very confusing to explain to the user. Since XKB and StickyKeys are available on virtually every X platform now, it makes sense to just require it. However, the sticky keys notification dialog still makes sense IMO, because any client which causes the user's physical keyboard to behave differently should probably let the user know about it. In a number of cases, there are dependencies which no client program attempting to do what GOK is doing can avoid. StickyKeys is a case in point; it is not technically feasible to implement sticky-keys-like functionality in the client alone. Is that because we are talking about a very general implementation that can feed any key combination (Ctrl-Alt-X) to any part of the desktop? I guess just providing for upper case ( and [ * etc.) would be easier (but not as useful). Likewise, it is not technically possible to make a reliable point-and-click onscreen keyboard using the system core pointer, using today's X server and widget toolkits. Hm. I seem to remember using GTKeyboard some time ago on a tablet PC with much less fuss. I think that is GTK1 though, and probably won't compile with Gnome 2. I think you would find that GTKeyboard acted oddly or failed to work at all with certain key combinations. For instance, if you invoke a menu using a keyboard shortcut, GTKeyboard would stop working; there are many similar situations where a simple point-and-click keyboard using the core pointer is bound to fail.There are two reasons; in some cases the pointer will be grabbed by another application, making dwell mode useless and causing point-and-click mode to behave oddly; and secondly, clicking a mouse button causes a number of desktop features to change state, for instance StickyKeys resets on mouse click, menus may un-post, etc. etc. If all you are doing is clicking on alphanumeric characters in a text field, things will mostly work, but if you are using non-alphanumeric keys, keyboard shortcuts, or posting menus, things will start to act strange if you are using the system core pointer to interact with any onscreen keyboard on the X Windows system. Bill - Henrik ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [g-a-devel] Unable to run latest CVS snapshot of orca.
Answer is yes, because at-spi-registryd has an open connection to the X server and thus will exit if the Xserver dies. You are right about bonobo-activation-server sometimes hanging around between logins. I think the latter is a bug. Bill Willie Walker wrote: Hi Bill: Is it the case that the AT-SPI registry will be guaranteed to quit when you restart the X Server? My hope has always been that the answer is yes, but I'm not sure this always is true -- I've run into situations (I think) where bonobo activation and other processes seem to just hang around and I need to either reboot or go through a process of killing them one by one. Will On Dec 7, 2005, at 11:25 AM, Bill Haneman wrote: Janina's right of course, just restarting the X server (or logging out!) should have solved the problem. It's probably a good idea to log out and back in after replacing a core component like the at-spi-registry anyway. best regards, Bill Janina Sajka wrote: Luke Yelavich writes: On Thu, Dec 08, 2005 at 12:53:12AM EST, Willie Walker wrote: Yikes - I've seen this before, and if I remember correctly, it's because the AT-SPI Registry is corrupt. Have you tried rebooting? Yes that helped, thanks. For the record, wouldn't restarting X accomplish the same result? I'm thinking Ctrl-Alt-Backspace? I'd hate to see our environment degrade to the primitive resolutions employed in that other OS ... -- Luke Yelavich GPG key: 0xD06320CE (http://www.themuso.com/themuso-gpg-key.txt) Email MSN: [EMAIL PROTECTED] ICQ: 18444344 ___ Gnome-accessibility-devel mailing list Gnome-accessibility-devel@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [g-a-devel] Unable to run latest CVS snapshot of orca.
Janina's right of course, just restarting the X server (or logging out!) should have solved the problem. It's probably a good idea to log out and back in after replacing a core component like the at-spi-registry anyway. best regards, Bill Janina Sajka wrote: Luke Yelavich writes: On Thu, Dec 08, 2005 at 12:53:12AM EST, Willie Walker wrote: Yikes - I've seen this before, and if I remember correctly, it's because the AT-SPI Registry is corrupt. Have you tried rebooting? Yes that helped, thanks. For the record, wouldn't restarting X accomplish the same result? I'm thinking Ctrl-Alt-Backspace? I'd hate to see our environment degrade to the primitive resolutions employed in that other OS ... -- Luke Yelavich GPG key: 0xD06320CE (http://www.themuso.com/themuso-gpg-key.txt) Email MSN: [EMAIL PROTECTED] ICQ: 18444344 ___ Gnome-accessibility-devel mailing list Gnome-accessibility-devel@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Cody's questions and Alexandra's reply
Hi Alexandra and Cody: Ada, I think there could be some confusing aspects to your answer, or perhaps you misunderstood Cody... you said: 2. What is teh command to make gnopernicus work with gaim messenger? A: There isn't a special command for your problem. Installing a new version of Gnopernicus and/or Gaim could solve your problem. This isn't enough to make gaim work with gnopernicus, and probably isn't necessary. Gaim will only work with gnopernicus if the GTK_MODULES environment variable is set before it is launched. Some versions of Gnome (like Sun's) have a patched gnome-session which does this automatically, but most do not. On most systems, the user must enter the following command from a gnome-terminal, or else put it in their .login file (in their home directory), and restart. export GTK_MODULES=gail:atk-bridge This will work for most users, using sh, ksh, or bash as their 'shell'. If you don't know your shell, don't worry, just try it and it will probably work. If you use the enter in a gnome-terminal approach, then if you run Gaim from that same gnome-terminal, it should be accessible. This probably also answers Cody's question number 3 (below). Hope that helps, Bill 3. If any programs require gnopernicus work by typing a command before launching the program, what is it? A: Gnopernicus starts to work when you launch it. The solution is to start Gnopernicus before you start the other program. 4. If anybody has gnopernicus, the latest version, I would like it, and all its dependancies along with it. I believe the latest is 1.12.0 or something. A: Source is currently available via anonymous CVS or from gnome's ftp. To download Gnopernicus tarball please see: ftp://ftp.gnome.org/pub/gnome/sources/gnopernicus/ For more information about Gnopernicus please visit: http://www.baum.ro/site-new/eng/products/gnopernicus/gnopernicus.html Regards, Alexandra Telescu ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [BRLTTY] Braille coding in Gnopernicus
remus draica wrote:... The other problem is that currently, unless I am mistaken, gnopernicus' braille tables are 8 bit tables, and gnopernicus always assumes Latin-1. That's right. Latin-2 is also 8-bit, so in theory the current gnopernicus architecture could handle this, but it would need to know when to convert from UTF-8 to Latin-2 instead of UTF-8 to Latin-1. I am not even totally sure that gnopernicus is converting from UTF-8 to Latin-8 now, before it does a braille table lookup, but it probably should be. Gnpernicus calls g_utf8_get_char () for every char to display. If the result is bigger than a value (256), the undefined code is dispalyed, otherwise the entry in a table. I think instead of checking to see if the utf-8 character is more than one byte, you could use g_convert_with_fallback to convert the character to either Latin-1 or Latin-2, etc. based on the current braille table. So if the user were using a braille table that required Latin-2, you would use g_convert to convert the UTF-8 characters to Latin-2 before doing the braille table lookup. http://developer.gnome.org/doc/API/2.0/glib/glib-Character-Set-Conversion.html#g-convert-with-fallback regards Bill If gnopernicus had a Latin-2 table that worked for your locale, then I think we could solve the problem by including the character set in the braille table, at the top, and making sure gnopernicus did the correct UTF-8 to 8-bit conversion for the given table before doing a character lookup. From there on, the correct dots should be sent to BrlAPI. Remus, please correct me if I have this wrong. If the new latin-2 table replaces the current table, it will be used by gnopernicus. Ther is no way to use both latin-1 and latin2 tables at the same time. A better solution long-term would not be limited to an 8-bit braille table lookup, but this is the sort of thing 'gnome-braille' attempts to handle. Regards, Remus ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: gnome-panel
Hi Julian: [EMAIL PROTECTED] wrote: Good morning, We are developing an application that allows to manipulate the main menu of GNOME desktop using some speech commands GERvoice. After making a study of the possible tools that allow the communication between two applications (the GERvoice Application and the main Menu of GNOME) we found to CORBA (Gnorba, Orbit and bonobo) like a possible solution. The idea is to construct a embebed application in the panel GNOME, who allows to send signals to the main menu and thus to be able to manipulate it. Speaking with rodrigo Moya it raises to us: that I know, not even with CORBA it is possible to be manipulated. The best form, I create, is through ATK, the support of accessibility. In any case, I recommend to you that you try to establish contact with the accessibility people, that better advice will give you than I. It's for this reason that I transmit the questions to you; these questions are: How to capture or to send signals to the main menu of GNOME. Exist some API dedicated to the programming of panel GNOME, in such a way that it can send signals and interact with the same one? There is general purpose API in Gnome that allows you to control _all_ user interface elements, including the panel and the launch menu. This API is called AT-SPI and it exists to support assistive technologies for disabled people. What you are describe, voice control of the menus, is a type of assistive technology. Try running the Onscreen Keyboard from the 'Accessibility' menus in Gnome. You will see that the onscreen keyboard knows which windows are focussed, it can launch applications, it can focus the bottom panel and post the launch menu, and it can interact with other parts of the gnome-panel. (Before this will work, you must turn on 'Assistive Technology Support' from the Preferences-Accessibility dialog.) To see how this works, you can look at some of the GOK source code. Here is some documentation about AT-SPI (these docs are for a new version in progress, but they are more complete than docs for the old version): http://gnome.org/~billh/at-spi-new-idl/html/html/index.html Here is some documentation about the Gnome Onscreen Keyboard: http://www.gok.ca/usermanual.shtml Here is some documentation about accessibility in general, in Gnome: http://gnome.org/learn/access-guide/2.10/ Best regards, Bill Thanks for the attention ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: gnopernicus concerns
Hi Jason, Cody: About Java and the bridges: As Jason mentioned before, there are two 'java access bridges'. One is for Windows, and if you are running on Windows you will need to make sure your screen reader supports the Java Access Bridge for Windows in order for it to work. If you are on Gnome/Linux/Solaris, then there is a different Java Access Bridge for Gnome, which is what the java-access-bridge package for Gnome provides. It bridges Java applications, and OpenOffice, to the AT-SPI accessibility interfaces which gnopernicus, gok, and orca use. HTH Bill Jason Grieves wrote: Hello, Sorry that was very misleading. You need to find a screen reader that supports java/java access bridge. Gnopernicus reads java via the gnome/java access bridge. I have been told emacspeak supports the java bridge. I am not sure about orca. The IBM ASI/SVDK for accessibility doesn't appear to be around. This accomplished the same task that gnopernicus does, but required you to set 2 TTS programs (gnopernicus and IBM's TTS for java) Does anyone have any other recommendations? God Bless, Jason G. Mathew 11:28-30 can you try to find out what name of ibm java screen reader is? - Original Message - From: Jason Grieves [EMAIL PROTECTED] To: [EMAIL PROTECTED]; gnome-accessibility-list@gnome.org Sent: Sunday, November 27, 2005 9:51 AM Subject: RE: gnopernicus concerns Hello, I will try to answer a few of your questions 1) I have gotten gnopernicus to speak with firefox, open-office, gnome desktop applications. I 2) some applications written in GTK require you export the gail and atk bridge this can be done via the command line type export GTK_MODULES=gail:atk-bridge 3)you will need to setup your java apps (aka open office) to either work with the java bridge or a native java screen reader (IBM has a free one I have used) 4) If you are using Ubuntu I build .deb packages for gnopernicus. Otherwise you will need to compile your own gonpernicus packages with a compiler. You will also require a little knowledge of building/making. If you post your distribution you may find someone who can build it for you. I hope this helps. God Bless, Jason G. Mathew 11:28-30 sorry I hadn't posted a subject here is the message just in case anybody had trashed my email, my bad. hi listers, I'd like a couple things, 1. a list of programs gnopernicus will work with. 2. What is the command to make gnopernicus work with gaim messenger? 3. If any programs require gnopernicus work by typing a command before launching the program, what is it? 4. If anybody has gnopernicus, the latest version, I would like it, and all its dependancies along with it. I believe the latest is 1.12.0 or something. This in itself would be a great help from anybody thanks Cody _ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
