[Accessibility] Rough draft minutes (plain text) April 27 2005
Bill.Haneman at Sun.COM
Wed Apr 27 12:07:37 PDT 2005
Minutes attached, comments, corrections, and clarifications welcome. I =
missed a couple of attendees, so please remind me who I missed accidentally.
-------------- next part --------------
minutes April 27
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
Catherine Laws - proposal for document api gap analysis/discussion subgroup.
b: were you able to read my reply today?
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
b: is this the place for this at all? It would seem to be out of scope for
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=
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=
a paper recently (ACM) about this cross-platform API, "Platform Independent
b: documentation explanation issue here, probably. There are not detailed
examples, for instance, of how existing at-spi interfaces are intended to w=
in a complex document scenario.
j: wondering if in the process we want to bless any of the w3c standards,
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
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,
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=
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=
Bill L talked about an sc35 meeting in Madison in July.
Janina will discuss sheffield meeting next week.
adjourned 19:03 UTC.
More information about the Accessibility