2010/6/18 Daniel Kinzler daniel@brightbyte.de:
- hidden (collapsed) menus use display:none. This makes them inaccessible to
screen readers, etc. Alternative ways for hiding them might be better - such as setting the hight to 0. Has this been tried?
display: none seems completely appropriate here. The screen readers should allow the user to expand the menus just like sighted users can -- if that can't be done, that's what should be fixed.
Also, would it be possible to detect at least the most popular screen reader plugins with JS, so a special mode could be triggered for the visually impaired?
That sounds unreliable . . . you probably can't detect this reliably, and if you could, the other mode probably wouldn't be maintained as well as the primary one. Is this necessary?
Perhaps it would be possible to make {|...|} generate a div-based layout using some magic word or option? This would be so easy with a real parser :) But doTableStuff() looks fairly sane, so perhaps it could be done.
This sounds like it's very impractical just on an HTML level. You'd have to duplicate the display exactly, and table-based display is very hard to replicate exactly in CSS. For one thing, table-based display is actually not defined exactly by any standard at all. Also, I'm not sure what the actual benefit would be -- do screen readers treat div soup better than presentational tables?
- Image thumbnails have an empty alt attribute. This seems like a bug to me -
was it always like this? I suggest to use the image's file name in the alt-attribute of the img tag, and also as the title of the link that wraps the thumbnail. After all, the target of that link is indeed the description of the image file. Could we just implement this, or are there any problems I didn't think of?
I've never been clear on what's the best thing to do here. Don't add alt at all (so screen readers can fall back intelligently)? Use the filename? I'd think it would be best to not add alt at all, if we think the image isn't presentational, so user agents can handle it intelligently. This is what HTML5 currently recommends:
"As a last resort, implementors should either set the alt attribute to the empty string, under the assumption that the image is a purely decorative image that doesn't add any information but is still specific to the surrounding content, or omit the alt attribute altogether, under the assumption that the image is a key part of the content." http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#guidance-for-markup-generators
On Fri, Jun 18, 2010 at 10:57 AM, Maria Schiewe maria.schiewe@wikimedia.de wrote:
We discussed this some weeks ago in the German Wikipedia. The preferred solution would be:
- If [[File:...|alt=...|...]] is given, use this text for the alt attribute.
- If no alt text is given, use the text given as the thumb caption.
- If no alt text or thumb caption exists, use the file name (without px data added, without file extension, without _ for blanks).
For (2), wouldn't that result in the screen reader reading the text twice? Some captions can be pretty long. We used to do this, but eventually changed it, IIRC in response to complaints.
Also, why is (3) preferred to just not providing an alt attribute (other than standards conformance)? HTML5 currently recommends against this explicitly:
"Markup generators should generally avoid using the image's own file name as the alternative text. Similarly, markup generators should avoid generating alternative text from any content that will be equally available to presentation user agents (e.g. Web browsers)." http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#guidance-for-markup-generators
If this is wrong, then maybe that text in HTML5 should be changed.
On Fri, Jun 18, 2010 at 11:41 AM, Maria Schiewe maria.schiewe@wikimedia.de wrote:
I have a second suggestion for the alt problem that will require the use of WAI-ARIA, namely aria-describedby. Drawback: That is currently only valid in HTML 5. But it would be the better solution since alternative text and caption text are two different things (see also http://en.wikipedia.org/wiki/Wikipedia:Alternative_text_for_images).
Using WAI-ARIA the solution would be:
- If [[File:...|alt=...|...]] is given, use this text for the alt attribute.
- If no alt text exists, use the “simplified” file name.
- Add aria-describedby="ImageCaption" to the img tag. (With ImageCaption being the id of the caption.)
The screen reader then can associate the caption with the image.
What would the practical effect of aria-describedby be in a typical screen reader, compared to the status quo?
P.S. Please not that the handling of alt text currently differs depending on whether you use thumb, frameless or pixel (see http://de.wikipedia.org/wiki/Benutzer:Raymond/alt). It must be consistent.
This is for historical reasons. The unnamed parameter is used for a caption if there's a caption, and used for alt text if there's not. I wanted to change this when adding the alt= parameter, so that it would be consistent, but Brion thought it was best to remain compatible with existing content that used the unnamed parameter as alt text.