Actually, Since the change rate on the diagram is high enough right now
and attachments don't make it through the listserv, it's probably best
to keep the discussion off the lists for now so Brian doesn't have to
manage publication via a web page.
Pete Brunet wrote:
>I'm a little surprised to see this discussion taking place on an
IAccessible2 mailing list...
That was my error. The discussion was within a smaller group in prep
for wider distribution on the a11y list and I inadvertently posted it
to the IA2 list. So all - please post replies to the a11y list.
Peter Korn wrote:
Hi all,
FYI - I'm the original author of this thread of GNOME accessibility
diagrams. I agree they should be in an editable & standard
document that can be edited from our own tools (as opposed to something
like Adobe Illustrator).
Alex - the main thing Mozilla family applications have in common is
XUL. Like most GNOME apps have GTK+ in common (or OOo family apps have
UNO). nsAccessible is the core accessibility object exposed by XUL on
UNIX. Like the current D-Bus Java stack, there should probably be 5
layers in the Mozilla stack (with atk-bridge at the bottom).
Brian - your diagram suggests but doesn't make clear that GOK &
Orca (and Dasher and...) also communicate to the atk-bridge in the
Mozilla & OOo stacks, as well as those in the Java & GNOME
stacks.
Also, I think it is a mistake to loose the AT support libraries from
the diagram. Things like TTS and Braille play a very important role in
the accessibility picture. I suggest also keeping tools in the
picture. The current emphasis on authoring tool accessibility support
(and the related developer tool accessibility support) is very
appropriate. Tools have a big impact on helping understand and debug
accessibility problems - whether they are API level tools like
accerciser, or features in developer tools like NetBeans assistance for
Java accessibility (or the related work IBM has done in Eclipse), or
features in authoring tools to help ensure the appropriate
accessibility metadata is in the document.
Perhaps that might be part of an "expanded" version of the document
-> one that simplifies the IPC portion of the picture and then
emphasizes developer & author tool support.
Regards,
Peter
P.S. I'm a little surprised to see this discussion taking place on an
IAccessible2 mailing list...
On 12/7/2010 8:13 AM, Alexander Surkov wrote:
Hi. I don't clearly understand the meaning of "Mozilla" and
"nsAccessible" on those diagrams. Is "Mozilla" a Mozilla applications
or Gecko engine that is used to run Mozilla applications? If it's a
Gecko then it's not very correct to separate "nsAccessible" (what I
assume is an accessibility implementation in Gecko) from Gecko because
accessibility implementation is part of Gecko. (Btw, I don't like a
term "nsAccessible" since Gecko moves away from "ns" prefix usage.)
Thank you.
Alex.
On Tue, Dec 7, 2010 at 11:47 PM, Pete Brunet <[email protected]> wrote:
The diagram is in pretty good shape - though Joanmarie has a lot of good
comments. The primary thing that struck me was the incorrectness of the
thin lines between AT Layer and Operating System Layer. Perhaps you could
put something like a } symbol (rotated two different ways) on each end of
the many to many relationship - or use UML's 0..* at each end of a single
thin line.
Brian Cragun wrote:
Hi,
We've been working to update the Gnome Accessibility Project Architecture
diagram that has been used for years. The original has disappeared, and we
have used the opportunity to use Open Office to create a new diagram that
resolves some of the contrast notation issues with the original version.
The notation is intended to divide into layer functions, as well as
distinguish those parts that are Gnome, Java, and application based.
1) In addition to colors, we've used an appended superscript to identify
Gnome parts (g) and Java parts (j).
2) We've added lines to connect components to make the stacks absolutely
clear. In the original diagram, must is inferred simply by proximity.
3) We've indicated the relationship between the layers with their own lines
between conceptual layers.
4) WeI have no idea what to do with the Tools layer. It's not dependent on
the apps layer. Rather, we think its just conceptually a different kind of
app.
Here is a reference link to the original diagram:
http://www.linuxfoundation.org/en/Accessibility/Minutes/Minutes20100907#Discussion_of_Illustrations_and_Their_Descriptors
Your input is invited:
David Bolter [email protected] to review the Mozilla part,
Malte Timmerman [email protected] to review the OpenOffice part,
and
Carolyn MacLeod [email protected] to review the Eclipse part
Regards,
Brian
Brian Cragun
IBM AbilityLab Consultant
Human Ability & Accessibility Center
www.ibm.com/able & w3.ibm.com/able
W:(720)-663-2801 H:(507)288-2437
--
Pete Brunet
a11ysoft - Accessibility Architecture and Development
(512) 238-6967 (work), (512) 689-4155 (cell)
Skype: pete.brunet
IM: ptbrunet (AOL, Google), [email protected] (MSN)
http://www.a11ysoft.com/about/
Ionosphere: WS4G
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
--
Peter
Korn | Accessibility Principal
Phone: +1 650
5069522
500 Oracle Parkway | Redwood City, CA 94065
 Oracle
is committed to developing practices and products that help protect the
environment
|
