Re: Newbie question: Section 508 and "full keyboard access" on Mac OS X
Re: Newbie question: Section 508 and "full keyboard access" on Mac OS X
- Subject: Re: Newbie question: Section 508 and "full keyboard access" on Mac OS X
- From: Raymond Fischer <email@hidden>
- Date: Tue, 02 Sep 2003 11:36:43 -0700
On Monday, September 1, 2003, at 02:31 AM, Bill Cheeseman wrote:
on 03-09-01 1:04 AM, Smith Kennedy at email@hidden wrote:
However, Macintosh systems have traditionally only allowed tabbing to
move the user between certain types of controls. I believe they are
the text-related ones, such as text areas, text boxes, etc. Buttons,
pop-up menus, checkboxes and radio buttons have always been basically
inaccessible without a mouse. This seems to be true in normal apps as
well as in some Web browsers, including Safari. Lately, there have
been things that are supposed to allow "full keyboard access" to all
GUI controls, but I haven't found that it extends to all applications.
Perhaps only Cocoa apps inherited that capability automagically? It
is
not clear to me. But if that was all that Apple was relying on, that
would be incomplete.
[...]
Certainly all Cocoa applications implement these accessibility features
automatically, and most of Apple's applications these days are Cocoa
applications (whether written in Objective-C or Java, or another
language).
But a little testing shows me that it works on the Finder, too, which
is not
a Cocoa application. I'm quite confident that all Carbon applications
written using Apple's latest APIs are also fully accessible, because
Apple's
APIs do support accessibility. You can test other Apple applications
yourself easily on your own computer.
I'm surprised you single out Safari as not being accessible by
keyboard,
when in fact it is. It is a Cocoa application and the Cocoa APIs
supply this
capability automatically.
In fact Safari is not fully accessible, regardless of whether it is
written
in Cocoa. In fact it's barely accessible at all. Sure, all the
standard
controls are accessible, but the contents of the main window are not.
And
without being able to read the contents of a web page or to follow links
it's pretty much worthless to anybody who cannot see.
I did notice with a quick look just now that the
Reload and Add Bookmark buttons at the top of a Safari browser window
are
apparently not keyboard accessible even when enabled, which is a
glitch that
Apple should fix. However, both of those commands are also menu items
with
keyboard equivalents, and in addition the entire Safari menu bar and
all
menu items in Safari are accessible by keyboard, so the functionality
is
keyboard accessible. A couple of tests showed me that editable fields
on a
Web page, such as the Google search box, are also keyboard accessible.
As well as radio buttons and push buttons. But links are not and the
text
of the window is not.
Which is disappointment since being able to use WebKit for an
application's
help information would be really nice, but having it be not accessible
leaves
a large gap in any application that uses it.
----
Ray Fischer
Adobe Systems
_______________________________________________
accessibility-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/accessibility-dev
Do not post admin requests to the list. They will be ignored.