[Accessibility] A11y Teleconference: Wednesday 31 March
Doug Beattie
dbb at linkexplorer.com
Wed Mar 31 07:10:31 PST 2004
I plan to attend.
Doug
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;
>
> 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
> _______________________________________________
> 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