On Fri, Jun 18, 2010 at 2:27 PM, Maria Schiewe <maria.schi...@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. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
