Re: GNOME A11y: where do we need to improve? (Want input by 25-Jan)
Hi All: Thanks so much for your feedback last week. David Bolter and I went over the e-mail and talked about things on the phone. I've just updated the http://live.gnome.org/Accessibility/GetInvolved wiki to reflect this. On this page, you'll find an Areas Needing the Most Attention section. The contents of this section are based upon your feedback and will likely be the stuff that gets the most attention. Please review this list -- this really is your time to help influence the direction of GNOME a11y work, so please take this review seriously. Thanks! Will ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME A11y: where do we need to improve? (Want input by 25-Jan)
On 26/01/2008, Francesco Fumanti [EMAIL PROTECTED] wrote: I don't understand exactly what you mean by general purpose ATs; what would be the non general purpose ATs? In fact, in my view the fonctionalities of the plugin would be available sessionwide We may be saying the same thing but using 'plugin' differently, especially from your comments below. I only meant that something like prediction or TTS has use with other ATs. If it is a plugin that only works with one AT then we the work will be repeated and plus if a user uses 2 ATs (screen reader and OSK say) then there will be duplication and conflict. If such work becomes a general 'service' usable by various ATs then we are in a much better position. The closest I think we have now is magnification which is a service and ATs like Orca drive it. One possible solution would be to have a AT plug in architecture that all ATs could use. However the UIs would vary greatly between ATs. And now the following occurs to me: should I not say systemwide instead of sessionwide!? For example what about GDM? Say a user installs an AT; should that same AT not automatically be available at the login-screen, but not necessarily activated. [snip] Does a plugin have to announce itself to the session? If that is the case, I would suggest that the plugin should not only announce itself to the session, but also to gdm. Fully accessible login is a holy grail to aim for ;-) You have some good ideas here. I guess the term 'plugin' is one that has various meanings and in the scenario you describe I wonder if there is another GNOME term as I thought 'plugins' are generally application specific (and that is what I thought you meant). 'Applet' perhaps, but that usually something in the panel? For the moment I don't know whether such a modular architectures with plugins makes also sense for the other ATs available. It might be possible to design such a modular infrastructure with care and cooperation. We don't have a large number of ATs/a11y features. Then again it might be something available already with a OS and it just needs the right UI designed. Do I get it right: the suggestion is to use a numerical computation to find the completion and prediction word? I am curious: Is there any theoretical model supporting the suggestion? No, I think it was just it was a bit of 'out of the box thinking' that if you entered an expression it could get evaluated as the result. Compared to predictive text that gets 'evaluated' as the word. A script plugin would be useful for power users. What kind of scripts are you talking about? Does the script provided by an application (or plugin) not depend on what that application expects? In the context of single application plugin architecture I just meant that power users could want a level of customisation greater than available through GUI config options. That opens up the program for community as well through sharing scripts. 'Scripts' could be purely declarative (like HTML, say). I thought a plugin would provide the environment to run scripts within its GUI (cif the ipython plugin in accerciser) . The same could apply in a system pluggable infrastructure, though shell scripting is a possibility and yes each program would expose its own API. I was only envisaging one language or format (e.g python) not bindings to many. Will (for example) Windows user even look for free software? I don't know, but I assume most will not. I fear that they have the reflex to walk into a shop and buy. That seems so in the AT world or at least for those who purchase and support users. They appear to be suspicious of FOSS and reluctant to support more systems. On the other handI get the impression that many end users of general software expect PC stuff to be free (e.g tucows, download.com etc) but are not always clear on the differences between freeware/shareware and FOSS and what the FOSS guarantees are. Priority should (in my opinion) be given to make the switch possible for users that want to switch, by providing them the AT they need. And if it is of outstanding quality, it might even attract new users who learn about it on specialised forums and lists. If other users share their good experiences and so help reduce the 'fear' of change. Even better, other users help them make the change (Besides AT, there are also other things that can hinder the switch, for example years of emails stuck in a client that cannot be moved properly to gnome,...) Ah but that is an example of where having cross platform programs removes silos and platform lock-in. Using Open standards (e.g. email DBs) and harmonisation of APIs across platforms means developers have less to do to avoid this sort for problem for users. Of course, if there are enough resources to make the product outstanding and cross platform, it will be better. (If making it cross platform requires only little more resources, it might also be worth doing it; but again:
Re: GNOME A11y: where do we need to improve? (Want input by 25-Jan)
On 24/01/2008, Francesco Fumanti [EMAIL PROTECTED] wrote: I just read a bit in the OSK-ng, on the LSR list,... and I find the idea of a modular approach very interesting. But don't expect from end-users to work with scripts; he should rather be present with an architecture similar to plugins. Yes scripting is more an implementation detail. cif accerciser plugins or mozilla add-ons which are scripted internally (the definition of scripting I'm using is an interpreted language and abstracting APIs). In this way scripts allow developers or geeky users to easily create and share plugins thus creating an active community. Scripting should have a part to play in situations where a service provider supports a number of users with various needs. I could for example imagine the following plug-ins: - a basic onscreen keyboard plugin - a dwelling plugin - a word prediction plugin - a switch access plugin - an ui grabbing plugin - a speech plugin - ... I like this, though a dwell and speech (and possibly prediction) are better served by integration with general purpose ATs. Someone suggested a calculator plugin that evaluated numeric expressions, rather like prediction. A script plugin would be useful for power users. A plug in architecture is definitely one of the ideas for Jambu. This would allow users to only install the plugins he needs (of course, each plugin would also install its settings gui) instead of confronting him with a package that offers a lot of fonctionalities that he does not need and that has only the potential to disturb. That is of course a pluggable architecture's strength. A slight downside is the need for each user to locate and install the right plugins but that can be mitigated with 'bundles'. Maybe another word concerning osk-ng: the intention is to make it work on multiple platforms. Could you please explain to me the reason for making it cross-platform? Being platform agnostic (like Mozilla) means more users can be reached using the applications that they prefer. In addition most users are on Windows and being cross platform reduces the barriers to migration to Linux. Moreover, what platforms do you have in mind? I think the intention was then Windows and perhaps Mac. And there are mobile platforms and the Ultra Compact PCs (e.g. eeePC). These look exciting from the point of view of portable communications devices (AAC). The increased presence of Linux in these applications means there is less distance between platforms. For example I have a Linux/Mozilla based Nokia n810 and plan to have a play with it in this area. -- Steve Lee -- Jambu - Alternative Access to Computers www.fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME A11y: where do we need to improve? (Want input by 25-Jan)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I originally sent this directly to Willie, but I think it wouldn't hurt to also send it to this list. On Wed, Jan 23, 2008 at 03:23:36PM GMT, Willie Walker wrote: Hi All: I've seen some good activity on the WIKI (thanks!). I also need your help with identifying the top 5 to 10 things that need doing on this list. Please be brave and speak up, especially those of you who have expressed concerns about where the community might be focusing or spending its energy. This really is your chance to help influence where things go. Hi Willie Here are my top 5 things I would like to see happen: 1. gnome-speech/speech infrastructure. 2. gnome-panel (No point having it, if we can't access all of it) 3. TTS localization (Jonathan, the author of ESpeak would be the best person to help here) 4. Rhythmbox. The computer is a jukebox these days, so lets make sure it works well with a11y. 5. Evince. We need to be able to read PDFs etc. We shouldn't rely on Acrobat Reader where at all possible. My involvement in general for GNOME/Linux accessibility will be to keep Ubuntu at the forefront of Linux Accessibility, and make sure the best tools are as well integrated for users as possible, to make things as seemless as possible. In light of the above list of attention items however, I feel I can help the most with what I think is THE most important issue we need to resolve, and need to resolve ASAP. Yep, you guessed it, speech. Firstly, there is the nice fact that KDE will be coming online with accessibility some time in the coming years, and they said early on, at least for use with the existing kde accessibility tools, that they favoured speech-dispatcher's model. Secondly, speech-dispatcher's model is flexible enough, that with some small speech-dispatcher changes, third parties could easily build drivers for synthesizers outside the speech-dispatcher source tree. This would especially be useful for building support for proprietary speech synthesizers, and would then make it easier for users to set up such synthesizers, without having to rebuild speech-dispatcher, with the possible effect of screwing up their system. There is also the changing face of audio infrastructure to be considered. Luckily, just about all speech synthesizers support returning audio to the calling application via a callback. Speech-dispatcher makes good use of this with espeak, festival, flite, and ttsynth, and then can send the audio to one of many audio outputs, such as OSS, NAS, ALSA, and recently, PulseAudio. At this point, I am very much grappling with having to deal with what direction to go for Ubuntu hardy, in relation to speech audio output, and PulseAudio. At this stage, I am looking at wrapping the espeak-synthesis-driver gnome-speech binary in a call to padsp, so that all OSS calls from espeak+portaudio v19 are sent to PulseAudio. For next release, I will likely implement a speech-dispatcher solution, as that is what users are asking for on the Ubuntu accessibility lists. if upstream could also support speech-dispatcher, that would be much appreciated. I could then easily add scripts to the speech-dispatcher package to allow for distributions to make use of speech-dispatcher per user session, as that is how PulseAudio is being run, at least in Ubuntu. All this would be possible, due to me now having speech-dispatcher CVS access. In the longer term future, I would then write a nice GUI, to allow users to more easily adjust speech-dispatcher's options, or even better, help in implementing a hook into Orca, so that Orca users could directly alter speech-dispatcher settings from clicking a button in the speech preferences pain. I would urge to consider my proposal, and my offer of help. Together with the speech-dispatcher developers, we can sort out any remaining issues you think exist, and move forward to using a completely GNOME abnostic framework for speech output. Thanks for your time. - -- Luke Yelavich GPG key: 0xD06320CE (http://www.themuso.com/themuso-gpg-key.txt) Email MSN: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHma1jjVefwtBjIM4RAjIqAKCkZM4byCXE45/gxTfRrvOY+twEtACfZc86 LA35kWsei4gJ9/OYBkcBrUk= =m6DO -END PGP SIGNATURE- ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME A11y: where do we need to improve? (Want input by 25-Jan)
On 24/01/2008, Ian Pascoe [EMAIL PROTECTED] wrote: B. Ensure that the apps utilise a widgets library that supports AT-SPI. GTK+ is very popular and it uses GAIL to automatically expose AT-SPI for stock widgets. So it is important for application developers to carefully consider the case for custom widgets and to ensure any they create are fully accessible. In addition application authors may also need to tune the stock accessiblity to make their applications as accessible as possible. We, as a community, need to advise other developers about these issues and provide the information and tools they need so they can make their apps fully accessible with little hassle. At GNOME summit in Boston it was clear that the wider GNOME community are aware of a11y and are keen to play their part. That is fantastic. There is a new plug-in for accerciser that makes application a11y testing easy. Secondly, and this is a bit off the wall, to provide an additional call to AT-SPI that apps can directly access to provide additional information that would not normally be needed by a visually unimpaired user? For instance, a classic one that comes to mind is a graphical status bar like the one used on Update Manager - the unimpaired user can see the progress of the bar, but for an impaired user if the ap could send out additional information like the progress of the bar, or changes to a status bar This could be used as an alternative to accessable widgets as well. AT-SPI is rich enough to cover this specific case and almost any other. In general it is a matter of the toolkit/application writers exposing enough information through AT-SPI so that ATs can consume it. However until there are ATs or test harnesses to consume the information and thus create a demand for it, it is not going to be implemented or completely tested. For example when working on Jambu switch access I started exercising Firefox in ways that Orca doesn't so I found bugs and omissions. That's not a criticism of Firefox, rather it shows the reality and priorities of software development. -- Steve Lee -- Jambu - Alternative Access to Computers www.fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME A11y: where do we need to improve? (Want input by 25-Jan)
On 17/01/2008, Willie Walker [EMAIL PROTECTED] wrote: One of the most important things for us to do right now is identify where we need to improve. Over the coming week, please set aside some time to look at http://live.gnome.org/Accessibility/GetInvolved. Thanks for getting us focused on this Will. I've added some ideas to the wiki http://live.gnome.org/Accessibility/GetInvolved?action=diffrev2=30rev1=28 My top 5 plus a bonus item: 1) Alt input - 1st class access for those not using mouse or keyboard or needing tweaks to them. 2) Evangalise and support, we need to get users and support organisations out of the proprietary + Windows mindset. 3) Support and resources for app developers to ensure all apps are fully accessible. Also encourage new new AT developers. 4) Reading/writing support e.g e-books with highlighting and word prediction 5) Standard TTS that just works with simple API (including all general sound issues) and Bonus) blue sky and innovation - lets make GNOME a11y lead the way and be where a11y users want to be. (I'm assuming D-bus migration is happening anyway) As for how I can get involved well I think we should seriously discuss the entire Alt input landscape once David Bolter comes back on stream. I've reached a pause in Jambu grant from Mozilla so now is a good time for me especially if I can find funding (as I need to pay the bills). For the next few months family commitments mean I have reduced availability and as I think we need to review the big picture of Alt access I'd also be very interested in working on documentation and resources for developers (or users). Oh the Python Magazine article on Python a11y, GNOME, pyatspi and accerciser etc will be released for free use on 20 Feb so it can go on the wiki. I'm always on the look out for a chance to evangelise Open Source a11y and especially GNOME and Mozilla and would love to do more formally. ;-) I usually 'spout off' through fullmeasure.co.uk, oatsoft.org.uk, schoolforge.org.uk and did a recent poster presentation at UK RAaTe a11y conference http://fullmeasure.co.uk/raate07 and which is CC. -- Steve Lee -- Jambu - Alternative Access to Computers www.fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME A11y: where do we need to improve? (Want input by 25-Jan)
Hi All: I just want to send out a note of thanks to everyone who contributed their input as well as those who added details to the http://live.gnome.org/Accessibility/GetInvolved WIKI page. Francesco, your additions to the page were especially good. David Bolter and I are going to review both the feedback and the content on the page. We'll then try to summarize the feedback as best we can. We hope to have something in your hands early next week for a review. Thanks again! Will ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME A11y: where do we need to improve? (Want input by 25-Jan)
On 23/01/2008, Francesco Fumanti [EMAIL PROTECTED] wrote: Please don't get me wrong: In my previous post quoted below I did not want to say anything about the importance of the point about having an onscreen keyboard that is more efficient for the users that... I only wanted to say that it is a need that exists and that has been proposed in the GetInvolved page; thus it should be considered, even if at the end it does not belong into the top ten. My view is that it's important to you and you've joined the community so it's important to us ;-) Actually we want to ensure that *all* user a11y needs are covered well and you've identified a gap. I also see it as a part of a the need to polish up 'alternative access' provision. The time is ripe for a good discussion. We did set up the OSK-ng list a while back, but i think it might be better done here in the view of the wider community. Another areas is reading support. OK I'll stop whittering on and go make some changes to the wiki today. By the way, what criteria do you intend to apply to establish the top ten list? Does it not depend on the resources available (a coder is not a documentation writer)? I assume there are things that need only little work while others need much work; the assistive technology needed by visually impaired users is probably not much related to that used by mobility impaired users,... I agree with Will that we need input and discussion from people with all sorts of skills to do the best possible job and to ensure we are requirements driven. -- Steve Lee -- Jambu - Alternative Access to Computers www.fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME A11y: where do we need to improve? (Want input by 25-Jan)
Hi All, I just wanted to explain my lack on involvement recently. I'm on holiday until mid-February so that I can have quality time with my new baby girl and her 5 year old sister. I'm still very passionate about the new momentum in GNOME a11y. I'll be back. cheers, David Willie Walker wrote: Hi All: One of the most important things for us to do right now is identify where we need to improve. This may result in positive things such as funding opportunities and the like. Over the coming week, please set aside some time to look at http://live.gnome.org/Accessibility/GetInvolved. It contains a large list of stuff to do, but it represents a pretty complete list of things people have mentioned over the past few years. What I'd like you to do is look at the page with these things in mind: 1) If there is something missing from the list, please make a suggestion. I'm looking for concrete ideas. Things such as we need to do more for people with hearing disabilities are less likely to get addressed than specific tasks such as develop close captioning software for x, y, z. On the same front, something like Be more researchy is more of a section where specific research and advanced development topics should live. 2) If you were someone who suggested one of the ideas, please help fill out the details. You obviously mentioned it because you thought it was important, so please make sure it is represented well on the page. 3) Look at the list. What are the top 5 to 10 things that need doing on the list, including stuff you may have added? Write your top choices down. Send them to me. 3) Think about where you may be able to step up and help and your availability. As a result of this exercise, I hope to be able to make the list of tasks more complete and better defined. In addition, we should also be able to come away with some top areas/tasks that we agree we need to focus on as a community. Please do this by next Friday (25-Jan). This is your opportunity to influence where things go, and I'm really hoping the get some response on this. Thanks! 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: GNOME A11y: where do we need to improve? (Want input by 25-Jan)
Hello, At 9:43 AM + 1/24/08, Steve Lee wrote: Actually we want to ensure that *all* user a11y needs are covered well and you've identified a gap. I also see it as a part of a the need to polish up 'alternative access' provision. The time is ripe for a good discussion. We did set up the OSK-ng list a while back, but i think it might be better done here in the view of the wider community. I just read a bit in the OSK-ng, on the LSR list,... and I find the idea of a modular approach very interesting. But don't expect from end-users to work with scripts; he should rather be present with an architecture similar to plugins. I could for example imagine the following plug-ins: - a basic onscreen keyboard plugin - a dwelling plugin - a word prediction plugin - a switch access plugin - an ui grabbing plugin - a speech plugin - ... The plugins that I listed are obviously for mobility impaired users; I don't know whether AT for visual impaired users could fit in that approach, but if it does, the better. This would allow users to only install the plugins he needs (of course, each plugin would also install its settings gui) instead of confronting him with a package that offers a lot of fonctionalities that he does not need and that has only the potential to disturb. Maybe another word concerning osk-ng: the intention is to make it work on multiple platforms. Could you please explain to me the reason for making it cross-platform? Moreover, what platforms do you have in mind? Francesco ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
GNOME A11y: where do we need to improve? (Want input by 25-Jan)
Will Couple of thoughts. Firstly, to ensure that the commonly shipped basic Gnome apps that appears on base distros all have accessability enabled as fully as possible. Maybe a two stage process: A. Ensure that keyboard shortcuts are activated and supported - is there such a thing as a Gnome standard for these, or an ISO type thing? B. Ensure that the apps utilise a widgets library that supports AT-SPI. Secondly, and this is a bit off the wall, to provide an additional call to AT-SPI that apps can directly access to provide additional information that would not normally be needed by a visually unimpaired user? For instance, a classic one that comes to mind is a graphical status bar like the one used on Update Manager - the unimpaired user can see the progress of the bar, but for an impaired user if the ap could send out additional information like the progress of the bar, or changes to a status bar This could be used as an alternative to accessable widgets as well. Ian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Willie Walker Sent: 23 January 2008 22:59 To: Francesco Fumanti Cc: gnome-accessibility-list@gnome.org Subject: Re: GNOME A11y: where do we need to improve? (Want input by 25-Jan) Hi Francesco: My goal for this exercise is to hear what the community thinks is the most important stuff to get done. As I see with the Orca project, having end users directly involved in the decision making process makes a world of difference in the outcome. Without this, we can sometimes end up in a situation where the architecture drives the user experience and not the other way around. We can also end up in a situation where resources are misdirected towards a snazzy demo while sorely needed gaps remain unfilled. In addition, I think it's also important for the community to know how the decisions were made, especially because their voice can influence the decisions. So, thanks to active people like yourself, opinions are coming in. Will Francesco Fumanti wrote: Hello, Please don't get me wrong: In my previous post quoted below I did not want to say anything about the importance of the point about having an onscreen keyboard that is more efficient for the users that... I only wanted to say that it is a need that exists and that has been proposed in the GetInvolved page; thus it should be considered, even if at the end it does not belong into the top ten. By the way, what criteria do you intend to apply to establish the top ten list? Does it not depend on the resources available (a coder is not a documentation writer)? I assume there are things that need only little work while others need much work; the assistive technology needed by visually impaired users is probably not much related to that used by mobility impaired users,... Best regards Francesco At 8:22 PM +0100 1/23/08, Francesco Fumanti wrote: Hello, Not knowing the state of the other ATs, I don't think that a top ten list from my part would make any sense. However, I would like to ask you to whether you could take into account the creation of an efficient onscreen keyboard for users that have good control of the movement of the pointer (regardless of them using a real mouse or some AT like a headpointer), but that are not able to use a hardware keyboard. Regards Francesco At 10:23 AM -0500 1/23/08, Willie Walker wrote: I've seen some good activity on the WIKI (thanks!). I also need your help with identifying the top 5 to 10 things that need doing on this list. Please be brave and speak up, especially those of you who have expressed concerns about where the community might be focusing or spending its energy. This really is your chance to help influence where things go. ___ 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 A11y: where do we need to improve? (Want input by 25-Jan)
Hi All: I've seen some good activity on the WIKI (thanks!). I also need your help with identifying the top 5 to 10 things that need doing on this list. Please be brave and speak up, especially those of you who have expressed concerns about where the community might be focusing or spending its energy. This really is your chance to help influence where things go. Thanks! Will Willie Walker wrote: Hi All: One of the most important things for us to do right now is identify where we need to improve. This may result in positive things such as funding opportunities and the like. Over the coming week, please set aside some time to look at http://live.gnome.org/Accessibility/GetInvolved. It contains a large list of stuff to do, but it represents a pretty complete list of things people have mentioned over the past few years. What I'd like you to do is look at the page with these things in mind: 1) If there is something missing from the list, please make a suggestion. I'm looking for concrete ideas. Things such as we need to do more for people with hearing disabilities are less likely to get addressed than specific tasks such as develop close captioning software for x, y, z. On the same front, something like Be more researchy is more of a section where specific research and advanced development topics should live. 2) If you were someone who suggested one of the ideas, please help fill out the details. You obviously mentioned it because you thought it was important, so please make sure it is represented well on the page. 3) Look at the list. What are the top 5 to 10 things that need doing on the list, including stuff you may have added? Write your top choices down. Send them to me. 3) Think about where you may be able to step up and help and your availability. As a result of this exercise, I hope to be able to make the list of tasks more complete and better defined. In addition, we should also be able to come away with some top areas/tasks that we agree we need to focus on as a community. Please do this by next Friday (25-Jan). This is your opportunity to influence where things go, and I'm really hoping the get some response on this. Thanks! Will ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME A11y: where do we need to improve? (Want input by 25-Jan)
Hello, Not knowing the state of the other ATs, I don't think that a top ten list from my part would make any sense. However, I would like to ask you to whether you could take into account the creation of an efficient onscreen keyboard for users that have good control of the movement of the pointer (regardless of them using a real mouse or some AT like a headpointer), but that are not able to use a hardware keyboard. Regards Francesco At 10:23 AM -0500 1/23/08, Willie Walker wrote: I've seen some good activity on the WIKI (thanks!). I also need your help with identifying the top 5 to 10 things that need doing on this list. Please be brave and speak up, especially those of you who have expressed concerns about where the community might be focusing or spending its energy. This really is your chance to help influence where things go. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME A11y: where do we need to improve? (Want input by 25-Jan)
Hello, First of all, thanks for making this possible. At 11:11 AM -0500 1/17/08, Willie Walker wrote: One of the most important things for us to do right now is identify where we need to improve. This may result in positive things such as funding opportunities and the like. Over the coming week, please set aside some time to look at http://live.gnome.org/Accessibility/GetInvolved. It contains a large list of stuff to do, but it represents a pretty complete list of things people have mentioned over the past few years. What I'd like you to do is look at the page with these things in mind: 1) If there is something missing from the list, please make a suggestion. I'm looking for concrete ideas. Things such as we need to do more for people with hearing disabilities are less likely to get addressed than specific tasks such as develop close captioning software for x, y, z. On the same front, something like Be more researchy is more of a section where specific research and advanced development topics should live. I have added the Improve efficiency of the GNOME desktop for mouse-only users to the above mentioned wiki page. In fact, GNOME is lacking (or did I miss it?) an onscreen keyboard targeted specifically at people that have no difficulty to move the mouse/pointer (regardless of whether it is a standard mouse or some adaptive hardware like a headpointer), but are not able to use a hardware keyboard. For users that have difficulties to use the mouse button, there is mousetweaks that should fill the gap. Unfortunately, I have not found any keyboard on linux as efficient as the commercial product that I am using on the other operating system: There is dasher that is reputed to have a good prediction engine; but it seems to lack the possibilities to control the desktop. There is gok, which seems to be rather targeted at users that can not efficiently use the pointer. It has word completion without word prediction. The keyboard is not resizable,... Should dasher be enhanced, should the composer in gok be enhanced, or should a new project aimed at the mouse only users be started from scratch? I don't know. By the way, the GetInvolved page mentions porting gok to python. Why the port? Cheap Head Mice? The adaptive Headpointers that I know of, use special reference items weird by the user to track his movement. I wonder whether a simple camera (webcam) working without a reference item can be accurate enough to use it as headpointer. Does anybody have any experience with reference-less headpointing? About writing drivers for headpointers: do you have any headpointers in mind? Some headpointers (usually the more expensive models) present themselves as a normal mouse to the computer and consequently should work with the mouse driver shipped by the operating: this has the advantage of not requiring a specific driver (and maybe the disadvantage of not being customizable). Another point I am wondering about: Am I right when I think that there is a standard about making the computer accessible for users that can only use the keyboard!? If it is true, maybe that a standard for people that can only use the mouse (with and without buttons) could also be useful. 2) If you were someone who suggested one of the ideas, please help fill out the details. You obviously mentioned it because you thought it was important, so please make sure it is represented well on the page. If anything is not clear in the Improve efficiency of the GNOME desktop for mouse-only users part of the GetInvolved page, please let me know and I will try to improve it. 3) Look at the list. What are the top 5 to 10 things that need doing on the list, including stuff you may have added? Write your top choices down. Send them to me. Unfortunately, I don't have much knowledge about the different solutions available for the various disabilities, and the state of these solutions. Consequently a top 10 list from my part would not make much sense. 3) Think about where you may be able to step up and help and your availability. I could exchange my ideas with the developer, test what he produces,... (but I will not be able to do the coding) About the availability: currently I am quite busy, but I hope it will be better in a few months. Best regards. Francesco ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME A11y: where do we need to improve? (Want input by 25-Jan)
Hi Francesco, Please see my answers/responses in-line, below. ... I have added the Improve efficiency of the GNOME desktop for mouse-only users to the above mentioned wiki page. In fact, GNOME is lacking (or did I miss it?) an onscreen keyboard targeted specifically at people that have no difficulty to move the mouse/pointer (regardless of whether it is a standard mouse or some adaptive hardware like a headpointer), but are not able to use a hardware keyboard. It may be that OnBoard fits this bill reasonably well. But I'm not familiar enough with the motivations behind OnBoard to say whether it is expressly targeting the population you describe. For users that have difficulties to use the mouse button, there is mousetweaks that should fill the gap. Unfortunately, I have not found any keyboard on linux as efficient as the commercial product that I am using on the other operating system: There is dasher that is reputed to have a good prediction engine; but it seems to lack the possibilities to control the desktop. There is gok, which seems to be rather targeted at users that can not efficiently use the pointer. It has word completion without word prediction. The keyboard is not resizable,... Should dasher be enhanced, should the composer in gok be enhanced, or should a new project aimed at the mouse only users be started from scratch? I don't know. I think the best place to start is for you to describe the feature(s) you like and use in the commercial product(s), and let that lead a discussion of how best to achieve those results. The more detailed you can be (both in the description of the feature(s), and in describing how they help you and aid efficiency/productivity), the better. By the way, the GetInvolved page mentions porting gok to python. Why the port? GOK uses a set of C language bindings to AT-SPI. In part as part of a move away from CORBA dependencies, we have introduced the pyatspi interface, Python bindings that can are designed in part to be layered on top of DBUS. This library is being shared by a number of tools, and if GOK were ported to Python, it could very easily move to pyatspi (in fact, it would be the natural thing to use). Also, Python being a higher-level language than C, numerous programming headaches go away (like memory management). Finally, per-application scripting is very easily accomplished in Python - Orca makes great use of this. There are a number of use cases in which per-application on-screen keyboard behavior would be very useful. Cheap Head Mice? The adaptive Headpointers that I know of, use special reference items weird by the user to track his movement. I wonder whether a simple camera (webcam) working without a reference item can be accurate enough to use it as headpointer. Does anybody have any experience with reference-less headpointing? About writing drivers for headpointers: do you have any headpointers in mind? Some headpointers (usually the more expensive models) present themselves as a normal mouse to the computer and consequently should work with the mouse driver shipped by the operating: this has the advantage of not requiring a specific driver (and maybe the disadvantage of not being customizable). I believe Steve Lee already addressed this question. Let me add that the Inference folks at Cambridge (who brought Dasher to the world) are working on the OpenGazer project (see http://www.inference.phy.cam.ac.uk/opengazer/), which uses a £50 Logitech QuickCam Pro 4000 to drive eye tracking (with somewhat limited resolution), which in turn can drive Dasher or some other on-screen keyboard. This is work I would very much like to see expanded and refined. Another point I am wondering about: Am I right when I think that there is a standard about making the computer accessible for users that can only use the keyboard!? If it is true, maybe that a standard for people that can only use the mouse (with and without buttons) could also be useful. There is a very fuzzy line between what apps do for accessibility in and of themselves, and what they do via the use of an assistive technology application. For a variety of reasons, on Windows in GNOME in KDE, we have drawn that line such that keyboard-only operation is handled by the apps themselves, while mouse-only is done via desktop AT. Of course, keyboard-only is only about full use of keyboard-only. We bring in AT with things like StickyKeys, MouseKeys, etc. On Macintosh, full use of keyboard-only requires desktop AT (VoiceOver) to give you all of the functionality you have in Windows GNOME in KDE. Which goes to the point that the line is fuzzy in desktop computing. For essentially these historical and current state of the art reasons, I think it is best to solve full use by mouse only via add-on (though perhaps built-in to GNOME) AT which accomplishes that task, and
Re: GNOME A11y: where do we need to improve? (Want input by 25-Jan)
Hello, On Mon, 21 Jan 2008 14:47:58 +0100 Francesco Fumanti [EMAIL PROTECTED] wrote: Hello, First of all, thanks for making this possible. At 11:11 AM -0500 1/17/08, Willie Walker wrote: *cut* Over the coming week, please set aside some time to look at http://live.gnome.org/Accessibility/GetInvolved. It contains a large list of stuff to do, but it represents a pretty complete list of things people have mentioned over the past few years. *cut* Cheap Head Mice? The adaptive Headpointers that I know of, use special reference items weird by the user to track his movement. I wonder whether a simple camera (webcam) working without a reference item can be accurate enough to use it as headpointer. Does anybody have any experience with reference-less headpointing? About writing drivers for headpointers: do you have any headpointers in mind? Some headpointers (usually the more expensive models) present themselves as a normal mouse to the computer and consequently should work with the mouse driver shipped by the operating: this has the advantage of not requiring a specific driver (and maybe the disadvantage of not being customizable). *cut* we are working on a headtracker (-pointer, -mice, -whatever). The project hosted at http://www.olpcaustria.org/mediawiki/index.php/Headtracker stucks a bit cause I am not able to write assembler or C code. The guys who are able do that do not have the time, now. If someone wants to join the project I would be glad. It is an OLPC project but should work for gnome or other unix desktops, too. regards, yokoy -- [EMAIL PROTECTED] ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME A11y: where do we need to improve? (Want input by 25-Jan)
Willie: Thank you for doing this. A few weeks ago it seemed that there was overwhelming support for starting an Accessibility Steering Committee. I agree that it makes sense to get the Accessibility Wiki in good order as a preliminary project to setting up a Steering Committee. One advantage of doing this is it will help to determine which people are really interested in getting involved, and these people will likely be the best candidates to be involved with the Steering Committee. I recommend that people review the task lists of the Wiki. It would be good if people could accept responsibility for driving certain tasks. Perhaps we could highlight these responsible people on the Wiki? Any takers? Brian One of the most important things for us to do right now is identify where we need to improve. This may result in positive things such as funding opportunities and the like. Over the coming week, please set aside some time to look at http://live.gnome.org/Accessibility/GetInvolved. It contains a large list of stuff to do, but it represents a pretty complete list of things people have mentioned over the past few years. What I'd like you to do is look at the page with these things in mind: 1) If there is something missing from the list, please make a suggestion. I'm looking for concrete ideas. Things such as we need to do more for people with hearing disabilities are less likely to get addressed than specific tasks such as develop close captioning software for x, y, z. On the same front, something like Be more researchy is more of a section where specific research and advanced development topics should live. 2) If you were someone who suggested one of the ideas, please help fill out the details. You obviously mentioned it because you thought it was important, so please make sure it is represented well on the page. 3) Look at the list. What are the top 5 to 10 things that need doing on the list, including stuff you may have added? Write your top choices down. Send them to me. 3) Think about where you may be able to step up and help and your availability. As a result of this exercise, I hope to be able to make the list of tasks more complete and better defined. In addition, we should also be able to come away with some top areas/tasks that we agree we need to focus on as a community. Please do this by next Friday (25-Jan). This is your opportunity to influence where things go, and I'm really hoping the get some response on this. Thanks! 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: GNOME A11y: where do we need to improve? (Want input by 25-Jan)
On Thu, 2008-01-17 at 11:42 -0500, Willie Walker wrote: Hi All: One of the most important things for us to do right now is identify where we need to improve. This may result in positive things such as funding opportunities and the like. Over the coming week, please set aside some time to look at http://live.gnome.org/Accessibility/GetInvolved. It contains a large list of stuff to do, but it represents a pretty complete list of things people have mentioned over the past few years. What I'd like you to do is look at the page with these things in mind: 1) If there is something missing from the list, please make a suggestion. I'm looking for concrete ideas. Things such as we need to do more for people with hearing disabilities are less likely to get addressed than specific tasks such as develop close captioning software for x, y, z. On the same front, something like Be more researchy is more of a section where specific research and advanced development topics should live. 2) If you were someone who suggested one of the ideas, please help fill out the details. You obviously mentioned it because you thought it was important, so please make sure it is represented well on the page. 3) Look at the list. What are the top 5 to 10 things that need doing on the list, including stuff you may have added? Write your top choices down. Send them to me. 3) Think about where you may be able to step up and help and your availability. As a result of this exercise, I hope to be able to make the list of tasks more complete and better defined. In addition, we should also be able to come away with some top areas/tasks that we agree we need to focus on as a community. Please do this by next Friday (25-Jan). This is your opportunity to influence where things go, and I'm really hoping the get some response on this. Thanks! Will_ Hi Willie, Glad to see this page come up. There's lots of hearing-impaired stuff that I've been struggling to find solutions for. I'll try to add them to this page soon. I'm convinced for a number of these solutions I'm searching for, the solutions already exist somewhere out there. Having a page up like this should really draw in the mainstream out there to offer their contributions/insight. Great page! -- ---Bryen--- ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
