12952 - Browser does not expose itself to ActiveAccessibility

Status: VERIFIED FIXED

(Core :: XUL, enhancement, P1)

Description

[dogboy]

On the Windows platform, the browser does not expose its UI and contents to
Microsoft Active Accessibility.  This means that a plethora of accessibility
aids (screen readers, magnifiers, etc.) will not work with Mozilla!

To reproduce, use the 'Inspect Objects' tool that comes with the Microsoft
Active Accessibility SDK (http://www.microsoft.com/enable/msaa/msaasdk.htm).
Moving the mouse around Mozilla will only emit information about the entire
client area.  Even menu items are not exposed, probably because they
are 'homegrown'.

Use 'Inspect Objects' on Internet Explorer to see all the information that it
generates...

Comment 1

[davidm]

Sounds like a XPToolkit problem in that all the widgets will have to provide
hooks.

Comment 2

[Peter Trudelle]

I don't think we're going to have time for this in the current release. Putting
on the Help Wanted radar

Comment 3

[Peter Trudelle]

resolving as later

Comment 4

[leger]

Resetting QA contact from leger.

Comment 5

[Peter Trudelle]

reopening all latered bugs

Comment 6

[Peter Trudelle]

Moving all latered bugs to M20 as ordered by project manager.  Although these 
bugs are now open, assigned and targetted, XPToolkit has no plans to 
fix/implement them in the current release cycle, if ever.

Comment 7

[Peter Trudelle]

Mass move of all M20 bugs to M30.

Comment 8

[Peter Trudelle]

Mass move of M20 bugs to M30

Comment 9

[Garth Wallace]

This recently appeared on n.p.m.wishlist:

===
   From: i.don'[e-mail]
   Newsgroups: netscape.public.mozilla.wishlist
   Subject: accessability of Mozilla
   Date: 10 May 2000 02:19:55 GMT
   Organization: University of Denver
   Message-ID: <8fah0b$[e-mail]>

Greetings all:
I am a blind computer user  and use a screen reading package in order to 
gain access to the computer.  This program takes visual screen 
information and translates it into auditory information.  The OS I use is 
Windows 95.  Currently, MSIE is the only web browser that is usable with 
my special software.  I downloaded Mozilla this afternoon to see how well 
it would work with my screen reading software, and I was not impressed.  
To start out, it is very possible that I am missing features that are 
already in the product, and just don't know how to get to them, if so 
please let me know.  
     First off, the Windows version of Mozilla appears to use nothing but 
custom controls.  In order for a product to work well with screen reading 
or other access software, it should either use standard windows controls 
or the MSAA (Microsoft Active Accessability) APIs.  MSAA is specifically 
designed so that an application can use nonstandard controls, yet still 
be accessable.  From what I saw, Mozilla doesn't make any effort to use 
MSAA, again please let me know if I am wrong.  If this is a feature that 
is lacking, I think it would help considerably to add this feature.  It 
would expand the Mozilla user community because at this point, as I said 
MSIE is the only browser that provides any kind of accessability features 
under the Windows platform and it would be nice to have a choice in 
browsers.  
     Another use of MSAA is to present an alternative page view for those 
using access technology.  MSAA allows access technology to buffer the 
actual HTML of a web page and to convert the page into a readable form.  
Again, I saw no evidence of this feature in Mozilla, and it would be a 
good feature to add.  If I have missed anything please feel free to let 
me know by posting to this group.
Thanks.
Ryan

===

To sum up, unless someone plans to build in a full audio-browsing component,
this is very important for accessibility. At this rate, blind users will be
simply unable to use Mozilla (and any Mozilla-derived tools) on Windows PCs.

Comment 10

[Peter Trudelle]

cc Aaron Leventhal

Comment 11

[Peter Trudelle]

Mass-moving all M20-M30 XPToolkit bugs to Future

Comment 12

[Garth Wallace]

Just wanted to add that fixing this could help Mozilla adhere to the User Agent
Accessibility Guidelines (http://www.w3.org/TR/UAAG/), a W3C Proposed
Reccommendation.

Comment 13

[Matthew T (active 1999-2002)]

*** Bug 45458 has been marked as a duplicate of this bug. ***

Comment 14

[Tomer Brisker]

*** Bug 47159 has been marked as a duplicate of this bug. ***

Comment 15

[Aaron Leventhal]

Okay, here's the low down scoop, part I:
[Lots of info to follow, some of it rambles]
1. From what I hear from engineers no longer working at Microsoft, no screen 
reader programs actually use MSAA, for many reasons among which are buginess, 
slowness, inconsistency and a poor signal to noise ratio.
2. Another issue is that MSAA only works on the Windows platform. We want 
Mozilla accessibility for all the platforms it runs on right?
3. Sun's Java accessibility works on all platforms where there is Java. They've 
got some easy to undererstand documentation on all of this at:
Good description of Java Accessibility at:
http://java.sun.com/products/jfc/jaccess-1.2/doc/core-api.html 
4. One thing about the accessibility API stuff, is it's a lot of work. It's 
supposed to help with data entry not just speech/braille output. I'm not sure 
why that's useful when the Mozilla UI already supports the W3C DOM.
5. Sun has decided to make Gnome/GTK/StarOffice accessible, probably using 
something similar to MSAA. Sun's offices are near the Netscape offices. When I 
visit this winter to work on Mozilla accessibility, I'll be having a few beers 
with Peter Korn to see where to go from here. Peter and others want a standard 
Linux or Open source Accessibility API that improves on the Sun Java standard. 
There are some old MSAA people that will work together with them. It's all a 
friendly community. We'll have to get KDE to follow this stuff too.
** Anyway, if we're going to follow some kind of Accessibility API, it 
shouldn't be MSAA - it should be whatever the accessibility community comes up 
with. I'll be getting people together in October to talk about it at Closing 
the Gap conference in Minneapolis. Anyone interested in being there? 
www.closingthegap.com.
Cheers -- Aaron

Comment 16

[Adrian]

So, use the Sun's Java accesibility.

Comment 17

[Ryan Shugart]

OK, here are a few comments from me on some of the issues that have been 
brought up here lately.  
First off, the point was made that MSAA isn't actually used in any screen 
readers.  Allow me to correct that right now, MSAA is actually very widely used 
in screen readers.  In fact, Jaws for Windows and Windoweyes, the two leading 
screen readers, both make heavy use of MSAA to get information from the 
application program.  In fact, at this time Internet Explorer is the only 
mainstream web browser that is usable to a screen reader user because it is the 
only web browser that supports MSAA.  
In contrast, not many screen readers that I know of support the Sun Java 
accessability standards.  In fact, Jaws for Windows is the only one I know of 
that has any Java access what so ever, and its java support is rather 
limitted.  
I do also understand the wish for accessability accross all platforms, and I 
realize that MSAA has its many drawbacks, but for now at least it has been 
excepted as sort of the defacto standard.  I can only speak from a Windows 
perspective, as I don't know of any screen readers available for a GUI platform 
under Unix, and only one for the mac.  
I guess to sum this up, please make sure that when you impliment an 
accessability solution into Mozilla, whatever it is, make sure that a wide 
array of current products can support it.  I'd assume all the major screen 
reader vendors will be at Closing the Gap, you might want to meet with them and 
decide based on that how to proceed.  Just my two cents here.

Comment 18

[andrew]

Hi all,

Regarding the Sun accessability, a small problem with the said is:
1.  How well implemented is it on a Windows platform (baring in mind that most 
visually impaired people are using a Windows based screen-reader which supports 
MSAA such as Window-eyes, JFW, Window-Bridge and WinVision, to name a few.
2.  How well rekognised is the Sun accessability standard (by the screenreader 
manufacturers, developers etc), baring in mind that MSAA is used not only in 
internet applications (for example, quite a few other apps use it as well).

Just my small comments, I would be interested in finding out more about this 
situation, though.

Andrew.
P.S.  Does the SUN accessability standard have anything to do with the SUN JAVA 
bridge?

Comment 19

[Aaron Leventhal]

Okay, I like this discussion about MSAA.
* Interesting to hear that people are in fact using MSAA. I've heard that they 
aren't, because there are a lot lot lot of problems with it. I'll try to find 
something that backs that up.
* About Java Accessibility, I don't know what products utilize that either.
* Sun is going to be developing something akin to Java Accessibility for 
Gnome/GTK.
* The reason I am interested in accessibility is to create a self-voicing (and 
refreshable brailling) browser. This is sort skipping the screen reader step 
altogether, like Home Page Reader. I think this will create what users really 
want - a refined, accessible, smooth user experience, in any operating system. 
I don't mean to provoke flames, but if we have a self-voicing cross platform 
Mozilla that inherently supports accessibility through preferences, do we still 
need MSAA? What gain is there at that point? Convince me that I'm wrong and 
I'll help build in whatever way I can. If I am guilty of an illegal thought 
process here, show me with some legit reasoning. I definitely want to move all 
this stuff forward in whatever's the best way.

Comment 20

[Ryan Shugart]

OK, these are some interesting ideas.  I'm not sure which approach is the best, 
I think they both have advantages.  
     One the one side, tying Mozilla into a preexisting screen reader through 
MSAA would have the advantage of presenting the user with an environemnt and 
interface they are familiar with, namely that of the screen reader.  It would 
also deal with the issues of how the page is presented, and how speech is 
generated.  
     On the other hand, however, screen readers are generally very expensive, 
and screen readers that do well with internet browsing are among the most 
expensive.  A well-done selfvoicing application could do wonders in bringing 
internet access to those who don't have it.  Also you already mentioned the 
advantage of cross platform capabilities.  Here are a few things to consider 
when deciding this question.  These are more just things to think about, if you 
haven't already.
1.  What kind of interface will you use?  In otherwords, will you build ontop 
of the existing Mozilla interface (AKA using keyboard commands and preexisting 
menu options, or designing your own front end interface alltogether?)  I've 
seen both approaches taken, and both can work well if done properly.  If 
Mozilla already has good keyboard support, then there is no reason a speech 
overlay couldn't be put over the existing interface.  
2.  How will you generate speech?  It seems going a little overboard to use 
your own synthesizer designed specifically for Mozilla.  Under Windows, there 
are two main speech synthesizer standards.  SSIL (which I think stands 
for "speech synthesizer interface library) is produced by Freedom Scientific, 
formerly Arkenstone, Incorperated.  It is primarily used for communicating with 
hardware synthesizers, (an external box that plugs into a sereal port, or a ISA 
card that is inserted into the computer.)  There is also SAPI, which is 
Microsoft's standard for software synthesizers, synthesizers that are 
completely software based and use the computer's sound card.  This is what a 
lot of products such as Homepage Reader use to generate there speech.  Again, 
this is speaking from a Windows perspective, I know software synthesizers exist 
for Macintosh and Linux (I'm not sure about the other Unixes.)  Hardware 
synthesizers, of course, are completely cross platform as they generally don't 
require anything besides a sereal port or ISA slot, but they are more expensive 
as well.  If you take the MSAA approach this interface to the synthesizer will 
be done for you.  If you take the self voicing approach, you have to code all 
that in yourself.  However, if you use a preexisting library it shouldn't be 
too hard.  
3.  Often, viewing a particular type of file will require the launching of an 
external viewer or plugin.  At this point, the self-voicing browser goes into 
the background and speech is lossed.  Under the MSAA approach, the focus would 
simply transition to the other application and speech would continue.  I have, 
however, seen this problem delbt with in other self-voicing apps including 
Homepage Reader.  How well this is done depends on the application and screen 
reader in use.  
     As I said, these are just a few things to keep in mind as this process 
progresses.  I'm sure there are other things as well that will come up.  My big 
point here is that both approaches have advantages and disadvantages, and I 
think you just need to be aware of them if you're not already.      

Comment 21

[Aaron Leventhal]

Thanks Ryan for the additional comments.
- I hadn't thought of the external viewer problem. Hmmm...
Basically, for the product I'm doing this for, namely a braille & speech 
notetaker running linux, we'll have to convert MS Word and Acrobat files to 
HTML.
- We already have an XPCOM component that uses the free IBM ViaVoice synthetic 
speech driver. The speech driver could be changed, by whoever wants to do it, 
to use SAPI or Mac speech or whatever. SSIL is definitely in the waste bin of 
software history by now, isn't it?
- I'm planning on altering XBL widgets to do this, so any chrome made with 
Mozilla would be self-voicing if the accessibility switch was turned on. I've 
had some successes with this already. I think the main Mozilla chrome will 
work, and we'll probably also have a special chrome with an optimal keyboard 
and menu spec.
- Perhaps in doing the self voicing, that will give the experience needed to 
get MSAA done easily as well, or at least we'll be able to work with Henter 
Joyce & GW Micro to show them how to access the DOM directly.
At some point we'll have a newsgroup for this stuff.
Cheers - Aaron

Comment 22

[Garth Wallace]

A mozilla-specific approach would have the advantage of making it easier to add 
support for CSS2 aural stylesheets at some later date. I'm not sure if that's 
even possible using MSAA or other systems. However, writing your own 
screenreader is a whole lot of work.

Perhaps we could take the same approach for this as the layout/rendering folks 
did for display: come up with an intermediate API that abstracts away the 
differences between platforms, and write platform-specific backends (MSAA, Mac 
text-to-speech, whatever the heck UNIX screenreaders use).

Comment 23

[Peter Trudelle]

->mozilla0.9/P1, we need to get our accessibility plans straight ASAP.  I like
Garth's proposal of an intermediate API, which I hope could eventually become
the primary accessibility API, since it would need to support a superset of the
functionality needed for any of the backend, platform specific APIs like MSAA.
Would part of this need to be an exposure of the W3C DOM APIs?  I know that JAWS
prefers to use the IE DOM APIs in MS products, and only falls back to using MSAA
when it needs to.  

Comment 24

[Ryan Shugart]

I don't know about Jaws as I don't use it, but I think Windoweyes relys purely 
on MSAA.  This is another reason why the intermediate API sounds like a very 
good idea, in theory, those screen readers that want MSAA can use MSAA, and 
those that want something else can have it as well.  In adition, as new 
versions of MSAA and the like come out, it should be relatively easy to make 
them work with Mozilla.  One small consern I just thought of, and do realize 
I'm not a programmer so this might sound completely stupid, but would there be 
any kind of performance hit on any screen reader that doesn't take the web page 
information dirrectly from the API?  In otherwords, Windoweyes can pull MSAA 
information from IE rather quickly.  However, using this new API, assumming I 
understand what's happening correctly which I very may not, MSAA would pull the 
information from the intermediate API, and then the screen reader pulls the 
information from MSAA, if this is true, how much of a performance hit would 
this make?Just something to think about.    

Comment 25

[Peter Trudelle]

->evaughan, enhancement, cc hyatt, self. Resource constraints necessitate doing
this work in stages. First up: make Gecko accessible for embedding in moz0.9.
Next: make the XPFE chrome accessible for a subsequent milestone.

Comment 26

[Peter Trudelle]

moz0.9.1

Comment 27

[Eric Vaughan]

Here is the first pass at MSAA support. I have supplied a cross platform
nsIAccessible interface that is mapped to MSAA IAccessible. I have partially
implemented <SELECT>, <TABLE>, <TD>, <IMG>, <INPUT>, text.

Enclosed are the diffs for hooking into the system. And a zip file containing
the new accessibility library. On windows you must build with a WINVER >=
0x0500. You can set this in mozilla\config\WIN32.

Comment 28

[Eric Vaughan]

Attachment: Diffs to integrate accessiblility into mozilla

Comment 29

[Eric Vaughan]

Attachment: Zip file containing the source to the accessible DLL. Should live at /mozilla/accessible

Comment 30

[Blake Ross]

(Just noting that eventually we'll need to localize those strings...)

Comment 31

[Eric Vaughan]

The accessible library is also in the tree but not built. You pull it by:

co mozilla/accessible

then modifying the main makefile to build it.

Comment 32

[Daniel (Leaf) Nunes]

hang on, couldn't this have gone under widget?

Comment 33

[Eric Vaughan]

Some of it is under widget. Should it all be under widget?

Comment 34

[Eric Vaughan]

Attachment: Additional diff for nsComboboxControlFrame.cpp

Comment 35

[David Hyatt]

It makes no sense to put this under widget.  The accessibility stuff
communicates with layout and content.  This is traditionally kept separate from
widget code.
I think it makes sense for this to be in its own top level dir.

Comment 36

[Eric Vaughan]

As it turns out the MSAA part of accessibility is under widget/src/windows. It
needs to be because its platform specific to windows. But the bulk of
accessibility is crossplatform and accesses the DOM and Frames. So it can't be
in widget. Widget doesn't know about Frames or the DOM. And it can't be in
Layout because it would bloat it. Its designed to only be loaded if needed. So I
think it warrants having its own directory. I also have makefiles on mac,
windows, and linux all set up. And some of it is already checked into the root
level accessible directory (just not in the build)

Comment 37

[Brendan Eich [:brendan]]

I'm about to lock up the top-level mozilla directory using despot, because
people never ask [e-mail] or just [e-mail] *before* going off
and creating some new top-level.  Now is not the time to be asking whether all
of accessible could be under widget -- do that *before* you go cvs add a new
directory to the top level, please.

End of lecture.  At this point, I'm not sure it's worth moving, but it seems
more likely to go under layout than under widget, judging by the .h files its
.cpp files include.  Someone make an argument, otherwise it stays where it
landed (which is not to say that we won't move something else that lands in the
top-level without prior [e-mail] approval!).

/be

Comment 38

[rods (gone)]

adding self to cc list

Comment 39

[rods (gone)]

I also don't think it should be under widget, maybe some platform specific 
stuff, but on whole as it was stated earlier: If it references frames and 
content, then it need to go elsewhere.

Also, r=rods for form control changes. Thanks

Comment 40

[Brendan Eich [:brendan]]

Ok, sorry to be such a hardcase -- the right thing (modulo name, accessible is
fine with me, shaver differs) happened here.  The problem is that without more
advice/consent dialog with staff, and unlimited cvs access to the top level, we
will tend to get bogo-subdirs that do not deserve to be separate modules (it's
happened before).

Countervailing that is the tendency for things to become independently built and
optional components, which makes for a large top-level.  We'll see how things
evolve.  Proposing before doing still makes sense, though.

/be

Comment 41

[vidur (gone)]

Comments on the first set of diffs:
1) The pattern:
  nsAutoString mystring;
  mystring.AssignWithConversion("cstring");
  obj->MyMethod(mstring.ToNewUnicode());
with MyMethod taking ownership of the string doesn't mesh with XPCOM rules.
Something like:
   obj->MyMethod(NS_ConvertASCIItoUCS2("cstring");
with MyMethod making a copy is better.
2) There are tabs in nsPresShell.cpp. Are the diffs in that file associated with
this bug? Same question for nsCSSFrameConstructor.cpp.
3) In nsView.cpp, you pass accessible events directly to the view observer (the
comment should say view observer, not view). This bypasses, among other things,
the visibility check for the view. What's the correct behavior if the view is
not visible? Since this will probably only happen for the root view, maybe this
is not an issue. Should visibility checks be done at the frame level?
4) In nsTextFrame.cpp, if mContent is not a nsIDOMNode, you try to QI to
nsITextContent. Is the content ever not a nsIDOMNode? If so, what about the
Is1b() case?
5) Should the names and roles of the various frames be hardcoded? Are the names
you've chosen from a well known MSAA vocabulary? Are there localization issues here?
6) I couldn't find the Accessible class (the one that implements IAccessible),
but the makefile indicates that it's in widget. It seems like you're setting the
ref count of the instance to 1 in its constructor. That's not good XPCOM.
7) In nsWindow.cpp, the method DispatchAccessibleEvent takes a nsCOMPtr
reference as an argument. I'd prefer to see it take a nsIAccessible** and do the
AddRef() explicitly.

