Jacob Schmude wrote:
Actually will I have to disagree on these points, I'd just as soon not
have them as I always turn them off anyway. I find that I can always
identify a table by context and, further, that often the Windows screen
readers identify tables where I don't want to know--tables used for
layout for example.
Sounds like their algorithms could do with fine-tuning, but it's not
just about announcing tables; it's also about navigation of complex data
tables (e.g. reliably moving to the next row or column when cells
contain multiple lines and links) and reliably identifying what the
headers for a given cell. Of course, people differ in terms of how much
they need to interact with tables.
I like as little verbosity as possible to be
honest--let me read the information and I'll decide how to interpret it.
Nevertheless for those who do want them these options should be
configurable, but I wouldn't want them forced on me.
Yep, verbosity settings are pretty crucial here, as user preferences
differ dramatically.
One thing I would like to see is the ability to read longdescs and/or
title tags make it into the systemwide Webkit framework
Out of interest, do you have an example of the long descriptions you
want to read? I believe the WebKit developers are operating on the
belief that most longdesc attributes are junk.
Also, do you have an example of the title attributes you can't read?
As far as I know, the VoiceOver Help command (Control Option H) will
read a title attribute on the focused element. (In my current WebKit
build, it erroneously reads the title attribute in preference to link text.)
Is your problem that you want the presence of the title attribute
announced, or the attribute read out automatically, or what?
> One final thing I'd like to see implemented is that it
would tell us if images and items are clickable that are not links--in
otherwords, elements with onClick and onMouseover functions.
Identifying elements with onclick and onmouseover attributes is
certainly possible. Unfortunately, this only catches a subset of
clickable and hoverable items, because better-quality code keeps content
and behavior separate by attaches event handlers through script, not
HTML attributes, and ideally attaches them to a higher element in the
tree than the one you actually click on. For example, if you have a
module containing clickable items, you might listen for clicks on the
module and, in the handler, detect if the click was on a clickable item
or not. (This is called event delegation.)
Unfortunately, the solution here appears to be better markup.
--
Benjamin Hawkes-Lewis
