[...] >> Do we have any specific improvements (and the reasons why they're > important >> - or the people for whom they're important) to point to? > > When we met last we discussed having a short list of the tasks that > the funds will be directed towards. I still think that's a good idea. > It can be an indicative list. ;) >
These are the main tasks you could help us to accomplish : 1. Performance Improvements Many users and developers complain frequently about performance with respect to GNOME accessibility, both the tools themselves (e.g. Orca) and the performance degradation seen in applications when accessibility support is enabled for the session -- even when no assistive technologies are being used. This latter issue is frequently cited as the cause for developers not enabling this support as well as for the community and distros being unwilling to enable this support by default. 2. GNOME Shell Magnifier track focus and caret GNOME Shell Magnifier does not track focus or the caret. As a result, GNOME Shell Magnifier users who need to use preferentially the keyboard must either regularly move the mouse to see the active area, or use Orca to cause the area of interest to be displayed by the magnifier. 3. Improved and Increased Access to Application and Toolkits The Accessibility team would like to provide more compelling access to currently-supported modules and implement support for modules which are currently not supported due to problems with their accessibility implementation. This requires collaboration between our team and the teams whose applications and toolkits we would like to provide access to. The most remarkable cases are: * Evince, the GNOME document reader, and Poppler, its PDF engine, should reflect the structure of the document (headings, paragraphs, etc.) and its formatted attributes rather than be a single text object. * WebKitGTK+, the new GTK+ port of the WebKit, the successful free and open-source web content engine, used in the GNOME web browser, epiphany, and the help viewer Yelp, needs some work to make ARIA and HTML5 accessible. Also it we would like to provide support for porting Evolution to WebKitGTK+ and removing the old code and custom widgets to make it accesible. 4. Alternative Input Devices Research GNOME has very few options for users who require alternative input device(s), including users with physical disabilities and users with learning disabilities. Because we lack compelling solutions in these areas, we do not have an extensive user population providing us with feedback and requests. In order to ensure that the GNOME Desktop is an environment which is truly universally accessible, we need to provide solutions based on a detailed and accurate understanding of user needs in this area. 5. Improved Regression Testing Tools for Applications and Toolkits We spend a non-trivial amount of its time triaging and filing bugs introduced by changes in the applications and toolkits GNOME ATs provide access to. It would be much better if these regressions could be automatically detected when they are made so that the problematic changes are identified and not committed. This will enable accessibility developers more productive. 6. Bug Fixing Despite the best efforts of the teams working on GNOME 3, there will undoubtedly be bugs which are not caught in time. We will not fully know what all is broken until a significant number of GNOME users have worked with GNOME 3 on a regular basis. In addition, there are already a non-trivial number of accessibility bugs logged in GNOME's bugzilla. If we want to provide a truly compelling desktop environment, we need to fix these bugs. You can get extended information about these and another goals in the GNOME accessibilty roadmap <https://live.gnome.org/Accessibility/Roadmap> -- marketing-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/marketing-list
