STR: 1. Build a current mozilla-central snapshot of Firefox with --enable-accessibility. 2. Start VoiceOver by pressing Cmd+F5. 3. Start the Firefox you just built. 4. A dialog will most likely come up asking whether Minefield should be the default browser. 5. Explore this dialog with the VoiceOver commands Ctrl+Option+RightArrow and Ctrl+Option+LeftArrow. Expected: VoiceOver should speak the text of the dialog prompt "Minefield is currently not...", and when navigating to the buttons should say "Yes button" and "No button", and the "Don't ask again checkbox" plus the current state. Actual: The text for the dialog title and prompt text is not spoken, and the roles for the checkbox and buttons aren't spoken. The state for the checkbox is spoken. 6. Select "No". Note that pressing this button with Ctrl+Option+Space actually works fine, and VoiceOver says "press button". 7. Once on the start page, navigate through elements. Results: a) Links are spoken as "HyperLink", whereas in Safari it's called "Link". b) button roles are not spoken anywhere. c) The "Search Mozilla" textbox is spoken properly. d) Images are identified. 8. Press Ctrl+F2 to open the menu bar, and navigate around using right and left, and up and down. Result: This part works just fine. Menus, submenus etc. are all identified properly.

Is this something that used to work in FF, but no longer does? If so please try to find a regression range.

Håkan, do you know? (see comment #1)

(In reply to comment #1) > Is this something that used to work in FF, but no longer does? I don't know, and since we never had official nightly builds with a11y enabled, it's difficult to find out without having to go through a hell of CVS and HG mixups, trying to build from different random points and see where it breaks. Moreover, I wasn't there when the grant that put this initial work in happened. I'm hoping Hakan can shed some light on this, since he was the grantee, but has since moved on to other projects. So far, I've ruled out that the nsRoleMap is out of sync in the Mac wrapper. I've found a few hardcoded strings that now have equivalents according to http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html. Since Firefox no longer supports anything below Tiger, I believe this is safe. I'm trying out now if that helps any.

That actually didn't change things at all, but I still think it's good to have those changes. However I did notice something else: When looking at the window with Accessibility Verifier, it found 547 or so errors and 837 or so warnings having to do with role and other attribute retrieval. One error that is I think directly related to this bug is "error AXButton - !Go forward one page" required attribute RoleDescription not specified. We specify the RoleDescription attribute as follows: http://mxr.mozilla.org/mozilla-central/source/accessible/src/mac/mozAccessible.mm#237. If I interpret this correctly from nsAccessibility.h, we pass in a role, but nil as the subrole, which I *think* is correct. But I'm not familiar with objective-c that much yet, and the way we pass in the role looks a bit funny to me.

> We specify the RoleDescription attribute as follows: > http://mxr.mozilla.org/mozilla-central/source/accessible/src/mac/mozAccessible.mm#237. > > If I interpret this correctly from nsAccessibility.h, we pass in a > role, but nil as the subrole Yes. There's sample code at http://developer.apple.com/ue/accessibility/accessibilitycustomviews.html that does the same thing, which *might* be where this originally came from. It's probably worth looking into. The alternative would be to call: NSAccessibilityRoleDescription([self role], [self subrole]); Note that other code above calls [self subrole].

I built Firefox 3.0/Granparadiso from source today, and the same problem exists there. So whatever the bug, it's been in our codebase for a long time.

Sorry I've taken so long to get back to this. Things now seem much worse than when you opened this bug ... but I've no idea why. I just compiled mozilla-central (code pulled this Monday, 2009-08-17) with --enable-accessibility, and failed to get even the most basic VoiceOver commands to work in it. Even Cmd-F5 to turn on VoiceOver doesn't work when this build has the focus! And that works fine on current nightlies (made without --enable-accessibility). Marco, what do you see when you build mozilla-central from current code with accessibility enabled?

I should also mention that *all* the accessibility mochitests fail.

Same thing is true on the 1.9.1 branch (also using code pulled Monday, 2009-08-17).

Though on the 1.9.1 branch, only 39 mochitests fail and 73 do pass :-)

Steven, the tinderboxes seem to disagree with you, since the Mac a11y tests are all passing there on both branches that we run them on: Firefox and Firefox3.6. I haven't built on Mac in recent weeks, but will try it out over the weekend to see hwat I get. But right now, I'm leaning toward something having changed in your configuration that breaks you so badly. Although I have no idea what that might be.

Confirmed, situation on my MB with the source pulled today is the same as it was when I filed the bugs, no situation change for the better OR worse.

So I need to figure out what I did wrong :-( I didn't realize we had tinderboxes doing Mac builds with --accessibility-enabled. Are they publicly accessible? Where are they? Do they have logs indicating what .mozconfig files they're using? For the record, here's the .mozconfig I've been using: export CFLAGS="-g -gfull" export CXXFLAGS="-g -gfull" . $topsrcdir/browser/config/mozconfig mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-firefox mk_add_options MOZ_MAKE_FLAGS=-j4 mk_add_options AUTOCONF=autoconf213 ac_add_options --enable-optimize ac_add_options --enable-tests ac_add_options --enable-cpp-rtti ac_add_options --enable-logrefcnt ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.4u.sdk ac_add_options --enable-accessibility

Turns out I was wrong about the accessibility mochitests -- I was running them the wrong way. The correct way (which I don't believe is documented anywhere) is: 1) Change to the [objdir]/_tests/testing/mochitests directory. 2) Run 'python runtests.py --a11y'

> I didn't realize we had tinderboxes doing Mac builds with > --accessibility-enabled. Are they publicly accessible? Where are > they? Do they have logs indicating what .mozconfig files they're > using? I've figured out the answers to these questions. The "OS X 10.5.2 mozilla-central unit test" tinderboxes that are running a11y mochitests. Their mochitest files are listed in their logs. They aren't much different from the one I've been using. But I'll play with the differences and see what I can find out.

I'll be taking this one as part of the Mac fix.

I am happy to report that the try-server build from here: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/hfiguiere@mozilla.com-b2c705a32cf8/ fixes this bug.

I believe the dialogs are addressed by bug 369710. Link also are spoken as "link". Clicking on the links is bug 718624.

Verified fixed in Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0a1) Gecko/20120128 Firefox/12.0a1 built from the projects/accessibility branch. The first on-change build from this branch, made on Jan 27, which only contained bug 712923 but not 712927, did not work properly yet. So I changed the dupe info to the correct bug.