Webサイトのアクセシビリティを高めるための方法や国内外の関連情報など、さまざまな角度からWebアクセシビリティに関する話題をご提供します。

当Blogの更新情報は、Twitter経由でも配信しています。興味のある方はぜひ、@mlca11yをフォローしてください。

リデザインされたARIA Authoring Practices Guideについて

アクセシビリティ・エンジニア 中村(直)

先月の話になりますが、毎年5月の第3木曜日に行われる(今年は5月19日に行われた)Global Accessibility Awareness Day (GAAD)にあわせて、WAI-ARIA Authroing PracticesがリデザインされたARIA Authoring Practices Guideが公開されました(ARIA Authoring Practices Guide (APG) - New User Interface)。

GAADがどういったイベントなのかについては、GAAD公式の説明を見ていただくとして、ARIA Authoring Practices Guide(以下ARIA APGとします)の話を進めます。

冒頭に記載したとおり、ARIA APGはWAI-ARIA Authroing Practicesの後続となる文書です。以前は、WAI-ARIA Authoring Practices 1.1WAI-ARIA Authoring Practices 1.2のいずれも、ARIA APGへのリンクが張られていた状態でした。執筆現在では、WAI-ARIA Authroing Practicesの以下のURLはすべて、ARIA APGへリダイレクトされます。

WAI-ARIA Authroing Practicesで最後のWorking Group Noteとなった2021年11月29日付けのWAI-ARIA Authoring Practices 1.2とARIA APGを比較しますと、

  • 1. Introduction、B. Change History~D. ReferencesがARIA APGではAboutのページに集約
  • 2. Read Me First、4. Landmark Regions~11. Structural RolesがARIA APGではPracticesからの個別ページへのリンクに
  • コアとなる3. Design Patterns and WidgetsはPatternsからの個別ページへのリンクに
  • A. IndexesはIndexのページに付け替え

以上のように再編成されています。複数のページに分割されたリデザインということもあり、取り付きやすさは向上したといえるでしょう。個人的には、目当てのroleがわかっている状態でIndexのページから、ページ内検索でたどっていくという状況が増えたように思います。

また、WAI-ARIA Authroing Practicesの1.1を見ればよいのか、1.2を見ればよいのかという問題も、URLが一本化されたことで気にする必要がなくなりました。個人的には、あるroleがWAI-ARIA 1.1で既に定義されているのか、WAI-ARIA 1.2で導入されたものなのか...と確認することがありました。しかし、この一本化により、Authroingの観点からはバージョンについて、そこまで深く考える必要がないのかもしれないと捉えているところです。

iOSの画像認識の活用方法と今後への期待

アクセシビリティ・エンジニア 大塚

スマートフォンは私を含めた多くの視覚障害者にとって、日常生活を送るうえで必要不可欠なものとなっています。Webサイトから情報を得たり、SNSなどでコミュニケーションをとるといった目的でももちろん使用するのですが、もう1つ重要な目的があります。それは、目の代わりとして、日常生活を送るうえでの課題を解決するというものです。わかりやすい例としては、OCRや画像認識を利用して、文字や物の色といった本来視覚から得られる情報を補うというものがあります。

スマートフォンのカメラを使った文字や画像の認識そのものは、以前から可能でした。しかし、ここ数年で、Seeing AIEnvision AIなど、利用できるアプリの選択肢が増えたり、文字や色の認識精度も向上し、比較的精度の高い情報が手軽に得られるようになりつつあります。私自身も、自宅に届いた郵便物の大まかな内容を把握したり、服の色を調べるといったことができるようになるなど、多くの恩恵を受けています。

Seeing AIが印刷物の文字情報を読み上げているところのスクリーンショット

Seeing AIの操作画面

そして最近の話題に目を向けると、音や振動で信号機の状態を伝えるOKOというアプリが開発されたり(日本では早期アクセスへ申し込むことでベータ版が利用できます)、今年の秋リリース予定のiOS16にドアまでの距離を認識するドア検知機能が追加されるなど、今後は屋外での移動中というこれまでとは違った状況でも画像認識を活用できるようになりそうです。

屋外では周囲の状況に気を配りつつカメラを向ける必要があるため、そもそも対象物にカメラを向けづらかったり、短時間しかカメラを向けられないなど屋外特有の様々な課題があることが想像できます。一方、操作方法の工夫や画像認識技術の向上により、ある程度の部分は解消できるのではとも考えています。屋外での画像認識についても、文字や色の認識のように精度が向上し、日常的に利用できるようになってほしいです。そして、より安全に、安心して屋外を歩けるようになることに期待したいです。

アクセシビリティオーバーレイのとりとめもない話

