|
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
|
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
