最近、ウェブアクセシビリティ関連の話題が盛り上がっているように感じます。2023年2月には「Webアプリケーションアクセシビリティ」という本1も発売になり、勉強会なども盛んになっているようです。
ウェブアクセシビリティの話題が出るたびに引き合いに出されるのが、W3Cが策定しているガイドライン「Web Content Accessibility Guidelines (WCAG)」です。現状で勧告になっている最新のものはWCAG 2.1というバージョンで、ウェブアクセシビリティ基盤委員会のサイトで日本語訳を公開しています。WCAGのガイドライン本体だけでなく、「解説書」と「達成方法集」という関連文書も翻訳しています。
つい先日 (2023年3月)、これらの日本語訳を一部更新しました (WCAG 2.1 および関連文書 更新のお知らせ)。この記事では、今回の更新内容に触れながら、ウェブアクセシビリティ基盤委員会の翻訳作業についてご紹介したいと思います。
ウェブアクセシビリティ基盤委員会の翻訳作業部会
ウェブアクセシビリティ基盤委員会には、常設の作業部会が4つあります。そのうちの1つが、翻訳を担当する「作業部会4(翻訳)」です2。内部では「ワーキンググループ4」「WG4」などと呼んでいますが、外部の方向けには「翻訳作業部会」という言い方をすることもあります。この記事では以降、翻訳作業部会と表記します。
翻訳作業部会では、月に一度の定例ミーティングをオンラインで実施しているほか、Slackでやりとりしながら作業を進めています。作業の集約にはGitHubを利用しています。
日本語訳の更新
WCAG 2.1の原文は、W3Cによってメンテナンスされ、更新されています。WCAG本体の更新頻度は高くありませんが、解説書や達成方法集といった関連文書は、それなりの頻度で更新されています。
日本語訳のほうを放置していると、最新の原文とは内容が合わない部分が増えてきます。そこで、ある程度の差分が出たところで、原文との差異を確認し、更新部分を翻訳して反映するようにしています。
また、日本語訳には誤記や誤訳が見つかることもあります。お気づきの点をご連絡いただいた場合、翻訳作業部会のメンバーがGitHubにIssueを登録します。翻訳作業を進めているGitHubリポジトリは公開されていますので、GitHubのアカウントをお持ちの方であれば、直接Issueを登録したり、プルリクエストを作成したりすることもできます。
翻訳作業部会では、月に一回の定例ミーティングでIssueを確認し、対応について議論しています。対応が必要と判断した場合、必要に応じて翻訳の見直しを行っています。
今回 (2023年3月) の更新でも、翻訳の見直しを行ないました。その主な変更点について、修正内容とその理由をご紹介しましょう。
"large print"を「大活字」に
WCAG 2.1には4つの原則があり、その下に12のガイドラインが属する構成になっています。実際に満たすべき基準である達成基準は、12のガイドラインのいずれかに属します。原則とガイドラインは、達成基準をとりまとめる見出しのようなものだと思えばよいでしょう。
12のガイドラインのうちの最初の1つが、1.1という番号が振られている"Text Alternatives"です。
Guideline 1.1 Text Alternatives
Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
これは以下のように訳されていました。
ガイドライン 1.1 テキストによる代替
すべての非テキストコンテンツには、拡大印刷、点字、音声、シンボル、平易な言葉などの利用者が必要とする形式に変換できるように、テキストによる代替を提供すること。
ここで、"large print"を「拡大印刷」としているのは誤りではないかという意見が出ました (ガイドライン 1.1:「拡大印刷」でよいか #1548)
"large print"は単純に直訳すると「大きな印刷」ですから、一見すると「拡大印刷」でも特に問題がなさそうに思えます。
しかし、よく考えてみるとおかしなことに気づきます。このガイドラインは「テキストによる代替」に関するものです。テキストによる代替によって可能になる処理の例として、以下が挙げられています。
- large print (拡大印刷)
- braille (点字)
- speech (音声)
- symbols (シンボル)
- simpler language (平易な言葉)
コンテンツを点字、音声、シンボル、平易な言葉などに変換したい場合、テキストの情報が必要になるのはわかります。しかし、拡大印刷はどうでしょうか。テキスト情報を持たない画像であっても、単純に拡大することはできるはずです。"large print"に、なぜテキスト情報が必要なのでしょうか。
あらためて辞書で"large print"の意味を調べてみると、「大活字」という訳があることがわかります。"large print book"が「大活字本」と訳されていることもわかります。大活字本とは、主に視力の弱い方に向けて、大きな文字を使って組み直した本のことです。
つまりここでは、単に大きく印刷することを想定しているのではなく、コンテンツのうちテキストだけを大きくしたり、行間を広げたりすることを想定しているのです。それを行うためには、テキスト情報が必要になります。
翻訳作業部会で議論した結果、"large print"は「大活字」と訳すことにしました。「大活字」という単語には馴染みのない人も多いのではないか、という意見もあり、訳注をつけることも検討しましたが、「大活字」という言葉は専門用語の雰囲気を醸し出しているので、気になった人は検索して調べるだろうと考え、いったん訳注はなしにしました。もし要望があれば、訳注の追加を検討するかもしれません。
"Readable"を「読み取り可能」に
12あるガイドラインのうちのひとつに、3.1という番号が振られた"Readable"というものがあります。
https://www.w3.org/TR/WCAG21/#readable
Guideline 3.1 Readable
Make text content readable and understandable.
これを以前は「読みやすさ」と訳していました。
ガイドライン 3.1 読みやすさ
テキストのコンテンツを読みやすく理解可能にすること。
ですが、ここでのニュアンスとしては、読みやすい、読みにくいという話ではなく、読めるかどうかを問題にしているのではないか、という主旨の意見が出ました (ガイドライン3.1は「読みやすさ」か? #1412)。
"accessibility"を「使いやすさ」と訳すことには違和感がある、という話はよく出ますが、それと同じような意見です。
また、ガイドライン 3.1の説明文をよく見ると、後半には"understandable"とあり、こちらは「理解可能」と訳されていました。同じ"-able"で終わる単語なのに、訳し方が違うのは気になります。できれば揃えたいところです。
実は、"understandable"は4つの原則のうちの3番目のもので、このガイドライン3.1の親見出しに相当するものです。こちらの訳を変えるのは、なかなか難しいところです。
同じ原則に属する他のガイドラインも見てみると、3.2は"Predictable"となっています。
https://www.w3.org/TR/WCAG21/#predictable
Guideline 3.2 Predictable
Make Web pages appear and operate in predictable ways.
訳はこのようになっていました。
ガイドライン 3.2 予測可能
ウェブページの表示や挙動を予測可能にすること。
こちらでは"predictable"を「予測可能」としています。これをみると、"Readable"も「……可能」と訳した方が良さそうです。
議論した結果、「読み取り可能」という訳を採用することになりました。
"Error Prevention" を「誤り防止」に
ガイドライン3.3は"Input Assistance"というもので、「入力支援」と訳しています。そこに属する達成基準のひとつ、3.3.4に"Error Prevention (Legal, Financial, Data)"というものがあります。
https://www.w3.org/TR/WCAG21/#error-prevention-legal-financial-data
Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data)
以前はこれを、以下のように訳していました。
達成基準 3.3.4 エラー回避 (法的、金融、データ)
「エラー回避」となっていますが、ここでは「避ける」ことを意味しないのではないか、という意見が出ました (達成基準 3.3.4, 3.3.6:エラー回避は意訳過ぎないか #1425)。達成基準の説明をみると、要求されているのは以下のようなことです。
取消: 送信を取り消すことができる。
チェック: 利用者が入力したデータの入力エラーがチェックされ、利用者には修正する機会が提供される。
確認: 送信を完了する前に、利用者が情報の見直し、確認及び修正をするメカニズムが利用できる。
必要なのは、利用者が送信後に送信を取り消したり、送信前に送信内容をチェックできることです。
Web制作の文脈において、カタカナで「エラー」と書くと、システムが出すエラーを連想することが多いと思います。「エラー回避」と言われると、フォーム入力の際にシステムのエラーが出ないようにする、と受け取る方も多いのではないでしょうか。
しかし、英語のerrorという単語は、人間のミスにも使います。ヒューマンエラーという言葉もありますし、野球にもエラー(失策)という用語があります。それらと同様に、この文脈ではシステムのエラーではなく、人間によるミスを指しているように思えます。
「エラー」という言葉自体が誤解を招きそうだということで、議論の結果、"Error Prevention"は「誤り防止」とすることにしました。
終わりに
翻訳作業部会の活動と、今回翻訳を更新した箇所について、作業部会の内部の議論も含めてご紹介しました。
先にも触れましたが、翻訳作業を進めているGitHubリポジトリは公開しており、どなたでもIssueの登録が可能です。今回の記事では詳しく触れていませんが、実際に外部の方からIssueを登録いただいたり、プルリクエストをいただいたケースもあります。
また、作業にご協力いただける方の募集もしています。
どなたでも簡単に翻訳作業に参加できる体制を作りたいと思っていますので、翻訳に関する議論に参加したい、実際に手を動かしたいという方がいらっしゃいましたら、ご連絡ください。
もちろん、翻訳の誤りをこっそりご連絡いただくだけでも大歓迎です。みなさまのご協力が翻訳の品質向上、そして日本のウェブアクセシビリティの向上につながりますので、お気軽にどうぞ!