TOP

人に優しいコーディングとは

アクセスビリティを考えたサイトとは

甲斐駒ヶ岳21年2月

こんにち、スマートフォン、パソコンが生活の必須アイテムになってきています。
これは、健常者のみならず、障害者やお年寄りも例外ではないと思います。
ウェブを製作する側も、このことは無視できない事柄として捕らえなければいけないと感じております。
ホームページのデザイン性については、製作サイドで十分にねられたものを多く見かけますが、誰もが見やすい、操作しやすい、アクセスビリティを考えたサイトとなるとあまり見受けられないように思えます。
ここでは、国内におけるウェブアクセスビリティの指針である、JIS X 8341-3:2016(高齢者・障害者等配慮設計指針-情報通信における機器,ソフトウェア及びサービス-第3部:ウェブコンテンツ)にある、要件に基づいて、特に、使用頻度が高い、重要と思われる項目を取り上げて、考えてみました。
尚、コーディング確認作業をするにあたって、以下の環境で検証いたしました。

  • Windows7 professional Service Pack 1
  • FireFox 63.0.3(64ビット)
  • Google Chrome 77.0(64ビット)
  • Internet Explorer11
  • Lynx289dev19THjp テキストブラウザ
  • NVDA  スクリーンリーダー

html5に準拠したコーディングを想定しております。

目次

見やすい、理解しやすいページになっていること

標準である、html5仕様にそって、html文を作成する。

html5において、 テキストに構造と意味 (セマンティクスともいう) の要素が強化されました。

html5では、各要素タグがコンテンツモデルとして定義されております。

コンテンツモデルとは、要素を、メタデータ、フロー、セクション、ヘッディング、フレージング、エンベッディッド、インタラクティブというコンテンツの種類 に分類し、定義したものです。

参照:ホームページ作成プランニング(後半) html5基本構造を考える

最新のブラウザやスクリーンリーダーはこの仕様に沿って表示、発声することになっています。正しいタグづけをすることによって、適切に機能することを保障するものと思われます。

何を伝えたいか理解できる

ウェブページのデザイン性がどんなに優れていても、内容が閲覧者に正しく伝わらなければ、目的が達成されているとはいえないと思われる。

htmlタグでマークアップされたセマンティックな部分は、あくまでも着飾ったものを指しているのであって、軸は文章である。

そのためにも、マークアップする前にテキストの状態で、十分に作りこむことが大切であると考えます。

参照: ホームページ作成プランニング(後半)

誰でも見れるようにするためのhtmlコーディング実例

画像・図表には代替テキストを入れる。

幸せを呼ぶブルーボトル

alt属性に画像内容をテキストとして示すことにより、画像が表示されなかった場合の代替表示をします。音声認識ソフトでは、alt属性の内容が発音されます。title属性はツールチップ(カーソルを近づけたときのtitleの内容が表示される。)として機能します。

アイコンや罫線などデザイン目的の画像にはスクリーンリーダへの適切な配慮をする。

タグで適切な論理構造として示し、スタイルシートで装飾をする。

強調を示すタグは下記のものがあります。

  • b 単なる太字テキスト表示
  • em 強調であることを示す
  • strong 重要であることを示す

これらのタグは見た目は同じような表示になることが多いですが、タグの役割を理解した上で使用することが望まれます。表示装飾の差別化は、スタイルシートを使って示します。

リンクであること、リンク先がどこであるか明確に示す

優しい情報サイト

リンクのクリック先を新しいウィンドウにすることを避ける

優しい情報サイト

適切なテキスト表現をする

文字色設定は、文字背景色設定とセットで行います

ブラウザの文字色、あるいは背景色のデフォルト設定がそれぞれ白、黒とは限らないので、文字そのもののコントラスト比を大きく保つように文字色と文字背景色はセットで設定します。


html
<p class="yellow-black">ブラウザの文字色、あるいは背景色のデフォルト設定がそれぞれ白、黒とは限らないので、文字そのもののコントラスト比を大きく保つように文字色と文字背景色はセットで設定します。
</p>
css
.yellow-black {
  color: Black;
  background: Yellow;
}

文字列の中の記号文字表記(- / :)が音声としてどのように読まれるのか考えて使用する

2020-11-11 10:22<!– 非推奨表記 –>

2020年11月11日10時22分<!– 推奨表記 –>

- / : はスクリーンリーダでは、マイナス スラッシュ コロンと読まれ、意味がわからなくなる。
<time datetime="2020-11-11">2020-11-11 10:22</time> <!-- 非推奨表記 -->
<time datetime="2020-11-11">2020年11月11日10時22分</time>  <!-- 推奨表記  -->

単語・文の区切りは明確にする