アクセシビリティ・エンジニア 中村(直)

「ウェブアクセシビリティ閲覧支援ツール」と称する、一般にはアクセシビリティオーバーレイと分類される技術あるいはサービスが、じわじわと国や地方自治体のWebサイトに導入されつつあります。なお、特定のサービスに対してものを言いたいわけではないので、具体的な名称はここでは取り上げません。どういったものがアクセシビリティオーバーレイとされているのかについては、Overlay Fact Sheetを参照してください。

さて、前述のOverlay Fact Sheetや、あるいはCTO木達のコラム「アクセシビリティ オーバーレイに対する見解」でも述べられているように、国内外のWebアクセシビリティの専門家からはアクセシビリティオーバーレイはネガティブな見方をされています。アクセシビリティオーバーレイについて、これはダメなものである、とするのは簡単なことでしょう。しかし、そうはいっても国内外で採用されているという現実に対して、筆者を含むWebアクセシビリティの専門家は目を向けるべきなのかもしれません。

アクセシビリティオーバーレイの導入のきっかけはさまざまでしょう。アクセシビリティオーバーレイのサービスを提供している企業から持ちかけられたのかもしれませんし、あの自治体や省庁が導入しているから、ウチも導入してみようなのかもしれません。導入するサイト担当者のWebアクセシビリティの知識や理解の不足が要因として挙げられると思いますが、一方でサイト担当者がアクセシビリティオーバーレイを導入しないと決められるだけの判断材料をWebアクセシビリティの専門家は十分に提供できていると言い切れるでしょうか。

そのような判断材料だけでなく、Webアクセシビリティに関する情報という観点では、日本語の情報をより拡充していく必要があると思っています。例えば、WCAGを発行しているW3Cは、W3C Accessibility Standards Overviewのようなアクセシビリティの理解に役立つ情報を提供しています。このW3C Accessibility Standards Overviewは、英語のほかに8カ国語に翻訳されていますが、残念ながらその中に日本語は含まれてはいません。

アクセシビリティオーバーレイの機能の中には、ブラウザーやOSで実現可能なものがあるとはいうものの、そういった機能を必要とするユーザーが知らないからこそ、アクセシビリティオーバーレイの恩恵を受けるというシーンもあるのかもしれません。果たしてITにあまり明るくないユーザーに対して、そういったブラウザーやOSの機能をわかりやすく説明できているでしょうか。

Webサイト提供者やサイト制作者だけでなく、ユーザーもスパイラルアップしていく必要があるわけです。また、OSや支援技術、ブラウザーといったハードウェア・ソフトウェアも進化を促していく必要があります。そういった底上げがされてはじめて、アクセシビリティオーバーレイという機能がなくてもいいよね、という合意形成がなされるのかもしれません。

ライトニングトーク「WCAG 2.2で追加される達成基準」のフォローアップ

取締役 木達

去る5月14日、TechFeed Conference 2022において、「WCAG 2.2で追加される達成基準」と題したライトニングトークを行いました。スライド(PDFファイル)は、以前からアクセシビリティ部で運用していたSlideShareのアカウントにアップロードのうえ共有したのですが、SlideShareの特徴であった内容のテキスト表示機能が、いつの間にか利用できなくなっていました。

別のWebサービスにアップロードし直すことも考えましたが、そもそもPDFのタグ付けがアクセシブルでなかった(なおかつ、その修正のための時間が直近で確保できない)こともあり、以下にスライド内容のテキストを当日の発言内容を一部補いながら記載し、フォローアップとさせていただきます。SlideShareのサービス上や、そこでダウンロードしたPDFにおいて、うまく情報を取得できなかった方は、こちらをご利用いただけたらと思います。

なお講演中も触れましたが、今回ご紹介したWCAG 2.2の内容は、今から1年ほど前に発行された草案に基づきます。今後、勧告候補のステータスに向け、達成基準の数が大幅に増えるといったことは考えにくいですが、細かいところで変更の加わる可能性はありますので、ご注意ください。

日本視覚障害者ICTネットワークが第2回支援技術利用状況調査を実施

アクセシビリティ・エンジニア 大塚

日本視覚障害者ICTネットワークが、2回目となる支援技術利用状況調査を開始しました。

1回目の調査結果はすでに公開されており、当Blogでも日本視覚障害者ICTネットワークによる支援技術利用状況調査報告書という記事で取り上げています。

類似の調査としては、アメリカの非営利法人であるWebAIMが定期的にScreen Reader User Surveyを実施していますが、日本国内のユーザーを対象とした調査というと、新潟大学 工学部 工学科 人間支援感性科学プログラムの渡辺教授らによる視覚障害者のICT機器利用状況調査2017に限られるのではないでしょうか。

