May I please offer some suggestions on how to approach this? If you're
willing to run beta software and are reasonably technical-minded, it's
probably best to report many webpage rendering, navigation, and
behaviour issues to the WebKit bug tracker rather than to
[EMAIL PROTECTED] In my experience, Apple developers review
WebKit accessibility bugs and add RADAR numbers (used for internal
tracking of bugs in WebKit by Apple). An advantage of reporting via the
WebKit bug tracker is that your report is publicly accessible, so other
members of the community can see it and non-Apple WebKit developers can
work on it.
Before reporting an issue via the bug tracker, you should test the most
current behaviour in a WebKit Nightly build having installed Safari 3
Beta. You should select Accessibility from the Component dropdown in the
bug report form. You'll need to provide an example URL. In the
description field you should give a description of the problem, details
of your VoiceOver configuration, and precise steps to reproduce the
problem. For more guidance on reporting WebKit bugs see:
http://webkit.org/quality/reporting.html
http://webkit.org/quality/bugwriting.html
You can review all 62 reported WebKit accessibility bugs (including a
few that have hopefully been fixed) at the following URL:
http://urlx.org/bugs.webkit.org/3017b
If you want to chat with some WebKit developers, you can find them in
the #webkit channel on Freenode IRC.
Obviously, when comparing the performance of Safari 3 Beta to the
VoiceOver improvements forecast for Leopard, don't forget you're still
using Tiger's copy of VoiceOver.
Now I'm going to try and deal with some of the specific points Gordon
raised.
Gordon Smith wrote:
For example, HTML tables are not identified at all.
Tables aren't specifically mentioned in the Leopard preview as an item
that will be described, and judging by the Accessibility Inspector,
WebKit currently provides no hint to VoiceOver that tables are tables
rather than a generic group. So it would definitely be worth people
raising that with [EMAIL PROTECTED]
Multi-selection list boxes just don't work.
Interesting. Would you be able to provide an example URL that
demonstrates that problem?
> Onclicks, (what JFW calls clickables), just don't work.
Click handling is a complex issue. Basically, some code to handle a
click can be attached to any element on the page. Thanks to earlier
attempts to bake accessibility into popular mouse-orientated coding
practices, sometimes pressing a key can effectively trigger a "click"
event. I'm not sure precisely what range of click events JFW can
trigger. Can you give an example URL featuring an "onclick" that doesn't
work and explain how you are attempting to trigger it?
Anchors (what some call same-page links), just don't work.
This is also quite a complex issue. I'd avoid the term "anchor" in this
context as it can mean several different things, and I'd also avoid the
term "same-page link" as it's too restrictive. HTTP (the communications
protocol underpinning the web) provides a mechanism for linking to
specific parts (fragments) of a webpage, in the following form:
http://www.example.com#example-fragment
Note the all-important hash symbol preceding the fragment identifier.
This link might be on the same page, or it might be on another page. In
current HTML, particular elements can be given fragment identifiers to
allow them to be targeted in this way. There are various different forms
of markup to do this.
The way Safari handles this sort of link is to open the document and
scroll the viewport to the targeted element, but not to move keyboard
focus to the element. As a result, VoiceOver users are none the wiser.
This is a serious accessibility issue, breaking skip links, precise
references, and same-page links, and one I'd intended to report myself.
However, I got bogged down in trying to work out both what the
specifications said browsers should do (which turned out to be
confusing) and what other browsers actually do in reality (which turned
out to vary wildly depending on the browser and the specific markup
used). I hope to return to this topic eventually. But don't wait up on
me to report problems with fragment identifiers in Safari. <grin>
Don't demand, I don't think that will get us far.
Yeah, I guess by "demand" I meant to politely but emphatically explain
how and why a particular feature is important to you. I'm not suggesting
you adopt a confrontational manner; rather, I'm suggesting you be vocal
rather than continue to hope quietly that developers will do the right
thing without your help. As the old adage goes: "the squeaky wheel gets
the grease".
If we also had a way to navigate by controls, similar to the item and link
chooser menus, I think that would also be a huge help.
Can you please explain a bit more about this idea? In particular, what
do you mean by "control"? Is a link ever a "control"? How about an <A>
element that triggers a scripted action rather than linking somewhere?
Or do you mean a list of form entry fields? And if so, would it be best
to group them by form, since you might have fields with the same name in
more than one form? How would you like the navigation to work in an
ideal world?
--
Benjamin Hawkes-Lewis
