[Accessibility] A11y Teleconference: Wednesday 31 March

[Janina Sajka]

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
-------------- next part --------------
* __    Cover Sheet; 

	USUAL BLATHER - JANINA

* __    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; 

- 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
- MID-JANUARY

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:

	AT-SPI
	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); 

- 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
LOOKING FOR
- IDENTIFY EXPERTISE OF PEOPLE WE WANT: AT, XSERVER, USER REQTS, CORE
FUNCTION EXPERTISE

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)
<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

- IS THIS ENOUGH MONEY?
- ARE ALL SUPPORT SKILLS COVERED [E.G. ASL INTERPRETER, NOTE/MINUTES
TAKER]
	= 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