Comment 42

[Brendan Eich [:brendan]]

vidur wrote:
> obj->MyMethod(NS_ConvertASCIItoUCS2("cstring");
>with MyMethod making a copy is better.

The latest string-fu, which avoids a copy on major platforms, is to use

 obj->MyMethod(NS_LITERAL_STRING("cstring"));

cc'ing scc for confirmation and review/advice.

/be

Comment 43

[Eric Vaughan]

Comments on the first set of diffs:
1) The pattern:
  nsAutoString mystring;
  mystring.AssignWithConversion("cstring");
  obj->MyMethod(mstring.ToNewUnicode());
with MyMethod taking ownership of the string doesn't mesh with XPCOM rules.
Something like:
   obj->MyMethod(NS_ConvertASCIItoUCS2("cstring");
with MyMethod making a copy is better.

-> Ok these are all converted. Take a look at the attached diff

2) There are tabs in nsPresShell.cpp. Are the diffs in that file associated with
this bug? Same question for nsCSSFrameConstructor.cpp.

-> All removed, In diff

3) In nsView.cpp, you pass accessible events directly to the view observer (the
comment should say view observer, not view). This bypasses, among other things,
the visibility check for the view. What's the correct behavior if the view is
not visible? Since this will probably only happen for the root view, maybe this
is not an issue. Should visibility checks be done at the frame level?

