Hi Ricky,
Ricky Buchanan wrote:
I'm getting a bit confused. Could somebody sum up the advantages and
disadvantages of downloading one of the WebKit nightlies and using
that as a primary browser, rather than Safari?
You can read my archived response on the nature of WebKit and why we
use it from a month ago, and follow the links given in that post:
http://www.mail-archive.com/[email protected]/msg45664.html
If you're using Safari, you can press control-p 10 times (or hold down
the control key and tap the "p" key 10 times) and read up the thread
to an earlier post that is my reply to Mike Arrigo on some of the
fixes. (For those of you who do not use Safari or WebKit with
VoiceOver as browsers, I'll give the direct link to that post in the
next paragraph, and summarize some of the accessibility fixes.)
A number of accessibility issues are fixed in the WebKit nightly
builds. I've never seen a complete listing of these, but I mention
some of them in this list post in my response to Mike Arrigo's first
impressions on using WebKit at:
http://www.mail-archive.com/[email protected]/msg45734.html
• Contextual menus (VO-Shift-M) for links on web pages.
We often get questions on how to download linked PDF or mp3 files from
web pages instead of displaying/playing them in the browser. Apart
from having to route the mouse cursor to the VoiceOver cursor to
control-click or option-click on the link, users also had to
understand that only "hardware clicks" work in this situation (e.g., a
physical click with a mouse button, track pad, press of the "5" key on
the Numeric keypad with NumPad Commander activated, or the
corresponding central key -- "i" or "5" -- with MouseKeys turned on)
-- "software clicks" like VO-Shift-Space do not work in this
situation, nor does the VO-Space command to perform the default
action. Now from WebKit users can just use VO-Shift-M on these links
as they would naturally expect to do, and then select from the
contextual menu options.
• Same page links on web pages.
(This wasn't mentioned in my archived response.) In web pages that
contain links to later sections on the same page, VoiceOver's focus
doesn't handle the jump correctly under the current version of
Safari. Tim Kilburn described a hack to get around this by forcing
VoiceOver to lose focus again just after the link is activated, and
then resume reading, but this kind of action isn't needed with
WebKit. For example, if you go to a Wikipedia page (e.g., the one
describing Apple Remote functions, to read about options to control
other application like VLC with the Apple Remote via third party
software), under WebKit you can read through the listed Contents links
by tabbing to successive links, then press VO-space to activate your
selected link and VO-right arrow to continue reading the linked
content. In Safari, as soon as you VO-right arrow after activating
the same page link you're sent to the next listed link under the
Contents, as though you had not activated the same page link with VO-
space at all.
* Multi-select list boxes.
This feature actually worked correctly with the previous version of
Safari (Safari 2) under Tiger, but stopped working in Safari 3 because
of problems in the underlying WebKit engine support. Since anyone
running the latest version of Tiger (Mac OS X 10.4.11) now has to run
Safari 3, multi-select list boxes no longer work for them, either.
See this list post on "Massive form oversight multi-select list boxes"
from over a year ago with Leopard's introduction:
http://www.mail-archive.com/[email protected]/msg21445.html
The WebKit fix for this has been in place for more than half a year
(unlike the fix for contextual menus for links, which only showed up
in August), but it is still not included in Safari. Since this
feature is often needed for filling out pages for jobs, insurance,
etc. it can have substantial accessibility impact.
• Other fixes
This is where I run out of the appropriate terms of reference to use.
Someone conversant in accessibility issues for web formats like
Benjamin Hawkes-Lewis could probably tell you whether these are
genuine WebKit fixes and the appropriate name for the access fix, or
whether these are simply more robust implementations of web element
handling that either get around poor coding or make VoiceOver's
behavior more resilient to coding limitations or errors. From the
user's point of view, it's often difficult to distinguish between
instances of flawed web page design and genuine deficiencies in the
browser interface with VoiceOver. So in the post that I linked above,
Mike's enthusiastic reaction to performance improvements seen with
WebKit is stated in terms of problems he does not encounter, and I'm
reduced to describing the symptoms of the problems he sees browsing
some pages with VoiceOver in Safari rather than using a name for this
problem or fix. For example:
"This is the bug where sometimes when a web page finishes loading,
VoiceOver can't interact and you have to use Command-R to reload it
and expose it to VoiceOver before you can interact? Yes, that's one of
the fixes in WebKit."
There's not enough information in the list posts to determine whether
all users encounter this problem on the same web pages, or whether it
depends on their available memory, type and speed of internet
connection, or state of their browser caches, etc. This does seem to
be something that WebKit handles much better, though. Maybe you'll
get more information in other responses to your post.
Similarly, I know there are instances where WebKit with VoiceOver
gives more information on labels for buttons where the same pages
produce no results under Safari. (This included Apple's MobileMe web
interface pages immediately after the transition from .Mac -- using
WebKit was initially the only way to discover the links for Mail,
Contacts, Calendar, Gallery, iDisk, and Account, although this was
later fixed. However, in the case of the MobileMe web pages some of
the examples I was going to use of features that were inaccessible
under Safari, but not WebKit, from a month ago -- one of the methods
for uploading files to public iDisk pages through a web page, for
instance -- are now fixed. So I don't know if WebKit is simply more
resilient against omissions in accessibility coding.)
• The main disadvantage to using the WebKit nightly builds is that
occasionally something that works gets broken. The most painful
recent example of this (for me), was when they redefined the access
key combination in Safari from the Control key to Control-Option --
the same keys used by VoiceOver. The access key combinations provide
an extremely efficient way to read through the Mailing List Archives
for this discussion list by allowing users to quickly read through
posts by topic (Control-p to navigate to a previous post in a thread;
Control-n to go to the next post in a thread) or read through posts
indexed in date order (Control-f to move forward in time; Control-b to
move back). You can also switch between a list of posts indexed
chronologically (Control-i) to posts listed by thread contents
(Control-c). In combination with an excellent search engine (that
supports Boolean searches, wild cards, date ranges, searches by
author, etc.) this is a great way to search for content in the
archived discussions, and to read through the ongoing discussions
related to these past topics. For more about searching and reading
through the archives using these features, see these two posts from
the archives:
http://www.mail-archive.com/[email protected]/msg46243.html
(Using Access Keys at the Mailing Archives for this list)
http://www.mail-archive.com/[email protected]/msg46245.html
(Using Search features at the Mailing List Archives for this list)
In any event, at the beginning of September the access key
combinations for the archives stopped being usable in WebKit (although
they continued to work in Safari), since sequences like Control-i and
Control-f were supposed to be replaced by Control-Option-i
(VoiceOver's item chooser menu command) and Control-Option-f (Find
command), etc. --- all pre-defined VoiceOver commands. The fix for
this in WebKit didn't take effect until about a month ago. This is
why the second post I linked in this reply has comments from another
list user giving a word of caution about keeping your last working
WebKit build handy.
I'm meaning for VoiceOver users specifically, and I'll be putting
the info in another ATMac article.
Thanks folks,
Ricky
--
Hope this helps to explain things. (And you can probably search for
more related discussion in the Mailing List Archives for this list at:
http://www.mail-archive.com/[email protected]/
Cheers,
Esther