住 所 : 東京都足立区<!– 非推奨表記 –>

住所: 東京都足立区<!– 推奨表記 –>

単語の文字の間に体裁を整える為に空白文字を入れてはいけない。この場合は、スタイルシートでスタイリングする
<!-- 非推奨 -->
html
<p>住 所 :  東京都足立区</p>
<!-- 推奨 -->
html
<p><span class="l-space1">住所</span>:  東京都足立区</p>
css
.l-space1 {
  letter-spacing: 1em;
}

機種依存文字はテキストエンコーディングutf-8で使用する

旧態のブラウザではShift_jisやEUC-JPなどの文字コードが標準で設定されていました。このような状況の下ではブラウザの違いによって機種依存文字(①、Ⅰ、∑など)の見え方が異なってしまうことになり、アクセスビリティを考えると使用すべきではないとされていました。今では、こうした問題も、国際化対応のユニコードutf-8が標準で使われており、考慮しないで済むようになっています。但し、文字化けしてしまうとか、イメージと違う表示になってしまうなどの問題がでてきた場合は、文字コードの設定を疑ってみる必要があります。

点滅・移動させるような表示の仕方はしない

携帯サイトでよく使われていた、文字を点滅させるBLINKタグと文字を移動させるMARQUEEタグは対応機種が限られており、使うべきではないとされております。視覚障害の人には、このようなタグが使われている画面を読み取ることが困難であったり、音声読み上げされません。html5においても、廃止タグとなっております

テーブル文の構成は先頭から順番に内容が通じるように作る

品種名長所短所
こしひかり食味が良い倒伏しやすく栽培がむずかしい
あきたこまちこしひかりより栽培期間が短い炊飯後時間がたつと食味がおちる
2020年度見解
左から右に、上から下にテキストが読まれ、意味が通じるようにする。
html
<table>
  <caption>
    <strong>お米の品種について?その長所と短所</strong>
  </caption>
  <thead>
    <tr><th>品種名</th><th>長所</th><th>短所</th></tr>
  </thead>
  <tbody>
    <tr><th>こしひかり</th><td>食味が良い</td><td>倒伏しやすく栽培がむずかしい</td></tr>
    <tr><th>あきたこまち</th><td>こしひかりより栽培期間が短い</td><td>炊飯後時間がたつと食味がおちる</td></tr>
  </tbody>
  <tfoot>
    <tr><td colspan="3">2020年度見解</td></tr
  </tfoot>
</table>

テーブルにcaptionをつけると、スクリーンリーダーが読み上げてくれます。

障害者にも使いやすい送信フォームになっている

フォーム送信を参照してください

障害を持っている人に対する色使いへの配慮をする

テキスト(前景)と背景色の組み合わせのコントラストは、色覚異常者にとっては、アクセスビリティの重要な要素になっています。各色の組み合わせのコントラスト比が高いほど、みえやすくなります。赤色と緑色の場合は特に注意が必要です。色覚異常者は特に、この色が見えにくい人が多いです。

2色のコントラスト比を計算し評価するツール ColorTester

W3Cのウェブコンテンツ・アクセシビリティ・ガイドライン(WCAG 2.0)では、少なくとも 4.5:1 、大きい文字では少なくとも 3:1のコントラスト比としています。

また、道標や情報を色だけに頼らないようにすることです。 これは、色が見えない人は色情報がわからないからです。 例えば、必須のフォームフィールドを赤枠であると定義された場合、色覚異常者には、その判別ができないことになりまっす。こういった状況では、テキストで「必須」と付け加えたほうがいいでしょう。

ナビゲーションを読み飛ばす為のリンク(スキップリンクス)について考える

スキップリンク

ナビゲーションがページの先頭にある場合、スクリーンリーダでは、ナビゲーションを読み上げてから本文に進む構成になっていると思われます。

下層ページそれぞれに同じ内容のナビゲーションが使われているのが一般的であり、サイト内を移動するたびごとに、長々と同じ音声アナウンスを聞くことになります。

スクリーンリーダー利用者に対してこのような煩わしさを取り除く為に、「スキップリンクスSkiplinks」というWebアクセシビリティのテクニックが使われる場合があります。これは、以下の条件を満たすようなhtml・cssコーディングによって実現するとされております。

  • html bodyの先頭部分にリンク元となる「a href」タグを設置する。
  • リンク先はナビゲーション部分を飛び越え、本文の始まり部分の任意のタグ内に、リンク元に紐づけられたid要素を設置する。
  • リンク元をdivタグで囲み、id属性をつける。
  • リンク元を指す、id属性に対してスタイルシートを記述する。但し、スクリーンリーダにはその存在が認識できても、それを必要としないページ閲覧者には見えないcssコーディング設定をしなければならない。
  • 具体的には、display:noneやvisibility:hiddenでは読み上げの対象とはされていないので使うべきではないが、display: absoluteとleft: -10000pxで画面の外に吐き出す設定により、スクリーンリーダーが認識してくれるようである。