-> Yes we want to bypass the point check. Accessibility has its own "GetAccAt"
method. You always want to the root frame for the root widget.

4) In nsTextFrame.cpp, if mContent is not a nsIDOMNode, you try to QI to
nsITextContent. Is the content ever not a nsIDOMNode? If so, what about the
Is1b() case?

-> Yes sometimes its not a nsIDOMNode not sure why. But I have found cases. So I
fixed it to support "1b" as well.

5) Should the names and roles of the various frames be hardcoded? Are the names
you've chosen from a well known MSAA vocabulary? Are there localization issues here?

-> Role names are from a well known fixed list. So they don't need to be
localized. Only things that will need to be localized are things like
"description" and "name' which I haven't got to yet.

6) I couldn't find the Accessible class (the one that implements IAccessible),
but the makefile indicates that it's in widget. It seems like you're setting the
ref count of the instance to 1 in its constructor. That's not good XPCOM.

-> This is fixed. I have enclosed Accessible.h and .cpp as well.

7) In nsWindow.cpp, the method DispatchAccessibleEvent takes a nsCOMPtr
reference as an argument. I'd prefer to see it take a nsIAccessible** and do the
AddRef() explicitly.

-> This is fixed. See diff

Comment 44

[Eric Vaughan]

Attachment: New diffs with changes.

