[Accessibility] A11y Teleconference minutes, Wednesday July 27

Wed Aug 3 09:14:40 PDT 2005

July 27, 2005

Gunnar Schmidt
Olaf Schmidt
“Willy” Wilcox
Janina Sajka
John Goldthwaite
George Kraft
Larry Weiss
Pete Brunet
Cathy Laws
Randy Horwitz
Peter Korn
Earl Johnson

No questions on minutes.  7/20/05 minutes
approved as submitted by George Kraft.  We will
retain audio on the AT-SPI discussion from last
week for reference.  John has not completed the
last half of the notes from 7/13.  Frank needs to
complete the minutes from June 23; he’s getting
married and has a new job so hasn’t had time to
complete it yet. 			

Notes from the JTC1 accessibility meeting are
starting to appear on the NCITS website.  Janina
will review them and prepare a report for the
group.  Janina finished round one of the
accessibility disclaimer statement on what it
means to certify to an FSG accessibility standard
last week.  Janina requested that Janet Sun
schedule a meeting but Jim Zemlin is now on his
honeymoon so that is delayed pending his return. 

Willy- no one else from accessibility at the OLS
Linux conference in Ottawa.  Attended the kernel
summit so could not report on the OLS desktop
sessions.  Did not see any discussion of
accessibility during OLS so this indicates we
have a lot of work to do. 
Janina- we couldn’t get there this year, will
work on future conference.
Willy- when I get the call for papers for OLS for
next year, I will forward it to the accessibility
list.  This is a developers conference so it is a
good place to win people’s hearts and minds.
George- the LSB normally gets a hotel suite
during OLS for working sessions.  Can get
together there for meetings and have a presence
at the conference.
Janina- Will it be in Ottawa next year?
Willy - It has been in Ottawa for the last seven
years so its unlikely to change.		
Janina- we will plan on attending next year. If
we had our AT/SPI and Adoc discussions to the
point they are now, I am sure we would have
wanted to attend. An in person would move us
forward more quickly.  Are there other parts of
the calendar we should look at for conferences
where open source developers attend?  If people
have suggestions, please post them.
Olaf - there is the KDE conference in a few
weeks. We will have a focus on accessibility
there. Don’t know if other members of the group
plan to attend.	
Janina- we had a big presence there last year
thanks to you, Olaf and at GUADEC but we can’t do
it every year.
Olaf- there was someone who tried to follow up
meeting to the accessibility forum at LinuxTag,
it was mainly a German event but a good
opportunity to meet people. It wasn’t so much a
developer event like last year but I don’t think
we need to do one every year.
Willy - I will be at the UK Unix group meeting in
Swansea next week.		

Janina- Earl, status on keyboard spec, should we
go with a review here?
Earl- only one potentially controversial point so
far in preparing the two documents.  0.61 had
functional specs with desciptions of how each of
the features work and there are place holders for
test assertions for insuring each one of the
functionalities called for in the functional
spec.  There is a place holder for XKB ABI, which
will be an example of implementation of the spec.
 What we are planing on putting out in this
review is the functional specification 0.71 and
broken out into a separate document the test
assertions for validating the functional
specifications.  XKB abi spec will come later;
all it is a subset of what is available on XKB.
Will hold there so that Bill can focus on AT/SPI.
Only controversial part was XKB supports a
function called sound sentry - which maps any
system bell event to a flashing screen or
flashing icon. There was a lot of discussion in
the group, since this is keyboard accessibility
and this is visual bell which is not keyboard
oriented, we made a decision to pull it out.  We
put into the RFC for others to review and
comment, we would like some feedback on that. 
Other than that we just need test assertions. 
Unless there is feedback, the functional spec and
test assertions will move from the review phase
to the final phase. We’d like to turn it into
final. Not clear to us, is the next public review
sufficient?  Should it include just the people
that were in Hawaii - what are follow on steps
for the review? This could be part of our
discussion with the FSG board.
George- normally LSB conducted a 30 day public
review and sent to as many sites as possible for
review, Linux weekly news, the website, emailed
to LSB distribution lists. When 30 day review
done and all defects were closed, then the FSG
has a form to submit to the board. We’re at this
level, we;ve closed all action items against it,
we’d like the board to endorse it and give it an
official version number. 
Earl- LSB was pretty broad on its request for
comment.
George- yes, we sent it to about 600 people plus
Linux Weekly News.
Earl- should we use the same list?  Should we go
to the various disability newsgroups and list
serves?
Janina- there is political value in casting a
wide net, announcing as widely that we have
something that is closing.  Just promoting the
fact that accessibility is being addressed in
standards that relate to open source environments
and Linux, I think that’s valuable to let users
and developers know.  Get people to speak up but
also to let people know that accessibility is
being addressed.  Even if we don’t get a lot of
comment, its good to get exposure. We should
think the process through. When we go public with
this, we should say something about what the
process is going to be from here; here is the
draft, we’re accepting comments at this address,
when comments close, here is what happens after
that, etc. So that the expectations of what is
going on are fairly clearly stated. And that is
something that we will want to follow on the next
spec that we want to move forward as an
accessibility spec. Maybe the visual bell, could
be a simple one, AT/SPI would be a bigger deal. 
Do we want to wait to get some finality about our
disclaimer statement on certification? 
John- It make since to take the visual bell out
of the keyboard spec but is there somewhere
specific to put the visual bell so that it
doesn’t get lost?
Peter- Maybe it needs its own category, a 
miscellaneous desktop category.  Another thing
people have asked for is closed caption for
multimedia.  I’m not suggesting we specify that
now or even soon but that seems like something
that would fit in with that category.
Earl- the reality is that the keyboard access
support of XKB is a subset, the working group is
thinking that developers aren’t going to... [
Recording ended here at 26:30, may be a problem
do to Janina dropping off line ]		

