On 9/3/07, Danny B. <Wikipedia.Danny.B(a)email.cz> wrote:
* the crossbrowser compatibility - I saw couple
scripts or styles which operated
in Gecko based browsers (Firefox & co.) as intended, but in IE it was completely
unusable.
There are none of those that I know of in MediaWiki proper, *if*
you're using the latest version of a non-defunct browser. If you're
using IE6, for instance, you won't get some of the link icons for
different media types, since those use CSS3 selectors not implemented
until IE7. We aren't necessarily going to test really marginal
browsers either, and if you're using something like lynx your viewing
experience is unlikely to be ideal. We do, though, fall back to
something usable on any browser, just you won't get some of the perks
in some cases, and things might occasionally not work as expected.
So I'd like some clearer wording before this proviso becomes added to
any sort of guideline. Obviously you're not going to get the same
functionality if you use an old, crippled, or broken browser. The
site's basic usability shouldn't be reduced, but if you miss out on
some neat extras then that's life. Leaving out such features just
shouldn't be gratuitous, is all (being too lazy to make a non-JS/CSS
equivalent for something).
* the accessibility issue - (not necesarily software
issue, but tightly related with
previous item) since we declare being "open" encyclopedia, we should take care
about having pages accessible at least against WCAG Single A and/or Section
508 guidelines.
Note that much of this is on the content level, not the software
level. But let's see:
We basically don't allow 1.1 to be passed for user content. 1.2-1.4
are irrelevant to default MediaWiki, that I can see. 2.1 is, I think,
followed in the software (color is used for emphasis or highlighting,
but never color alone). We fail 4.1. 5.1-5.2 are irrelevant. We do
very nicely on 6.1-6.3. 7.1 is no problem. 8.1, 9.1, and 12.1 seem
irrelevant for now. 14.1 we do pretty well on, but that's mainly a
content issue.
So, our only real problems seem to be checkpoints 1.1 and 4.1:
1.1 Provide a text equivalent for every non-text element (e.g., via
"alt", "longdesc", or in element content). This includes: images,
graphical representations of text (including symbols), image map
regions, animations (e.g., animated GIFs), applets and programmatic
objects, ascii art, frames, scripts, images used as list bullets,
spacers, graphical buttons, sounds (played with or without user
interaction), stand-alone audio files, audio tracks of video, and
video.
For example, in HTML:
* Use "alt" for the IMG, INPUT, and APPLET elements, or provide a
text equivalent in the content of the OBJECT and APPLET elements.
* For complex content (e.g., a chart) where the "alt" text does
not provide a complete text equivalent, provide an additional
description using, for example, "longdesc" with IMG or FRAME, a link
inside an OBJECT element, or a description link.
* For image maps, either use the "alt" attribute with AREA, or use
the MAP element with A elements (and other text) as content.
4.1 Clearly identify changes in the natural language of a document's
text and any text equivalents (e.g., captions). [Priority 1]
For example, in HTML use the "lang" attribute. In XML, use
"xml:lang".
1.1 isn't failed by anything in the software itself, I don't think,
but we make it practically impossible for in-article images to pass
it. 4.1 isn't followed anywhere, we have one big lang attribute for
everything last I checked.