Helpfeelエンジニアのbalarです。突然ですが、プロダクトのアクセシビリティについて考えるとき、その基準をどこに置いていますか？Helpfeelではデジタル庁が公開している『ウェブアクセシビリティ導入ガイドブック』を一つのベンチマークにしています。

‍

このガイドブックは「ウェブアクセシビリティの向上に取り組む初心者の方が最初に読むことを想定して作成しました」とあるとおり、初心者にもわかりやすく、かつ改善のプロセスが具体的に示されていることが特徴です。

‍

かくいう私もアクセシビリティについては素人同然だったのですが、これを読んで以来、"熱"が一気に高まっています。そこでまずはアクセシビリティ向上の第一歩として、このガイドブックを片手に、Helpfeelのアクセシビリティを検証してみました！

‍

‍

最重要の4点については、概ねクリアか……？

‍

『ウェブアクセシビリティ導入ガイドブック』では、アクセシビリティ向上のために「達成すべき項目」が、重要度別に分類されています。最も重要度の高い「達成しないと利用者に重大な影響を及ぼすもの」として提示されているのは以下の項目です。

‍

• 自動再生はさせない
• 光の点滅は危険
• 袋小路に陥らせない
• 自動でコンテンツを切り替えない
  ‍

‍

「自動再生はさせない」については、より具体的に「音声の自動再生は避け、再生させる場合は3秒以内に収める」（要約）という達成基準が定められています。この項目から検証してみましょう。

‍

まずはHelpfeelのコード上で、audioタグやvideoタグに「autoplay属性」が指定されていないかを確認していきます。検索の結果、「autoplay属性」が指定されている箇所はありませんでした。ブラウザ上でもaudioタグやvideoタグの埋め込み箇所をチェックし、音声の自動再生がされないことを確認。これで「自動再生はさせない」については「達成済み」であることがわかりました。

‍

ほかの項目についても同じように「コードの記述を確認」→「ブラウザ上で挙動をチェック」というプロセスで検証を進めたところ「光の点滅は危険」「袋小路に陥らせない」の2項目についても、達成済みであることがわかりました。

‍

判断に迷ったのは「自動でコンテンツを切り替えない」という項目です。Helpfeelでは、検索ボックスに何も値が入力されていないときにplaceholderの表示が自動で切り替わるように設定されています。

‍

そこでもう一度ガイドブックに目をやると、当該項目を達成するべき理由を「画面上に動き続けるコンテンツがあると、他の箇所の操作や閲覧を妨げられる利用者がいるため」との記述が見つかりました。

‍

placeholderの表示切り替えが、利用者の操作に大きな影響を与えるとは考えにくいため、今回はひとまず「自動でコンテンツを切り替えない」についても達成済みであると判断。ただ、もしも「いやいや、placeholderも避けるべきだよ」という知見をお持ちの方がいましたら、ぜひご連絡いただけると幸いです。

‍

‍

「必須項目」については、一部に改善の余地がありそう

‍

続いて『ウェブアクセシビリティ導入ガイドブック』が「必ず達成しなければならないもの」と定める項目ですが、こちらは項目数が多いので、本記事では下記の4点についての検証結果をご紹介します。

‍

• ロゴ・写真・イラストなどの画像が指し示している情報を代替テキストとして付与する
• キーボード操作だけで、サービスのすべての機能にアクセスすることができるようにする
• 操作に制限時間を設けてはいけない
• リンクを適切に表示する
  ‍

‍

「ロゴ・写真・イラストなどの画像が指し示している情報を代替テキストとして付与する」という項目を達成するためには、すべてのimgタグにalt属性で代替テキストを指定する必要があります。そこでコード上でimgタグを検索したところ……、残念ながらHelpfeelではほとんどimgタグにalt属性が付与されていませんでした。ここをどう改善していくかについては後ほど考えるとして、まずは検証を進めていきましょう。

‍

結果から述べると「キーボード操作だけで、サービスのすべての機能にアクセスすることができるようにする」についても、Helpfeelは達成基準を満たせていませんでした。実際にHelpfeelをキーボードだけで操作してみたところ、一部のコンテンツで移動ができなくなってしまったり、マイクボタンにフォーカスしたときにフォーカスインジケーターが表示されないという現象が確認されました。この項目についても、改善の必要がありそうです。

‍

未達成が続いて少し不安になってしまったのですが、「操作に制限時間を設けてはいけない」「リンクを適切に表示する」の2項目については、コード上でもブラウザ上でも達成済みであることが検証でき、ひとまずホッとした次第です。

‍

‍

さらなる改善のために、さらに細かく達成度をチェック！

‍

すべてのWebサイトや情報システムで達成するべき必要はないものの、アクセシビリティを高めるために「状況に応じて確認すべきこと」についてはどうでしょうか。たとえば「入力フォームを様々な使い方でも使えるようにする」という項目です。こちらについてはいくつかの達成基準が設けられていますが、Helpfeelに関連性が高そうなのは以下の3点です。

‍

• ラベルとフォームコントロールを関連付ける
• 入力エラーはスクリーンリーダーで読み上げられるようにする
• エラーの回避方法は具体的に示す

‍

「ラベルとフォームの関連付け」「スクリーンリーダーでのエラーの読み上げ」についてはHelpfeelでも達成済みであることが確認できましたが、エラーの回避方法については回避方法が不明確なものも一部存在しました。この点は改善の余地がありそうです。

‍

さらに『ウェブアクセシビリティ導入ガイドブック』では、アクセシビリティを損なう可能性があることから「導入に慎重な検討が必要」な技術や実装方法も示されています。具体的には下記の2つの項目です。

‍

• アクセシビリティ・オーバーレイなどのプラグインは支援技術の機能と重複させない
• 文字サイズの変更、読み上げプラグインの利用は非推奨

‍

この2項目については、Helpfeelでは導入していないため問題がなさそうです。

‍

‍

"現在地"を確認することが、アクセシビリティ向上の第一歩

‍

このように『ウェブアクセシビリティ導入ガイドブック』で示されているすべての項目について検証してみた結果、「Helpfeelは概ね達成基準を満たしているが、一部で改善の余地がある」ことがわかりました。当たり前と言えば当たり前の結果ですが、「達成できていること／できていないこと」が明確になったことは大きな一歩だと考えています。

‍

『ウェブアクセシビリティ導入ガイドブック』を読めば、改善のためのプロセスがある程度まで推測できると確認できたことも収穫でした。引き続き本ガイドブックを参考に、アクセシビリティの向上に取り組んでいきたいと考えています。

‍

エンジニアのみなさんには釈迦に説法からもしれませんが、こういうときに「一度にすべての問題を解決しよう！」と考えると、なかなか物事が前に進みません。タスクを分割して、できるところから取り組んでいくのが大切かなと思っています。私の場合はまずは未達成だった「代替テキスト（alt属性）の付与」を最初のタスクと定め、ほかのメンバーにもレビューをもらいながら、具体的な記述方法を検討しているところです。

‍

アクセシビリティの向上は、個人ではなくチームを巻き込みながら進めていくことが重要だと考えています。私たちの開発チームでも、毎週の定例会議において、アクセシビリティの改善状況について共有する時間を設けるようになりました。複数人でチェックすれば、課題の見落としも少なくなります。チーム全体としてアクセシビリティに対する関心が高まれば、新機能の実装時などにも「誰にとっても使いやすいものになっているか」という点に意識が向くようになるはずです。

‍

私たちHelpfeelは、ユーザビリティはアクセシビリティの上に成立すると考えています。とはいえ、私たち自身もまだまだスタート地点に立ったばかりです。「真のユニバーサルデザイン」を実現するために、これから何をしていくべきなのか。本ブログでは、その取り組みの過程を、今後も積極的に発信していきたいと考えています。アクセシビリティに関心のあるみなさまにとって、少しでもヒントになれば幸いです。

‍

-------------------------------------------

▽イベントの様子はYouTubeで公開中（登壇資料も掲載しています）

Helpfeel Tech Hour vol.3 「アクセシビリティを始めたい！編」 を開催しました

-------------------------------------------

‍