Comment 45

[vidur (gone)]

Points 2) and 7) from the original list need to be applied to Accessible.cpp,
but other than that r=vidur.

Comment 46

[David Hyatt]

sr=hyatt

Comment 47

[Eric Vaughan]

Attachment: Makefile diff for accessibility

Comment 48

[Dan Rosen]

Re: Makefile diff for accessibility (03/28/01)

You need the equivalent change in Makefile.in as you currently have in
makefile.win (that is, somewhere you have to say "DIRS += accessible" if it's
going to build on linux). Also, I think you forgot the mac change (in
whatever.txt, I don't remember the filename). The rest looks good...

Comment 49

[timeless]

> #ACCESSIBLE_CO_TAG=SeaMonkey_M17_BRANCH
?

Comment 50

[Eric Vaughan]

Attachment: linux makefile

Comment 51

[Dan Rosen]

timeless: that's just a placeholder, for consistency when we branch again.
obviously that won't be the m17 branch when un-commented :)

eric: r=dr, provided you merge both 3/28 patches or just check both in at once.

Comment 52

[Eric Vaughan]

ok got the mac makefiles working thanks to Saari. Here are the diffs:

Index: mozilla/build/mac/build_scripts/MozillaCheckoutList.txt
===================================================================
RCS file: /m/pub/mozilla/build/mac/build_scripts/MozillaCheckoutList.txt,v
retrieving revision 1.5
diff -u -2 -r1.5 MozillaCheckoutList.txt
--- MozillaCheckoutList.txt	2001/03/24 03:31:16	1.5
+++ MozillaCheckoutList.txt	2001/03/30 02:20:11
@@ -12,4 +12,5 @@
 mozilla/security/psm,   
 mozilla/security/manager,
+mozilla/accessible,
 DirectorySDKSourceC,    LDAPCSDK_40_BRANCH
 mozilla/lib/mac/Instrumentation

Index: mozilla/build/mac/build_scripts/MozillaBuildFlags.txt
===================================================================
RCS file: /m/pub/mozilla/build/mac/build_scripts/MozillaBuildFlags.txt,v
retrieving revision 1.16
diff -u -2 -r1.16 MozillaBuildFlags.txt
--- MozillaBuildFlags.txt	2001/03/27 23:08:21	1.16
+++ MozillaBuildFlags.txt	2001/03/30 02:20:09
@@ -24,4 +24,5 @@
 intl            0
 nglayout        0
+accessiblity    0
 editor          0
 embedding       0
@@ -57,4 +58,5 @@
 useimg2         1
 lowmem          0
+accessible      1
 
 filepath_flags


Index: mozilla/build/mac/build_scripts/MozillaBuildList.pm
===================================================================
RCS file: /m/pub/mozilla/build/mac/build_scripts/MozillaBuildList.pm,v
retrieving revision 1.67
diff -u -2 -r1.67 MozillaBuildList.pm
--- MozillaBuildList.pm	2001/03/29 20:05:30	1.67
+++ MozillaBuildList.pm	2001/03/30 02:20:10
@@ -689,4 +689,7 @@
     InstallFromManifest(":mozilla:dom:src:base:MANIFEST",                     
    "$distdirectory:dom:");
 
+    #ACCESSIBLE
+    InstallFromManifest(":mozilla:accessible:public:MANIFEST",                
    "$distdirectory:accessible:");
+    
     #JSURL
     InstallFromManifest(":mozilla:dom:src:jsurl:MANIFEST_IDL",                
    "$distdirectory:idl:");
@@ -1020,4 +1023,6 @@
     BuildIDLProject(":mozilla:layout:macbuild:layoutIDL.mcp",                 
     "layout");
 
+    BuildIDLProject(":mozilla:accessible:macbuild:accessibleIDL.mcp",         
     "accessible"); 
+
     BuildIDLProject(":mozilla:rdf:macbuild:RDFIDL.mcp",                       
     "rdf");
 
@@ -1514,8 +1519,27 @@
         BuildOneProject(":mozilla:xpinstall:wizard:mac:macbuild:MIW.mcp",     
     "Mozilla Installer$D", 0, 0, 0);
     }
