Accessibility/ja

MediaWiki のアクセシビリティとは MediaWiki サイトを閲覧しやすくするという目標です. もともとは障害者への補助を意図していましたが、どんな読者にも助けになりえます.

MediaWiki のアクセシビリティに携わる人と組織

 * 「すべての人が使えるように」（ICTユーザ補助のスイスの団体）; W3Cによるウェブ・アクセシビリティ指導要綱（WCAG）2.0に基づく、段階的アクセシビリティ分析. （英語）
 * この分析手法はウィキメディアドイツ支部（WMDE）のKai Nissenと「サードエイジ・オンライン」（Third Age Online=TAO）AALプロジェクトの協同で完成
 * 上記で提言された課題の大部分は機能強化やテーマ関連で、その他は編集ガイドラインの設定または再定義を伴わないと実現できないものです.
 * ルシア・グレコ Lucia Greco ユーザー補助技術専門家（カリフォルニア大学バークレー校）
 * サミ・ムバラク Sami Mubarak - MediaWiki の視覚障害者向け補助を担当（アラビア語）（カタールの非営利組織ユーザー補助技術センター）
 * ケイティー・フィルバート Katie Filbert - ユーザ補助の改善に関心を持ちハッカソン開催をサポート（ウィキメディア・ワシントン特別区支部）
 * アンドレア・ザニ Andrea Zanni - ウィキソースが新人ユーザーにとって便利で使いやすくなるよう、ウィキメディア・イタリア協会はソフトウェア開発に投資しています. （協会加入が会費制）
 * アディ・クシュニル Adi Kushnir - 2011年ウィキマニアでユーザ補助のセッション（英語）の開発者参加日程でリーダーを補助、修正が必要な箇所を協議.
 * ウィキメディア・フランス協会はウィキメディアのユーザ補助に関心を持っており、現状の監査や将来の活動のロードマップ作りを目指しています.
 * Jopparn - ウィキメディアの研究員制度に応募したユーザ補助プロジェクト計画（英語）.
 * ウィキプロジェクト:アクセシビリティの参加者一覧 - 他のウィキにも保存されているかも？
 * マリア・シーウェ Maria Schiewe、 Danny B.、ローデン・バリー Rodan Bury - 2010年ウィキマニアでアクセシビリティに関する発表とワークショップを主催（英語）.
 * Danny B.とマリア・シーウェ - アクセシビリティのイニシアチブの発起人（英語）.
 * Mark Holmquist - ウィキメディア財団職員で、アクセシビリティの課題を進んで手伝います.
 * Derk-Jan Hartman (thedj) - ソフトウェア開発者として開発者向けユーザ補助ガイド（英語）を担当.
 * Hoo man (Marius Hoch) - 2013年、ウィキメディア・ドイツ支部と協力してa11yバグを修正.
 * ウィキメディア・スウェーデン（Wikimedia Sverige）- ウィキペディアの記事のユーザ補助を進めるため「Wikispeech」（ウィキスピーチ）というMediaWikiの文書読み上げ拡張機能を開発中. 参加希望者は連絡をお願いします.

DZBからのフィードバック(2010年6月)
2010年6月にウィキメディア・ドイツ支部の人々がライプツィヒのドイツ視覚障害者図書館（Deutsche Zentralbücherei für Blinde= DZB）を視察しました. その成果としてDZBにウィキペディアの外装（当時はベウター）をアクセシビリティの問題がないかどうか評価してもらう合意に至りました. 評価結果の第1便はウィキテックに掲載して協議しました（gossamer 2010年6月18日号 / pipermail 2010年6月20日号）. 主にマリア・シーウェとSimetricalがかわした会話のまとめは次のとおりです.

a:focus
CSSにa:hoverはあるがa:focusが欠損している. そのため、キーボードでリンクをナビゲートする場合、強調してあるものが見つからない. 修正対象としては細かすぎるのか - あるいは問題を避けるために改善しないのか？
 * 少なくともベクター外装であれば、Special:Code/MediaWiki/70015で修正できるはず.

タブオーダー
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.
 * 24581

折りたたみメニュー
Screen readers need some indication that the item is clickable. An onclick event would help, but the only good way is WAI-ARIA.
 * 23428

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.
 * 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.
 * 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.
 * 24584

alt属性
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:
 * If ... is given, use this text for the alt attribute.
 * 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?
 * 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.
 * If ... 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.)
 * 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)."
 * 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.
 * 24586

DZBからのフィードバック(2010年7月)
に続き、評価結果の第2便が届きました. 今回は実際にスクリーンリーダー（JAWS）を使うある視覚障害者の評価です.

ブラウザーのウィンドウが縮小してあると履歴タブが隠れる
ブラウザのウィンドウが縮小してある場合（視覚障害者には判断できない）、例えば「履歴表示」などタブの一部はドロップダウン・メニューに格納され、下向きの矢印が貼りついてしまう. アイコンにカーソルが触るとメニューが展開する. このアイコンにラベルその他何をするか説明が付いていないため、ドロップダウンメニューを開く手がかりがなく、視覚障害者にはまったく利用できない. またキーボードの入力でそれらの操作をする方法もないように感じている.
 * 24590、24298

検索候補のアクセシビリティが低い
検索語の入力領域の下に表示される検索候補は、スクリーンリーダーで利用できないし、利用できないことを知らせていない上、リーダーで読み上げができない.
 * 24591

編集ボタンのアクセシビリティが低い
編集ボタンに割り当ててあるAlt-Textを読み上げさせると、語句の間に区切りが入らず、1つの単語のように繋いでしまう. またボタンかリンクかなど、要素の種類が判別できない. 視覚障害者はツールバーを利用しようとは考えず、直接、ウィキテキストを利用するのではないかと思うが、それでもどんな機能があるか自分で調べたり、自分流の使い方を試したりする方法は与えられるべき.
 * 24592

アクセシビリティ関連のその他のバグ

 * Bug 11555 - 節見出しよりあとに節の編集リンクが来るべき：理想としては見出しには節のタイトルのみ表示し、編集リンクを含むべきではない.


 * キーワードに"accessibility"を含むすべてのバグ

関連項目

 * Accessibility guide for developers&mdash;開発者向けアクセシビリティガイド
 * Wikipedia:アクセシビリティ
 * Wikipedia:WikiProject Accessibility&mdash;ウィキプロジェクト アクセシビリティ
 * Accessibility&mdash;ウィキペディアのアクセシビリティを協議する場
 * Accessibility&mdash;2011年までユーザビリティを協議したウィキ.
 * Accessibility and usability cleanup - 関連ページと終了したページへのリンクダンプ（完全版ではない?）&mdash;アクセシビリティとユーザビリティの修正関連