157209 - No support for Apple's accessibility API (VoiceOver)

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, enhancement, P5)

Description

[dsirnapalli]

Attached test case. In the test case i am unable to get Accessibility Service. I
belive this bug is similar to bug# 139621. Accessibility xpt files might be missing.
I dont know where to check for these file on mac. I know where to check when its
trunk build, but dont know where to check on nightly build because when i did
nightly build there were only 3 files in mozilla folder(Mozilla, Mozilla Profile
Manager and Mozilla Profile Migration).

Comment 1

[dsirnapalli]

Attachment: Test Case to reproduce the bug.

Comment 2

[Kyle Yuan]

I couldn't help on that, because we have no Mac here. I think John is the right
person to fix that problem.

changing platform, OS, severity and milestone, because we have no plan for Mac
accessibility work yet.

Comment 3

[Aaron Leventhal]

Perhaps someone at Apple can own this bug? Dave, if they have an accessibility
API for OS X, can you get them to show it to us? We've had no luck getting
traction with Apple with respect to an accessibility API on that platform.

Comment 4

[Aaron Leventhal]

I doubt this will ever get done unless someone steps up to the plate.

Comment 5

[Phil Ringnalda (:philor)]

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

Comment 6

[David Niemeijer]

(In reply to comment #3)
> Perhaps someone at Apple can own this bug? Dave, if they have an accessibility
> API for OS X, can you get them to show it to us? We've had no luck getting
> traction with Apple with respect to an accessibility API on that platform.

Your problem (no, sorry, Firefox's problem) is that Firefox does not use the standard UI elements 
provided by OS X. If it would you would have accessibility almost for free. For custom UI elements you 
have a lot more work to do. There is documentation on Apple's developer site for both Cocoa and 
Carbon applications on how to add accessibility using the Accessibility API to custom UI elements. 
Apple also has a email discussion list that you can find on http://lists.apple.com on accessbility issues 
in which developers and Apple engineers discuss these issues.

Hope this helps,

david.

Comment 7

[Aaron Leventhal]

> Your problem (no, sorry, Firefox's problem) is that Firefox does not use the 
standard UI elements provided by OS X. If it would you would have accessibility 
almost for free. For custom UI elements you have a lot more work to do.

Yes, same story for our Windows port, where we support MSAA. Same on Linux too, 
where we support ATK. Firefox is not ever going to use custom widgets, that's a 
core architectural decision so that XUL can be used and Firefox can have an 
almost identical UI everywhere it runs. So, we would have to do the hard work 
you're mentioning in order for Firefox to be accessible on OS X. No one is 
stepping forward to do the work at this point, and there has been virtually no 
one beyond yourself even asking for it so far.

On the other hand, Camino is a very nice OS X web browser that uses Mozilla 
Gecko for the HTML content area, but it also uses standard OS X UI elements 
both in the UI and content area. It probably works a lot better, but still has 
big issues. I'd be very interested to hear if it works better with Voice Over 
and other assistive technologies on OS X.

It's good to hear that someone is interested in Firefox accessibility on OS X. 
Does your company assistiveware.com actually develop Voice Over for OS X?

Comment 8

[David Niemeijer]

(In reply to comment #7)
> Yes, same story for our Windows port, where we support MSAA. Same on Linux too, 
> where we support ATK. Firefox is not ever going to use custom widgets, that's a 
> core architectural decision so that XUL can be used and Firefox can have an 
> almost identical UI everywhere it runs. So, we would have to do the hard work 
> you're mentioning in order for Firefox to be accessible on OS X. No one is 
> stepping forward to do the work at this point, and there has been virtually no 
> one beyond yourself even asking for it so far.

I guess that is because there are so few developers working on providing assistive technology software 
for Mac OS X and few users with disabilities know how to file bugs against Firefox. I have my hands full 
on our own software so it is not like i can step in here right now.

> On the other hand, Camino is a very nice OS X web browser that uses Mozilla 
> Gecko for the HTML content area, but it also uses standard OS X UI elements 
> both in the UI and content area. It probably works a lot better, but still has 
> big issues. I'd be very interested to hear if it works better with Voice Over 
> and other assistive technologies on OS X.

I tried 0.81 and it fares no better. Don't know why exactly, but despite their use of standard eelements 
they are doing something that prevetns the standard elements from working.

> It's good to hear that someone is interested in Firefox accessibility on OS X. 
> Does your company assistiveware.com actually develop Voice Over for OS X?

No, Apple does that themselves. What we are doing is developing a product not for blind people but 
people with low vision and ours will provide multilingual speech.

david.

Comment 9

[Jo Hermans]

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

Comment 10

[Jo Hermans]

Note that bug 187508 (Follow "full keyboard access" setting in System
Preferences for tabbing navigation) was recently checked in.

Comment 11

[Simon Fraser [no longer active]]

Aaron: have you looked at the Carbon accessibility APIs to see how well they fit
with mozilla's accessibility design?
<http://developer.apple.com/documentation/Carbon/Conceptual/MakingAppsAccessible/access_over/chapter_1_section_1.html#//apple_ref/doc/uid/TP30001127-DontLinkChapterID_5>

Comment 12

[sairuh (rarely reading bugmail)]

notes to myself about this issue:

a. prevent access to objects in gecko (content), via an a11y API --which affects
all gecko apps, firefox, camino, mozilla, tbird, etc.

b. prevents access to objects in XUL (ui, chrome), via an a11y API --which
affects firefox, mozilla and tbird.

not only does this affect assistive technologies, but on the QA side of things
this won't allow AppleScript to access the a11y API, thus preventing most
automation (if so desired). mozilla-based apps on Mac have very limited
Applescripting capabilities at present; the a11y API would've been another
possible route.

Comment 13

[Aaron Leventhal]

(In reply to comment #11)
> Aaron: have you looked at the Carbon accessibility APIs to see how well they fit
> with mozilla's accessibility design?

No more than a cursory look. I would love to see a volunteer step up and help us
fill out our api cross reference doc and document the differences with what we have:
http://www.mozilla.org/access/platform-apis

Comment 14

[Asaf Romano (gone)]

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

Comment 15

[Asaf Romano (gone)]

-> Josh

Comment 16

[Josh Aas]

I'm not going to get to this soon, so -> nobody for now

Comment 17

[Alexis Gallagher]

FYI, the same kind of bug was squashed in gnu emacs Carbon this month. The thread starting with the reporting of it and ending with comments on the squishing starts with the message here:

http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-09/msg00052.html

The discussion also includes links to more Apple Accessibility API documentation than has been referenced above.

This information might be useful, if anyone ever becomes interested in adding accessibility support for Mozilla on OS X.

Comment 18

[Håkan Waara]

(In reply to comment #17)

Yes, I'm already working on this. The first patch is awaiting review in bug 342146

Comment 19

[Håkan Waara]

If anyone is interested in trying out the support I've implemented so far, build a trunk build with --enable-accessibility in your mozconfig.

Comment 20

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381