Hi All: > We need to choose a day for the meeting, and develop an agenda - please log > in to the wiki and add your suggestions. If there's enough support for this > idea, we can dedicate a room to it - it might be useful to nominate a chair > person to maintain the wiki page and run the meeting.
I'm happy to volunteer to be chair for this meeting and have support from my management to spend time on it. I've been working on accessibility to the X Window System since the early 1990's and have most recently been leading the Orca screen reader effort. Ultimately the meeting will be based upon what people decide they want to discuss. Looking at what is emerging from the community input on the WIKI (http://live.gnome.org/Boston2006/AccessibilitySummit), I propose there might be at least three main themes for the summit: 1) Improving the accessibility of the base platform. This can include topics such as the a11y component to the icon theme, magnification, keyboard traversal, windows from multiple users on the same display, and the thought of getting SpeechDispatcher into the platform. Possibly also a discussion on AT-SPI futures: CORBA, DBUS? 2) Improving and providing multiple assistive technology offerings and how to manage their selection/configuration/setup. A concrete goal here could be to determine the appropriate user interface(s) that works within the GNOME "highlander principle" (i.e., there can be only one of any breed in the GNOME platform), yet easily supports distributions that ship more than one solution for a given disability (e.g., GOK and SOK/onBoard). Various people are giving some thought to this space and this summit could be a good way to reach a consensus and a plan of execution. 3) Brainstorming how to get the whole of the GNOME community more proactive in testing for accessibility. Prior to the release of GNOME 2.14 and now prior to GNOME 2.16, Sun spent considerable time chasing down and fixing a11y regressions in other people's modules. We need a better way for us (and ultimately the module owners themselves) to find and prevent these regressions. Related to this, we're working on an automated regression test harness for Orca, which I hope is ready by the summit. Given #3, I'd also like to try expose plain old non-a11y developers from the GNOME community to a11y. My experiences from doing these types of meetings many times in the past is that we tend to end up preaching to the choir when we often want the rest of the congregation to attend. Jeff has suggested that we can do a "accessibility summit report" to the larger conference the day after the summit. Finally, the Boston area is home to important and influential accessibility organizations such as the Carroll Center for the Blind and the Massachusetts Office on Disability. Basing your work on input from real live end users is always a good thing (I personally think it is mandatory). If the summit attendees find it appropriate, we can extend an invitation to our close contacts in these organizations. In any case, these are initial thoughts that can be twisted, contorted, and expanded as need be. :-) Will _______________________________________________ gnome-accessibility-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
