Open Source OCR
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
Re: [oats-sig] Re: harmonizing on-screen keyboard progress
Great Henrik, I've added my original thoughts from the moz accessibility list. My ideas have moved on a little and I'm looking at doing something with Mozilla for Firefox initially but with long term cross platform goals in this space. -- Steve Lee www.oatsoft.org www.fullmeasure.co.uk On 10/25/06, Henrik Nilsen Omma <[EMAIL PROTECTED]> wrote: > David Bolter wrote: > > > > Great! Let us know when the wiki page has an URL you can share. > > > > I've just made a quick start on it here: > https://wiki.ubuntu.com/Accessibility/Projects/OSK-ng > > I've ambitiously called it OSK Next Generation :) I'm not implying that > a completely new app will arise from this, just that we are looking forward. > > I've deliberately avoided a classic Pros and Cons setup, but just > invented some fields that should have some relevance. Please help > complete it and add your own fields, topics and ideas! > > Henrik > > ps. CCing oatsoft list as well > > ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: harmonizing on-screen keyboard progress
There's some previous thoughts on this over at mozilla accessibility http://tinyurl.com/ye683x Steve Lee On 10/25/06, Henrik Nilsen Omma <[EMAIL PROTECTED]> wrote: > David Bolter wrote: > > Henrik, All, > > > > Hi. I'm just wondering if it might be helpful for everyone involved or > > interested in free/open-source on-screen keyboard (or alternative input > > software) development to get together in one place or on one phone call > > to educate each other on our plans and ideas for best serving our users. > > > > Hi David, > > I think that's a great idea. We have three different projects with > similar goals but very different approaches, GOK, SAW and onBoard. > > It would be great cherry pick features from those and either work on > some common code or at least try to find some synergies. > > I'll set up a wiki page where we can list what we know about the > different approaches and future goals. If those interested in > participating would sign up there we can look for a mode of > communication next (the oats team had a fancy web-cam conference recently). > > Henrik > -- -- Steve Lee www.fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Accessability Interfaces
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? AT is very unlikely to use a particular GUI for any UI they present as that UI has to be accessible. -- Steve Leewww.oatsoft.orgwww.fullmeasure.co.uk On 11/8/06, Bill Haneman <[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 isincluding ATK as its exported accessibility interface onLinux/Unix/Solaris). Because Firefox is cross-platform, and also needs to speak MSAA on the Windows platform, is uses a different accessibilityinterface 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 nsiAccessibleinterface.To clarify - ATK itself is available on Windows, but it not a standardpart of a Windows installation, so in that respect ATK is already "cross-platform". However, existing Windows assistive technologies usea mixture of Microsoft's MSAA and proprietary interfaces to do theirjob, so Firefox needs handle the export of its accessibility info differently on the two platforms. On Linux/Unix/Solaris, theinformation 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 someinterprocess communication technology. AT-SPI is the standard interfacefor 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 thesame technique is used for Firefox, OpenOffice.org, and some othercomponents 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 butmay 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 withoutusing 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 preservesthe 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 necessarydependencies, and can work with other GUIs as well; however the distrosneed 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 isa dependency of GTK+, it does not require GTK+ in order to work, so anyGUI 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 listgnome-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
Well I was really making a fairly general question ignoring the layers and agree it depends on the language or libraries you use. My question was not so much the mechanics but more what you are conceptually doing. Perhaps it is rather fuzzy distinction. It's all useful info thanks David.My main experience is with the windows equivs of MSAA and COM. Using C you can do it the painful way of rolling all your own low level client code, you can use general classes and libraries, you can use #imports that creates classes for you from the IDL. In Python for general com you use Mark Hammond's wonderful code that creates python classes from the IDL (though event sinks are a little fidely). From what I've seen ATK provides an abstract API devoid of CORBA details and perhaps even a little different from AT-SPI. Rather like the Python COM classes, or a library built on top of them. SteveOn 11/8/06, Bill Haneman <[EMAIL PROTECTED]> wrote: Hi David, Steve:I think there are two aspects to Steve's question. One aspect has to dowith 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 actuallyrequire the client to add any CORBA-specific code. The second aspectof the question is the one I was addressing - whether the client needs to know much about CORBA details. That also depends a little on theclient's programming language, but mostly the answer is "no", the onlyplace 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 theAT-SPI Registry, via which the client receives event notifications fromrunning applications.best regardsBill 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?>>>>-- Steve Lee www.oatsoft.orgwww.fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Accessability Interfaces
Thanks Bill.BTW is the presentation you did at Gnome Boston available online yet?On 11/8/06, Bill Haneman < [EMAIL PROTECTED]> wrote:Steve Lee wrote:> Well I was really making a fairly general question ignoring the layers > and agree it depends on the language or libraries you use. My question> was not so much the mechanics but more what you are conceptually> doing. Perhaps it is rather fuzzy distinction. It's all useful info > thanks David.>> My main experience is with the windows equivs of MSAA and COM. Using C> you can do it the painful way of rolling all your own low level client> code, you can use general classes and libraries, you can use #imports > that creates classes for you from the IDL. In Python for general com> you use Mark Hammond's wonderful code that creates python classes from> the IDL (though event sinks are a little fidely).> > From what I've seen ATK provides an abstract API devoid of CORBA> details and perhaps even a little different from AT-SPI. Rather like> the Python COM classes, or a library built on top of them. Yes, but bear in mind that ATK is an in-process API and therefore is notavailable to assistive technologies (since they are in a separateprocess space from the apps which provide the ATK services). ATK is not an abstraction on top of AT-SPI, but vice-versa.You might find this presentation of interest:http://www.gnome.org/~billh/ArchitecturalOverview.odp Bill>> Steve>> On 11/8/06, *Bill Haneman* <[EMAIL PROTECTED]> [EMAIL PROTECTED] >> wrote:>> 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?> >>> >>>>>>> --> Steve Lee> www.oatsoft.org < http://www.oatsoft.org>> www.fullmeasure.co.uk <http://www.fullmeasure.co.uk>> >> ___> gnome-accessibility-list mailing list> gnome-accessibility-list@gnome.org> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list>-- Steve Leewww.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
Re: what is AT-SPI ?
On 5/24/07, Gautam Ravi <[EMAIL PROTECTED]> wrote: > I read some where that after doing all these things, I have to export all > these to AT-SPI layer. What is this AT-SPI layer? > Is it really needed to my system (Mine is an embedded system). > > Is AT-SPI a protocol ? or Daemon ? .. Is it very essential ? > Can I do without this? > Will my custom widget be accessible without this layer? or Should I also > install this in to my system? Hi Guatam, I'm pretty new to the Linux side but this summary that I just sent to someone might help "The Gnome a11y infrastructure allows end user assistive technology (AT) programs such as screen readers to get rich information about an application's UI state. Application's use the ATK library to serve information but for stock GTK+ widgets the GAIL library does this automatically when the Gnome Accessibility option for Enable Assistive Technology is turned on. ATs access the information via AT-SPI protocols (Corba based). KDE are now looking at implementing it as well and IAccessibility2 extends Microsofts MSAA to be very similar semantically. http://live.gnome.org/GAP " So AT-SPI is the platform, consisting of a standard protocol implemented on CORBA (there's talk of D-BUS for KDE) . ATs use AT-SPI directly to access a11y info from applications like yours and *IS* a vital part of the infrastructure. (I'm not sure how that pans out if you're embedded as I expect CORBA is quite resource hungry.) ATK provides a library api that applications use to serve up the a11y info for widgets. They don't need to deal with AT-SPI directly. A third component is a broker or registry that manages event traffic allowing applications to source and ATS to sink various broadcast-based message flows by subscription. This presentation from Bill Haneman is good. http://www.gnome.org/~billh/ArchitecturalOverview.odp and there's more here from Mozilla http://www.mozilla.org/access/unix/architecture That's the overview, perhaps someone could correct or expand on this and provide the practical steps? -- Steve Lee -- Open Source Assistive Technology Software PowerTalk - your presentations can speak for themselves www.fullmeasure.co.uk ___ 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
> On the other hand, I strongly suspect there are further potential contributors > who don't yet appreciate the opportunities that open development models offer. > The old, proprietary mindset of lobbying corporations to get work done, and of > believing that technical expertise lies elsewhere - that software is produced > by proprietary vendors and consumed by everyone else - needs to undergo a > transformation. Yeah! We also want users and their supporters to get involved creating the solutions they want. It's not just code contributions. Apart from www.oatsoft.org I also keep chipping away by writing letters and articles to the UK Ability magazine (http://www.abilitymagazine.org.uk) about the benefits of the Open model. My strategy is to be a 'dripping tap' and I've just sumbitted an article on the Mozilla Live access CD that we gave away at CSUN. I encourage others to do like wise in similar magazines in other countries. The proprietary model is so ingrained it needs those guerrilla marketing tactics (which also happen to match Open Source's attention to recognising users needs). -- Steve Lee -- Open Source Assistive Technology Software PowerTalk - your presentations can speak for themselves www.fullmeasure.co.uk ___ 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
On 6/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Do you know if there's a "dummies guide to python"? What i mean by this is > that You could try: How to Think Like a Computer Scientist, Learning with Python by Elkner and Meyers: http://www.ibiblio.org/obp/thinkCSpy/ or the official sites beginners guide http://wiki.python.org/moin/BeginnersGuide One of the great things about Python is that you can just sit at the console and try things interactively. A useful quick reference is http://rgruet.free.fr/#QuickRef Have fun -- Steve Lee -- Open Source Assistive Technology Software PowerTalk - your presentations can speak for themselves www.fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [g-a-devel] D-BUS based magnification API
On 30/08/2007, Peter Korn <[EMAIL PROTECTED]> wrote: > Assume that without GL, we can have a magnifier of quality 5, and with > GL a magnifier of quality 10 (just an assumption for sake of argument, > please bear with me). Since GL now runs on even somewhat older video > hardware, and you can get a GL card for not much money if you don't have > one already, I believe it would be better to make the decision to > require GL in the magnifier. Have some simple, basic magnifier that > works everywhere so folks who cannot get GL hardware have something > reasonable (perhaps quality level 3 - the point here is to focus > resources on the great stuff that we believe most folks will be able to > get with minimal hardware investment). And then focus on the GL based > stuff. > > Now, this assumes a big difference in what we can do with and without > GL. That may be a bad assumption on my part. But I look at how GL > hardware can do things like magnification of videos with little to no > slowdown in video performance, and I imagine the other cool things GL > can give us. I agree that we should look to the future so as not to limit what we can do when GL capable hardware becomes ubiquitous. We want innovative and outstanding accessibility for Linux, partly in order to encourage users to move to OSS. However when visiting people at their homes as an ITCH volunteer I was amazed at some of the venerable hardware being used (some also used win 98). Certaily older than most hackers would use (even with Linux). In addition upgrading hardware may not be so easily achievable by many users (cost and finding someone to perform the work can be big issues). So we should still work on reasonable features on low spec hardware for the short term. Obviously entry level advances rapidly so we should focus more effort the higher spec. I guess many users would only start to consider changing to Linux at the point that they need a new PC (though Linux would perform very well on their older kit) so that also suggests developing for thehigher spec hardware. -- Steve Lee -- Open Source Assistive Technology Software PowerTalk - your presentations can speak for themselves www.fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [g-a-devel] gnome-speech, and audio output, moving forward.
On 16/10/2007, Luke Yelavich <[EMAIL PROTECTED]> wrote:
> - From reading a summary of the recent Boston summit, I don't remember seeing
> anything regarding
> speech. I would really like to see if we as a community can't work out a
> solution.
My 2cs, a standard speech platform would be excellent for developers
and users. I would like to add a simple self voicing capability to
Jambu but have not done so yet, largely due to the number of
permutations to consider. Charles Chen suggested a number of
possibilities including bundling espeak.
My ideal is a standard Gnome speech API which could be assumed to be
there (so no need to include in build) but still allows end user
flexibility. So that's similar to SAPI on Windows (the SAPI speech
markup is just icing on the cake). As Linux thrives on choice a more
palatable option might be an API wrapper that works with the various
speech systems.
Could a module be factored out of Orca for this as much work has
already been done there? Python would suit me as it seems to be
becoming the language of choice for Gnome AT.
Then for a simple self-voicing scenario I could just:
import pygspeak as pgs
pgs.say('hello world')
I18n would no doubt add some interesting wrinkles.
For general non-visual accessibility making the program fully
accessible to Orca should be the approved approach.
A mechanism is needed to mute self voicing apps when using Orca. A non
server solution could be to check for orca in the say() function and
having orca check at startup.
--
Steve Lee
--
Open Source Assistive Technology Software
PowerTalk - your presentations can speak for themselves
www.fullmeasure.co.uk
___
gnome-accessibility-list mailing list
gnome-accessibility-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Tapir predictive keyboard
I thought I'd (re)introduce the Tapir 'OSK' program that features disambiguation (sometimes incorrectly called prediction) similar in operation to mobile phone entry systems. It has been developed by David MacKay's Dasher team with design input by Mick Donegan. I think it could be a useful GNOME program (it depends on Python + GTK). It can optionally use festival but that could be changed to eSpeak. A little polishing may be needed for HIG and it currently does not have a Linux package but that should be a nice little project for someone. http://www.inference.phy.cam.ac.uk/tapir/ -- 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: Tapir predictive keyboard
On 28/11/2007, David Bolter <[EMAIL PROTECTED]> wrote: > Looks slick. Is this already going to become part of GNOME via Dasher? > cheers, David MacKay has indicated that it will be a separate project as far as they are concerned upstream. -- 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: [Usability] Discoverable off-screen window dragging
On 05/12/2007, Kristian Lyngstøl <[EMAIL PROTECTED]> wrote: > In Compiz, this is indeed bugged, but not in the way you describe it. > > Alt+F7 and alt+space->move functions the same, however what happens > here is that you can initially move the window freely, but once moved > back, you can no longer move it above the struts. Aha, I was not able to reproduce that after I first saw it but have just done a little more investigation and there are a few more details. * you can only go above when the window opens flush against the top panel * any movement at all with mouse or keyboard stops it going above. Perhaps you could update the bug as I don't have an account (oh for openid in all these bugzillas). -- 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: Forming an Accessibility Steering Committee
Nice one, and I'm happy to contribute. Will: FYI re docs, there should be an article on GNOME a11y, AT-SPI, pyatspi, accerciser etc in the December issue of Python Magazine which will subsequently be available for open use (CC'd) such as a11y.org or gnome docs. I'd be interested in doing more. -- 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 documentation Re: Forming an Accessibility Steering Committee
On 19/12/2007, Willie Walker <[EMAIL PROTECTED]> wrote: > On a higher level, I think we need to take a bigger picture view of the > GNOME a11y documentation and consider a big refactor/reset -- it's > currently spread out over a number of places, with many of these places > being somewhat outdated and/or unorganized. > > What I'd like to see is a main 'jumping off' spot that developers, > future contributors, and users can start with and then easily end up > getting to the information they want. I'd propose that this place is > the WIKI (http://live.gnome.org/GAP or perhaps a page with a more > intuitive name http://live.gnome.org/Accessibility). > I'd also propose that we "clean house": get rid of all the old stuff > and/or clearly mark it as being an archive. In addition, we should > strive to eliminate overlap as much as possible. We've had a number of > problems, for example, where people have ended up on AT-SPI > documentation that is not accurate, mostly because there seem to be a > number of pages that have been created over time. As someone who recently went through the process of trying to 'zero in' on it all as a developer I quite agree. I found many conflicting sources of various ages (to some extent this a common Open source problem). For example most people I asked were unsure of the correct AT-SPI docs to use and I still haven't found a definitive list of events and their semantics. I also spent a lot of time making design choices that caused large problems. AT-SPI has hidden depths that would benefit from easy to assimilate introductions or 'best practice' guides. Sure the code has it 'all there' but you often don't see the 'wood for the trees' until you've learnt the hard way. I'd like to have a11y as easy as possible for developers and users, so it just works. The starting point also needs to be big and bold so it is found rather than web searches which can land you anywhere (perhaps we could SEO it so it gets found first). I'd be keen to see the user/dev/content-creator stuff kept pretty close too. Though they are different needs there is actually overlap (e.g. devs new to a11y will want to know how to use it) and it all needs to stay in synch. I agree the wiki is the best place as it is open. I'd go for http://live.gnome.org/Accessibility. > I think this kind of work really needs a good writer with a good sense > of how to organize and wordsmith the content. With this proposed > refactor, I'd like for a writer to not only help do the work, but also > help us devise a clear plan for how to maintain the pages and how/where > new documentation should be added. For example, assuming a new > assistive technology comes along (e.g., MouseKeys), I'd like to see a > plan for how its end user and developer documentation can be quickly > reached from the 'jumping off' spot. Yes that makes sense to avoid entropy rapidly encroaching ;-) I think a key is to make it easy to find the answer to a specific question as well as providing introductory/conceptual/educational material for quick orientation and depth understanding. Quite what structure that takes will be interesting to solve. > If this makes sense, is this something you can help with? I'm interested in helping as this is an area I'm getting more 'into'. However I need to work out a few things for next year. Brian's wiki page idea sounds like a good starting point. -- 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: Forming an Accessibility Steering Committee
Aaron your comment is good. Perhaps we just need to keep a collective eye on the big picture? Having a regular discussion may ensure we cover strategy? Whatever this discussion is great. On 19/12/2007, Brian Cameron <[EMAIL PROTECTED]> wrote: > 2) What would you like to see the Committee be responsible for doing? Ensuring GNOME 'just works' for as wide a range of users as possible, covering small a11y tweaks to full-blown ATs. Ensuring Linux/GNOME is the choice for users wanting a11y (sorry they're fuzzy) > 3) What do you see that is blocking progress (or hindering acceptance) > of GNOME a11y. What do you think could be done to improve things? The issues I see when promoting Open Source a11y around the UK (oatsoft.org, senit, schoolforge.org.uk) are that with a few exceptions: 1) users including clinicians and suppliers don't see Linux as a option 2) support organisations are concerned about the cost of having another OS to support, especially one with many flavours. 3) residual erroneous fears about open source I think Willie is right in saying that it really needs evangelism/marketing effort in order alter opinions and get the great work in GNOME to the users who can benefit. As Linux becomes a real option for consumers it would be fantastic if those needing accessibility were drawn to it as it provides the best options. e.g an eye tracking system would be a winner as commercial systems are so expensive Things are definitely moving in the right direction. We should attempt to further reduce entry barriers by more of: * help developers understand the general issues and what they can/should do * reduce the load for app developers in adding and testing a11y * make creating new innovative AT's easy * enable users to easily find the options or ATs they will benefit from * docs/education/evangalism > 4) Assuming that we can identify a list of tasks in the answers to the > above questions, would you be willing to invest time in the Committee > to chip in and take on tasks to make progress in these areas? Sure, given time. -- 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: Forming an Accessibility Steering Committee
That's great Willie, I've just a few suggestions who: * Clinical and educational support staff (probably a mixture of end users, IT staff, and power users). They want to know how to support a number of clients, how to customise settings or create accessible media. * Windows AT developers: pointers to how to port their AT :-) GNOME for real: why open source is good and myth debunking What: how about a matrix of features per disability for users/support Future directions: add missing features e.g reading support and eye gaze + where to go for help. There's overlap with the a11y.org work on AT-SPI and testing Steve On 20/12/2007, Willie Walker <[EMAIL PROTECTED]> wrote: > Hi All: > > Before I invest a lot of effort into getting things going on the WIKI, I > wanted to pass some ideas by everyone. > > I'm thinking that we want the work and impact of the committee to be > very transparent. In addition, we want to avoid duplication of > information as much as possible. This will also tend to be tightly > coupled with the WIKI refactor, which might be one of the first things > we want to get done. > > So...let's try to work out what we want the GNOME A11y WIKI to look > like. I'll start with a proposal that we can twist/turn/modify. :-) I > think the first question to ask is "who are the typical visitors to the > site and what do they want to do?" I'm going to guess it will be a mix > of mainly the following: > > o End users wanting to know how to get going with a11y support > o IT staff making decisions about whether or not they want GNOME > o Developers and future a11y developers wanting to know how they can > help the GNOME a11y project > o Developers wanting to know how they can test their stuff for > a11y and how to fix problems they run into > > The top level page, http://live.gnome.org/Accessibility, will be our > face to the world. It should be relatively short, clear, and easy to > navigate by our target visitors. Much of this information is already > available; we just need to organize it and bring it up to date. Here's > a potential skeletal outline, though it's not short and probably not clear: > >[Logo] -- we really need a good logo. >o "A11y 101" (what is a11y?) >o GNOME A11y is for Real > o Impact of GNOME a11y around the world >- Testimonials >- Case studies (e.g., GNOME in Spain) > o Commonly used apps that provide compelling access >- Evolution, gedit, gnome-terminal, ... >- Firefox 3, Thunderbird, OOo, Pidgin, ... > o Organizations involved >- Sun, Mozilla Foundation, Ubuntu, OLPC(?), ... >- Steering committee (see below) >o Latest news: ... >o Active projects and current focus > - Orca, AT-SPI/DBus investigation, ... >o Future directions and ideas > - (achievable tangible projects) >o GNOME's built-in a11y: > - keynav, theming, AccessX, MouseTweaks, ... > - GOK, Dasher, Orca, ... > - A11y infrastructure >- AT-SPI, ATK, GAIL, GTK+, bridge(s), ... >- pyatspi >- gnome-speech, gnome-mag >- accerciser >- External extras: BrlTTY, ... >o For application/toolkit developers > - How to develop/test for a11y > - Matrix of a11y vs. application coverage > - Accessibility bugs sorted by priority/severity >o For a11y developers > - A11y projects for you to help with (see active and future above) > - Getting started with pyatspi (or whatever) > - Jumping off points to Orca, GOK, ... developer documentation >o For operating system distributions > - Dependency lists > - Short smoketest steps >- Accessible login >- Quick tests with AccessX, GOK, Dasher, Orca, ... > - Integration tips, tricks, and troubleshooting > > I'd propose that the 'doings' of the steering committee be held at > http://live.gnome.orca/Accessibility/SteeringCommittee. It will contain > our charter (which we need to create), a member list, and meeting > agendas/minutes. Representation of the other work of the committee > probably should find its way into the rest of the WIKI. > > Anyhow, those are some quick thoughts before I need to step out for the > day. Thoughts? > > Will > > PS - I'm going to be on break next week and part of the following week, > but I'll try to keep up with e-mail during that time. > > ___ > gnome-accessibility-list mailing list > gnome-accessibility-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > -- 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: Forming an Accessibility Steering Committee
> 3) Brainstorming / developing improvements that push the envelope in > the user experience. It's great to have a set of familiar assistive > technologies for people to use today when migrating to GNOME from > other platforms. But a benefit of developing on an open stack with an > excellent (the best?) accessibility infrastructure is that it affords > us the opportunity to create alternative, better, more usable, (pick > an adjective) software to help users. Dasher is a perfect example: > born out of research and later packaged with GNOME releases as a new > "flavor" of on-screen keyboard. Absolutely! FOSS offers the possibility of innovation (ignoring those who say it only copies existing projects) so we could offer something that can't be got elsewhere. This is especially true of alt input where users could get maximum benefit from technology. While I only hinted at it before it looks like 'eye gaze' is one such area as it is effective, in it's infancy and commercial solutions are VERY expensive at the moment as vendors recoup R&D costs. Reading support and communication aids are also ripe for innovation. Steve ___ 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
On 21/12/2007, Peter Parente <[EMAIL PROTECTED]> wrote: > So what could we do to push the envelope under the same premise, that > is, reuse existing, commodity hardware and platforms? The Nokia N800 > line of Internet tablet products with Maemo comes to mind. It's > GNOME-based, supports open development, and has an API for > communicating with Bluetooth GPS receivers. The cost is around $300 > for the N800 and roughly $100-$300 for a separate GPS receiver. It looks like the N810 includes GPS so you can save that $100-$300 ;-) http://europe.nokia.com/A4568578 Were just waiting for them to land. Steve ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Collection of AT videos
The Ability Net channel on YouTube features a steadily growing collection of videos on AT and accessibility that introduce technologies, show how to use it and provide user experiences. http://www.youtube.com/profile_play_list?user=abilitynet It'd be great to see more examples of Open Source and GNOME a11y, whether on this channel or another (with care they could also be interesting to people who can only access the speech). -- 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 21/01/2008, Francesco Fumanti <[EMAIL PROTECTED]> wrote: > There is dasher that is reputed to have a good prediction engine; but > it seems to lack the possibilities to control the desktop. I understand that Dasher has a control mode, but I'm not clear on if it is experimental as there is nothing obvious in the version I have installed via the Ubuntu repositories. > 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,... Without wanting to answer for the GOK team I think I heard there may have once been an investigation into prediction. What features are needed that GOK does not have in its main OSK? Is it simply they way it starts up and having a simple OSK appear would be what you prefer? > 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? No but I have seen demos of head tracking with simple webcams without reflective dots on foreheads if that is what you mean? There has been discussion of webcam-based eyetracking over at www.oatsoft.org, including combining it with headtracking to improve accuracy. > 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 guess that is the usual hardware/software tradeoff. Perhaps the USB standard ensures all conforming devices can be covered with standard drivers? > 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. AFAIK the keyboard standards are to ensure that application authors add complete and standardised keyboard access as it is their job to do so. For pointer access I think there is less of an issue as it is generally predefined by OS / UI tookits used and extra accessibility options like dwell click are features of system or device drivers. So there should be operating/window systems guidelines rather than application guidelines. There is a need for guidelines for custom widget use of pointer. -- 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: efficient osk - was GNOME A11y: where do we need to improve?
On 22/01/2008, Francesco Fumanti <[EMAIL PROTECTED]> wrote: > maybe I should > list the main features that I would like to see > (they also are in the GetInvolved page): [snip] Can you put these on the wiki so they get captured? This is really useful. > as > far as I know, the usual layouts (qwerty?) were > designed for technical reasons to maximize the > distance between two subsequent letters; for > onscreen keyboard that distance should be > minimized to type faster: Yes to stop typewriter keys jamming The trouble is QWERTY has become the standard though there are alternative layouts (Dvorak). Perhaps an OSK frquency-based standard could be devised (language dependant). > Should onboard be enhanced, should gok be > improved (for example the setup wizard idea, > concentrating on uses cases instead of technical > aspects; refine the composer; core pointer > issue,...)? Any solution should do that (e.g using 'Personas') ;-) > Two moving references; this surprises me: I > assumed that eyetracking required a resting head. I tried MyTobii/Grid and it was quite resilient to my attempts to confuse it with lateral head motion. My thought was that headtracking could be used to help compensate for motion by helping to locate the eyes. > Are you talking about porting all (if not most) features of gok to python? That has been discussed. Technically it would be great if pyatspi became the standard that AT authors used to access applications. If you would like to know more there is an introductory article in the latest edition of python magazine (http://pymag.phparch.com). > By the way, there are a few words concerning > switch input in the specifications of sok. My understanding is that switch access was added in a later release after basic pointer access. GOK started with switch access as a requirement. As an alternative Jambu's jambuinapp gives another option by allowing switch users to directly move around a User Interface (e.g Firefox). http://www.oatsoft.org/trac/jambu/wiki > I don't know whether it would really make sense > to have a variable keyboard for the use case that > I have in mind (a user without problems to move > the pointer). It would require more learning from > the user. Maybe that I get you wrong: what > behavior are you talking about? It might be worth making a distinction between text input and application control. If a program has complete keyboard access then it is possible to control it from an OSK with a sticky keys feature. However 'keyboards' with context sensitive menus of actions do give a simplified experience with less cognative load (no need to remember all those key combinations). A more extreme case is highly reduced 'option sets' that are useful for people with multiple and/or learning disabilities who need simplified and graduated UIs and not exposure to raw applications. > PS: I have not named the exact AT that I am using > because I don't know whether it is good practice > to name commercial items in a free software list. I don't know, I don't think it is a problem as they all help users. BTW there are some interesting resources on the ACE Centre site that include info on prediction and head mice. http://www.ace-centre.org.uk/index.cfm?pageid=B2592F93-3048-7290-FED2AED562D4432C -- 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: efficient osk - was GNOME A11y: where do we need to improve?
On 23/01/2008, Steve Lee <[EMAIL PROTECTED]> wrote: > On 22/01/2008, Francesco Fumanti <[EMAIL PROTECTED]> wrote: > > maybe I should > > list the main features that I would like to see > > (they also are in the GetInvolved page): > [snip] > > Can you put these on the wiki so they get captured? > This is really useful. Whoops sorry, you did ;-) -- 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 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)
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)
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=diff&rev2=30&rev1=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)
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 mi
Re: [gdm-list] Bringing back a11y
This is a fantastic discussion and many of my thoughts have been covered already. Perhaps it is worth getting a bit more abstract and thinking of a few scenarios so as to cover all uses. 1) Single user: They want their AT/a11y config(s) remembered at login and beyond. Arguably some may don't even want to login but I think that would not be a good idea. 2) multi user: Each user will need a unique AT/a11y config for login but don't know AT requirements until user is identified and at the moment this means logged in. 3) clinical/education/corporate: support staff will want to configure AT for individual users and ideally deploy remotely. Note here the user is not directly responsible for selecting their AT/a11y. Once better ways of identifying people arrive (biometrics, Near Field Computing, RFID etc. etc.). then the problem gets simplified as a users custom AT config could be automatically selected before authentication (login). 'Till then the solution has to be to provide sets of configs that can be easily selected before login, as discussed. Some predefined common cases and the ability add more should cover the scenarios. A simple list of named configs should be the simplest UI, with various gestures to access. As a bit of blueskying a 2 level system might work but it does seem more complex and may be unworkable. I'm thinking of a course selection for vis/mobil with simple gestures or selection by device used, that load ATs for selection of individual config using richer gestures. It occurs to me that we really want a extra layer of gesture abstraction where gestures on various devices (possibly more than one) get mapped to actions in the OS and applications. Failing that we have to map the gestures to standard input (key and pointer). The trouble is input and output are never quite so decoupled, as in the case of screen readers. -- 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: Thin Client Networks was [gdm-list] Bringing back a11y
When I looked into this before: www.schoolforge.org.uk/index.php/Assistive_Technology_with_Terminal_Servers It seems that LTSP works due to the great design of X and basically adds a neat way to get it going. X provides distributed operation with displays and various input devices but other devices like sound and Braille (I think) aren't included so need to be handled separately. AFAIK sound is now most sorted but the problem boils down to careful thought about distributed operation (what is running on which machine). Designing for deployment across machines possibly with AT on another machine to the application and not assuming everything is on the same machine (as Windows mostly does, even with Terminal Services or RDP). Steve Lee On 12/02/2008, Ian Pascoe <[EMAIL PROTECTED]> wrote: > Following on from Steve's point 3 below. > > With the higher availability of interconnects and CPU performance, more and > more corporate organisations are moving to a thinner client infrastructure. > In addition, the cost benefits are also making the thin client ideal more > attractive to educational establishments. > > With this in mind, what potential problems would this type of network > present to a user requiring AT style applications? > > I know that Speech Despatcher works quite happily over this infrastructure , > but what about the other AT applications? > > Using LTSP as an example for Thin Client networks, they appear to offer a > number of different ways of logging into the network - would any development > as a result of discussions here be useable in a similar thin client network > setup? > > Ian > > -Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Steve > Lee > Sent: 08 February 2008 10:50 > To: Brian Cameron > Cc: Matthias Clasen; gnome-accessibility-list@gnome.org; > [EMAIL PROTECTED] > Subject: Re: [gdm-list] Bringing back a11y > > > This is a fantastic discussion and many of my thoughts have been > covered already. Perhaps it is worth getting a bit more abstract and > thinking of a few scenarios so as to cover all uses. > > 1) Single user: They want their AT/a11y config(s) remembered at login > and beyond. Arguably some may don't even want to login but I think > that would not be a good idea. > > 2) multi user: Each user will need a unique AT/a11y config for login > but don't know AT requirements until user is identified and at the > moment this means logged in. > > 3) clinical/education/corporate: support staff will want to configure > AT for individual users and ideally deploy remotely. Note here the > user is not directly responsible for selecting their AT/a11y. > > Once better ways of identifying people arrive (biometrics, Near Field > Computing, RFID etc. etc.). then the problem gets simplified as a > users custom AT config could be automatically selected before > authentication (login). > > 'Till then the solution has to be to provide sets of configs that can > be easily selected before login, as discussed. Some predefined common > cases and the ability add more should cover the scenarios. A simple > list of named configs should be the simplest UI, with various gestures > to access. > > As a bit of blueskying a 2 level system might work but it does seem > more complex and may be unworkable. I'm thinking of a course selection > for vis/mobil with simple gestures or selection by device used, that > load ATs for selection of individual config using richer gestures. > > It occurs to me that we really want a extra layer of gesture > abstraction where gestures on various devices (possibly more than one) > get mapped to actions in the OS and applications. Failing that we have > to map the gestures to standard input (key and pointer). The trouble > is input and output are never quite so decoupled, as in the case of > screen readers. > > -- > 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 > > > ___ > gnome-accessibility-list mailing list > gnome-accessibility-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > -- 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: March 2008 Linux Journal has articles on GNOME Accessibility
Congrats to both of you, that's a great mag to be published in. Hope I can get a copy here. That reminds me that the little article I wrote for the new Python Magazine is released next week so it can be posted on GNOME and/or a11y.org. So I'm wondering where it would best go and what format it should be in. At the moment it's text (with a little light markup) plus images. I'm thinking the GNOME wiki is the place to be. -- Steve Lee On 15/02/2008, Willie Walker <[EMAIL PROTECTED]> wrote: > Hey All: > > Just a quick note -- Eitan Isaacson and I have GNOME accessibility > articles published in the March 2008 Linux Journal. Mine is on Orca and > Eitan's is on Accerciser. This is exciting stuff to me because it helps > get our GNOME accessibility story out to a large range of mainstream > developers and decision makers. > > One of the great things about working on accessibility in GNOME is that > the majority of the people support it across the board. Way to go, and > many thanks for your support, your positive attitude, and the fact that > you "get it". > > Will > > PS - I blogged about it here: http://blogs.sun.com/wwalker/. Click on > it and you can see the "Many Faces of Will" at the top. The most recent > is the one furthest right -- I have very short hair and I'm skinny after > a hard season of bicycle racing. My favorite is the second from the > left, but my wife thinks I look too "Hey Dude". > ___ > 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: Exciting news: funding coming our way!
Awesome! Well done everyone and huge thanks to Will for leading us. Now we can see GNOME and Open Source and really rock the accessibility world and even take the lead. I need to lie down. Steve Lee On 17/02/2008, Willie Walker <[EMAIL PROTECTED]> wrote: > Hi All: > > The larger community has seen our work with identifying and prioritizing > the accessibility tasks we find really important. As a result, they are > now providing funding to get the work done. This is FANTASTIC news! > > More details will be coming out very soon (this week?), but the GNOME > Board has requested that we let the GNOME accessibility community know > first. :-) > > David Bolter from the University of Toronto, Luke Yelavich from > Canonical, and I will be the judges for the program. Between the three > of us, we can represent industry, academia, infrastructure, assistive > technology, standards, and end user considerations. We of course will > not operate in a vacuum but will instead continually consult with you, > the community members, to make decisions. > > Way cool stuff. The nature of the funding will support shorter term > individual projects (e.g., USD$6K with a 6 month deadline). When I look > at the tasks we identified as a community > (http://live.gnome.org/Accessibility/GetInvolved), I see a really good > balance of achievable tasks that fit within the budget, and they are all > on the top of the list. In particular, the following seem to be very > good matches: > > 1) Documentation. There is a steep learning curve for users, > developers, and operating system integrators. Many people just need a > place to start and concise hand-holding directions. With good > documentation in place, we can provide answers to common questions such > as "how do I test my application for accessibility?", "how do I fix > common accessibility problems?", "what assistive technologies are > available for my disability and how do I use them?", etc. We will get a > lot of really good impact across the board with this task. > > 2) Evince accessibility. Accessible free open source document viewing > is dearly needed on our platform, and Evince is sooo close. With a > concentrated effort, this task will help bring accessible document > viewing to GNOME. Way cool and way needed. > > 3) Speech and magnification. With Orca helping exercise speech and > magnification, we have been able to identify the strengths and > weaknesses of the existing support provided by gnome-speech and > gnome-mag. At the same time, the world has changed a bit around us, > with considerations needed for a more global view. These two separate > tasks will help move us to state-of-the-art cross-platform solutions > that can be used by GNOME, KDE, OLPC, OpenMoko, etc. Again, way cool > and way needed. > > 4) Testing. It's hard for me to count the number of times we've seen > components make changes late in the release cycle that adversely effect > accessibility. My only measurement is how much hair I have lost as a > result. GNOME needs a unified testing strategy, and we need to make > accessibility a core part of that from the start. This task will help > get us there. AWESOME. > > 5) Bug fixing. We need bugs fixed and good hackers will now have money > to inspire them. 'Nuf said. :-) > > So...we still have some work to do as a community. In a separate > e-mail, I will be sending out proposed times for an IRC meeting next > week based upon the availability I've received from everyone so far. In > this meeting, we can discuss the program and the tasks further. > > This is s exciting. Many thanks to everyone who has helped -- we're > going to make some great strides with this. > > Will > ___ > gnome-accessibility-list mailing list > gnome-accessibility-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > -- 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 Community IRC Meeting
Thurs suits me followed by Tues. I'll have problems with Friday. Bryen I think the dress code is smart casual (from the waist up) Steve On 18/02/2008, Willie Walker <[EMAIL PROTECTED]> wrote: > Hi All: > > Based upon the feedback, I think the following times seem like they > might work for us. It's a struggle, however, since we are all over the > world, various people already have standing meetings, and there is also > a bias towards a number of European folks not being able to do this > during normal working hours. > > Tue 19-Feb: UTC 21:00-22:00 > Thu 20-Feb: UTC 19:00-??? > Fri 21-Feb: UTC 19:00-??? > > Please let me know your availability/preferences for these slots, and I > solidify it. If there's some other time that you really strongly > prefer, please also let me know. > > Will > ___ > gnome-accessibility-list mailing list > gnome-accessibility-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > -- 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
Article now on Wiki
The GNOME a11y introductory article is now on the Wiki http://live.gnome.org/Accessibility/PythonPoweredAccessibility (I need to figure out how to add the images) What licence is the GNOME wiki under? I want to put the article under a CC 'by at' but could someone advise me on compatibility with the Wiki? I might post it somewhere else like a11y.org or even break it up and distribute it over the wiki. -- 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: A spotlight on the need for basic reading and writing support in GNOME
Hi Mats, It's great to see you here, bringing as you do, very considerable experience. You have raised some great points that highlight an important area that is missing and if implemented will add to GNOMEs usefulness. I wonder if reading support may also offer some interesting 'curb cut' possibilities for being used in other scenarios such as primary education and talking books. I have a couple of quick thoughts before I retire. 1) I'm guessing the additions you suggest for Orca reading support might be achievable in the $6K/6mo limits and we should look at finding someone to do them. 2) We've just been discussing new magnification schmes using the window manager and I wonder if magnification is useful for reading support (in addition to highlighting). If so what are the requirements? 3) Text-under cursor should be possible with accessible applications that expose AT-SPI. 4) What are the minimal writing support that needs implementing? Steve Lee On 21/02/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Hi all, > > My name is Mats Lundalv (employed at the DART AAC and AT centre, as well as > at the Swedish Institute for Special Needs Education (SIT) in Goteborg, > Sweden). I'm a new voice in this forum, but have been encouraged by Steeve > Lee and David Bolter to post my thoughts here, following from the > discussions in the Oatsoft email forum. > > My main reason for writing now is to advocate for putting the spotlight more > on one or more of all the good things that are found – and possibly a bit > hidden – among all the good things down in the > http://live.gnome.org/Accessibility/GetInvolved listing. I > would like to see them among the high priority tasks. > > The background is a survey we did at SIT comparing the accessibility and AT > support situation for the WinXP, MaxOSX and Ubuntu-GNU/Linux platforms. We > found that the big problem with the GNU/Linux environment is its total lack > of proper support for the largest groups of users with accessibility > problems - that is; users in need of basic reading and writing support > (other than users with pure visual impairments)! > > > > > This is the reason why we cannot currently recommend the free and open > source platforms for schools from an inclusion and accessibility point of > view, as students with reading/writing and learning disabilities - ranging > between 5-15 % of the students in different educational environments - are > left without proper assistive support. > > If, on the other hand, these needs were reasonably well supported in the > basic GNOME - GNU/Linux environment, this would immediately make it a very > attractive alternative for the educational areas. This is a strategic issue > for the wider acceptance of the free software alternatives for the > educational systems – and in general. > > I would really like to challenge this forum to consider ways to start > addressing this problem now, rather than leaving it further down on the wish > list for another round. > > The question is where and how to start of course. A few points: > > Proper tts support for these needs is the fundamental thing. This could > either be taken on as a separate project, based on existing tools for > Windows – as indicated in the "Dyslexia and Learning Disabilities" point in > the list etc. > Another idea would be to look at the possibility of building on all the good > functionality of Orca and refurnish that for providing basic reading and > writing support. I'd like to see your views on that approach. An indication > of what's needed and what Orca has to offer, and would additionally need: > > Needed: > In Orca > Basic settings: > Options to shut the speech up and - no – context > info reading etc cannot be disabled > just provide the support needed as far as I can > see > Keyboard input echoing: ... - basically > supported ... > key-by-key on/off - > yes > word-by-word on/off - yes > sentence-by-sentence – after > punctuation/new line on/off - no > Reading tools: ... > Key_command_controlled: ... > whole text (with reading cursor) - yes > (cursor?) > line-by-line (with reading cursor) - yes > word-by-word (with reading cursor) - yes > sentence-by-sentence (reading cursor)- no > > GUI-based: ... > ... above reading tools through > a reading toolbar - > no >
Re: Re: A spotlight on the need for basic reading and writing support in GNOME
On 22/02/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > 4) What are the minimal writing support that needs implementing? > I think this is indicated in my points about Orca: [snip] ah, so basic writing support is really reading back what has just been written? This in addition to spelling/prediction etc? -- Steve Lee -- Open Source Assistive Technology www.fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Quick notes on the mechanics of the AT-SPI infrastructure
On 22/02/2008, David Bolter <[EMAIL PROTECTED]> wrote: > Thanks for sharing. I wish I'd made my notes public over the years... > especially since I tend to lose them. I think it is a great idea to get > this stuff on the wiki. Thanks again. +1 That's what wikis are for. We can refactor later. The important thing is to get all that stuff out of peoples heads so it can be shared.. Nice one Will. -- Steve Lee -- Open Source Assistive Technology www.fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Thoughts on testing and outreach
I'd add 2 forms of user testing: * 'Ad hoc' or 'guerilla' testing often exposes problems not always caught by methodical test strategies. AFAIUI this is users playing fast and loose with the UI, trying to catch it out. * real world usage as users may exercise stuff it in unexpected ways (I think Orca has benefited greatly from this). I agree that we should concentrate on accessibility tests. While it seems to make sense to leverage the effort and cover the the forms of testing I think that will dilute what we need to achieve as the a11y group and the message of the outreach program. Even when we are producing tests that have obvious general test application I think we should remain foucussed for now (other groups can always use and contribute). Once we have good mileage there we can embrace the other testing and share work. That said, the AT's and infrastructure should have good unit/automated test suits for regression etc. Steve Lee On 23/02/2008, Eitan Isaacson <[EMAIL PROTECTED]> wrote: > Hi, > > I think a few stuff were left in the air about the huge testing > challenge we face, and how to put the outreach program to play in that > direction. I would like to organize a few of my own thoughts, and get > other people's opinions on this. I'm not appending this to the existing > thread in desktop-devel, because I think this might be less specific > than that conversation. If you are in a rush, jump to the conclusion at > the bottom. > > In my mind there are a few things we mean when we say "testing", here > they are: > > UNIT TESTS > > These are small non-runtime tests that are usually invoked by "make > check". They are ideal for shared libraries. There are plenty of GNOME > modules out there that take advantage of autotools integration of these > kinds of tests, and the GNOME build brigade provides test results during > it's (nightly?) automated builds. In my mind we have, or potentially > have, good coverage of these kinds of tests. > It's very much like tinderbox, you could see it in action here: > http://build.gnome.org > > AUTOMATED GUI TESTS > > These are runtime tests that automate user interaction, and have > different methods of asserting the test results. This is what the talk > about is in desktop-devel[1]. I think everyone there is in agreement > that - the status quo sucks, we need an open and collaborative space for > automated testing, maybe something like build.gnome.org. And a blessed > single testing toolkit. > Coincidentally, automated GUI testing usually relies heavily on our > accessibility framework. But let's not get confused, the main purpose of > most of these tests is not accessibility, a developer will put these > tests in place to squash conventional bugs. Will has a hidden agenda > when he pushes for these kinds of tests in other GNOME modules, we get > to exercise an application's accessibility "for free". > > ACCESSIBILITY TESTS > > Unlike the top two categories, accessibility tests don't have a specific > method, it's just any kind of test that tests for accessibility, they > could be unit tests, or GUI tests. They could also be a third kind of > test, and that is external poking, like at-poke and accerciser do. They > could be automated, and they could be manual. I think this is a very raw > but fertile ground. A good example of a start is Peter Parente's > validation plugin[2] for Accerciser, it will give a lint-style > accessibility test. > > CONCLUSION > > In my opinion, our outreach program should focus on the third meaning of > "testing" - accessibility testing. Besides the obvious test schemas and > accerciser extensions, I think this also entails work inside other > modules, and adding to their testing story a sleuth of tests that test > nothing other than accessibility. It could be as simple as writing a > test that searches for unrelated labels in a glade file, this script > could be duplicated across every module that uses glade, and run during > "make check". Or a dogtail sequence that simply listens for the right > events as buttons get clicked. > > Think about it - I haven't. [3] > > Eitan. > > 1. > http://mail.gnome.org/archives/desktop-devel-list/2008-February/msg00103.html > 2. http://pithy.tumblr.com/post/23941873 > 3. Stephen Colbert > > ___ > gnome-accessibility-list mailing list > gnome-accessibility-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > -- Steve Lee -- Open Source Assistive Technology www.fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Dasher project needs volunteers
I don't know if it is common knowledge but the amazing Dasher project is in need of some TLC, particularly maintainers and developers, but all contributions would be most welcome. http://eduspaces.net/stevelee/weblog/283248.html -- Steve Lee -- Open Source Assistive Technology www.fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Thoughts on speech
Brilliant Will, I've just leant a whole lot, thanks What is the main API for speech? Something like speak( sText ) ? Steve On 07/03/2008, Willie Walker <[EMAIL PROTECTED]> wrote: > OK - welllet's see. I'll fill in what I know, but I need the Speech > Dispatcher folks to fill in what they know. > > GNOME Speech: > >Just a thin wrapper over a TTS engine. > >Doesn't do audio management - leaves that to the TTS engine. > >Drivers for Festival, FreeTTS, DECtalk, IBMTTS/ViaVoice, >Loquendo, eSpeak, Cesptral/Swift, Eloquence, and even a >wrapper for SpeechDispatcher. No support for DECtalk >Express. > >At a minimum, callbacks supported at the utterance level, >where an utterance is the chunk of text tossed at it via >a single speak command. Callbacks are also supported at >the word progress level if the engine supports it. > >Mostly just sends text off to the speech synthesis engine >for speaking. The only 'extra' stuff that's really done >is adding index marks to text strings to be notified of >speech progress at the word level for those TTS engines >that support it. > >No real support for SSML. > >Audio is controlled by the speech synthesis engine. > >Bonobo/CORBA based, essentially locking it to GNOME >for all intents and purposes. > >Speech services are discoverable and activatable as >system services (via Bonobo Activation). > >Those skilled in the art and with knowledge of the TTS >engine's API can write a driver in a day. It's much more >difficult for those not skilled in the art. ;-) > >Difficult to debug. > > Will > > > David Bolter wrote: > > Will, > > > > That sounds very reasonable to me. Can you start it? :) > > > > cheers, > > D > > Willie Walker wrote: > >> Hi All: > >> > >> This speech issue is obviously one filled with passion and high > >> expectations. I think our ultimate end goal here is to find a > >> solution that works well and fits within the various constraints. > >> > >> The two solutions we've been talking about, gnome-speech and Speech > >> Dispatcher, both have their strengths and weaknesses, and I'm not sure > >> we all understand what they are. Nor do I think we all understand > >> what "works well" means and what the constraints are. > >> > >> As an exercise, what do you all think of us having a somewhat > >> impassioned and pragmatic discussion about the various features and > >> the current state of gnome-speech and Speech Dispatcher? > >> > >> 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 > -- Steve Lee -- Open Source Assistive Technology www.fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Dasher
On 19/03/2008, Bryen <[EMAIL PROTECTED]> wrote: > Is Dasher a useful tool that is still needed as part of a distro's > default install? It may seem rather obscure or strange but for some with physical disabilities it greatly eases text input as it requires only minimal gestures and vision. I don't know what the criteria are for default install but Dasher addresses mobility a11y so if Orca is a default I think Dasher should be.as well. It's also a chance to demonstrate innovation and leadership in the a11y field which I feel is good for GNOME and Linux.. Is there any way we can get an idea of numbers of users? We could ping the dasher team but they might be a little biased ;-) -- Steve Lee -- Open Source Assistive Technology Software www.fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Dasher
On 19/03/2008, David Bolter <[EMAIL PROTECTED]> wrote: > Before we completely leave this thread... Does anyone have any ideas on > how to collect accurate usage data for adaptive input programs? Are you talking predictive text? If so you could ping SImon Judge at OATSoft.org as it's one of his favourite topics. One of the Project Possibility Semester teams are working on a predictive engine, I have slides so could scan them for you. -- Steve Lee -- Open Source Assistive Technology Software www.fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Time for another IRC meeting?
+1 On 25/03/2008, Willie Walker <[EMAIL PROTECTED]> wrote: > Hey All: > > Wow - these past few months really wore me out. There were a lot of > deadlines all over the place, and they all seemed to happen at the same > time. > > Those are behind us now (yeah), and I'm wondering if anyone would be > interested in getting back on the #a11y channel on irc.gnome.org some > time just to chat as a group. One thing I really want to see is more > progress on the "GNOME Outreach Program: Accessibility" work. There's > good work to be done, and we need good people: > > http://www.gnome.org/projects/outreach/a11y/ > > Will > ___ > gnome-accessibility-list mailing list > gnome-accessibility-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > -- Steve Lee -- Open Source Assistive Technology Software www.fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Time for another IRC meeting?
WIll, I'll try to attend but it might be a bit tricky this time. Steve On 08/04/2008, Willie Walker <[EMAIL PROTECTED]> wrote: > OK - Let's shoot for 01:00 UTC this Friday. NOTE that for a lot of > people, this means the meeting will happen on Thursday. Here's a page > that does the magic needed to convert 01:00 UTC to local time for cities > around the world: > > > http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=11&year=2008&hour=1&min=0&sec=0&p1=0 > > For possible agenda items: > > 1) How to move "GNOME Outreach Program: Accessibility" along > (plus some exciting news about at least one task) > > 2) Setting up regular meetings > > Talk to you all on irc.gnome.org #a11y in a couple days! > > Will > > > > Willie Walker wrote: > > Hey All: > > > > Wow - these past few months really wore me out. There were a lot of > > deadlines all over the place, and they all seemed to happen at the same > > time. > > > > Those are behind us now (yeah), and I'm wondering if anyone would be > > interested in getting back on the #a11y channel on irc.gnome.org some > > time just to chat as a group. One thing I really want to see is more > > progress on the "GNOME Outreach Program: Accessibility" work. There's > > good work to be done, and we need good people: > > > > http://www.gnome.org/projects/outreach/a11y/ > > > > Will > > > > ___ > gnome-accessibility-list mailing list > gnome-accessibility-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > -- Steve Lee -- Open Source Assistive Technology Software web: fullmeasure.co.uk blog: eduspaces.net/stevelee/weblog ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [Accessibility] Nokia to fund D-Bus based accessibility
ccessibility-list > > > > > > -- > > > > > > Janina Sajka, Phone: +1.202.595.;sip:[EMAIL PROTECTED] > > > Partner, Capital Accessibility LLC http://CapitalAccessibility.Com > > > > > > Marketing the Owasys 22C talking screenless cell phone in the > > > U.S. and Canada Learn more at http://ScreenlessPhone.Com > > > > > > Chair, Open Accessibility [EMAIL PROTECTED] > > > Linux Foundationhttp://a11y.org > > > ___ > > > gnome-accessibility-list mailing list > > > gnome-accessibility-list@gnome.org > > > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > > -- > > Janina Sajka, Phone: +1.202.595.;sip:[EMAIL PROTECTED] > Partner, Capital Accessibility LLC http://CapitalAccessibility.Com > > Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada > Learn more at http://ScreenlessPhone.Com > > Chair, Open Accessibility [EMAIL PROTECTED] > Linux Foundationhttp://a11y.org > ___ > Accessibility mailing list > [EMAIL PROTECTED] > https://lists.linux-foundation.org/mailman/listinfo/accessibility > -- Steve Lee -- Open Source Assistive Technology Software web: fullmeasure.co.uk blog: eduspaces.net/stevelee/weblog ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GOPA: Magnification proposal
Thanks Kristian, that gives a very clear picture of the situation and issues. Good luck My impression is that this will also act as a good basis for future advanced and innovative mag features. -- Steve Lee -- Open Source Assistive Technology Software web: fullmeasure.co.uk blog: eduspaces.net/stevelee/weblog 2008/5/4 Kristian Lyngstøl <[EMAIL PROTECTED]>: > Reffering to various mail and IRC conversation, and the task page on > http://www.gnome.org/projects/outreach/a11y/tasks/magnification/ , > here's my proposal as to how to move forward with magnification. > > I know proposals are supposed to go to [EMAIL PROTECTED] > according to the rules, but I figure it's a good idea to send it here > first. > > Background > === > Magnification under GNOME today is limited to the use of gnome-mag, > optionally enhanced by Orca. It is made difficult by conflicts with > composite window managers which are the new trend. > > In addition to this, gnome-mag and Orca integration relies heavily on > ORBIT/Bonobo, which is on it's way out. While it was discussed at > GNOME Boston 2007 to keep ORBIT around for accessibility only, it was > concluded that this would require the accessibility community to > maintain ORBIT, which is not reasonable. > > For these reasons, and the wish to generally improve magnification, > the "GNOME Outreach: Magnification" task has come to be. > > > Summary of Goals > === > 1. Investigate exactly which features exist in gnome-mag and how they > differ from their equivalents in Compiz Fusion. Investigate what > information composite window managers could be interested in getting > from Orca that they currently are not requiring. > 2. Create a D-Bus based communication protocol to accommodate > communication between Orca and a Composite Manager. > 3. Give Orca the ability to directly configure accessibility parts of > a composite (window) manager with minimum visual changes to the > current UI. > 4. Mirror the functionality that gnome-mag has into Compiz. > 5. Create a hilight plugin in Compiz Fusion using the new D-Bus interface. > > > Details > > 1. > We want an interface that can stay stable, simple yet powerful. The > point of the initial investigation is to break down what exactly the > communication protocol needs to accommodate. The goal is to make > information available from Orca without taking full control of the > composite manager. > > This investigation will also be a requirement for being able to mirror > gnome-mag functionality in Compiz Fusion. > > 2. > Creating a D-Bus interface is the true core of this project. The idea > is to avoid locking ourself to a specific application, be it Orca, > Compiz or something else. It should be a fairly straight forward > process. > > The interface should also allow for discovering what is available. A > composite manager might support magnification but not highlighting, > and allowing this to be discovered would enable us to gray out the > features in a configuration UI (or otherwise indicate that they are > not available). > > 3. > Orca has done a magnificent job uniting the different accessibility > features, and is able to control gnome-mag without requiring the user > to be aware that they are in fact two separate applications. Ideally, > a transition from gnome-mag to Compiz Fusion should not require the > user to configure Compiz using a second tool. Compiz Fusion already > allows for easy configuration through D-Bus, however, this is > application specific. There are a few different ways of solving this; > > - Use the application-specific interface in Orca. > - Create a small plugin for Compiz Fusion to relay the necessary > configuration request from a generic bus. > - Something Else. > > 4. > Most of the features Gnome-mag has are already present in Compiz > Fusion in one way or an other, however, gnome-mag, unlike Compiz > Fusion, has had a significant amount of input from visually impaired > users to get where it is today. Mimicking the features of gnome-mag in > Compiz Fusion should not be tremendous amount of work; it is mostly in > the glue, with some exceptions like split-screen magnification and > cross hair functions. > > 5. > As simple as it sounds. > > Concerns, limitations > > A very common concern is the hardware requirement involved when > dealing with Compiz. Compiz currently requires composite, but more > importantly, OpenGL to work. OpenGL in turn requires moderately recent > hardware, which does pose a problem. However, this project would not > make gnome-mag unusable, it would simply add featur
Re: Sending a hide() signal to a given widget ?
2008/5/14 Yann DIRSON <[EMAIL PROTECTED]>: > I have played with dogtail, and could browse the accessible object, and > sent a couple of click(), but hide() does not seem to be accessible from > there. > Am I just looking for something that does not exist ? Probably ;-) It's not part of the AT-SPI API though Dogtain may add other facilities for interactive use. AT-SPI is designed to allow ATs to monitor application GUIs and so provides interfaces that allow you to inspect accessible objects, monitor accessible events and perform a few limited application 'actions' that have been specifically exposed through it (like click this button). General GUI operations are performed by the application using other APIs, in this case GTK. -- Steve Lee -- Open Source Assistive Technology Software web: fullmeasure.co.uk blog: eduspaces.net/stevelee/weblog ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: This Monday's 13:30UTC IRC meeting: special guests from RedHat :-)
Thanks Will, that is very encouraging. A fully accessible login experience in all the scenarios that have been identified will be a real plus for Linux + GNOME. -- Steve Lee -- Open Source Assistive Technology Software web: fullmeasure.co.uk blog: eduspaces.net/stevelee/weblog 2008/5/15 Willie Walker <[EMAIL PROTECTED]>: > Hi All: > > I spent some time down at RedHat today talking with Jon McCann, Matthias > Clasen, Ray Strode, and David Zeuthen about their proposal for revamping > gdm. Included in this is an overall approach to making it easier for > people to discover and use the accessibility features of GNOME, both > from the gdm login screen and your desktop session. > > I think what they've come up with is a really big step in the right > direction, and I've asked them to come to our irc.gnome.org/#a11y > meeting this Monday at the usual 13:30UTC time (9:30AM EDT) to discuss > the proposal. There are still some details to be worked out, so your > feedback is going to be important. > > Jon and company will be working up some information to send out prior to > the meeting, but I just wanted to take the time to grease the skids a > little bit --- I think it's fantastic that mainstream developers are > taking a strong interest in accessibility and are doing so proactively. > They are also approaching the problem in a way that makes me happy, > which is to include end users very early in the process. > > So, expect more info on the proposal to come to this list soon and > please set aside some time to participate in the irc.gnome.org/#a11y > meeting Monday at 13:30UTC. > > Cool stuff, > > 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: This Monday's 13:30UTC IRC meeting: special guests from RedHat :-)
In order to help me organise my thoughts on this I did a brief analysis of my understanding of the current state of alt input options. I'm posting it here in case anyone else finds it useful as well. http://eduspaces.net/stevelee/weblog/348733.html Steve Lee On 15/05/2008, Willie Walker <[EMAIL PROTECTED]> wrote: > Hi All: > > I spent some time down at RedHat today talking with Jon McCann, Matthias > Clasen, Ray Strode, and David Zeuthen about their proposal for revamping > gdm. Included in this is an overall approach to making it easier for > people to discover and use the accessibility features of GNOME, both > from the gdm login screen and your desktop session. > > I think what they've come up with is a really big step in the right > direction, and I've asked them to come to our irc.gnome.org/#a11y > meeting this Monday at the usual 13:30UTC time (9:30AM EDT) to discuss > the proposal. There are still some details to be worked out, so your > feedback is going to be important. > > Jon and company will be working up some information to send out prior to > the meeting, but I just wanted to take the time to grease the skids a > little bit --- I think it's fantastic that mainstream developers are > taking a strong interest in accessibility and are doing so proactively. > They are also approaching the problem in a way that makes me happy, > which is to include end users very early in the process. > > So, expect more info on the proposal to come to this list soon and > please set aside some time to participate in the irc.gnome.org/#a11y > meeting Monday at 13:30UTC. > > Cool stuff, > > Will > ___ > gnome-accessibility-list mailing list > gnome-accessibility-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > -- Steve Lee -- Open Source Assistive Technology Software web: fullmeasure.co.uk blog: eduspaces.net/stevelee/weblog ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: ASUS Eee PC
2008/6/30 Willem van der Walt <[EMAIL PROTECTED]>: > I would say the best > would be to replace the Zandros system with Ubuntu or one of the other > Linuxes where we know the a11y setups. There is a lot of info on the > wikki. I do know one of the Orca team who relies on Orca was running Ubuntu on his eeePC at CSUN last year when I spoke to him. You could ping them on IRC to see how it has gone. I understand some of the hardware requires non-free drivers, which is a bizare choice for a Linux device. -- Steve Lee -- Open Source Assistive Technology Software web: fullmeasure.co.uk blog: eduspaces.net/stevelee/weblog ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GOK module maintainership
Fantastic news and a big cheer for Gerd Steve 2008/7/21 Francesco Fumanti <[EMAIL PROTECTED]>: > Hello, > > Gerd Kohlberger has already done a marvelous job by developing mousetweaks. > Having his qualities now also devoted to GOK is great news for the GOK > community. > > A big applause to Gerd for accepting this difficult task. > > Cheers > > Francesco > > David Bolter wrote: >> >> Gerd Kohlberger has accepted the honour and responsibility of helping >> maintain GOK, the GNOME suite of on-screen keyboards that, among other >> things, provides access to the entire GNOME desktop via a single switch. >> >> Gerd has already proven himself in the GOK codebase, is a skillful and >> thoughtful developer, and I think is the right person to help meet the >> challenges of maintaining a venerable C program beyond its 7th year. I'm >> hugely thrilled to have his help! >> >> With the help of others that have emerged in the GOK community recently, >> these are happy days for GOK. A huge shout out to the helpful people who >> meet regularly in #a11y. THANKS! >> >> cheers, >> David Bolter >> ___ >> 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 > -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Mouse scroll wheel/button and hand dexterity
2008/7/28 Rick Berger <[EMAIL PROTECTED]>: > Are there any utilities out there that let you control whether the > scroll wheel is going just act as a scroll wheel or just as a middle > mouse button? My dexterity is such that there are times I'm scroll > through a page in Firefox and find I'm way off in web space somewhere > else because I've accidental click the wheel. Or likewise in most > application I can't click on something because I can't hold the scroll > wheel still and click it at the same time. A utility that lets you > toggle from the keyboard the meaning of the scroll wheel would great. hmm, the general mouse settings do indeed seem to be missing any options for middle wheel and button. I also seem to be a heavy scroller as i often get an 'invalid URL' error when I'm scrolling with the wheel in FF. So I just looked in Firefox's about:config and setting middlemouse.contentLoadURL to false does the trick for me. There's also a middlemouse.openNewWindow but I'm not sure when that comes into effect. -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Mouse scroll wheel/button and hand dexterity
2008/7/30 Janina Sajka <[EMAIL PROTECTED]>: > We probably need to do better integrating the various customizations > available. We also need to expand our existing specs where functionality > is missing. > > The Open A11y group has finished a Keyboard I/O spec which goes only so > far as what is in Xkb. Perhaps this is one use case for a future rev of > the spec. I agree that this should be addressed in the interests of filling one of the gaps current provision and rounding out support. However this is largely an issue with *mouse* use so would that spec make a good home without a rename? Steve ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GOPA reviews at upcoming #a11y meetings
excellent idea - i'll do my best to attend. Steve > Willie Walker wrote: >> We have three GOPA (GNOME Outreach Program: Accessibility) tasks in full >> swing right now: Kristian Lyngstøl doing magnification, Flavio Peroco >> Premoli doing MouseTrap, and Vincent Alexander doing documentation. >> >> I've contacted each of them to see if they can present their work in >> future #a11y meetings on irc.gnome.org. >> >> Vincent Alexander will be the first to go, and will present his progress >> on http://www.gnome.org/projects/outreach/a11y/tasks/documentation/. >> Please come to this coming Monday's meeting at 13:30 UTC. If you want >> to prep ahead of time, please take a look at his current work in >> progress: >> >> http://snoringbeagle.net/gag.html >> http://snoringbeagle.net/dtg.html >> >> 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 > -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Will not be present at next week's meeting.
me neither - covering the end of school holidays. Steve 2008/8/30 Francesco Fumanti <[EMAIL PROTECTED]>: > Hello, > > As I have another appointment during the next meeting time, I will not make > it either. > > Cheers > > Francesco > > Willie Walker wrote: >> >> Hey All: >> >> Monday is a national holiday here in the US as well. So, I won't be >> there, either. Feel free to meet, though! >> >> Will >> >> Luke Yelavich wrote: >>> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> Hi folks, >>> Just letting you know that I will not be at next week's meeting. I am >>> taking a week off from work, and would like to not have to stay up late for >>> work related activities when I am on a break. >>> >>> Thanks, and see you Monday week. >>> >>> Luke >>> -BEGIN PGP SIGNATURE- >>> Version: GnuPG v1.4.6 (GNU/Linux) >>> >>> iD8DBQFIt+nBjVefwtBjIM4RAkCuAKDyLlH+sDOIIx3UtO2sabuuKkevAACdH7es >>> cebCpaglgdNIeYmeR32Dwmc= >>> =3bg+ >>> -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 > -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Help!
Su, it's not complete but there' some listed at the end of :http://live.gnome.org/Accessibility/PythonPoweredAccessibility and there's a list on www.oatsoft.org - search for 'activity' (sorry it's down at the moment) You should add MouseTweaks and Mouse Trap Steve 2008/9/1 Su <[EMAIL PROTECTED]>: > Hi people, > > First, sorry about my english, it´s not so good! > > I am doing a job for the college about open source software created to help > disable people > Called accessibility softwares. > > If you can, > I´d like to know the softwares that you know > I need to find this softwares, test it and detail all!! > > Thank for help! > > Aprendiz! > > > > ___ > gnome-accessibility-list mailing list > gnome-accessibility-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > > -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Help!
2008/9/1 Steve Lee <[EMAIL PROTECTED]>: > and there's a list on www.oatsoft.org - search for 'activity' (sorry > it's down at the moment) This is the page http://www.oatsoft.org/Forge/articles/accessibility-activities/ Steve -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Text reader
You could loo at Project Possibilities PowerReader project http://projectpossibility.org/viewProject.php?id=1 It's Java + Free-TTS but I don't know the state on *nix. Perhaps GNOME could pick it up? Steve 2008/9/3 Willie Walker <[EMAIL PROTECTED]>: > Hi Jonh: > > Most speech synthesizers come with a standalone application that will take a > text file as input. eSpeak, for example, provides the 'espeak' application > that takes a '-f' parameter that lets you specify a file. > > I suspect, however, that this is pretty insufficient for most heavy speech > users. Is there something else that you have in mind? > > Will > > Jonh Wendell wrote: >> >> On Qua, 2008-09-03 at 00:15 +0100, Calum Benson wrote: >>> >>> On 2 Sep 2008, at 18:51, Jonh Wendell wrote: >>> >>>> Hi, folks. >>>> >>>> Is there any text reader integrated with GNOME? >>> >>> Yes: Orca, which has been part of GNOME since 2.16, when it replaced >>> gnopernicus. >>> >>> <http://live.gnome.org/Orca> >> >> Actually I mean a text reader in the sense that you could choose a text >> file or just type some sentence and let the computer read it for you. >> Orca is a screen reader. >> >> Cheers, > > ___ > gnome-accessibility-list mailing list > gnome-accessibility-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Text reader
One thing people want with reading support is text highlighting as it is read which requires integration with the speech engine to work really well. Power Reader seems to have many of the features people want for this area AFAIK. Steve 2008/9/3 Tomas Cerha <[EMAIL PROTECTED]>: > Jonh Wendell wrote: >> Actually I mean a text reader in the sense that you could choose a text >> file or just type some sentence and let the computer read it for you. >> Orca is a screen reader. > > Hello John, > > What else would you expect from such a program, than what you get when > you open a text file in a text editor (such as Gedit) and read it with Orca? > > Best regards, Tomas > ___ > gnome-accessibility-list mailing list > gnome-accessibility-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Accessibility project ideas
Project:Possibility are looking for accessibility project ideas to let students loose on. http://eduspaces.net/stevelee/weblog/448589.html -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Mouse/Numpad and Topkeys app
Hi Dan, you know I'm not sure from the description why that is different to MouseKeys that is built into Windows or the X extension? Steve 2008/10/7 Daniel Alexandre <[EMAIL PROTECTED]>: > > Actually, > > Was looking to implement something a bit more sophisticate, like using the > keys Q A O P and stuff as does TopKeys for windows: > > http://www.download.com/TopKeys/3000-2317_4-10868751.html?tag=mncol&cdlPid=10868752 > > Cheers, > Dan > > > > ___ > gnome-accessibility-list mailing list > gnome-accessibility-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > > -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
fwd: Eye Gaze Study Day - 5 November 2008, London
For those in the UK there's a chance to explore the state of the art in the proprietary gaze world and someone could make sure Open Source gets represented. Kath and Mick gave the presentation at RAatE last year that got me fired up about what we could offer, something that is getting closer with MouseTrap... http://eduspaces.net/stevelee/weblog/225753.html. -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk Eye Gaze Study Day - 5 November 2008, London Eye Gaze has long been considered to offer vast potential as an access method for communication; in the last few years it has been emerging as a means of accessing AAC and other technology. This AAC study day has been developed by Communication Matters in response to the large amount of recent interest in this area. The study day is an essential guide for any professional working in AAC or Assistive Technology with an interest in how eye gaze technology can be used to access communication and technology. The study day will explore this cutting edge topic, including the foundations of eye pointing for communication, an overview of the potential of eye control of technology by a leading expert, a chance to try the latest developments from suppliers, and an opportunity to hear about and share experiences in the use of eye gaze for interaction. The programme will include the following sessions: Eye Pointing for Communication - Katharine Buckley (ACE Centre) & Catherine Harris (Gloucestershire Adult SLT Services) Gaze Controlled Technology Tutorials - Mick Donegan (ACE Centre) Eye Gaze in Practice - Hannah Curry (PCAS, Bristol) & Liza Clements (parent) Eye Gaze Evaluation and Provision - Plenary Discussion, facilitated by Katie Price (Wolfson Neurodisability Unit) There will also be an exhibition of the leading eye-gaze technology available today. It is anticipated that this day will be very popular, so be sure to book early to avoid disappointment. Download booking form and more information about the study day Please do not hesitate to contact me if you have any questions. Regards Patrick Poon Communication Matters Tel & Fax: 0845 456 8211 Email: [EMAIL PROTECTED] Website: www.communicationmatters.org.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [g-a-devel] Announcing AEGIS - a €12. 6m investment in open source accessibility
Peter this is totally fantastic and even better news than I had hoped for. Thank you for all your hard work making this possible. Many, many people are going to benefit from the improved open accessibility. -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk 2008/10/17 Peter Korn <[EMAIL PROTECTED]>: > I am *very* pleased to share with you news about the AEGIS project, a €12.6m > investment in accessibility, with the vast majority of it focused on open > source solutions. > > Rather than repeat here all that I have written about AEGIS already, I will > instead invite you to read about it in my blog: http://blogs.sun.com/korn/ > or check out the AEGIS website at: http://www.aegis-project.eu/ > > I have worked in the field of accessibility for nearly 17 years, and on open > source accessibility almost a dozen of those years. In that time, open > source accessibility has become a deep and abiding passion. > I'm very proud that the techniques we have pioneered in the open source > community have since been adopted by Apple with the Macintosh & VoiceOver, > and are being adopted by Microsoft with UI Automation. These same > techniques are enshrined in the report a 42 member committee delivered to > the U.S. Access Board earlier this year (and which at this very moment being > reviewed by them as they work on their refresh of the Section 508 > accessibility standard). And these techniques are at the core of the AEGIS > project. > > With AEGIS, over the next 3.5 years we will attempt to bring programmatic > accessibility more fully to the web, and to the mobile world. With AEGIS we > will also address a number of issues that still remain in accessibility on > the open desktop. And while we're at it, we will bring a bunch of new and > talented people into the open source accessibility community (you should > start seeing them showing up on our mailing lists and wikis in the coming > months). We will also fund a number of the experts who have already made > tremendous open source accessibility contributions - to enable to them to > continue and to do even more. I'm sure they will shortly make their voices > heard on these lists and in the blogosphere. And we will explicitly fund a > number of European disability organizations. These organizations and many > dozens of their members will be providing their expert input on our work, > and thoughtfully evaluating our prototypes, and perhaps adopting the > solutions we come up with because they do a great job of meeting their > needs. > > Oh, and we'll also write a bunch of open source accessibility code. > > > This Sunday the 19th of October marks the 8th anniversary of the GNOME > Accessibility Project. AEGIS helps bring a fantastic 8th year to a close, > and also serves to inaugurate the next 3.5 years! > > > Regards, > > Peter Korn > Accessibility Architect & Principal Engineer, > Sun Microsystems, Inc. > ___ > Gnome-accessibility-devel mailing list > [EMAIL PROTECTED] > 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: screencasts - license
Thanks Brian, I see a lot of the CC BY-SA and it seems the closest to Open Source copyleft for non-software. BY looks closest to a liberal, BSD style licence. PD means you effectively waive all copyright and any one can do anything with and I would usually prefer something that keeps works in the public 'commons' . However as the important thing is to spread the word PD is probably OK. -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk 2008/10/18 Brian Cameron <[EMAIL PROTECTED]>: > > Willie: > >> I'm assuming you're talking about >> http://master.gnome.org/~wwalker/demos. I actually didn't think about >> licensing, though they should be Copyright 2008 Sun Microsystems, Inc. >> I'm not sure what the license-du-jour is these days. I'll ask around. > > I'd recommend this license: > > Public Domain Dedication [1] > > Or, if you want to be attributed for the work, you could use this: > > Creative Commons Attribution-Share Alike 3.0 Unported License. [2] > > Brian > > > [1] > http://creativecommons.org/licenses/publicdomain/ > > [2] > http://creativecommons.org/license/results-one?q_1=2&q_1=1&field_commercial=yes&field_derivatives=sa&field_jurisdiction=&field_format=MovingImage&field_worktitle=A11y+Videos&field_attribute_to_name=&field_attribute_to_url=&field_sourceurl=&field_morepermissionsurl=&lang=en_US&language=en_US&n_questions=3 > > >> On Thu, 2008-10-16 at 14:24 -0300, Fernando wrote: >>> >>> Hi Will, >>> >>> Can you tell me under what license are the screencasts made available? >>> >>> Thanks, >>> >>> Fernando >>> ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [GOK] Why ui grabbing in direct selection mode of gok?
I'd also add that GOKs OSK to anextent provides an abstraction and simplification of the UI and is very consistent. Such limited interaction may be of benefit to some people mentally as well as physically Steve 2008/10/19 David Bolter <[EMAIL PROTECTED]>: > Hi Francesco, > > Thanks for raising this. I think it is important to consider the > difference between interacting with GOK keys, and interacting directly > with the interface. Here's some reasons I can see for leaving ui > grabbing enabled for the direct selection access method. > > * GOK keys can be bigger than the widgets (or actions) they proxy (== > larger target area). > * If the user is interacting with GOK anyways, perhaps for text input... > it might be an advantage just to interact with GUI within GOK, instead > of moving the pointer a greater distance to perform a UI interaction > that may even be less pleasant than GOK's ui grab. > * GOK can provide key averaging and other smarts to help users who might > have tremors but who might want to use direct selection. > * Etc. > > Thoughts? > > cheers, > David > > > > Francesco Fumanti wrote: >> Hello, >> >> >> I am wondering the following about the direct selection mode of gok: >> >> Based on the assumption that the direct selection mode is intended for >> users that are able to control the pointer, what is the sense of >> making gok grab the user interface in this mode? >> >> In fact, if the user can control the pointer, he can interact directly >> with the desktop and does not need a duplication of the active >> interface elements in gok. >> >> Consequently, unless I am missing something, I would suggest to >> disable the ui grabbing feature in direct selection mode. >> >> >> Many thanks in advance for any comment. >> >> >> Cheers >> >> Francesco >> >> ___ >> gnome-accessibility-list mailing list >> gnome-accessibility-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > > ___ > gok-list mailing list > [EMAIL PROTECTED] > http://mail.gnome.org/mailman/listinfo/gok-list > -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Ang. Re: [GOK] Why ui grabbing in direct selection mode of gok?
2008/10/21 Mats Lundälv <[EMAIL PROTECTED]>: > Perhaps it is > no significant problem to have at-spi available/activated then also, but > then why isn't it by default? Security issue I suppose? It's historical, when it was introduced the larger GNOME community were concerned that it would hit performance and introduced bugs to the desktop. This was made worse by the dependence on Bonobo, which is is being phased out. However AT-SPI (and a11y) have now gained such acceptance that I think the time is ripe to make it on by default and optionally turned off. The AT-SPI on D-Bus work makes this much more acceptable, as does the increased use of UI testing via AT-SPI, where it is critical to be testing the 'live' system not something with an option that is off for most users. Steve -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME Accessibility on by default, and Firefox
2008/10/22 Aaron Leventhal <[EMAIL PROTECTED]>: > There is no need for an "enable > a11y" flag in the OS. Just the fact that something asks us for an accessible > object wakes us up. > We really need lazy instantiation like that under Gnome. If the AT is loaded > and starts asking us for objects, then we can wake up. Ding! Yes, of course. The user should NOT have to state they want AT support for accessibility turned on when the fact that they are using an AT that want's it is enough. Ditto any desktop features that rely on AT-SPI. So we just need to get rid of the need to logout/in after turning it on/off and add a protocol for AT's to request it and for it to to be enabled turn when an AT fires up. Does the D-BUS port give us this capability? We can perhaps defines some system messages for a11y? -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME Accessibility on by default, and Firefox
2008/10/27 Li Yuan <[EMAIL PROTECTED]>: > A way to do this in my mind is to create functions in atkmisc, to tell gail > and other accessibility implementations to send out signal or not. If an AT > is started, at-spi-registryd will call the function to tell applications > "now it is time to send out the signals". But this require modification in > all accessibility implementations (Firefix, OpenOffice, Gtk+ applications, > Java applications). What if that gets pushed down the stack a bit so the decision to actually send on the wire is made even though ATK/FFx etc still call and look for events? Would the over head of the function calls that test and return with no a11y be too much to bear? It would be localosed in one place and all appswould behave the same. -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Updating the brainstorming list
Looks pretty comprehensive Will, I cant think of any thing right now. Steve 2008/11/5 Willie Walker <[EMAIL PROTECTED]>: > Hi All: > > As we discussed in this week's IRC meeting, we'd take a stab at updating the > brainstorming list. I took a first pass at it: > > http://live.gnome.org/Accessibility/GetInvolved > > For now, the more important thing to me is getting things up to date and > making sure the list is more complete. The ordering of things is less > important to me right now. Please take a look at the page and feel free to > edit it. > > Thanks! > > Will > > ___ > gnome-accessibility-list mailing list > gnome-accessibility-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [Fwd: UK Charity to distribute eee PCs with Open a11y installed]
Out of interest is ORCA known to work with either eeebuntu or ubuntu-eee? I just pointed them out to David Banes at AbilityNet. The netbook remix probably doesn't have AT-SPI enabled Steve 2008/11/7 Willie Walker <[EMAIL PROTECTED]>: > FYI...cool. One of the configurations is Ubuntu+Orca. > > Will > > http://eduspaces.net/stevelee/weblog/498549.html > > -- > Steve Lee > Open Source Assistive Technology Software and Accessibility > fullmeasure.co.uk > ___ > dev-accessibility mailing list > [EMAIL PROTECTED] > https://lists.mozilla.org/listinfo/dev-accessibility > > ___ > gnome-accessibility-list mailing list > gnome-accessibility-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > > -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Summer Interns for GNOME Accessibility
All I can add is 'wow'. Thanks Stormy. Steve 2009/1/6 Willie Walker : > Stormy: > > This is AWESOME! Many thanks for your promotion of accessibility and for > getting GNOME some resources. > > We should talk about this in the weekly #a11y meetings on irc.gnome.org, but > there's a whole bunch of ideas at > http://live.gnome.org/Accessibility/GetInvolved. > > Some of the things on the top of my list are Evince accessibility and WebKit > accessibility. Both require a bit of in-depth knowledge, though, and would > require some strong mentoring. > > Another area, which is pretty cool and could use some help, is MouseTrap. > It has a good start, and I'm sure Flavio would welcome help. > > Other areas include improving the out-of-the-box experience of GOK, helping > "fix" speech, testing, etc. > > In any case, the above are just quick thoughts off the top of my head and > are not meant to detract from anything I neglected to mention. > > Do you have any deadlines or dates where we'd need to get our act together? > > Will > > Stormy Peters wrote: >> >> GNOME Accessibility folks, >> >> We have the opportunity to have two summer interns working on GNOME >> Accessibility issues during the summer of 2009. We just need to come up with >> projects and mentors! >> >> Background: >> >> At the Grace Hopper conference this year I went to a panel about the >> Humanitarian FOSS Project, www.hfoss.org <http://www.hfoss.org/>. As a >> result I met Trishan de Lanerolle, the project director, as well as >> Professor Ralph Morelli from Trinity College. >> >> The Humanitarian FOSS project is bringing students into software >> development by appealing to them with open source humanitarian projects. >> They've had a lot of success over the past two years. They bring all the >> students together on a university campus, house them, pay them and give them >> open source software projects to work on. The students have access to each >> other, professors and remote mentors from the project. Past projects have >> included working on disaster recovery software, volunteer scheduling >> software and medical imaging software. >> >> Another benefit from my perspective is that the humanitarian aspect brings >> in people that might not traditionally have been drawn to open source. (They >> were at the Grace Hopper conference because last summer's group included >> quite a few women.) >> >> Their project is 100% funded by an NFS grant right now although they'd >> like to have companies fund additional interns in the future. >> >> What is being offered to us: >> >>* Two interns during the summer of 2009, housed at Trinity, paid by >> Trinity, with professors to help them. >> >> What we would need to come up with: >> >>* Projects: >> o projects that a novice coder could get started on >> o humanitarian focus (accessibility is good) >> o something they can make good progress and complete in a summer >>* Mentors >> o mentoring is done via email and skype >> >> Does this sound like a good idea? Something you are interested in? >> Thoughts? >> >> Stormy >> >> >> -------- >> >> ___ >> 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 > -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Time-Shift Meeting Proposal
> >From my experience in other channels, having time-shifted meetings has > been beneficial to ensuring a more global presence on the team. With a > time-shift meeting, a specific monthly interval meeting occurs at a > different time to accommodate that region. Thanks good idea. Every other week would be gr8, but every month ok too Times well 18:00 to 21:00 (end) would be best for me as I need my beauty sleep. Steve Lee ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Instantiating Firefox A11y on GNOME
2009/1/16 David Bolter : I personally am using the workaround Steve gave us here: > https://bugzilla.mozilla.org/show_bug.cgi?id=460926#c4 on my install of > Intrepid (Ubuntu). Actually that was from Ginn. -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: AT-SPI: Associating X11 Window with Accessible object?
2009/1/29 Andrew Shu : > I am working on a program that needs to know when one window is obscuring > another. I know I can use either Xlib XQueryTree() or something in libwnck > to find the window stack ordering, since ATK doesn't seem to have info about > whether a window is being blocked. > > Also I know that this way of determining if they are being obscured is not > completely foolproof even if I compare the component bounds. But that's fine > for what I'm doing. > > My issue then, is how to associate the Xwin Window id with some Accessible > object. Is there a mapping to go between them easily? I couldn't find one, > so I may resort to something like matching up the window titles & > coordinates. > > Any suggestions would be very appreciated. Andrew This may not tell you any more than you already know but getAccessibleAtPoint and related functions may help Take a look at Accerciser's _inspectUnderMouse and _getChildAccAtCoords http://www.koders.com/python/fid8F2A47CCB9FACC23867491E2BC6729B8EFCDCB2F.aspx?s=_inspectUnderMouse#L25 There was a thread about these issues recently on the mozilla accessibility mail list, dev-accessibil...@lists.mozilla.org, -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Ideas for upcoming Bolzano GTK+ hackfest
2009/2/10 Behdad Esfahbod : > Go ahead and prepare then! Great work everyone. Keeping a11y in mind at all stages will help make GTK+ even better for everyone. @Flavio - superpowers AND a VIP - yay. Steve Lee ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Project:Possibility SS12 at UCLA
http://dailybruin.ucla.edu/news/2009/feb/03/closing-tech-gaps-open-source-fixes/ (cross posted) -- Steve Lee Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: HFOSS: VizAudio & DOTS
2009/2/24 Bryen : > Reach: > DOTS reaches the market where braille printers (embossers) exist. How > large that market is, is not clear at this time. VizAudio can reach a > broader market without need for additional hardware and is beneficial > not only for Deaf users, but also for anyone who wishes visual events. > > Blind market gets a lot of attention in Linux. Deaf market has well... > almost zilch. As Willie stated, the Deaf community has been left behind > for too long. (Bless his heart.) I'm all for making the reach more rounded - reach more people * VixAudio appears to have a clearer 'curbcut' effect so make GNOME better for all and may raise perception of the value of a11y work in wider community. * Notify enhancements should attract more mainstream folks who are willing to contribute/mentor so would be a better FOSS community experience for interns. > After some thought, my feeling is this: There > is interesting potential for notify-osd, but at this point in time, it > may be a long time before it becomes a fully upstreamed implementation > and I would rather we focus on existing modules that all distros can > immediately take advantage of and participate in. +1 Steve Lee ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: HFOSS: VizAudio & DOTS
2009/2/27 Bryen : > So, if there's no further discussion, I'm putting my support to DOTS for > HFOSS inclusion. I think it is a great project and covers a specific > need that helps us compete better with other proprietary solutions. Bryen thanks for being a "decent chap" about this. It's great we have 2 projects now and a good one for next steps. -- Steve Lee OSS Watch Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: screen reader
2009/4/2 Willie Walker : > So, you might be running into #2 and the situation where accessibility has > not been enabled. In this case, Orca is asking you things such as which > speech synthesizer you want to use, if you want key echo, etc. If you > answer the questions, then Orca will have the information it needs. You > then need to logout and log back in for accessibility to be enabled and Orca > should function normally. Would it be worth adding a one line text prompt that explains that at the start of the cmd line prompts? Assuming you know the reason for asking them is as GNOME a11y is off. Steve Lee ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: HFOSS Projects: VizAudio, MouseTrap, Dots
Hi Ted and welcome, it's fantastic that you HFOSS folks are going to be involved in pushing the open a11y boundaries. P.S if anyone is going to be at the AEGIS workshop on Friday - see you there. -- Steve Lee http://fullmeasure.co.uk Open Accessibility 2009/5/29 Willie Walker : > Welcome Ted! > > It was great meeting you all yesterday. You're smart folks and there's no > doubt you're going to get some good work done. > > For everyone else on the gnome-accessibility-list --- please welcome the > HFOSS folks. Let's do our best to help them enter the GNOME accessibility > community and set them up for success. > > I'm excited, :-) > > Will > > Ted Nichols wrote: >> >> Hi everyone, >> >> Writing in to say that we are ready to work on these proposals! We have >> eight full weeks left in the program and need to decide what tasks can be >> accomplished for each project in that time. We'd like to work on as much as >> possible, but we don't want to promise more than we can deliver. Will Walker >> came and gave a talk about GNOME a11y yesterday, which was great. We're >> sending e-mails to the project mentors individually, but we wanted to say >> hello! >> >> --Ted Nichols, HFOSS Intern >> >> >> >> >> ___ >> 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: Accessibility Team Updates for Q2 (March-June) of 2009.
Hey That's amazing, though I don't see anything there for Orca. BTW I read the GNOME report and was delighted by the high profile of the accessibility work and that Stormy's very first sentence mentioned it. Awesome. Steve Lee 2009/7/22 Willie Walker : > Hi All: > > Stormy would like to start publishing GNOME Foundation Quarterly reports, > which I think is a great idea. > > To start, she's asking for Q2 (March-June 2009) updates. I need your help > accurately representing the progress made in Q2. Here's what I have so far: > > * Had the AT-SPI/D-Bus summit > * Saw great progress on the Java ATK Wrapper > * Saw great progress on Mono a11y for GNOME > * Began the WebKit a11y work > * Started the HFOSS program for MouseTrap and VizAudio > * Started the Speech Dispatcher work > * Addressed a number of GNOME Goals regarding migrating > from a number of "this thing" to "that thing" items. > > This is pretty awesome stuff. There were also a number of milestones in > individual projects, which I don't have the complete details on. Please > send me items I have missed so we can have a good update for Q2. > > 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: Close buttons in dialogs
2009/7/23 Eitan Isaacson : > Close buttons are good for > screen reader users because it puts the dialog dismissal as part of the > focus order (and work order), and thus discoverable. > Currently a keyboard user could get by without knowing about alt+f4 at all, > I could see it being frustrating to new users if there is no way of > dismissing a modal dialog without learning alt+f4. and it's discoverable visually for mouse users and for those who don't know of the window managers menu. So I agree it's good for very new users, but as long as the user knows they're in a modal dialog I'd think Alt F4 would be consistent enough to be knowable. Now the strange this is I use ESC to close dialogs, thinking ALT-F4 was 'quit application' only. From my windows dev days ESC was the same as the cancel/close button on dialogs. That makes me think that there is a risk that if the user is in any doubt about whether they are in an dialog or not using Alt-F4 is dangerous as you might close the application. That uncertainty is enough to make me say the button should be left. Steve ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Close buttons in dialogs
> this not because Ms Windows applications uses it all the time, but because > there is one rule of interface design saying that it may be possible for us > to undo any changes we have made. Clearly, most of gnome applications don't > obey this rule. Why does it happen? Indeed I seem to recall that (on WIndows) the button text should change from close to cancel if it becomes possible to undo something. Some dialogs seem to perform actions when interacting with the controls that take immediate effect and can't be undone. And should an Apply button be undo-able by cancel? Ho hum. Such rules are hard to enforce when they are up to individual developers' diligence. Steve Lee ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Vbf:Ang: [GOK] plan for GNOME 3.0 - please comment
You make some excellent points Mats and I agree about speed being an important priority. It's amazing how fast some users can scan. 2009/10/12 Mats Lundälv : > - the selection button grid I envisage similar to a table component (in an > office application) – possibly built on some existing one – where a regular > grid with a certain number of rows and columns is set up – then the width of > columns and hight of rows may be adjusted, cells may be joined, grouping > options may be added etc. – with a limited set of built-in focus navigation > schemes (that may later be expanded). (I remember a button grid component > like that in the good old NextStep development environment – is there > something like that floating around in the Python universe ;-) Well Maavis [1] ticks quite a few of your boxes but it's XUL + javascript, with a Python server for some functionality. It is deployed as a Firefox extension but could be ported to XUL Runner. The vision is that Maavis will be a platform for creating new and innovative styles of interaction by those with web-style technical skills and yet provides very simple configuration for non technical facilitators. An intermediary level of skill could easily be added for using a GUI to configure cell layouts etc. So far we have a simple touch UI and have just added switch support for research in schools. I took the design approach that selection sets are created in XUL (which is similar to HTML) + CSS + javascript. The idea being to use a familiar declarative web style that gives great flexibility and has low barrier to entry as far as technical skills are concern. However this is not suitable for non technical facilitators who use a simple file copying paradigm to setup resources (plus some text files that will eventually become a GUI). The platform is rich enough to allow the development of GUIs for editing selection sets, indeed work has started in the form of a 'settings' UI . As experience has grown it's clear that much can be abstracted into standard features available from the higher levels. This is done by adding new XUL elements and attributes as well as providing a small API for using from javascript. The switch access we have added for maa...@school was designed to be expandable from the simple linear scanning provided and to allow spatial modes as well. This is yet to be proven though. Technically it is a simple event driven state machine with the specifics of navigation and selection/focus being provided by the layout code. We've started with 1/2 switch auto/user scan with USB devices as suggested by Simon Judge. While Maavis has been developed on Windows XUL is naturally cross platform and the platform specific areas have been localised. It uses Outfox which is a local Python server, currently for voip integration and switch input (via pygame). There is obviously scope for moving functionality across the client/server divide but I would expect UI and network services would stay on XUL client side as they are it's strengths. I'd be very happy to discuss how Maavis could be used as we are keen to have engaged users and contributors . 1: https://www.assembla.com/wiki/show/maavis Steve ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: CSUN Hackfest and Exhibition: Call for Participation
Eitan That is excellent news and I now have even more reason to pop over for CSUN (apart from Stevie Wonder spotting and looking at your great photos of service animals). Will you be next to Mozilla's booth? I'm a passing this on to the Project:Possibility board as they are local and there should be some great synergy. BTW Project:Possibility are running a SS12 event at CSUN. Regards SteveLee 2009/10/14 Eitan Isaacson : > Hello fellow GNOME a11y folks. > > On March 22-27 2010, GNOME will have a booth presence at the CSUN conference > in San Diego. CSUN is one of the largest and most important gatherings on > the topic of technology and persons with disabilities. This is going to be a > great opportunity to bring the gospel of Free Software to a space and > industry that is largely proprietary, and to a user base with special needs > that sometimes could only be addressed with Open Source software. This is > going to be über exciting! > > Along with the booth and a presentation or two, we will also be hosting a > GNOME assistive technology hackfest. The reasoning for this being the fact > that this is an assistive technologies conference, so there really isn't a > better place to draw inspiration, both by seeing the "state of the art" > proprietary products first hand, and by talking with users who have needs > that we could answer. > > Are you a maintainer of one of GNOME's assistive technology modules? Are you > developing an on screen keyboard? An alternative means for text input? A > magnifier? Some trippy head-tracking app? Voice control? Switch access? > Something new and exciting for cognitive disabilities? Are you hacking on > new features for Orca? Are you working to provide users with disabilities > unfettered access to GNOME? > > If the answer to any of the above is 'yes', we hope you will consider > joining fellow GNOME a11y folks at CSUN this year to help promote GNOME and > to hack with fellow AT developers. > > We hope to have funding for this hackfest, but we don't yet really know what > that means. We know that we will have to be creative about it to pull it > off, so hopefully once you made up your mind to attend, you could help > figure out how to afford it, if your employer could pay, if you have student > discounts, etc. We will do our best to make it affordable to people who > should be there, but no promises. Hope to have specifics about that in the > future. > > Please reply to this mail, or contact me if you have interest in attending, > or any other questions, suggestions or concerns. > > Cheers, > Eitan. > > ___ > 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: Mon-Oct 19 Meeting for #a11y
2009/10/15 Eitan Isaacson : > I wold like to use the meeting to gauge preliminary interest for the a11y > hackfest, and get some feedback on how we could make it successful. Eitan, I had another OSS Watch meeting but read through the IRC notes. So Project:Possibility will be at CSUN, though the extent of involvement is not yet known. We had discussions with CSUN after they suggested P:P brought along students and mentors as they would like more student involvement. The 3 weekends before will be P:P hacking events (USC, UCLA, CSUN) so it's not clear if it will realistic to do much more than meet up and help out at the booth or hang out in the hacking room. It sounds like a good chance to forge links and introduce students to GNOME a11y. I'm hoping to come along this year. I'll keep everyone updated as plans develop. Steve ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
New GNOME / KDE online course
Does anyone have the bandwidth to ensure a11y is well represented in this great resource http://is.gd/4G0aU -- Steve Lee OSS Watch - supporting open source in education and research http://www.oss-watch.ac.uk ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Request for comment (accessibility team): release date for GNOME 3.0
2009/11/5 Willie Walker : > I think there's a few sides to this. And another is to expose CS students to the concepts so they take them forwards with them into industry experience. Steve ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Monday Meeting - 16 Nov 2009
2009/11/13 Bryen M Yunashko : > So I goofed and made it an hour later. You too busy playing with the latest open SUSE? > How's about a quick debate amongst us all and see what everyone prefers? > > Vote #1: 16:00 UTC +0 > Vote #3: Steve provides refreshments at either time meeting. nice cup of tea and biscuits anyone? Steve ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: A11y Holiday Party
Bryan, after you sold it so well it's a real shame to say I can't make it (again). We're running an OSS Watch workshop on Building an Engaged Community and I'm leading an activity at that time (it's not my 3rd strike yet, honest). So wishing everyone a merry Christmas and an a11y new year. PS I met Stormy Peters this week and even showed a few photos of a11y folks at the CSUN 08 Mozilla booth. It's excellent that she is fully behind the a11y work. Steve 2009/12/4 Bryen M Yunashko : > Okay, it won't really feel like a holiday party. We won't have > refreshments, no singing of Carols (or Barbaras or Janes either), and > certainly no lights hanging along the IRC Channel's walls and festooning > trees and menorahs. > > But we're still going to have an end of the year #a11y meeting on > Monday, December 7th at our usual time. Let's use this time to tackle > any immediate business we need to tend to, reflect on what has happened > for the past year and think of what we want to see happen for this > awesome A11y Team in 2010. This will be the last meeting of the year, > what with holidays coming up and everyone busy out shopping for holiday > gifts for me. > > So... See you all in GNOME's #a11y channel at 15:00 UTC And if you've > never come to our meetings before, come on down anyway. We'd love to > see you there! > > Bryen > > ___ > 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: Proposal: mouse-only Caribou for GNOME 2.30
2009/12/9 Willie Walker : > So that leaves GOK users who depend upon switch-based access. With XEvIE > having suffered a ill-fated death, poor GOK is being attacked on yet another > side. So, I think it may make sense to revisit switch-based access once > XInput2 is more prevalent. At that time, we may also investigate other new > ideas for switch-based access such as Nomon, Jambu, etc. Until that point, > we may need to recommend that existing switch-based users remain on GNOME > 2.28 -- I'm not sure if that's an acceptable thing, however, and will check. As most switches these days appear as USB HID devices, through the use of physical interfaces such as the JoyCable, it is possible to get switch input events using PyGame Joystick support (though you have to poll). So in Jambu the following is used from the main GTK pump http://www.oatsoft.org/svn/jambu/trunk/src/lib/jambu/Switch.py I'm not clear how this compares with the fully integrated X events approaches that Willie mentions. My view is the sooner we have a viable switch solution on GNOME the better in order to be able to attract the users. Steve Lee ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Ang. Re: Proposal: mouse-only Caribou for GNOME 2.30
2009/12/11 Mats Lundälv > > I strongly support you on these points Steve: > Go for USB game as the primary source of switch input - as it's a standard, > but clearly separated from the basic keyboard and mouse input - and good > interface products - like the JoyCable - are there on the market. Support > for the other interface alternatives may come later > And of course the general urge for switch input asap. > As an aside, there are advantages to having an alternative input stream. At the RAatE conference a guy from the RNIB showed how a DAISY reader could be controlled with a USB foot switch, allowing a tutorial on using Windows to be followed with keyboard access and a screen reader. This only worked as the reader responded to the switch input and Windows did not. Steve ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Ang. Re: Proposal: mouse-only Caribou for GNOME 2.30
2009/12/11 David Colven : > Sorry if I’m being dum – I am down with flu at the moment – but I don’t see > why a joystick switch inout should not do exactly what the daisy reader > wants. Window will not react to input from a USB fire button unless it’s > told to, will ot? Yes that is exactly correct. AFAIK the foot switch was a USB HID - ie same as joystick. So the point was that sometimes having events ignored by the OS can be useful. Windows doesn't treat joysticks as first class input devices that all programs must support (like mouse and keyboard). The same with default X. I'm not familiar enough with the X switch stuff that Willie mentioned, but get the impression switch events become first class events so applications including desktop may react. As I said it was an "aside". Steve ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Ang. Re: Proposal: mouse-only Caribou for GNOME 2.30
2009/12/11 David Colven : > I feel what we need - and is part of the ACE contribution to AEGIS - is a > central switch handler (control panel type thing) which reads switches and > that any scanning program can use. The control panel would deal with all the > methods and filtering and pass scan select (and more) to the scanning > programs. This would eliminate the need for multiple set-ups and a lot of > duplicate effort in reading switch inputs. +1 Just need flexible ways for apps to register for events. And is one better that other platforms. Steve ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: [Usability] Announce - GNOME 3 Usability Hackfest (London, Feb 22-26, 2010)
2009/12/16 Brian Cameron : > I would like to announce the GNOME 3 Usability Hackfest planned for > February 22-26, 2010 in London, England. > > This is an exciting opportunity for GNOME Usability to take a step > forward and this hackfest will provide the GNOME Usability team an > opportunity to focus, set goals, and accomplish work to prepare the > GNOME community for the GNOME 3.0 transition and the future. As already discussed with Brian Cameron and David Flanders, there is a great opportunity to hook up this event with the JISC Dev8D developer event that is happening in London at the same time. http://www.dev8d.org OSS Watch are very interested in forging links between open projects as part of our support services to UK HE projects. So we're looking for ideas for how to develop some positive synergy and how develop this into the perfect opportunity for UK HE developers to learn about, use and and hack on GNOME projects, and visa-versa. Below I've listed some ideas for collaboration that have already been proposed by Brian and David and I've added a couple more ideas. * Organize a day when the GNOME Usability Team or community meets at the Dev8D venue to give a talk or session or hang out for or hack. The 27th looks like being a good day to encourage people from the GNOME Usability hackfest to attend the Dev8D conference as it is the day after the GNOME event. * The GNOME Foundation could provide some compelling speakers, presenters, or discussion topics on GNOME Usability or free software GUI usability in general. * Dev8D attendees could provide an introduction to HE research specific projects * OSS Watch will be running a workshop before the events that will provide an opportunity for learning about Wookie, the W3C Widget server that is now in the Apache Incubator. This means there will be people hacking on Wookie and widgets at Dev8D. * Eye gaze control using cheap web cams is a hot accessibility topic so it would be good to see some joint hacking on GNOME Mouse Trap and University of Cambridge Inference group's opengazer project; http://bit.ly/6iZqbr and http://bit.ly/GL9tJ (thanks to @pepperbox for the idea). So who has more ideas? -- Steve Lee OSS Watch - supporting open source in education and research http://www.oss-watch.ac.uk 2009/12/16 Brian Cameron : > > I would like to announce the GNOME 3 Usability Hackfest planned for > February 22-26, 2010 in London, England. > > This is an exciting opportunity for GNOME Usability to take a step > forward and this hackfest will provide the GNOME Usability team an > opportunity to focus, set goals, and accomplish work to prepare the > GNOME community for the GNOME 3.0 transition and the future. > > Details, goals, and instructions can be found on the Usability Project > London 2010 Wiki here: > > http://live.gnome.org/UsabilityProject/London2010 > > If you plan on attending, please sign up in the Attendees section. > If you need assistance with travel costs, note the instructions > to follow the GNOME Travel Subsidy process on the Wiki page. > > Looking forward to seeing you in London! > > Brian > > ___ > Usability mailing list > usabil...@gnome.org > http://mail.gnome.org/mailman/listinfo/usability > ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Finding GNOME a11y tasks for Project:Possibility students to work on
Project:Possibility [1] run the SS12 [2] weekend hack events where around 60 CS students get to learn about open accessibility by working on self contained 'project tasks'. The next event is in Feb 27/8 and is a competition between traditional rivals UCLA and USC. We'd like to find a number of GNOME a11y tasks that are suitable for students to pick from a pool of suggested SS12 activities and get excited about working on. So I'm wondering if folks on this list can suggest ways to develop ideas and assist in compiling a list? In general SS12 projects have been development tasks like 'create an On Screen Keyboard' but as Yippi pointed out they do not have to be pure coding and could even be something like 'Fix a bug and see how many more you can find in GNOME apps'. The tasks are judged and winners selected, so that needs to be kept in mind. The students also need mentoring and while people are present at the event Stormy pointed out that having relevant GNOME developers on IRC could extend that and provide an enhanced experience. I'm hoping this will help bring some resource to GNOME a11y problems and introduce students to real open development activity. They could well remain engaged after the experience. I think this is great opportunity. Can you help make it happen? @Eitan: the next SS12 is 13 Mar at CSUN which seems tantalisingly close to the GNOME a11y hack event, so perhaps there can be some sort of connection, or continuation? Most of P:P are based around LA so there may even be a chance for a f2f. 1: http://www.projectpossibility.org 2: http://ss12.info -- Steve Lee ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Finding GNOME a11y tasks for Project:Possibility students to work on
2010/1/7 Steve Lee : > We'd like to find a number of GNOME a11y tasks that are suitable for > students to pick from a pool of suggested SS12 activities and get > excited about working on. > > So I'm wondering if folks on this list can suggest ways to develop > ideas and assist in compiling a list? In general SS12 projects have > been development tasks like 'create an On Screen Keyboard' but as > Yippi pointed out they do not have to be pure coding and could even be > something like 'Fix a bug and see how many more you can find in GNOME > apps'. The tasks are judged and winners selected, so that needs to be > kept in mind. Having discussed this with Willie I have created a new page to capture suitable small tasks. These will also be useful for the hackfest and other events. http://live.gnome.org/Accessibility/GetInvolved/SmallTasks Please do take a look and add any ideas you have. I've seeded it with some possibilities. Steve Lee ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: #a11y meeting Friday 20:00UTC
2010/1/7 Willie Walker : > Let's have a quick meeting on the #a11y channel in irc.gnome.org tomorrow to Is that 21:00 UTC? I'll try to stay awake and actually attend this time. Steve ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
CSUN registration
Does anyone know what the full CSUN registration covers ($450) compared to the hall only access ($0). I'm about to register and need to decide. I plan to hang out at GNOME and other booths and do some hacking but not so bothered about seminars, other than to support friends. No point me spending the money if not needed. -- Steve Lee ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
