[Accessibility] Final Minutes, A11y On 27 April
janina at freestandards.org
Tue May 17 20:06:09 PDT 2005
Janina Sajka Phone: +1.202.494.7040
Partner, Capital Accessibility LLC http://www.CapitalAccessibility.Com
Chair, Accessibility Workgroup Free Standards Group (FSG)
janina at freestandards.org http://a11y.org
If Linux can't solve your computing problem, you need a different problem.
-------------- next part --------------
minutes April 27, 2005
Gunnar Schmidt = gs
Olaf Schmidt = os
Bill Haneman = bh
Bill LaPlant = bl
George Kraft = gk
Cathy Laws = cl
Pete Brunet = pb
Janina Sajka = js
Andreas Gonzales = ag
The minutes from April 6 were approved as submitted.
Catherine Laws of IBM has joined our meeting with a proposed standardization
task from IBM for an "accessible document" specification (adoc).
Catherine Laws - proposal for document api gap analysis/discussion subgroup.
bh: were you able to read my reply today?
cl: 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:
how can we nav struct content efficiently and effectively
how collect lots of info, large page, complex structs, list of links,
headings, without neg impact on performance
*Support efficient navigation of content structures for users
* Collect document data such as link lists, <hX> headers, table
* structures, etc., without evident impact on system performance
* Support multiple OS platforms and client environments
since initially posting the proposal, CL has dbegun creating a document
comparing and contrasting existing api approaches. This doc will be posted to
our web site.
bh: is this the place for this at all? It would seem to be out of scope for
GK: in general, yes, this is out of scope, since FSG reuses existing
technologies. But where would you do this instead? OMG?
bh: not omg.
OS: We should consider the goal. We've already agreed on a standard AT-SPI
approach that could be cross platform. So, if there are things that would be
missing to support document accessibility, we need to know that sooner, not
later. However, we need to make sure this isn't a competing specification, but
a complimentary one.
bh: I'm concerned about a dilution of effort.
js: iThere are two separate issues, and we have limited time today. Let's move
the discussion forward and accept that the project can be staffed if we decide
it is in scope and should be taken on. either way it's an important documentation activity.
gk: would this be appropriate on at-spi list?
os: in Qt they are supporting mac a11y and msaa as well as at-spi
ag: 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 choose
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) wrote
a paper recently (ACM) about this cross-platform API, "Platform Independent
Accessibilty API" that I will be presenting at the upcoming WWW conference in
bh: iPerhaps there's a documentation and explanation issue here, probably. There are not detailed
examples, for instance, of how existing at-spi interfaces are intended to work
in a complex document scenario.
js: I'm wondering if in the process we want to bless any of the w3c standards,
cl: a lot of it is related to use cases, as to how to address w3c user agent
a11y guidelines, how to address performance issues.
bh: I would like to see example documents/use-case documents.
cl: html is where my expertise is, so HTML is probably a good example format.
GK: Should we have this discussion on at-spi list, can be subscribed to via the
bh: too bad apple didn't come closer to adopting at-spi's IDL.
js: maybe this process will help. no matter what platform we use, we need to share documents, that's
fundamental. Docs on a11y document specification should not be proprietary,
bl: 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.
js: we might pull some of the OOo folks in.
ag: it would be ver helpful to have a more powerful api at the core, with
adapters to other apis such as MSAA.
Elections/nominations process: George...
need to follow up with Earl before finalizing. Will straighten out next week.
bl: L talked about an sc35 meeting in Madison in July. FSG members can attend.
Janina will discuss the ISO sheffield meeting next week.
adjourned 19:03 UTC.
More information about the Accessibility