-
+    
     EndBuildModule("nglayout");
 }
 
+#//--------------------------------------------------------------------------------------------------
+#// Build Accessiblity Projects
+#//--------------------------------------------------------------------------------------------------
+sub BuildAccessiblityProjects()
+{
+    unless( $main::build{accessiblity} ) { return; }
+
+    # $D becomes a suffix to target names for selecting either the debug or
non-debug target of a project
+    my($D) = $main::DEBUG ? "Debug" : "";
+
+    StartBuildModule("accessiblity");    
+    
+    if ($main::options{accessible})
+    {
+      BuildOneProject(":mozilla:accessible:macbuild:accessible.mcp",  
"accessible$D.shlb", 1, $main::ALIAS_SYM_FILES, 1);
+    }
+    
+    EndBuildModule("accessiblity");
+} # imglib2
 
 #//--------------------------------------------------------------------------------------------------
@@ -1912,4 +1936,5 @@
     BuildInternationalProjects();
     BuildLayoutProjects();
+    BuildAccessiblityProjects();
     BuildEditorProjects();
     BuildEmbeddingProjects();

Comment 53

[Simon Fraser [no longer active]]

sr=sfraser on the mac build script changes.

Comment 54

[Dan Rosen]

r=dr

Comment 55

[Mike Pinkerton (not reading bugmail)]

