[Accessibility] Accessibility Conference January 25, 2005
john goldthwaite
jgoldthwaite at yahoo.com
Wed Feb 16 14:47:47 PST 2005
Accessibility Conference January 25, 2005
Attendees:
Al Gilman – W3c protocols &
Bill Haneman – Sun & Gnome accessibility, AT-SPI,
keyboard group
Marc Mulcahy (gnome-speech)
Janina Sajka
George Kraft
Marcos Gambra – Suse, Suse Gnome
Jonathan Blanford (Red Hat, GNOME)
Harald Fernengel KDE
Olaf Schmidt (KDE accessibility)
Gunnar Schmidt (KDE accessibility, Kmouth)
C Libre- brai
Aaron Seigo - KDE
Neil Scott – Archimedes
Kevin Gill – Archimedes
Right side –
Jan Buchal (speech-dispatcher, BrailleCom)
Milan Zamazal (speech-dispatcher)
Tomas Cerha (BrailleCom, speech-dispatcher)
Hynek Hanke (speech-dispatcher)
Larry Weiss IBM
John Goldthwaite Georgia Tech CATEA
Peter Korn – Sun
Will Walker – Xwindows access, keyboard navigation,
Java Access, free tts synthesizer
Sebastien Hinderer < (brltty)
Samuel Thibault (brltty)
Doug Beatie - Free Standards Group
Ed Price - Wireless RERC, V2
Mike Paciello
Kate Gnide - N
Stuart Anderson - LSB project
Frank Carnical - Syracuse, Linux program
Phone-
Earl Johnson – Sun Accessibility program office
founder, Xwindows accesss
Pete Brunet - IBM accessibility for Linux,
IRC-
Kurt Reiser -
Matthew Wilcox
Keith Packard 50% (X)
Gradimir Kragic (South Slavic Disability Website)
Gary Cramblitt (KDE, KTTS)
Kris Van Hees (FSG)
Deedra Waters 50% (FSG, Gentoo)
Bill Laplant (v2)
Sebastien Sable (libbrl)
George Kraft – Free standards group
Presentation on a11y website
http://accessibility.freestandards.org/%7Egk4/a11y/stds/
Consensus standardization of de facto implementation,
No design, just standardize what is in practice
Specifications
Multiple distro implementations
Public review
DocBook SGML formatted – free
Certification
Conformance testing of candidate
TETware – test environment
GPL or Artistic licensed tests, all free
Specification Tiers (informal)
Runtime environments
Development Environment
User Environment
System Management
Most standards have been in the Run Time area
LSB deliverables
LSB generic and Architecture specs for IA32. IA64,
PPC64, S390,
Conformance tests
LSB Timeline
Large number of small releases working toward a 1.0
version
LSB Marketing – articles, interviews, press releases,
tutorials, Conference presence, Workgroup
presence(freedesktop.org, x.org, ISO) we need to self
promote.
30 Linux releases are LSB certified, all major Linux
distributions have adopted it. LSB 2.0.1 being
adopted by ISO – have path to international standard
Expansion – add new API’s
LSB partnerships- packaging, desktop,
We can turn over to LSB to merge into the broader
picture of LSB standards.
LSB desktop – new desktop spec for LSB 3.0, specifying
ATK v1.9.0,
www.linuxbase.org/LSBWiki/
Weaknesses- scope of LSB is not broad enough, added
C++ to LSB 2, n
Need to improve test case coverage, takes time to
write
LSB is over committed given resources
ISVs too skeptical to adopt
Open Internationalization workgroup
- Globalization spec.
- -LSB I18N runtime certification, adopted by Red Hat
RHES3 and SLES9
Accessibility Workgroup
3 subgroups – Keyboard, AT-SPI, I/O
Keep specification scope small and manageable
Defer implementation and systems integration to GAP
Invent/design as little as possible – work with what
is in GAP
Documentation
Source code control
Work on APIs and ABIs, make sure has description, what
it returns,
IDL? Does ISV application use the ABI?
-
Conformance Test
POSIX.3 test methodology, special return codes
TETware and Open source test environment
Six ways to pass- Pass, Warning feature deprecated,
FIP need further info
TETworks Language
C, C++, Java, Sh, Ksh, Perl, Tcl
X11 testing p binary LSB X window test suite
VSM5 – Motif conformance test suite for widgets
Can to GUI testing with the suite. Lots of
permutations. Can take a month to write a test for a
single function.
A11y Recommendations
Add Project management workgroup and subgroups
- roadmap of spec and testing deliverables
- weekly subgroup calls
- Action item tracking
Establish formal A11y steering committee- review work,
is it ready to release to FSG. Need steering
committee to review work, make sure its working
Establish formal GAP steering committee
Bill – those are the
Peter- outside of scope of the group, if we want
formality it should be at the freedesktop.org level.
Examples of deliverables
Specification – Keyboard, GAP, I/O)
Conformance tests
Application A11y Style Guide – do presentations and
articles
Application A11y How-To Guide
All deliverables complement implementation
Action Items
-Publish 0.1 of individual specification for Keyboard
in 1st quarter
Get started on conformance tests
FSG Booth at LinuxWorld in February
DDC/OLS presentation in June
References
Workgroup Committee Procedures
Workgroup Charters
Book on Building standards, IBM Press ISBN 012145695
Peter- How-to Guides – url to JAVA accessibility
How-to
Bill – also version of the document in Gnome\learn
Al Gilman- doesn’t seem possible to do accessibility
testing without user testing. The current LSB testing
doesn’t use user test, we need to add the additional
layer. Need to work with FSB to modify test
procedures.
Peter – there is already a disconnect between user
expectations and ability to produce. Will need to be
extremely clear about what the standard means and what
it doesn’t cover. Need to be clear when we do
presentations.
Janina- Mission and Scope of the Workgroup, Methods
Accessibility has challenged standards process. Can’t
do test exclusively by machine. Also other
breakdowns, Free and Open software cannot control
everything. Need to point to where other tested is
required.
Initially some of the efforts were targeted toward
what FSG has covered. It works on desktop but not
Kernel or Bios. Many things involved with access by
require changes there. No accessibility group in the
Kernel and BIOS workgroups. We need to consider the
entire stack, beginning with boot up screens. Must
cover the boot loader, the current boot loader is less
accessible that the prior version in some way. We
need to document these issues and advocate with the
other groups to get changes made.
Source is open but it takes someone’s time to make
changes, test and coordinate with the Kernel
workgroup. Many of our participants are from the
Gnome and KDE environments. These are not accessible
for many users. It’s complicated, whether it’s
console or desktop, there are many environments.
Need to make it easy for the developers to make the
application accessible and compatible with assistive
technologies. There are many legacy environments that
won’t get adapted for accessibility, will deal with in
other ways.
Blind users- Braille users, Emacs, speech. Most are
using hardware speech but we now have software speech
thanks for some of the participants. If you use
software, some issues will run multiple speech
applications. May have to use one at a time. We’ll
talk about these issues this week. We have breakout
groups around them. We need to come up with
mechanisms that allow the user to move smoothly
between environments. We’re not here to solve all
the problems of the Linux audio environment, just to
identify the problems so that we can pass it on to the
Audio developer/maintainers. We want our AT to work
but we also want to use audio streams, play audio, and
edit multiple streams. Accessibility adds additional
problems to those already in Audio.
You are here because you are a success. There is a
dream and a vision that goes beyond what we have
achieved today. We want this workshop to make the
decisions, commitments and compromises to enable this
vision. Some testing will be in the standards.
Others will have to be recommendations for manual
testing. No one person can do all that needs to be
done.
We may need to concede a few things. We need to look
at what we are doing and see if it is because it is
the way we have already done or whether it is the best
way. Braille groups have agreed to make parts of
there code to a GPL. We need the code to be open and
available to be built into other products.
We have 3 Sub-areas. When we return from lunch, we
will dive into the Keyboard. It is the area that will
likely be standardized first. It will be prior work
on Xwindows. We will hear from Earl Johnson who leads
that area. He is unable to attend but will
audio-conference with us. This area will serve as a
model for how we can proceed in the other areas.
To determine whether a particular interface is usable
by a group with specific requirements. It takes some
expertise to put together the tests for this area. We
have some specific proposals for a standard in the
Keyboard area.
The Second area will take much of tomorrow and some of
Thursday. AT-SPI assistive technology service provider
interface. We hope to achieve a clear understanding of
how we can all agree to and that will fit user needs.
We have multiple graphic interfaces which have their
own libraries and toolkits. We need a spec that every
one can use and that is robust enough to fill the
needs of all users.
The Third area is I/O – covers several areas. It has
not started yet. We have the people here who can do
this. We need the environment to work with
Work in the BIOS and Kernel. We have breakout on BIOS
and Kernel. We need to see what is needed to make
accessibility work during boot process and in the
console. Must work with the kinds for the
applications that run in the console environment but
still work in GUIs. Will work when it’s called on in
the GUI environment. The area needs a group leader.
We will look at Braille and audio issues. We need
text to speech that can work in many languages. We
won’t design them but we’ll talk about the
requirements for screen readers and Braille devices.
The audio folks will talk about the broader audio
environment- requirement of Jack or other
audio-server.
We have charter documents on the website a11y.org.
Please look at these documents to see the Scope and
mission of the workgroup.
Peter- to what extent is it within scope to define
Keyboard shortcuts for widgets. These are some of the
things that vary between Linux versions. And are
frustrating to blind users.
Bill- For the short term we have been staying away
from application behavior and the Desktop behavior is
similar. Providing a consistent user environment is
important but difficult.
These are concerns of the broader standards groups.
The W3C is looking at the keyboard shortcut issues.
Al Gilman- the protocols and formats working group in
W3C WAI. We are working on a roadmap to interaction.
Keyboard model or device independent to keyboard
input. As you build a keyboard capability in a user
environment, can we get the definitions to be as
device independent as possible. In human testing,
how do we organize user evaluation.
Peter- I agree it is out of scope, not for 1.0 but it
needs a standard. It is something that is being
worked on at opendesktop. It falls with in our area
and we should make a tbd in the plan.
Olaf- in KDE keyboard bindings are user definable. We
c
Aaron- the FSG is interested in standardizing de facto
standards. It include how the keyboard not just the
bindings. What could happen, how do we create a
process of communication to make the de facto
standards happen? In standards, we want to assign
these to standards area as early as possible and keep
in group as long as possible
Janina- good area to discuss and make concessions. It
Alt Tab or Shift Tab, has a standard be arrived at –
Or technology may change faster than standards but
people don’t change that fast. The human needs are
not going to change. If we can define our
requirements for what human needs are, we should be
able to move forward.
Accessibility means the standard interface is not all
that is needed by many users. Al talked about device
independence, we are not just talking about computers
in offices, and we are also talking about washing
machines, remote controls, and thermostat. We will
talk about Embedded Linux which is being built into
these devices. We have representatives for other
standards groups- Al with W3C and INCITS V2. We will
see if we want to use some of there standards as part
of our effort. We may also need to give them
comments. We can put out requirements. Daisy
Consortium – st
Al- Do you see the scope as working in the user
interface layer of open software. At the 40,000 foot
level there should be a model that allow the client
software to deliver a user interface that is usable
for each users. There is burden on the server side to
support the right kind of model. If html is delivered
to a browser, it needs the features to support the
interface wanted by the user. Will the scope include
servers?
Bill- We’re touching on issues of content
accessibility there. We’d be doing our end users a
disservice by going there now. Historically, the
model control looks like the ideal solution but where
do you get your model from. There lots of small model
in UI, each widget has a small model. The interface
designer has decided on how to breakdown a view.
Mark- representing the embedded space, we need to look
at this as a two-step process. Lets get parity in
desktop for blind users. Next is trying to optimize.
In Model/View/Control, you care about content and
about the view. You can throw out the way you
interact with the data. I want to navigate a document
in the same way as other users. There is a lot in
semantics and being able to collaborate with sighted
peers.
Peter- I’m not saying we discuss this year or in V
1.0, we need to create a place marker for it.
Al- everyone one wants to have a view that is as close
to that used by other workers. In W3C, we’ve learned
some things about peoples needs; we are trying to get
things models. A lot of our effort in the W3C is on
beating up on authors, it has to be in the content.
It’s a stretch.
Peter- a procedural suggestion, can we make time at
lunch or dinner for demos? I have something to demo
and would like to see the current Qt.
Tomas- I understand what Bill said but as long as we
want to make accessibility sustainable, we need to
continue to push for separation of content and format.
Lunch
Keyboard
Xkb
StickyKeys
RepeatKeys
MouseKeys
SlowKeys – trouble hitting a single key, have to press
and hold before accepted
BounceKeys- set a timer, ignore a key if x seconds
after same key pressed
SerialKeys- use input through serial port
ToggleKeys- audio indicator for state of modifier keys
Mike Paciello- Filterkeys?
Wally – Filterkeys is what Microsoft calls Slowkeys
and Bouncekeys
Audience for this is the person writing the testing
specification.
- Identify mature features that represent mature
features
- Identify existing API: XKB xserver, AccessX –
workstation features to support xkb
Functional specification:
Configuration and setting requirements” enumerates the
features and associated controls, configurability and
minimum ranges that must be exposed via a user
interface.
End user Notification, keyboard invocation and mouse
emulation requirements
Feature behavior requirements.
Keyboard Access API
Subset of XKB
- determined by identifying those portions of
What still needs to be done?
- Bill has looked though code
- Provide sufficient detail to enable ABI test
assertions to be written
- Develop a glossary that describes the meaning of
unclear requirement
Open Questions and concerns
-What is required of an FSG spec?
-who writes the tests for the keyboard access API? (
we could write or find someone )
-will those specs be accepted by FSG without having
the tests written
-Are pre-existing implementations across most Linux
offerings always a prerequisite for acceptance?
Janina- We are experts in accessibility but might not
write the best test. We may need to find people with
those skills.
Bill- we signed up to do the spec, not tests
Earl
Will- just specify that a visual or audio is required
but not completely specify the interface.
Stuart-
Will- manual tests are okay
Peter- if we are going as far as saying some method to
initiate, we should be able to specify that the
pressing the shift key five times.
Bill- that’s okay, a few bootstrap commands are okay
Al- test generation is the way to go. It sounds that
you can do a machine check list, you can see what the
UI saw and then create a subset for manual
verification. There are people the standards world,
who understand that multiple outputs are needed for
each interface object- sound, Braille label.
Will- what if you are creating a PDA for blind people?
We have to create the spec so that that case will
comply. Should show what to do if there is no GUI
interface.
Stuart- who is going to make sure this gets written
and done?
Mike P- there are people in companies who understand
the needs and are interested in doing the work.
Doug- have looked at automating this, NIST people are
interested in creating tests. As we go forward we can
coordinate with NIST.
Janina-
Mike- I know that Gnome has this, does KDE support XKB
Olaf- AccessX has been in KDE since 3.2, the exact
Jonathan- Red Hat ships the Gnome XKB with it
Marco - Suse uses KDE so it supports it.
Bill- xkb is on by default in the Red Hat and Suse
distributions.
Bill Haneman
Keyboard testing
Why do we make the functional specification so
generic? We didn’t want to specify the user interface
since we don’t have a single interface in all
versions. The interface is one way the distributions
differentiate themselves.
To turn into regression tests, someone will have to
write a set of assertions that are specific to that
version’s interface. This may be new ground for FSG
to make it possible to use the generic specification.
Manual test
There will be some automated test but will need to be
specific to each distribution.
Assertions that are conditional- if a mouse if
provided, a keyboard alternative must be provided
also.
Why Generic-
- KDE, Gnome, etc have different Uis
- Existing Uis pull in different dependencies
- Specifying UI could slow innovation
- The spec is a minimum standard, not an attempt to
create ideal
SlowKeys
Don’t specify slider vs. combo box
Al- we want to track the development of HFES 200, they
may be creating a standard that covers that.
Action item – Al will talk to HFES 200 about
participation
Al- the xforms variable types have a variable type.
This should be a duration.
Bill- we could leverage the definitions that xforms
creates, good
Someone will take the generic assertions and turn them
into a set of regression tests. A question for Stuart
– we have identified a piece of testing, there is a
gap between what we specify and what the test engineer
would. E.g. user needs to be able to turn on
StickyKeys – regression test for specific OS-
assertion: move slide to x value.
Stuart- might be able to write the assertions so they
are parameterized. Use the fubar widget to set the
slider.
D
? one of the techniques were using is in DocBook we
have different sections for each use case. We could
keep them together, it will facilitate maintenance.
Bill- we can create of assertions that
What do we need before sending to FSG?
George- need a binary test suite.
Bill- so we need to go back to the FSG and explain
that we can do the specs but will need more resources
for testing. How should we document the generic test
so that we can give it to someone to write?
Peter Korn demo- Adobe has been working on adding
AT-SPI support for the Acrobat reader.
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com
More information about the Accessibility
mailing list