[Accessibility] A11y Teleconference: Wednesday 31 March
janina at rednote.net
Tue Mar 30 18:12:38 PST 2004
Announcing the 31 March 2004 meeting of the Accessibility Workgroup
Please RSVP so we can know when those attending have called in.
This will help us start the meeting without unnecessary delay.
Wednesday, March 31, 19:00 UTC
-- 20:00 CEST (Berlin)
-- 19:00 BST (London)
-- 14:00 EST (New York)
-- 13:00 CST (Chicago)
-- 12:00 MST (Salt Lake City)
-- 11:00 PST (San Francisco)
-- 09:00 HST (Honolulu)
-- 04:00 JST (Tokyo -- 04/04/01)
Dial-in North America.. 800.664.6895
Dial-in International.. 719.955.1126
passcode: 5 7 7 9 1 7
1. Welcome and Agenda Review
2. Review of minutes from our last meeting
3. Action Item Review
Brief progress reports for open items
4. Old Business
NSF Proposal Discussion (See attached draft document)
5. New Business
6. Identify key items for the next agenda.
Janina Sajka, Director
Technology Research and Development
Governmental Relations Group
American Foundation for the Blind (AFB)
Email: janina at afb.net Phone: (202) 408-8175
-------------- next part --------------
* __ Cover Sheet;
USUAL BLATHER - JANINA
* __ Summary of one page or less indicating the objectives of the
The Accessibility Workgroup of the Free Standards Group (FSG) requests
funding of $35,900 from the National Science Foundation (NSF) to convene
a face-to-face meeting of invited experts to adopt and develop an
engineering agenda for standards supporting comprehensive access to
information and user interfaces for persons with disabilities on
computing platforms which adopt free and open standards (such as Linux,
Aix, <Mac OS X,> and Solaris). A face to face conference is the
appropriate mechanism to:
Engage the additional stakeholder participation needed in the
process already begun by the FSG
Reach consensus on a Road Map for creating a common layer of
accessibility support that can be deployed and maintained on multiple
Reach consensus on a common support layer that can promote
future collaborative research to provide multiple, interoperable,
heterogenous and accessible products.
In order to achieve the substantial consensus needed to adopt and
implement such standards we expect to invite between 20 and 30
individuals from industry, developer communities, research and
educational institutions, and persons with disabilities. We need to
ensure broad participation across all sectors of these groups worldwide,
and we need, particularly, to engage participants who would otherwise
not become involved in this process.
Of course achieving standardization for accessibility support in the
free and open source environment requires substantial consensus among
developer communities, marketers of free and open source technologies,
and user communities. The purpose of the proposed international
conference, therefore, is to achieve this substantial consensus
regarding the Workgroup's Year One identified standardization
activities, and to devise an engineering consensus regarding Year Two
and Three tasks, including particularly those requiring additional
research and development before standardization may properly occur.
* __ Statement of the need for such a gathering and a list of topics;
The heterogeneous nature of toolkits, component inter process
communication models, libraries, and applications on free and open
source platforms has made the development of robust and effective
assistive technologies difficult, at best. Without standards and binary
* Users with various disabilities can not effectively use the systems.
* Systems do not meet legal requirements <for accessibility> (which
marketing of free standards based systems).
* Developers cannot consistently write accessible applications.
* Comprehensive and consistent platform services that support
accessibility do not exist.
* Assistive technology developers cannot create assistive technologies
for free standards platforms.
* The lack of standardization prevents leveraging the existing work,
sharing of expertise, and reduces the value of individual
The beneficiaries of the accessibility standardization activity which will be
accelerated by this meeting are numerous, cutting across all sectors engaged
with either providing or using technology and include:
* Implementations of free standards such as GNOME, KDE, and GNU
* Vendors of Unix and Linux such as IBM Corporation, Novell
Hat Inc., Sun Micro Systems, and United Linux, among others.
* Vendors of hand-held devices, consumer and business products using
embedded technologies, as well as those providing large industrial
systems such as Hewlett-Packard Corporation and IBM Corporation,
* Both individual consumers and institutional ones such as governmental
agencies and educational institutions, many of which are now legally
required to support accessibility.
The principle beneficiaries of FSG Accessibility Standards will, of course, be
persons with disabilities worldwide. They are the reason for these standards.
However, it is also important to note that these benefits will be available
world-wide in developing and developed nations alike because cost will never be
a barrier to anyone's participation, either as an end user or as a technical
Specific topics which must be addressed and will be discussed at this
The Assistive Technology Service Provider Interface (AT-SPI) was
developed for the GNOME2 desktop and its approach to providing
accessibility is in the process of being adopted by KDE.
AT-SPI is toolkit-neutral. It is already compatible with and supported
GTK+2, Java/Swing, the Mozilla suite, and StarOffice/OpenOffice.
via reuse of the related ATK interface in version 4 of the Qt toolkit
which KDE is based) has been announced by TrollTech.
AT-SPI enables assistive technology tools, e.g. screen readers,
magnifiers, and even scripting interfaces to query and interact with
graphical user interface (GUI) controls. As such it facilitates access
for individuals who cannot use the standard GUI. It enables developers
(or a third party) to build applications that are, or can be made
The AT-SPI enables developers and distributions to meet the
requirements of many individual and corporate customers.
[--So, what's to discuss? Brief overview of the issues in our
previous telecons on this topic and the need to reach consensus on what
is a somewhat different approach for many in the standards community.
2.) AT Device Shared I/O
AT device shared I/O would make it possible for devices that are
commonly used by persons with disabilities to operate smoothly with
several client applications simultaneously.
In some circumstances it is necessary to support simultaneous access for
different client applications. For example, allowing a software-based
speech synthesizer to speak while a multi-media stream is playing,
than queueing its messages to play after the stream concludes. In
addition, it may also be necessary to have messages queue or suppress
until a particular window or console has focus. This activity supports
seamless user experience from bootup, in the console and desktop
environments, and through shutdown.
We will support/coordinate the development of libraries that allow
applications to share these I/O devices. Shared access to accessibility
related devices, such as Braille displays, reduces the cost of
and improves the user experience. These libraries should offer a
high-level abstraction of the underlying device to allow client
applications, to use those libraries independent of the actual hardware
in use. This simplifies the development of accessibility related
by sharing commonly used code such as low-level driver implementations
3.) Keyboard Accessibility
Persons unable to use a keyboard and mouse sometimes use alternative
devices. However, many users can be accommodated programatically
software that causes a standard keyboard to behave differently. Many of
these features and behaviors have long been available in the XKB
specification available at
"Sticky Keys" is one keyboard accessibility feature provided in the XKB
specification. It supports users who cannot press key combinations. For
example, the user is unable to press the Ctrl-Alt-TAB keys
simultaneously, Sticky keys allows them to achieve the same result by
pressing the keys sequentially.
Individuals with mobility impairments will benefit by having such
features built-in and available through standard activation strategies,
such as tapping the Shift key five times to activate Sticky Keys. The
routines provided by the API will also benefit assistive technologies
such as on screen keyboard and screen reader applications.
We propose to identify and adopt a subset of the XKB specification in
order to provide standard keyboard features and behaviors required by
persons with mobility impairments.
4.) Text-only accessible booting (Year Two)
It should be possible for any user who is a person with a disability to access any user supported interface during the boot process, including the
selection of the kernel to boot, rescue modes, interactive device loading, etc. We will support/coordinate the development of best practices and
coordinate with kernel and boot loader development teams to facilitate the interfacing of assistive technologies at any point during the boot process
where user access is supported.
This will particularly benefit those users with disabilities who are technology professionals and need, or desire, to participate in development and
testing of system products and features.
5.) Accessible Feature Configuration (Year Two)
Users who are persons with disabilities should have accessible applications and tools to assist them with configuring their system user interfaces to
Quite often the user is left trying to configure their own system, because technical support staff does not have sufficient knowledge about the
available configuration options. However, most of the information these users need can be documented and exposed in a systematic manner.
We will support/coordinate the development of scripted wizards and best practices documentation to facilitate the end user by providing easy to use
tools and clear, non-technical documentation for creating appropriate configurations on individual workstations. For users whose needs may vary from
day to day, we will support/coordinate the development of scripted mechanisms to allow users to select an alternative configuration easily, as their
needs change during system use.
6.) Magnification (Year Two)
Service API support for magnification should make it possible to provide sophisticated magnification of one or more portions of the video display
screen for users who require, a larger or different font, and alternate foreground or background color.
In addition, magnification of icons and text should be able to achieve a wide range of magnification ratios. Many users with visual disabilities need
3X, 4x, etc. magnification, while other users can benefit from ratios as small as 1.2X magnification.
Currently it is not possible to achieve required magnification functionality on X platforms without requiring high-end video hardware with multiple
frame buffering. This should not be a requirement. Also, the user should be able to maintain magnification while applications are writing to the
Historically the networked nature of the X technology has not made it possible (nor desirable) for AT to replace device drivers or write directly to
video hardware. We will support/coordinate the development of enhanced windowing technologies capable of supporting magnification technologies more
robustly and appropriately. Creating this standard will require significant cooperation with X, GNOME, and KDE developers. There are currently
projects under development, among some vendors, that can provide reference implementations.
7.) Text To Speech (Year Two)
Interfaces based on synthesized text to speech (TTS) technology have proven a successful and powerful accomodation for users with various
disabilities, including persons who are blind or who have learning disabilities. A standard mechanism supporting numerous voices in numumerous
languages, yet providing a single, consistant interface to applications is preferred.
We will support/coordinate the development of a standard API for TTS services capable of supporting numerous languages and including the ability to
smoothly and quickly switch among different languages and/or voices. This project will adopt or develop standardized mark up for spoken dialog, and
provide an API for TTS services, such as JSAPI.
People with disabilities benefit by a larger availibility of languages choices, many that may not be supported by assistive technologies today.
Providing a robust, reliable TTS interface supporting multiple voices will make it possible to facilitate the vast populations around the globe who
otherwise, might not soon participate in a tecnology based economy.
8.) Alternative Interface Access Protocol (Year Three)
The Alternative Interface Access Protocol (AIAP) is being developed by a technical committee of the InterNational Committee for Information Technology
Standards (INCITS) (see www.v2access.org). The AIAP provides for a Universal Remote Console (URC) "that allows users to control a mass-market
device/service (target). The URC may be a dedicated device or a feature running on a computer, a cell phone, an Assistive Technology, or other device.
The key to this approach is that the target projects a presentation-independent version of its user interface (UI) which is rendered as a concrete
user interface by the URC. The concrete UI may be visual, speech-based, braille-based, or in some other form. If desired, the manufacturer may also
provide customized concrete UIs to optimize aesthetics and usability for certain classes of users or devices. The structure of a V2 user interface
definition is intended to facilitate the use of intelligent software agents to control services and devices in the future."
The objective of the standard is to allow two devices to negotiate, in a transport independent manner, the interface that is appropriate to a
particular user. This standard will be especially important for use in public access systems to provide user appropriate interfaces rather than only a
single user interface as is the case today. It will also be useful for providing a defined mechanism whereby a user's PDA (or similar device) can
serve as an alternate interface to a public access system and to the full range of consumer devices such as thermostats, kitchen appliances, laundry
facilities, and home security and entertainment systems.
Without this (or a similar) universal remote console (URC)technology public access and consumer technologies are likely to become even less accessible
to an ever wider range of users than they are today. Users with disabilities are often unable to use public kiosks such as ATMs, airline boarding pass
systems, etc., because they cannot use the default user interfaces provided by such systems. The INCITS V2 specs are designed to provide these
interfaces directly or to negotiate, over a secure wireless transport-independent channel with the user's personal device to provide service.
The V2Committee expects to have a candidate 1.0 specification available
for ANSI certification early in 2004. We propose to adopt relevant
* __ Recent meetings on the same subject, including dates and
There has not yet been a conference devoted to defining an engineering
agenda--a Road Map--to deliver accessibility on free and open source
platforms. Notably, several hour-long and day-long sessions addressing
this and related topics have been held at conferences which tend to draw
professionals working on computer and information systems accessibility
such as the annual Technology and Persons with Disabilities Conference
in Los Angeles (CSUN). A Linux Accessibility conference accompanied CSUN
in 2002 and 2003 (see http://ocularis.sourceforge.net/). Sun
Microsystems also sponsored daylong sessions on aspects of their work,
and that of others in the GNOME community, at recent CSUN conferences.
Sun has also presented on this topic at several European conferences of
GNOME and KDE developers, most notably the annual Guadec conference
The Accessibility Workgroup of the FSG has been meeting weekly since
February 2003 by teleconference. Several members of this Workgroup also
met in an extended working session during CSUN 2003.
The complex nature of the issues to be understood, the need for a
comprehensive consensus plan to address accessibility on Linux, BSD,
Solaris, Aix (and other platforms implementing free and open source
technologies) needs a focused event where accessibility on F/OSS
platforms is the only agenda.
* __ Names of the chairperson and members of organizing committees
and their organizational affiliations;
- WE'LL DISCUSS THIS AT THE NEXT MEETING
* __ Information on the location and probable date(s) of the meeting
and the method of announcement or invitation;
- HAWAII, JUST BEFORE ATIA, ATLANTA, IBM-ALMADEN
Three of our member organizations have offered facilities to host this
conference. Therefore, it is most probable that we will meet either at:
1.) The University of Hawaii, Honolulu,
2.) Georgia Institute of Technology, Atlanta,
3.) IBM Corporation, Almaden, California,
4.) Or immediately preceding the ATIA Conference in Orlando this
It is our strong desire to schedule this conference expiditiously.
Participation in this conference will be by invitation. We will invite
technically conversant participation from industry, research
institutions, consumer organizations, and professional associations in
an effort to bring sufficient representation to achieve a consensus that
can both meet the need and be implemented within shipping products. We
will also invite interested individuals to request an invitation by
announcing this conference on targeted email lists and at our web site,
* __ Statement of how the meeting will be organized and conducted,
how the results of the meeting will be disseminated and how the meeting
will contribute to the enhancement and improvement of scientific,
engineering and/or educational activities;
[how the meeting will be organized and conducted]
Since the purpose of our conference is the development of an engineering
agenda that can result in standards to support accessibility, our
organization will be fairly simple. We will develop a specific agenda of
issues and questions to be addressed in advance of the conference. The agenda will be published at the Accessibility Workgroup's web site at http://www.a11y.org.
The conference will be conducted by the conference chair, and all
breakout sessions by the team lead for each project area. We will hold
plenary sessions as well as break-out sessions for teams focussing on
particular areas, including:
[how the results of the meeting will be disseminated]
All discussions at the conference will be recorded in conference
minutes. The minutes, together with a report of conclusions, identified
activities, tasks, deliverables and timelines will be published on the
Accessibility Workgroup's web page at http://www.a11y.org.
[how the meeting will contribute to the enhancement and improvement of
* __ A plan for recruitment of and support for speakers and other
attendees, that includes participation of groups underrepresented in
science and engineering (e.g., underrepresented minorities, women, and
persons with disabilities);
- BY INVITATION ONLY, INVITING 20-30 PEOPLE
- ANNOUNCE MTG ON VARIOUS LISTS AND A11Y WG WEB PAGE INVITING PEOPLE TO
SAY WHY WE SHOULD ASK THEM TO COME; WE WILL IDENTIFY SKILL SETS WE'RE
- IDENTIFY EXPERTISE OF PEOPLE WE WANT: AT, XSERVER, USER REQTS, CORE
AI: FIND OUT HOW OTHER GROUPS INVITE ATTENDEES
* __ Estimated total budget for the conference, together with an
itemized statement of the amount of support requested from NSF (the NSF
budget may include participant support for transportation (when
appropriate), per diem costs, stipends, publication and other
conference-related costs. (Note: participant support costs must be
excluded from the indirect cost base.) See Chapter II, Section C.2.g.(v)
We request, $35,900, funds to cover:
1.) $23,400 Travel and accommodation support for between 12-18
who could otherwise not attend;
2.) $9,500 Conference room, equipment, support staff, and meals*
3.) $ 3,000 Organizational and advance staff expenses
- IS THIS ENOUGH MONEY?
- ARE ALL SUPPORT SKILLS COVERED [E.G. ASL INTERPRETER, NOTE/MINUTES
= QUICKLY DISCUSS IN NEXT MTG, IDENTIFY WHAT IS MISSING
- ALSO NOTE COMPANIES ARE FUNDING TRAVEL AND EXPENSES FOR THEIR PEOPLE
AI: WE NEED EVERYONE TO SEE IF THEIR MANAGEMENT WILL FUND
* __ Support requested or available from other Federal agencies and
other sources. (Chapter II, Section C.2.h <2.htm> should be consulted to
prepare this portion of the proposal.) For additional coverage on
allowability of costs associated with meetings and conferences, see
below 625 Meetings and Conferences
- JANINA NEEDS TO CHECK WITH GRANT OFFICER ON WHAT'S NEEDED HERE
More information about the Accessibility