all well and good but the statements below demonstrate that it is
possible for them to make ff accessible. I don't know how oo was made
accessible, I don't know how opera was made accessible I do know
though that they point the way to others. look at tables too. I'm
sorry, All this shows me is what the excuses are and not what the real
problems are. Yes, I do know that there is some information lacking
but to stop short of accessibility using coco because "we don't want
to do it that way" is not enouh to convince me that there is a problem
that prevents accessibility. I did not say that there are not
problems. I've been following the problems from te beginning. You
said yourself that they turned their attention elsewhere and haven't
worked on this since 06. I'm sure it will happen at some point. The
excuses though need to be revealed for what they are.
I'll be happy to use ff on the mac when I can.
On Dec 29, 2008, at 10:59 AM, Benjamin Hawkes-Lewis wrote:
On 29/12/08 14:21, David Poehlman wrote:
and they wouldn't experience the problems in mac os if tey used coco
and
devellopped according to the accessibility api.
Mozilla does use Cocoa. Here's a blog post discussing its use of Cocoa
by Mozilla developer Josh Aas:
http://boomswaggerboom.wordpress.com/2008/06/10/firefox-3-for-mac-os-x-under-the-hood/
Mozilla are also trying to use the accessibility API, to which the
work and problems previously cited is evidence.
So this statement is demonstrably false.
Perhaps you mean Mozilla should be using bog-standard Aqua controls.
But the blog post above also happens to explain how this is (a) not
what other browsers (including Safari) do and (b) why it's not
feasible for a browser to do. It's worth quoting at length:
"We do not use actual Cocoa buttons or any other Cocoa controls within
any Gecko 1.9 windows. The context menus, dropdown menus, the toolbar,
the search bar, the buttons and text fields within web pages - they
are not actual Cocoa controls. For example, instead of using actual
Cocoa buttons for “Submit” buttons we just draw the image of an Aqua
“Submit” button into an NSView, one of the basic Cocoa objects we use.
Gecko 1.9 has Aqua form controls because we now draw images of Aqua
form controls when appropriate, not because we use actual Cocoa
controls. The reason we don’t use actual Cocoa controls isn’t because
we are lazy or we can’t figure out how to use them or because we are
constrained by our cross-platform requirements - Apple’s WebKit
doesn’t use actual Cocoa controls for things like “Submit” buttons or
popup buttons in web pages either, at least not the last time I
checked. IE for Windows is in the same boat. The reason Gecko 1.9
doesn’t use Cocoa controls is for the sake of flexibility - form
control behavior and appearance can be changed significantly via HTML,
CSS, and JavaScript. Actual Cocoa controls are simply not flexible
enough to do all of the things that people want to be able to do with
controls on the web."
Compare this similar discussion from a WebKit developer:
http://webkit.org/blog/17/the-new-form-controls-checkbox-2/
Also, it's hard to see how adopting native form controls would fix the
critical performance problems Håkan Waara was asking for aid with:
http://lists.apple.com/archives/accessibility-dev/2006/Oct/msg00005.html
You keep talking about
features and cross platform accessibility but from where I sit, a
browser is a browser and if Apple can make one accessible on the Mac
and
opera can make one accessible on the mac, mozilla can.
Mozilla might be able to make _a_ browser that is accessible to
VoiceOver; but the question is how they can make Firefox accessible.
These browsers differ from each other in codebase, featureset, user
interface, and politics, so it's illogical to conclude that what is
easy for developers of one is equally easy for developers of another.
Firefox is an open source project that belongs to the world. If you
believe you can make it accessible on Mac OS X and that it would be
worth making it accessible, you can contribute code to fix the
outstanding issues. If you think the accessibility implementation
needs to be done differently, you can again volunteer to do that. If
you don't know how to do that (and I certainly don't) or don't want to
try, it might be wise to have a least a little bit more trust in the
developers who have actually tried to do so, found it problematic,
raised blocking issues, and asked for help.
The situation with Mozilla is very different from (for example) the
situation with Adobe Flash Player, where the vendor has an explicit
policy of not developing accessibility support on Mac OS X, i.e. no
attempt has been made.
It's hard to draw productive lessons from Opera's success, because
there's so little information about how it was accomplished, either
technically or socially, whereas we at least know that their Windows
accessibility implementation drew help from IBM, Mozilla (in the
person of Aaron Leventha), and GW-Micro:
http://my.opera.com/chaals/blog/2007/09/04/a-new-baby-kestrel
--
Benjamin Hawkes-Lewis
