2010/6/18 Daniel Kinzler <daniel(a)brightbyte.de>de>:
3) 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?
6) 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(a)wikimedia.de> wrote:
We discussed this some weeks ago in the German
Wikipedia. The preferred solution would be:
1. If [[File:...|alt=...|...]] is given, use this text for the alt attribute.
2. If no alt text is given, use the text given as the thumb caption.
3. 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(a)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:
1. If [[File:...|alt=...|...]] is given, use this text for the alt attribute.
2. If no alt text exists, use the “simplified” file name.
3. 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.