what's the point of the |accessible| build option? It only prevents one project 
from being built and doesn't even stop the pull of that tree, the MANIFEST, or 
the building of the IDL project. Seems like a waste, especially if the default is 
on.

Is the build conditional on unix and win32?

Comment 56

[Eric Vaughan]

You must build the nsIAccessible.idl for the rest of the code in the project to
compile. But You don't have to compile all the implemetations. The idea is to
make it possible for people not to have to compile accessibility, expecially on
the mac if people care about it.

-Eric

Comment 57

[Mike Pinkerton (not reading bugmail)]

ok, i understand now. r=pink on mac build changes.

Comment 58

[Simon Fraser [no longer active]]

Noting my dislike of both having accessible as a top-level dir, and using an 
adjective for the directory name; "accessibility" would have been much nicer than 
"accessible". See bug 74405. Wouldn't mozilla/extensions have been a better place 
for this?

Comment 59

[Aaron Leventhal]

Attachment: Changes state to 2 sets of bitfields; fixes viewer makefile

Comment 60

[Eric Vaughan]

-r evaughan

Brendan can we get a -sr?

Comment 61

[Brendan Eich [:brendan]]

-      a.AssignWithConversion("default");
+          *_retval |= STATE_DEFAULT;
    else

Tab alert!  Please fix this indentation glitch.

