[Accessibility] A11y Teleconference: Wednesday 31 March

Doug Beattie dbb at linkexplorer.com
Wed Mar 31 07:10:31 PST 2004

I plan to attend.


On Tue, Mar 30, 2004 at 09:12:38PM -0500, 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.
> Day/Time
>  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)
> Phone/Passcode
>  Dial-in North America.. 800.664.6895
>  Dial-in International.. 719.955.1126
> passcode: 5 7 7 9 1 7
> Agenda:
> 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
> -- 
> 				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

> * __    Cover Sheet; 
> * __    Summary of one page or less indicating the objectives of the
> project; 
> 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
> platforms
> 	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 
> hampers
>    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
> contributions.
> 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
> software
>  * 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
> contributor.
> 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
> by 
>  GTK+2, Java/Swing, the Mozilla suite, and StarOffice/OpenOffice.
> Support
>  via reuse of the related ATK interface in version 4 of the Qt toolkit
> (on
>  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
> accessibility 
>  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,
> rather
>  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
> a
>  seamless user experience from bootup, in the console and desktop
>  environments, and through shutdown.
> We will support/coordinate the development of libraries that allow
> client 
>  applications to share these I/O devices. Shared access to accessibility
>  related devices, such as Braille displays, reduces the cost of
> ownership
>  and improves the user experience.  These libraries should offer a
> generic
>  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
> software
>  by sharing commonly used code such as low-level driver implementations
> in
>  these libraries.
> 3.) Keyboard Accessibility
> Persons unable to use a keyboard and mouse sometimes use alternative
>  devices. However, many users can be accommodated programatically
> through
>  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
> locations; 
> 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
> (http://www.guadec.org).
> 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,
> http://www.a11y.org.
> * __    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)
> <2.htm>
> We request, $35,900, funds to cover:
> 1.)  $23,400 Travel and accommodation support for between 12-18
> individuals 
> 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
> http://mail.freestandards.org/mailman/listinfo/accessibility

Doug Beattie
dbb at linkexplorer.com

More information about the Accessibility mailing list