[Accessibility] Doc 1 of 4: Today's meeting
Bill Haneman
Bill.Haneman at Sun.COM
Wed Apr 21 12:22:45 PDT 2004
Hi
I have some inline comments. I would clip to shorten, but I would guess
it's best to keep the context.
- Bill
Janina Sajka wrote:
>------------------------------------------------------------------------
>
>
>* __ Summary of one page or less indicating the objectives of the
>project;
>
>The Free Standards Group (FSG), Accessibility Workgroup, wishes to convene a face-to-face meeting in
>
{REVISION}
early 2005. At this meeting, invited experts will have in-depth face-to-face discussions to further ongoing standardization
efforts in support of the comprehensive access to information and accessible user interfaces for persons with disabilities.
> The Workgroup's focus is on computing platforms that adopt free and
> open standards, such as Linux, BSD, AIX, MacOSX, and Solaris. At this
> time, the FSG Accessibility Workgroup would like to request funding in
> the amount of $35,000. from the National Science Foundation (NSF) in
> support of this meeting. A face-to-face conference is needed for the
> Workgroup's continued work, and is the most appropriate mechanism to:
>
>
> * Finalize and propose industry wide accessibility standards where FSG work has already begun;
how about:
"Finalize proposals for industry wide accessibility standards where FSG
work has already begun;"
> * Develop a Road Map for additional open source technologies and standards to support comprehensive accessibility on open platforms;
>
> * Reach consensus on a common layer of accessibility support that can be deployed and maintained on multiple platforms and can serve as the basis for future collaborative research to provide multiple, cost effective, interoperable, heterogenous and accessible products.
>
>Achieving standards to support comprehensive accessibility in the free and open source environment will require participation among developer communities, marketers of free and open source technologies, and user communities. The very diverse and unstructured nature of these groups has tended to prevent adequate contact and communication among them so that excellent accessibility for some users exists in certain contexts, while other contexts remain unaddressed and inaccessible. The objectives of our international conference, therefore, are:
>
> * achieve consensus on those standards which can be adopted to support accessibility in the near term;
>
> * Agree on engineering work which must yet be performed in order to support all persons with disabilities;
>
>
add:
* Identify areas where further targeted research is required before
engineering solutions can be put forward;
> * Provide structured and sustainable working mechanisms to accomplish both.
>
>We plan 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.
>
>* __ Statement of the need for such a gathering and a list of topics;
>
>The very diverse and unstructured nature of
>stakeholder constituencies which must agree to create a common
>layer of accessibility support on open platforms has tended to
>prevent the contact and communication needed to achieve such a
>consensus.
>
Is the restatement necessary here?
>There simply has not been an industry forum to support such
>an effort--until now. The diverse nature of the technology that
>constitutes today's open platform has also made it very difficult
>to achieve a comprehensive and cohesive layer of accessibility
>support. 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
>consensus among stakeholders, and without standards and binary
>interface components:
>
> * Users with various disabilities can not effectively use
> these systems--or major portions of these 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
> 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:
>
>
>
Let's promote end-users of accessible software and
researchers/developers of products for persons with disabilities to the
top of the list below.
> * 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
> others;
>
> Researchers who must now constantly address the basics of
>accessibility support rather than creative and innovative approaches to
>more complex questions;
>
> * 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, always be persons with disabilities worldwide. They
>are the reason for the research and engineering work we will organize
>and the
>FSG standards which will result from it. However, it is also
>important to note that these benefits will be available
>world-wide in developing and developed nations alike because neither
>cost
>nor access to the technology itself will ever be a barrier to anyone's
>participation, either as an
>end user or as a technical contributor. This is a fundamental
>benefit of open source technology. It explains why research
>institutions tend to prefer open platforms for their activities.
>And, by including accessibility support through a common layer
>that all platforms can adopt, persons with disabilities will be
>empowered to participate at any level in technology's benefits
>throughout their professional careers and personal lives.
>
>The conference agenda will include work on FSG's current
>accessibility standardization efforts and on developing a Road
>Map, with timelines and deliverables, which can point the way to
>a comprehensive solution that is implementable incrementally.
>Specific topics which must be addressed and will be discussed at
>this conference include:
>
>Part A: Current Tasks
>
>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.
>
> Yet, adopting the AT-SPI as a standard that platforms and
> products can certify against is a somewhat different
> approach for many in the open standards community. So, while
> the technology approach may be sound, it is nevertheless
> necessary to obtain stakeholder consensus for AT-SPI to be adopted
>industry-wide as a standard. It will also
> be necessary to devise and agree on certification
> procedures.
>
>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 which a user may
> have open. Not only does the system as a whole need to
> provide appropriate behavior to an application which
> currently has focus, it should facilitate programmatically
> determined output in an appropriate manner aswell for applications
>that may not have focus but have been set to monitor and report on
>conditions.
>
> Because applications which support accessibility have
> historically been developed by isolated communities, they do
> not necessarily operate without impinging upon one another
> today. In some circumstances, for example, 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. Both of these behaviors must be available to the
>end user.
>
> 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, in turn, simplifies the
> development of accessibility related software and helps drive the
>cost of assistive technology down.
>
>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.
> Yet some of these features are today in danger of being
> removed from XKB because its maintainers are no longer aware
> of how critical they are to certain users. We will protect
> and extend these important technologies by engaging all of
> the stakeholders in the creation of an internationally
> acknowledged standard against which platforms and products
> can certify.
>
> "Sticky Keys" is one such 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.
>
>Part B: Future Activities
>
>The FSG Accessibility Workgroup has named several areas which it
>believes require additional engineering development and
>standardization. While we do not believe this list is exhaustive,
>we do believe it can serve to start the all important discussions
>on creating a Road Map for comprehensive accessibility on open
>platforms. Thus, the Road Map produced by the conference we are
>proposing may include all or some of the following activities:
>
>1.) Magnification
>
> One critical area requiring engineering and standardization
> is support for magnification in Xwindows applications.
> 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. 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.
>
>2.) Text To Speech
>
> 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 API supporting numerous voices in numumerous
> languages, and supporting the ability to smoothly and
> quickly switch among different languages, yet providing a
> single, consistant interface to applications does not exist
> today. Such an API is needed if conversational foreign
> language education is one day to be made available. People
> with disabilities will also benefit by a larger availibility
> of language choices in spoken interfaces, many that may not
> be supported by assistive technologies today. Providing a
> robust, reliable TTS interface supporting multiple voices
> will also make it possible to facilitate the vast
> populations around the globe who otherwise, might not soon
> participate in a tecnology based economy.
>
>3.) Alternative Interface Access Protocol
>
> 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 target projects a
> presentation-independent version of its user interface (UI)
> which is rendered as a concrete user interface by the URC
> and may be visual, speech-based, braille-based, or in some
> other form. This activity dovetails with current emphasis
> within the World Wide Web Consortium (W3C) on the
> development of device independent, multi-modal XML markup
> technologies. Incorporating these developments into a common
> accessibility support layer on open platforms can facilitate
> accessibility for a host of common devices from public
> access terminals to the full range of consumer devices
> such as thermostats, kitchen appliances, laundry facilities,
> and home security and entertainment systems. Without support
> for this (or a similar) universal remote console
> (URC)technology in SDKs, public access and consumer
> technologies are likely to become even less accessible to an
> ever wider range of users than they are today. Withit, ever
> more research and educational opportunities can be made
> accessible where they are not accessible today.
>
>4.) Text-only accessible booting
>
> 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. This will
> require coordination 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 customarily supported. This will particularly
> benefit those users with disabilities who are technology
> professionals or scientific researchers and need, or desire,
> to participate directly in the development and testing of
> products.
>
>5.) Accessible Feature Configuration
>
> 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. In
> particular, we are concerned to devise technologies which
> facilitate rapid configuration and adaptation as users move
> from one device to another, or as a user's needs change
> during the day.
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Accessibility mailing list
>Accessibility at mail.freestandards.org
>http://mail.freestandards.org/mailman/listinfo/accessibility
>
>
More information about the Accessibility
mailing list