Otherwise looks good to me, although I didn't read all the source files, only
the context shown in the diffs.  sr=[e-mail].

/be

Comment 62

[Eric Vaughan]

Ok I have added:

1) Event support
2) Implemented checkbox, radiobutton, push button
3) Implemented basic focus and selection

Diffs attached. Can you review this AAron?

Comment 63

[Eric Vaughan]

Attachment: Patch

Comment 64

[Eric Vaughan]

Attachment: Better patch

Comment 65

[Aaron Leventhal]

Comments:
accessible/src/Makefile.in is missing nsSelectAccessible and nsGenericAccessible
nsAccessibilityService: use NS_STATIC_CAST for casts. Fix repeating comments 
about checkbox
nsHTMLFormControlAccessible .cpp & .h: why is nsIWeakReference declared and not 
used?
Fix that, and r=aaronl

Comment 66

[Eric Vaughan]

Ok fixed. Brendan can we get a -SR?

Comment 67

[Brendan Eich [:brendan]]

+  *_retval = new nsHTMLCheckboxAccessible(shell,node);
+  NS_ADDREF(*_retval);

new can return null -- use NS_IF_ADDREF at the least *if and only if* callers
expect to deal with NS_OK and a null *_retval, or (better) check for null and
return NS_ERROR_OUT_OF_MEMORY.

+  *aRealFrame = (nsIFrame*)aFrame;

NS_STATIC_CAST please.

+  PRInt32 shells = document->GetNumberOfShells();
+  NS_ASSERTION(shells > 0,"Error no shells!");
+  *aShell = document->GetShellAt(0);
+  NS_ADDREF(*aShell);

Why call GetNumberOfShells()?  If only for the assertion, put #ifdef DEBUG
around the two lines.  If necessary before calling GetShellAt(0), mebbe a
comment to that effect?  I assume *aShell should never be null.

+  return NS_ERROR_FAILURE;  }

wacky closing brace (takeSelection and takeFocus only).


+NS_IMETHODIMP nsDOMAccessible::AccRemoveSelection()
+{
+    nsCOMPtr<nsISelectionController> control = do_QueryReferent(mPresShell);
+    nsCOMPtr<nsISelection> selection;
+    nsresult res =
control->GetSelection(nsISelectionController::SELECTION_NORMAL,
getter_AddRefs(selection));  
+
+    nsCOMPtr<nsIDOMNode> parent;
+    res = mNode->GetParentNode(getter_AddRefs(parent));
+
+    res = selection->Collapse(parent, 0);
+    return NS_OK;
+}

What's the point of res here?  It's set but never used.  Either get rid of it,
or test it and do something other than fall through to subsequent code that
depends on successful prior results.

I'm stopping at nsDOMAccessible::AccTakeSelection, to grab lunch and stuff. 
More in a bit.

/be

Comment 68

[Eric Vaughan]

Excellent finds, keep them coming Brendan!

Comment 69

[Brendan Eich [:brendan]]

Sorry, dogfood mail problems and I lost track of this bug.

