[Accessibility] Rough draft minutes (plain text) April 27 2005

[Bill Haneman]

Minutes attached, comments, corrections, and clarifications welcome.  I =

missed a couple of attendees, so please remind me who I missed accidentally.

thanks!

Bill
-------------- next part --------------
minutes April 27

present:
Gunnar Schmidt =3D g
Olaf Schmidt =3D o
Bill Haneman =3D b
Bill LaPlante =

George Kraft =3D gk
Cathy Laws =3D c
Janina Sajka =3D j
Andreas Gonzales =3D a

=3D=3D=3D=3D

Catherine Laws - proposal for document api gap analysis/discussion subgroup.

b: were you able to read my reply today?
c: yes

c: why did we bring this proposal? grew out of experience with homepage
reader, using msaa and at-spi, as well as in development of homepage reader
with different apps. proposal is trying to address several major issues:

1) effective navigation of structured content w/o dropping to dom level
2) collecting lots of information in a performant manner

since initially posting the proposal, K has done more API study
compare/contrast.

b: is this the place for this at all?  It would seem to be out of scope for
FSG activities.

o: in general, yes, this is out of scope, since FSG reuses existing
technologies.  But where would you do this instead? OMG? =


b: not omg. =


j: you're bringing up two separate issues. with limited time to talk about
this, let's get the discussion going.

b: I'm concerned about dilution of effort.

o: If it's in scope, should we worry about that?  The main question is, what
is the goal of this comparison?  It was proposed to create a cross-platform
API, and this is related to our goals with respect to at-spi.  If there are
things missing in at-spi, we need to talk about that, and the comparison is
important.  If the goal is to create yet another api, then I think it's
possibly not so clearly positive.

j: either way it's an important documentation activity.

gk: would this be appropriate on at-spi list?

o: in Qt they are supporting mac a11y and msaa as well as at-spi

and: this is a critical issue for adobe - we support all apis now, need good
cross-support for document a11y. linux api is probably the one I would choo=
se
if I had to pick one.  There are needs unmet with respect to documents, in
particular xhtml, dhtml.  In addition to cathy's comparison, we (adobe) wro=
te
a paper recently (ACM) about this cross-platform API, "Platform Independent
Accessibilty API".

b: documentation explanation issue here, probably.  There are not detailed
examples, for instance, of how existing at-spi interfaces are intended to w=
ork
in a complex document scenario.

j: wondering if in the process we want to bless any of the w3c standards,
markup, etc.

k: a lot of it is related to use cases, as to how to address w3c user agent
a11y guidelines, how to address performance issues.

b: would like to see example documents/use-case documents.

c: html is where my expertise is, so HTML is probably a good example format.

Will have this discussion on at-spi list, can be subscribed to via the
a11y.org webpage.

b: too bad apple didn't come closer to adopting at-spi's IDL.

j: maybe this process will help.  no matter what platform we use, we need t=
o share documents, that's
fundamental.  Docs on a11y document specification should not be proprietary,
surely.

b: fsg has an advantage here in a way, since we can go via the JTC1 route,
which gets this out as an international formal standard, which I gather you=
'd
ultimately like to have.  It may in fact be SC35 (?) that's the right
location, but there may be some additional complications.

j: we might pull some of the OOo folks in.

a: it would be better to have a more powerful api in at the core, with
adapters to other apis such as MSAA.

j: we have multiple open source screenreaders for linux now.

Elections/nominations process:  George...

need to follow up with Earl before finalizing.  Will straighten out next we=
ek.

Bill L talked about an sc35 meeting in Madison in July.

Janina will discuss sheffield meeting next week.

adjourned 19:03 UTC.