IMPORTANT: This content is being preserved for historical purposes. Current information and documentation about GNOME Accessibility can be found at: the GNOME Accessibility Project


Contents

  1. Accessibility Summit - Sunday, October 8
  2. Minutes from Accessibility day at GNOME Boston Summit
    1. Attendees
    2. Introduction and Overview of Where We Are
    3. Where Do We Need to Go?
      1. What's Good?
      2. What's Needed?
      3. Misc Comments
    4. How do Others Get Involved?
      1. Engineering and Technical Types
    5. Action Items
      1. Testing: Rodney, Nags, Dave
      2. Automated Tools to "Lint" Glade Files for A11Y: Shane and WebAIM
      3. Best Practices Document for AT-SPI Implementations: Peter Parente and George Kraft
      4. Firefox A11Y Improvements: Aaron Leventhal & Ginn Chen
      5. Approachable Documentation for End Users: Joe Lazzaro
      6. Approachable Documentation for Programmers: Bill Haneman
      7. Prioritized list of hot bugs, trivial bugs, for folks to start: Willie Walker
      8. Improve support for using existing hardware, make it work better: David Zeuthen
      9. White Paper: Peter Korn
      10. Public wiki list of a11y projects to work on (cf. mozilla.org/access/projects): Peter Korn
      11. Usability testing of GNOME a11y by PWD: Brette Luck w/Novell & Dave w/ITD
      12. Description of what an office user w/a disability needs to be functional, efficient: Barbara Lybarger
      13. Performance testing, evaluation of accessibility framework: David Zeuthen
      14. Corral the multiplicity of broken audio frameworks together & make them work: Janina, Leon
    6. Recommendations to GNOME Community and Distros
  3. Strawman Agenda
      1. 10:00-10:30: Introductions and Overview of the Day - Willie Walker
      2. 10:30-11:30: Overview of Accessibility Infrastructure - Bill Haneman
      3. 11:30-12:30: Overview/Demos of Assistive Technologies - Willie Walker, Peter Parente, [Ubuntu?]
      4. 12:30-1:30: Lunch - preliminary discussion of gaps
      5. 1:30 - 2:30 Assistive Technology Gaps - Developers + End Users
      6. 2:30-4:00: End User Setup and Configuration - Ubuntu[?]
      7. 4:00-5:00: [MOVED TO SATURDAY, MORNING BOF] Testing - Willie Walker, George Kraft, Peter Parente, Nagapan A
      8. 5:00-5:30: [ONLY IF TIME ALLOWS] Speech Infrastructure - Brailcom[?], Willie Walker
      9. 5:30-6:00: Wrap up - All

Accessibility Summit - Sunday, October 8

A one day GNOME accessibility team meeting at the Boston Summit 2006, to talk through common goals, differing solutions, and how to get all of us on the same page and working to a master plan!

Minutes from Accessibility day at GNOME Boston Summit

These are the notes from the Accessibility Summit at GNOME Boston 2006 held on October 8, 2006.

Attendees

  • Leon Shiman of XOrg (Shiman Associates)
  • Dave Patterson ITD
  • Barbara Lybarger MOD
  • Brette Luck, Novell
  • Aaron Anderson,WebAIM (Utah State Univ.)
  • Shane Anderson, WebAIM (Utah State Univ.)
  • Bill Haneman, Sun Microsystems
  • Willie Walker, Sun Microsystems (CHAIR)
  • MIke Pedersen, Sun Microsystems
  • George Kraft, IBM
  • Peter Parente, IBM
  • Ginn Chen, Sun Microsystems
  • Zhao-Zhou Li, Sun Microsystems
  • Nagapan A, Novell (LDTP)
  • Steve Lee, OATSoft.org
  • DavidZeuthen, Red Hat a11y

  • David Malcolm, Red Hat Dogtail
  • Doug JOhnson
  • Joe Lazzaro, Mgr. AT group at ITD
  • Joanie Diggs, Carroll
  • Rodney Dawes, Novell a11y
  • Peter Korn, Sun Microsystems
  • David Bolter, UToronto
  • Janina Sajka, FSG/A
  • Aaron Leventhal
  • Ali Sobhi, IBM

Introduction and Overview of Where We Are

The morning was comprised of:

  • An overview of the AT-SPI infrastructure and implementation (Bill Haneman)
    • This includes pleas to:
      • Help find maintainers for the infrastructure to spread the maintainership around and to help with documentation
      • Move the gail module to gtk.
    • ACTION ITEM: we concluded that we want to use http://live.gnome.org/GAP as the jumping off point and will work to get Bill's slides up on this site. Joe Lazzaro also stated it is OK to put up the slides early as long as we commit to making them more accessible soon.

  • Demos of AccessX, Themes, Keyboard Navigation, Dasher, at-poke, GOK, gnome-mag (using composite), LSR, and Orca.

