On Fri, Jun 18, 2010 at 2:27 PM, Maria Schiewe
<maria.schiewe(a)wikimedia.de> wrote:
It’s not about the screen reader preventing the
interaction. The interaction will be the same as for keyboard-only users. The problem is
that there is no indication that the element can be interacted with. It is a heading level
5. How can you know, it does something? The small arrow is not visible to blind people.
What can we do? If you use onclick="" JAWS, for example, will indicate that the
element is clickable, so the user will either use the space or enter bar or the routing
keys of the Braille display to interact with the heading. (Note: The element does not
necessarily have the focus but rather a virtual focus within the screen reader’s view of
the website. The screen reader then handles the clicking or focussing, so we must somehow
tell it that there is interaction possible.) If you have one of the new screen readers
supporting WAI-ARIA, you could build a semantically understandable menu (see
http://www.w3.org/TR/wai-aria-practices/#menu).
I don't know what we can do, since I'm not familiar with how AT works.
However, I'm pretty sure that making it height: 0 instead of display:
none is not a good solution. If it actually works at all to hide
stuff from AT, it's only because the AT is buggy, and we shouldn't
rely on that. Kind of like setting "position: absolute; left:
-1000000px". Giving it an onclick handler sounds like a much better
idea, if that will work. (We can keep the existing onmousedown
handler too, so sighted users' experience doesn't suffer.)
I don't know why JAWS treats onclick differently from onmousedown here, though.
Divs are not spoken, but sometimes indicated by a
blank line. Whenever you read from one cell to another, you usually get information about
your position within the table, the reference to the header etc. If you have boxes really
displaying data in a tabular way, that’s fine. But it’s not fine to have tables merely for
the sake of layout. (That’s one core thing repeated by accessibility experts again and
again.) You will get all this positional information which wouldn’t make any sense and
slow down your reading. So, yes: div soup is better than table soup. (Screen reader do
have some heuristics to detect layout tables and treat them differently, but the results
are varying.)
Oh, I see. That's really terrible, then, and we should avoid
presentational tables if at all possible. I think this really has to
be done on the content side, though, not on the software side --
auto-translating tables to divs sounds like a bad idea.
Maybe we could remove attributes like cellpadding, cellspacing, align,
etc. from the attribute whitelist. That would make it much harder to
use presentational tables, wouldn't hurt non-presentational table use
much, and would also improve our standards conformance (HTML5 bans
them). We'd have to announce this way in advance and give people
tools to adapt content before we break everything, but it'd be doable
if we really wanted.
Ah, shame on me. I totally forgot about the
recommendation. This is useful and we should follow it.
I'm fine with that. However, I'm not sure if we should assume that
images are probably presentational, or that they're probably
meaningful. A lot of images on Wikipedia are decorative, but a lot
aren't. If we omitted the alt attribute entirely, it would help to
alert people by triggering validation errors, so maybe that's the best
approach. It would help if we gave people tools to spot bad alt text
-- like have a preference that displays alt text in small print under
the image, with a clear warning if there's no alt text specified.