On 9/3/07, Danny B. Wikipedia.Danny.B@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.