nsDOMAccessible::AccTakeSelection should check res after first setting it, to
the r.v. of control->GetSelection (I see no null test before selection is used).

Same method, offsetInParent is really an index, so indexInParent?  Nit.

Please expand the tabs in nsGenericAccessible.h, per the Emacs modeline.  More
important: why aren't the interfaces defined in XPIDL?

Give me a warm fuzzy that those getters returning *_retval = blah.ToNewUnicode()
are called infrequently -- otherwise I'll recommend nsAWritableString etc.  In
any event, use new string fu:

    *_retval = ToNewUnicode(NS_LITERAL_STRING("Select"));

(I think that'll work; scc?)

BTW, what's the P in erP (nsCOMPtr<nsIDOMEventReceiver> erP) stand for?

Oop, more tabs in nsRootAccessible.h, and below -- please expand per modelines.

I'll rubberstamp= windows/Accessible.cpp.

Hope this helps, please gimme some responses and maybe a new patch and I'll sr=
right away.

/be

Comment 70

[Eric Vaughan]

> nsDOMAccessible::AccTakeSelection should check res after first setting it, to
> the r.v. of control->GetSelection (I see no null test before selection is 
used).
>
> Same method, offsetInParent is really an index, so indexInParent?  Nit.

Done

> Please expand the tabs in nsGenericAccessible.h, per the Emacs modeline.  More
> important: why aren't the interfaces defined in XPIDL?

tabs now fixed
All interfaces are implemented in XPIDL. See nsIAccessible.idl

>Give me a warm fuzzy that those getters returning *_retval = > 
blah.ToNewUnicode()
> are called infrequently -- otherwise I'll recommend nsAWritableString etc.  In
> any event, use new string fu:
>
>   *_retval = ToNewUnicode(NS_LITERAL_STRING("Select"));

This won't compile.

> BTW, what's the P in erP (nsCOMPtr<nsIDOMEventReceiver> erP) stand for?

changed to "receiver"

> Oop, more tabs in nsRootAccessible.h, and below -- please expand per 
modelines.

done

Comment 71

[Eric Vaughan]

Attachment: New patch

Comment 72

[Scott Collins]

  > *_retval = ToNewUnicode(NS_LITERAL_STRING("Select"));

  This won't compile.

Why not?  What is the error message?  Is |_retval| a |PRUnichar**|?  Or did you
not |#include "nsReadableUtils.h"|?  The declaration for |ToNewUnicode| can be
found at

  http://lxr.mozilla.org/seamonkey/source/string/public/nsReadableUtils.h#93

Comment 73

[Scott Collins]

By the way, even this new patch contains lots of old style casts, e.g.,

  +       accService->CreateHTMLTextAccessible((nsIFrame*)this,&acc);

An old-style cast always succeeds, even if it has to turn into a
|reinterpret_cast| to do so.  Be in the habit of using |NS_STATIC_CAST| and
friends, so when you make an error, the compiler tells you.  It's a lot easier
to fix when you find the error at compile time, than when you have to debug your
way to it.

Comment 74

[Eric Vaughan]

Ok I got scc's string fu working. And I now only use static casts.
New patch attached.

Comment 75

[Eric Vaughan]

Attachment: New patch

Comment 76

[Aaron Leventhal]

+/* wstring getAccRole (); */ 
+NS_IMETHODIMP nsHTMLButtonAccessible::GetAccRole(PRUnichar **_retval) 
+{ 
+    nsAutoString state; 
+    state.AssignWithConversion("button"); 
+    *_retval = state.ToNewUnicode(); 
+ 
+    return NS_OK; 
+} 
  

state.AssignWithConversion("push button"); 

and I would change the string name to role - it's not a state. 

Comment 77

[Brendan Eich [:brendan]]

sr=[e-mail], modulo Aaron's fine variable renaming suggestion.

/be

Comment 78

[Eric Vaughan]

Fixed with accessibility landing

Comment 79

[Chad Austin]

Looks like the architecture is working fine, but it doesn't seem like the 
browser itself actually returns much useful information.  For example, menu 
items don't have the role "menu item".  Various dialog box elements such as 
buttons don't have a useful name, value, or role either.

Should this move to a different bug?

Comment 80

[Peter Trudelle]

This bug was filed on browser accessibility as a whole, but was used to cover
making the embeddable browser (content area) accessible.  Making the chrome
accessible is another major project.  We should probably have a new bug for
that, although it will look much like this one.

Comment 81

[Chad Austin]

I filed the new bug (bug 82207).

I went to google.com and the controls on the page didn't return useful 
accessibility information either.

Comment 82

[Claudius Gayle]

rubber stamping this bad boy VERIFIED Fixed as specific issues will have to be new bugs.