[Accessibility] A11y Teleconference: Wednesday 31 March

Bill Haneman Bill.Haneman at Sun.COM
Wed Mar 31 03:30:17 PST 2004

I will attend.

Don't forget, fellow eurozone folks, that Europe is on summer time this 
week but the US is not (yet).
- Bill

Janina Sajka wrote:

>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.
>7. Adjourn
>* __    Cover Sheet; 
>* __    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
>interface components:
> * 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
>Corporation, Red
>   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,
>among other;
> * 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
>conference include:
>1.) AT-SPI
>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
> accessible.
>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
> these libraries.
>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
> http://ftp.x.org/pub/R6.4/xc/doc/specs/XKB/XKBlib/allchaps.ps.
>"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
> best advantage.
> 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
> screen.
> 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
>portions of
> their specifications.
>* __    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; 
>* __    Information on the location and probable date(s) of the meeting
>and the method of announcement or invitation; 
>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
>coming January.
>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:
>	Keyboard Accessibility
>	Shared I/O
>	Magnification
>[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
>scientific, engineering]
>* __ 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); 
>* __ 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
>* __ 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 
>Accessibility mailing list
>Accessibility at mail.freestandards.org

More information about the Accessibility mailing list