Earl- connection is just functionality.  The code
is separate.  Mark has pointed out that the
functionality has gone far beyond Access DOS. 
Our limitations, got to be something implemented
across a number of distributions, then you
develop specification. We are limited by what is
supported.  In the case of XKB if we wanted to
add functionality, XKB would have to change, ...
what have to get that added to the specification.
 That would take far longer that the keyboard
spec has taken.

Olaf- can it be implement on other computers?
Earl- tried to write it from an implementation
perspective.  
Olaf- if someone would develop a small device ..
Running on the frame buffer, but no X running
would they be expected to implement the visual
bell?
Earl- hypotheticly- doing nothing with bell
sounding functionality where XKB does. Risk that
if we put visual bell in, and they do a different
implementation, they 
Olaf- would it make adoption of the standard more
difficult if the visual bell were in there? 
Similar keystrokes, would Apple to follow the
spec.
Earl- can think of only one thing that is not
present in those other implementations.  We
mention the other linux distro but, looked across
multiple platforms, functionality is present in
all except for bouncekey function.  The spec
should be - other platforms are living up to the
spec.

Janina- I’m back, I was asking how much we need
to include with the spec when we send it out for
comment.  Will want something about the process
plus our disclaimer statement.
Earl- I don’t think they need to be connected.
Janina- that makes it easier
Earl- we want to have the disclaimer done before
the AT SPI spec is done.
Janina- the only critical thing is to have it
complete before the final spec to avoid
confusion.
Earl- 	We’re ready to go. I’ve got to thank
George for helping out.  I’ve been using HTML but
have been dependent on George to get it put onto
the site correctly.  There were some cut and
paste errors where some of the cut didn’t get
removed, need to fix.  The keyboard access group
should decide what we want in our emailing.  Want
to connect with you to discuss it.
Janina- lets set up a time to talk about.  We’ll
want to send the draft to the full group for
review and get a list of sites for distribution. 
We can do that before the next call.  Good,
congratulation, this is exciting.  Thank you
Earl.

Janina- we don’t have Bill to discuss AT-SPI ADOC
use cases.  We had a useful round when Rich
posted a whole list of questions to the list. 
Should we look for a time to discuss this.  Asked
Rich if he could join us but his is a bad hour
for him.  I will send Bill a note to see what
other possible times are.  If we need to move
that forward with a separate meeting.  Will
document those meetings with audio as well. 
Catherine?
Catherine- I’ve been traveling and on vacation so
haven’t had time to review all the comments. 
Will look at that when I get back and reply by
Monday.
Janina- not looking for a lot with that but just
setting up the appropriate process.
Catherine- if anyone has any general comments on
how to organize the document, please do so.

Janina- didn’t think we’d have a final draft this
week on ___, had some comments from George on
being , crafting a statement on accessibility, on
achieving it. 

Olaf- main question, statement by this group and
one by KDE group.  How detailed in statement by
this group.  Gnome and KDE teams, what we are
offering.  Is short paragraph suggested by George
enough?  Would be helpful to describe our
agreement on AT SPI that we developed in Hawaii. 
I would like to get that into words.
Peter- we’d talked about a statement, the ATK is
a reference implementation but spec was to be
implemented by others.
When is KDE conference? It would be good the have
this done before then.
Olaf- 25th of August
Peter- good, we have some time, if we could
announce it then or shortly before.
Olaf- language the desktop group has used, used
GNOME implying standardizing on GNOME
Peter- don’t need to say anything about GNOME in
the statement,... first release to spec.
Olaf- need to describe the idea of having several
versions of spec, release two specs at the same
time - IDL, IDL transformer, how to apply to
RPC’s 
Janina- you did fairly well, others will support
the standards, what is missing- a general
statement of principles.  Standardizing on
messaging , more mature and less mature
implementation, we intend interoperability, take
a piece from GNOME, piece ... put that up top and
here is how its coming to happen, It is not
neccessary to pick a platform,    Promised to
work on this some.

Willy- should say that is harmful to pick one.
Put the point of view across that it is harmful
to standardize on one
Peter- I think that makes sense.
Janina- Okay, allow communities to meet it in
their own way.
Olaf- is there a native speaker of English that
can work on it.
Janina- yes, even if you are native speaker, it
is hard to get it in the first draft but you are
doing pretty good.  We’ll have the same three
agenda items for next week.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 