Where Do We Need to Go?

After lunch, we developed a list of what's good and what's needed:

What's Good?

  • Accessibility framework
  • GNOME community embrace of of A11y
  • GOK is cool
  • Dasher is cool
  • AccessX is good
  • Keyboard navigation (for desktop, most apps) built-in is good
  • Screen reader access is coming along
  • Developers are actively seeking involvement of PWD (not just employed by companies, but in community)
  • Organizations (e.g. companies) have involved end users
  • End users have also involved themselves
  • Transparency of work
  • Good to have competition in screen readers
  • Braille engine
  • ShowSounds

  • HelixPlayer to show captions

What's Needed?

  • Shared set of tools to help AT do their job (e.g., common utilities, testing tools, etc.)
  • Accessibility lint test tool (to work with Glade, maybe others)
  • Accessibility run-time test tools (Rodney Dawes has some stuff for this); can also cooperate with i18n tools
  • Good DAISY/NIMAS player
  • OpenBook (unbound) software equivalent

  • High quality OCR engine that is open source

  • High quality ASR engine, then end-user app for it (Sphinx-4, ASR/dictation engine written in Java; OSSRI)
  • High quality FOSS TTS
  • Braille translation & formatting (Duxbury equiv.) - (Janina: TurboBraille is an app)

  • UNIX software to sync. to Windows CE devices (may have something now...)
  • Best practices documentation (on a wiki?)
  • Code authoring assistance, that encourages good a11y programming (Forte, NetBeans, Eclipse, etc.)

  • Document authoring assistance, that encourages good authoring practices (ODF, PDF, etc.) - "This document is inaccessible. You can't save it until you make it accessible." :)

    • Shane of WebAIM wanting to get involved here
    • Want this incorporated directly into the authoring tool, not as a separate test app
  • GPS system support, integration (with speech, Braille, Magnification) (Geoclue guys at summit)
  • Common test framework (we have two good ones, but they are different)
  • Database accessibility (the front ends need to work well)
  • 5,000' view presentation to policy-makers (white paper)
  • Web accessibility (to Firefox, etc.)
  • Magnification improvements (cf. ZoomText)

  • Multimedia authoring tools for a11y (to add captions)
  • Bookshare reader for UNIX
  • RFB&D media reader

  • TTY interface (to talk with Baudot, and new TTY) (also IP/TTY interoperability)
  • Support for people with LD, Dyslexia
  • Plugins for web browser for cross-process embedded (e.g. Flash plug, PDF plug, Java plugin)
  • Grant/funding system for this (Joe: what about NIDRR for this? Dept. of Edu?)
  • Stuff just below the level of "adaptive technology" - any number of smallish stuff on the desktop
  • People who have expertise in a11y who can be hired to work on FOSS a11y
    • connections into Universities
  • "orphan software" support - for folks with multiple disabilities, (the 1% of the 1% of need)
  • Better "out of the box" experience
  • Accessibility "wizard"
  • Accessible Login working by default
  • Accessible install
  • Tactile graphics
  • Haptics
  • Chording keyboard support
  • Terminal services (thin client support through AT)
  • Accessible "Skype" and similar products
  • MathML accessibility
  • Flash, SVG, PDF viewers to be accessible
  • More accessible bugzilla
  • A way for contributers to ramp up -> for new interested folks to get involved in development

    • Mentoring as a way to do this - to grow our community and spread the knowledge
  • accessible installers for software
  • Disability organizations focusing their members, programmers into FOSS a11y work
  • UNIX drivers for inexpensive AT hardware (e.g. the cheap head mice)
  • Fixing broken audio on UNIX

Misc Comments

  • "Finishing" screen reader work is a top priority - reaching a certain level of functionality, performance
  • We want diversity in AT solutions

How do Others Get Involved?

Engineering and Technical Types

If you (an engineer type, documentation type) want to get involved:

  • Write documentation to turn "nerdspeak" into "humanspeak" +++
  • help test
  • help finish web a11y
  • lots of people without deep experience who can help write scripts soon (need to help them be effective)
  • jump into our bugs (ACTION ITEM: provide pointer to URL to pull up bugs we desperately need fixed)
  • Human "glinters" (Glade Lint verification by human/hand) (or a program that walks through Glade XML files and files bugs)
  • <blindprogramming.com - blind geeks hang out here>

  • make bugzilla more accessible

If you (an artist type) want to get involved:

  • Help create accessible icons for the various GNOME applications