1回目の調査結果について、個人的にはPC-TalkerNetReaderの利用など、日本特有の状況が反映された最新の調査結果が公開されたことに大きな意味があると感じました。また、Windowsで複数のスクリーンリーダーを併用するユーザーが65.81%いたというのが印象的でした。調査結果に記載はありませんが、これはおそらくナレーターを補助的なスクリーンリーダーとして利用しているユーザーが多いためと考えられます。実際にどのスクリーンリーダーをどういった目的で使い分けているのか、個人的に非常に興味があります。

2回目となる今回の調査では、個人的にはWindows 11の普及が少しずつ進むなか、Windows用のスクリーンリーダーであるPC-TalkerやNVDAのシェアに変化があるかに注目したいです。

日本語環境で支援技術を利用するユーザーを対象とした興味深く貴重な調査であり、対象者はぜひ回答いただきたいですし(スクリーンリーダーユーザーとして私も回答する予定です)、調査結果については公開次第、当Blogで取り上げる予定です。

WCAG 2.1達成方法集が更新されました(2022年4月)

アクセシビリティ・エンジニア 中村(直)

ウェブアクセシビリティ基盤委員会(WAIC)からアナウンスがあったように、WCAG 2.1 達成方法集が更新されました(WCAG 2.1 関連文書 更新のお知らせ)。

今回の更新では、IDがGで始まる一般的な達成方法の翻訳が完了しました。

PDFのような一部の達成方法については未翻訳のままですが、今回の更新によっておおむねWCAG 2.1の達成方法の翻訳は完了し、翻訳として実用に耐えられるようになっているのではないかと思われます。

また、今回の更新では、達成方法集およびWCAG 2.1 解説書に対して、これまでに報告された誤字などの修正もあわせて行われています。誤字や翻訳の誤りと考えられるものを見つけましたら、Googleフォームへコメントをお寄せください。

TechFeed Conference 2022

取締役 木達

エンジニア向けのオンラインコミュニティ、TechFeedを運営する株式会社テックフィードが来る5月14日、TechFeed Conference 2022というオンラインイベントを開催します(「エンジニアの祭典」TechFeed Conferenceが5/14に開催。スポンサー企業も絶賛募集中|株式会社テックフィードのプレスリリース)。

同イベントの特徴のひとつは、エキスパート50名による大ライトニングトーク大会という点で、25の技術ジャンルそれぞれについて、トレンドと上級テクニックが紹介されます。以下、当日のタイムテーブルに沿って、どんなジャンルがあるかご紹介します(個々のジャンルのリンク先は、TechFeedの該当チャンネルです):

  1. Web / フロントエンド(13:00〜14:30)
    1. Web標準 / ブラウザ最新動向(13:00〜13:10)
    2. CSS / Webアニメーション(13:10〜13:20)
    3. Web Accessibility(13:20〜13:30)
    4. React(13:30〜13:40)
    5. Vue.js(13:40〜13:50)
    6. Angular / Capacitor(13:50〜14:00)
    7. WebGL(14:00〜14:10)
    8. WebAssembly(14:10〜14:20)
    9. フロントエンド設計(14:20〜14:30)
  2. モバイルアプリ / ゲーム開発(14:55-〜5:35)
    1. iOS(14:55〜15:05)
    2. Android(15:05〜15:15)
    3. Flutter(15:15〜15:25)
    4. Unity(15:25〜15:35)
  3. プログラミング言語 / サーバーサイド開発(15:35〜16:15)
    1. C#(15:35〜15:45)
    2. Kotlin(15:45〜15:55)
    3. Java(15:55〜16:05)
    4. C / C++(16:05〜16:15)
  4. プログラミング言語 / サーバーサイド開発(16:40〜18:00)
    1. Rust(16:40〜16:50)
    2. Go言語(16:50〜17:00)
    3. コンテナ技術(17:00〜17:10)
    4. PHP(17:10〜17:20)
    5. Python(17:20〜17:30)
    6. Ruby(17:30〜17:40)
    7. TypeScript(17:40〜17:50)
    8. Node.js(17:50〜18:00)

私は、上記の中で「Web Accessibility」のトレンド枠を担当させていただき、「WCAG 2.2で追加される達成基準」と題したライトニングトークを行います。WCAG 2.2については、昨年5月に発行された草案から更新されておらず、内容を既にご存知の方も少なくないと思いますが......以下、講演概要です。よろしければ是非ご参加ください。

2022年の秋には勧告されると噂の?Web Content Accessibility Guidelines(WCAG)2.2。目下、最新バージョンである2.1に対し、新たに追加される達成基準にはどのようなものがあるのか? その概要を手短にご紹介します!