Jump to navigation Jump to search
This page is a translated version of the page Accessibility and the translation is 24% complete.

Other languages:
English • ‎Frysk • ‎Lëtzebuergesch • ‎Nederlands • ‎Scots • ‎dansk • ‎español • ‎français • ‎italiano • ‎polski • ‎português do Brasil • ‎русский • ‎中文 • ‎日本語

A accessibilidade do MediaWiki é a meta de fazer os sites de MediaWiki mais fáceis para navegar e ler. Enquanto isso destina-se principalmente a ajudar as pessoas com deficiências, também pode ser útil a todos os leitores.

As pessoas e organizações trabalhando na acessibilidade de MediaWiki

Feedback do DZB, Junho de 2010

In June 2010, some people from the German Wikimedia chapter visited the German Central Library for the Blind (Deutsche Zentralbücherei für Blinde, DZB) in Leipzig. One result of the visit was that the DZB agreed to look at Wikipedia's skin (at that point, Vector), and identify any accessibility problems. The first batch of results was then posted and discussed on wikitech (gossamer / pipermail). The conversation was mainly between Maria Schiewe and Simetrical. Here's a quick summary:


CSS uses a:hover but is missing a:focus; Thus, there's no highlighting when navigating links with the keyboard. This should be trivial to fix - or are there any problems with this?

tab order

The tab order is inconvenient. IE8 und FF3.6 show first the search box, then the show/hide toggles from the sidebar, then content, then the top bar, and only then the actual navigation items from the sidebar. This is probably because the toggles get inserted by JS, i guess. Opera 10 goes to searchm then the toggles, then back to search. That's bad.

collapsible menu

Screen readers need some indication that the item is clickable. An onclick event would help, but the only good way is WAI-ARIA.

presentational tables

Tables are used for layout a lot. This is mostly true for content, especially for Infoboxes, Navigation boxes, etc. This is quite bad for screen readers. It's going to be very hard though to get wiki editors to use proper css based code for table layouts.

  • 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.
  • 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).
  • WAI-ARIA provides a way to say that a table is presentational: the presentation role [1].
  • The original comment was actually about the box structure on the main page. Which is a presentational table. Infoboxes are, arguabley, "real" tables. Though often it's a real table wrapped in a presentational table, which is pretty bad.

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.

  • Special:Code/MediaWiki/68230 is a proof of concept for this
  • 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.
  • IE doesn't recognize display: table-*, and without that simulating presentational tables is a nightmare.
  • bugzilla:24583


In image thumbnail boxes, the "zoom" link is before the caption, so people have to skip over it every time. Perhaps it could be moved after the caption.


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?

  • might be a bug, Special:Code/MediaWiki/41837 changed the way alt attributes are handled.
  • 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.
      • wouldn't that result in the screen reader reading the text twice?
    3. If no alt text or thumb caption exists, use the file name (without px data added, without file extension, without _ for blanks).
      • why is this preferred to just not providing an alt attribute?
  • WAI-ARIA: aria-describedby. Drawback: That is currently only valid in HTML 5.
    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.)
  • handling of alt text currently differs depending on whether you use thumb, frameless or pixel w:de:Benutzer:Raymond/alt. Should 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.
  • 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." and "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)." [2]
  • 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.
  • bugzilla:24586

Feedback from the DZB, July 2010

As a follow-up to the #Feedback from the DZB, June 2010, we received a second batch of comments. This time, the feedback comes from a blind person actually using a screen reader (JAWS).

Guia de histórico escondida quando a janela do navegador é pequena

quando a janela do navegador é pequena (o que uma pessoa cega nunca saberia), algumas guias (como "histórico") são transferidas para um menu drop-down, colado a um ícone de seta para baixo. O menu desce quando o mouse é passado sobre o ícone. Isso é totalmente inacessível para pessoas cegas, o ícone não tem título ou qualquer outra indicação de que ele faz, não há nenhuma maneira para ativar o drop-down. Provavelmente, não existe uma maneira de navegar até lá usando o teclado.

Sugestões de pesquisa não acessíveis

the suggestions shown under the search field are not accessible via the screen reader. it's not announced, and it does not get read.

botões de edição não acessiveis

Alt-texto para botões de edição são lidos sem espaçamento entre eles, eles ficam atolados juntos. Também não ficou claro quais elementos são botões, que são links, etc. As pessoas cegas, provavelmente, não se incomodam com as barras de ferramentas de qualquer maneira e usam wikitext diretamente, mas eles devem ser capazes de explorar a funcionalidade e encontrar o seu caminho.

Outros bugs relacionados a acessibilidade

Ver também