If you (a University) want to get involved:

  • Write grants to work on a11y
  • Teach/train students to contribute to FOSS a11y

Action Items

We worked as a community to decide where to start.

Testing: Rodney, Nags, Dave

  • Get together and hash out GNOME and GNOME a11y testing (all said "yes")

Automated Tools to "Lint" Glade Files for A11Y: Shane and WebAIM

  • Develop automated tools to test Glade tools for XML a11y (with the three testers above) (all said "yes")

Best Practices Document for AT-SPI Implementations: Peter Parente and George Kraft

  • Develop best practices document for AT-SPI implementations, perhaps using the GTK/gail implementation as the de facto standard. (all said "yes" and Bill will offer help as needed)
  • Jumping off point: http://live.gnome.org/GAP

Firefox A11Y Improvements: Aaron Leventhal & Ginn Chen

  • Continue work on Firefox a11y implementation (all already said "yes")

Approachable Documentation for End Users: Joe Lazzaro

Approachable Documentation for Programmers: Bill Haneman

  • Continue effort on AT-SPI, ATK, etc., documentation (Bill said "yes")

Prioritized list of hot bugs, trivial bugs, for folks to start: Willie Walker

  • Provide single URL that lists these for newbies coming in and wanting to help

Improve support for using existing hardware, make it work better: David Zeuthen

  • Look at what it means to support braille devices, etc.

White Paper: Peter Korn

  • Work with community to develop a multi-author 5,000' view presentation geared towards policy-makers

Public wiki list of a11y projects to work on (cf. mozilla.org/access/projects): Peter Korn

Usability testing of GNOME a11y by PWD: Brette Luck w/Novell & Dave w/ITD

Description of what an office user w/a disability needs to be functional, efficient: Barbara Lybarger

Performance testing, evaluation of accessibility framework: David Zeuthen

  • Bill Haneman notes there are memory leaks in framework

Corral the multiplicity of broken audio frameworks together & make them work: Janina, Leon

Recommendations to GNOME Community and Distros

  • Turn AT support on by default in GNOME 2.17 builds (Willie to start discussion on desktop-devel)
  • Help enable autostart of assistive technologies:
    • Have AT follow the freedesktop.org autostart spec http://freedesktop.org/wiki/Standards_2fautostart_2dspec so they can more easily be added to the autostart directory

    • Have all AT include a "start me on startup" item
    • Provide right-click on menu item in App menu that is "add this to auto-start" (like "add to panel")
    • Put an AT tab into the "Preferred Applications" Preference dialog
  • Make it easy to find and enable AT
    • An "Accessibility Setup" Wizard
    • Group AT in a menu
    • "Tour of the desktop" for GNOME that accessibility becomes part of
  • Need good tooltip help for all a11y options
  • Accessible install (e.g., Ubuntu): should modify global gconf schema to enable a11y if an accessible install was used

Strawman Agenda

This is an attempt at organizing the original agenda suggestions (see below). People/Organizations listed with a [?] next to their name have not been contacted or verified for their participation.

NOTE: This is still a draft. We'll try to post a semi-final version by Saturday afternoon (Oct. 07)

10:00-10:30: Introductions and Overview of the Day - Willie Walker

GOALS: Get us settled in, learn a bit about each other, and get an idea for what the day will be like.

10:30-11:30: Overview of Accessibility Infrastructure - Bill Haneman

GOALS: Provide an understanding for what holds it all together, and identify ways to improve infrastructure docs and level of understanding among Gnome hackers:

Depending on who attends, this can be more of a discussion/roundtable about issues/strategies implementation, arch docs, and developer uptake and maintenance

11:30-12:30: Overview/Demos of Assistive Technologies - Willie Walker, Peter Parente, [Ubuntu?]

GOALS: Provide better insight into the capabilities of assistive technologies we currently have on the GNOME platform, including:

12:30-1:30: Lunch - preliminary discussion of gaps

1:30 - 2:30 Assistive Technology Gaps - Developers + End Users

GOALS: Now that we've seen what we've got, what do we need and how do we get there?

  • Improved magnification: gnome-mag, metacity magnification, xmcm

  • Speech recognition: command and control and dictation
  • OCR
  • ...
  • Alternate IPC and activation strategies? Should we remove bonobo from gnome-mag, for instance? Should we use gnome-braille?
  • Is it time to move libgail into GTK+?
  • How do we ensure that new Gnome components work with a11y? We have resourcing and division of responsibility issues, can we improve this?

2:30-4:00: End User Setup and Configuration - Ubuntu[?]