WAI-ARIA(ウェイ・アリア)の利用

WAI-ARIA(Web Accessibility Initiative – Accessible Rich Internet Applications)とは、HTMLやSVGでは表現できない、アクセスビリティ向上のための追加的なW3Cの仕様です。

フォーム送信

フォーム画面を操作する場合に、項目を選択・記入後送信ボタンを押していきなり送信してしまうような事は、ユーザには、親切であるとはいえません。

使い勝手を考えた場合、以下の手順で操作できることが求められるとおもいます。

  1. ユーザーが項目を選択し送信ボタンを押す
  2. 必須項目が未選択や条件を満たさない記入に対して、警告表示をする(バリデーション)
  3. バリデーションで通過したものを再度、確認画面表示で送信確認をする
  4. 送信ボタンとやり直しボタンのどちらかの動作を選択することになり、送信ボタンを押すとデータがサーバーに送られ、やり直しボタンはフォーム画面に戻ることになる

バリデーションは操作ユーザのブラウザで行われる事が一般的になっております。

以前はこの処理をjavascriptまたはサーバー側でのプログラミング処理を使って行っておりましたが、html5が使われ始めて以降、inputタグのtype属性の指定により入力データの妥当性チェックや入力補完がタイプごとに行えるようになってきております。但し、これらのチェックは、html5タグでやるのか、javascriptでやるのか、 WAI-ARIA を使うのか、それらを混在して使用する場合は、整合性を保つ為、使用方針を決めて、製作する必要があると思われます。

フォーム送信においては、セキュリティを考えると、サーバー側においても、チェックが必要かと思われます。

非推奨フォーム

お名前:
メールアドレス:
性別: 男性 女性
好きな色: 黄色

html5仕様フォーム

名前入力(必須)
メールアドレス入力
性別選択(必須)
好きな色選択(複数選択可能)

非推奨フォームでは、lableタグ、for属性を使っていない為に、フォーム内の項目名がスクリーンリーダでは読み上げられません。

html5フォームではアクセスビリティを上げる為に、以下のように修正いたしました。

  • 各項目にlegendタグを追加し具体的な操作説明文をつける。ユーザが項目を記入する前に説明文が表示される。また、この説明文はスクリーンリーダで、読み上げられる。
  • lalelタグとその属性としてforを定義し、項目と関連づける。スクリーンリーダで項目名が読み上げられる。
  • フォーム部品にrequired属性をつけることで必須項目が未記入で送信ボタンを押したときに、未記入警告表示され、スクリーンリーダでアナウンスされる。送信されない。
  • メールアドレス入力inputタグのtype属性にemailを使用する。これにより、メールアドレスにふさわしくない記入に対して、警告表示され、スクリーンリーダでアナウンスされる。送信されない。
  • メールアドレス入力欄にinputタグのplaceholder属性を使って、入力補助に係わる表示を入れる。スクリーンリーダではアナウンスされない場合がある。
  • フォーム表示画面スクロール手前に、javascriptのdom操作で動的に生成させる、エラー画面と確認画面の領域をulタグで確保する。

以上のようにすることで、ずいぶん扱いやすくなりました。但し、送信ボタンを押したのちのエラー画面や確認画面に対してはスクリーンリーダでは音声として機能しないことに気づかされます。

このことを実現させる為には、以下に示す WAI-ARIA の記述が必要になってきます。

WAI-ARIA仕様フォーム

WAI-ARIA仕様フォーム

名前入力(必須)
メールアドレス入力
性別選択
好きな色選択(複数選択可能)

WAI-ARIA は W3C によって定められた仕様で、htmlやjavascriptのdom操作だけでは実現できないアクセスビリティ向上技術を要素に適用したものです。

この仕様では、主に次の3つの機能があります

ロール(Role)
htmlの要素に「この文はどういう文なのか」という意味を表すものです。html5登場前はheader main footerなどのセマンティックなタグは無く、divタグで括られたものだったので、このタグに意味論的な要素を追加するのに有用であると思われていました。html5ではセマンティックな要素を使用すれば特にRoleとして規定する必要性は無いようです。但し、role=”banner” role=”search”などは、これらに含まれていない為に、使用価値は見出せることでしょう。
プロパティ(Property)
要素の追加的性質や値を定義します。、たとえば、aria-label または、aria-labelledbyは画像などの説明文を値またはラベルとしてセットして、スクリーンリーダで読み上げられるようにしたものです。alt属性と同様の役割を持ちますが、これらは、長い説明文や、複数の画像に対して同じラベルとして動作させることを可能にするという違いがあります。
ステート(State)
要素の現在の状態を定義するプロパティです。但し、上記のプロパティは一度定義すれば動的に変更できないものであるのに対して、ステートはdomをプログラミング操作することにより、動的に値を変化させることができるものを指します。チェックボックス要素で予めチェックをつけておきたい項目にaria-checked=”true”とするようなものはこの分類に属します。