GOALS: Create a strategy and plan to improve the end user experience for choosing from a variety assistive technologies, how to configure them, and how to enable them at the login prompt and for the user's session.

  • Discussion of the long-proposed accessibility configuration wizard? Configurable gnome-at-properties and gdm login setup for other ATs added by the distros

  • How proposals 1] 2] 3] for capplet amalgamation might/should affect a11y options... e.g. there will be more a11y than non-a11y themes in the Themes capplet with a standard 2.16 install, which is sure to tick off some people, so perhaps other (simpler) options for selecting high contrast/large print themes might be in order. (E.g. just having a "large print" checkbox that could apply to any selected theme would get three of the a11y themes off the list.)

  • Consider the proposal to write the high contrast themes into the f.d.o Icon Theme Spec, placing the onus on app developers to provide high contrast equivalents of any hicolor icons they provide, rather than having the HC theme maintainers play an impossible catch-up job.

  • GOK configuration and support: how to make the out-of-the box experience work better, and allow zeroconf GOK. Possibly a short discussion, as there's a proposal for doing this, but if there are any additional serious obstacles unknown to the GOK maintainers this would be the time to voice them.

  • What are the defacto standard keystrokes and mouse gestures we should promote for starting the various AT's from gdm?

4:00-5:00: [MOVED TO SATURDAY, MORNING BOF] Testing - Willie Walker, George Kraft, Peter Parente, Nagapan A

GOALS: Create a testing strategy to help verify AT-SPI implementations as well as prevent regressions in AT-SPI implementations and assistive technologies.

How do we:

  1. Test for regressions in the accessibility support of toolkits and "regular" applications?
  2. Test assistive technologies?
  3. Encourage more consistent implementations of the AT-SPI through "best practices" documentation see mailing list posting and WIKI

What do we have in place today?

  • Overview of LDTP, Dogtail

  • LSB conformance testing for ATK, XKB, and SPI

  • Overview of Orca's test harness

5:00-5:30: [ONLY IF TIME ALLOWS] Speech Infrastructure - Brailcom[?], Willie Walker

GOALS: Discuss the potential of improving the TTS infrastructure of the GNOME platform.

Is gnome-speech sufficient for our needs? Should it be replaced? Is there an alternative, such as Speech Dispatcher? What would it mean to replace gnome-speech (impact on assistive technologies, need to get replacement in as part of the GNOME platform, support issues, etc.).

5:30-6:00: Wrap up - All

GOALS: Quick review of the day, summary of actions for ourselves and the GNOME community.

---

Original agenda suggestions from community:

  • Comprehensive overview of the accessibility architecture, including test strategies and how to implement ATK inside apps
  • Recent ATK/AT-SPI enhancements introduced in Gnome 2.16

  • Pending ATK/AT-SPI features: Collection, Terminal, EditableText, multi-user accessibility

  • wiki:Orca, Gnopernicus, wiki:LSR, wiki:Gok

  • gnome-mag, metacity magnification, xmcm

  • Possibly related to the above: finally do something about the long-proposed accessibility configuration wizard? Configurable gnome-at-properties and gdm login setup for other ATs added by the distros

  • How proposals 1] 2] 3] for capplet amalgamation might/should affect a11y options... e.g. there will be more a11y than non-a11y themes in the Themes capplet with a standard 2.16 install, which is sure to tick off some people, so perhaps other (simpler) options for selecting high contrast/large print themes might be in order. (E.g. just having a "large print" checkbox that could apply to any selected theme would get three of the a11y themes off the list.)

  • Consider the proposal to write the high contrast themes into the f.d.o Icon Theme Spec, placing the onus on app developers to provide high contrast equivalents of any hicolor icons they provide, rather than having the HC theme maintainers play an impossible catch-up job.

  • Regression testing - how do we help others from breaking accessibility support? How do we get them interested in testing their modules for accessibility?
  • LSB conformance testing for ATK, XKB, and SPI

  • TTS API Provider, SpeechDispatcher, Gnome-Speech

  • GOK configuration and support: how to make the out-of-the box experience work better, and allow zeroconf GOK. Possibly a short discussion, as there's a proposal for doing this, but if there are any additional serious obstacles unknown to the GOK maintainers this would be the time to voice them.

  • Let's hear from real end users: what are the gaps? what are the concerns?
  • Auto test of Accessibility, meaning recording the manual test once and running the generated script several times.
  • Demo of LDTP?
  • Mozilla/Firefox ATK support. In addition there will be a Mozilla Accessibility Hackfest from October 8-10.

  • wiki for atk "best practices" see mailing list posting


CategoryAccessibility

Events/Summit/2006/AccessibilitySummit (last edited 2013-11-27 23:05:11 by JuanjoMarin)