ここでは、送信ボタンを押した後の表示動作に対して、スクリーンリーダーなどでも認識できるようにするために以下のようなWAI-ARIAタグを使用しております。

aria-liveは何らかの更新表示により、それをユーザにしらせるかどうかのwai-aria属性です。assertiveは即座に伝えるということを意味しています。aria-atomicはこの更新表示により、変更部分だけを伝えるか、属性が定義されているタグの範囲全体を伝えるかを設定します。trueは後者になります。

aria-required=”true”は音声ブラウザに入力必須であることを伝えます。html5inputタグのrequired属性と同じような役割をします。但し、html5のrequired属性は空欄の場合はツールチップで警告表示が出ることがあります。どちらかを使えばいいでしょう。javascriptでこの項目の細かいバリデーションをするときは、ariaを使ったほうが良いようです。

placeholderは項目の内容に追加的な説明を加えるのに適しております。スクリーンリーダではこの説明を読み上げてくれない場合があるので、aria-label属性を追加して、読み上げられるようにしました。

javascript dom関連のメソッドである、setAttributeでaria-lable属性を動的に生成しております。

スライドショー

自動的に画像が推移するスライドショーや動画などは、近頃のウェブサイトでは当たり前になってきています。
障害者や高齢者に優しいサイトであるために、最低限以下のようなものであるべきだと考えます。

  • 字幕をつける
  • そして、それが音声で読み上げられる
  • 開始・停止ボタンがある
  • 音量調整が出来る

ここでは、javascriptでのdom操作による、スライドショーを題材として、取り上げました。

画面推移の素材(画像とテキスト)はjavascriptのコードとして動的にhtmlの中に挿入しております。

アニメーション効果はcssの中のクラスとして定義し、これもjavascriptで生成しております。

前記で書かれているように、動的コンテンツは、スクリーンリーダでは認識しませんので、このままでは、利用者はスライドショーが何であるか、知りえることが出来ません。

ここでも以下のようにWAI-ARIAを利用することにより、スクリーンリーダーの音声機能が使えるようになります。

src alt titleの値はjavascriptにより、動的に生成されます

tabindex属性はwai-area属性ではありません。この属性はtabキーでフォーカスされるタグを指定できます。数値はフォーカスの順番を示します。数値を0とすると通常タブキーでの移動対象とならない要素をタブ移動可能にします。

スライド画像にたいして、スクリーンリーダに読み上げてもらう為にラベルをつけています

スクリーンリーダーでも、一定の時間間隔で画像が変化するものを音声認識させる場合は、ページを開いたときには、停止ボタンが押されている状態である必要があります。

ページ内の他のコンテンツを見ているときでも、自動的に画面推移されるとそのたびに、音声アナウンスが入り、利用者が混乱してしまいます。

また、画面推移の間隔調整を適切にしないと、アナウンスのタイミングがずれたりするので、その辺を考慮したうえで製作する必要があることを認識すべきであります。

アクセスビリティを考えたコーディングをしよう

html5の使用に準拠していれば、ある程度のアクセスビリティは確保できると思われます。さらに、使い勝手、凝った表示を追及しようとすれば、javascriptなどのプログラミング言語を使った、動的なコンテンツが必要になり、そのアクセスビリティも考えていかないといけないようになります。

このような問題の解決には、WAI-ARIA利用により、ある程度は、動的ものに対応できるようにはなります。

但し、各osのパッケージに入っているものや、NVDAなどのパソコン操作支援ソフトは操作に慣れる必要があったり、セットアップしなければならないので、手軽にというわけにはいかないようです。

障害者・健常者、老若男女区別無く、内容の伝わりやすさを第一に考えるサイトとするのならば、html5とcssのみを駆使して製作していくのが良いと思われます。

参照・参考

尚、上記に示した、 ウェブアクセスビリティの指針 書かれたものを満たす為のコーディング実例は、ほんの一部であり、詳細は以下を参考にしていただきたい。

WAI-ARIA についての詳細は、参照サイトも含め、以下のようになります。

以下のスクリーンリーダーの為のサンプルにて動作検証できます。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください