kintoneアプリのWebアクセシビリティを見直すときは、ラベル、画像、色、キーボード操作、見出し、フォームの六つを順に確認します。
標準設定で整えられる部分と、プラグインやJavaScript、CSSで追加した画面を分けると、修正すべき場所を特定しやすくなります。
kintoneで確認するアクセシビリティの範囲
Webアクセシビリティとは、障害や年齢、利用している機器や操作方法にかかわらず、必要な情報と機能を利用しやすくする考え方です。
kintoneでは、アプリの項目名や説明文だけでなく、追加したボタン、画像、ダイアログ、エラーメッセージまで確認の対象になります。
- アプリ設定：フィールド名、説明文、選択肢、必須項目の示し方
- 追加した画面要素：プラグインやJavaScript、CSSで作ったボタン、画像、通知、ダイアログ
- 実際の操作：キーボードだけでの入力、読み上げ、拡大表示、色の見分けやすさ
設定画面を見ただけで判断せず、レコードの作成、編集、一覧表示など、利用者が実際に通る操作を試すことが必要です。
ラベルと説明文を具体的にする
スクリーンリーダーは、画面上の文字や操作部品の名前を読み上げる支援技術です。
フィールド名やボタン名が曖昧だと、何を入力し、何が実行されるのかを判断しにくくなります。
フィールド名は「名前を入力してください」のような指示文ではなく、「氏名」のように対象を短く示し、入力方法の説明は別の説明文にします。
ボタン名も、周囲の文脈だけでは目的が伝わらない場合は、「送信」より「申請を送信」のように対象と動作を組み合わせます。
必須項目や入力形式は、入力後のエラーだけに頼らず、操作を始める前に読める位置へ示します。
画像の役割に合わせて代替手段を用意する
内容を伝える画像には、その画像と同じ目的を果たす代替テキストを用意します。
たとえば、状態を示すアイコンなら、見た目の説明ではなく「承認済み」のように伝えるべき状態を書きます。
一方、装飾だけの画像に詳しい説明を付けると、読み上げる情報が増えて操作を妨げます。
画像を追加した場所で代替テキストを設定できない場合は、近くの本文で同じ情報を伝えるか、表示方法そのものを見直します。
色だけに意味を持たせない
エラー、進捗、優先度などを色だけで区別すると、その色を見分けにくい利用者へ情報が伝わりません。
赤い枠だけでエラーを示すのではなく、「入力内容を確認してください」のような文言を添え、該当する項目も特定できるようにします。
文字色と背景色の組み合わせについては、WCAGで示されている通常サイズの文字のコントラスト比4.5:1以上を確認の目安にできます。
CSSで色を変更した場合は、本文だけでなく、ボタン、入力欄、通知、キーボードフォーカスの見え方も確認します。
キーボードだけで一連の操作を試す
マウスを使わず、Tabキーなどで入力欄やボタンへ順に移動し、レコードの入力から保存まで完了できるかを試します。
フォーカスの移動順が画面の意味や操作の流れと合っていること、現在選んでいる部品が見た目で分かることも確認します。
独自のダイアログを追加している場合は、開いた後にダイアログ内を操作でき、閉じるボタンにもキーボードで到達できる必要があります。
既存の操作へカスタマイズを重ねた箇所ほど、マウスでは気付かない操作不能が残りやすいため、画面ごとに確認します。
見出しとフォームの構造を整える
カスタムビューや説明ページでHTMLを出力する場合は、見出しを内容の階層に合わせます。
ページのタイトルをH1とし、本文の大きな区切りにH2、その下位の項目にH3を使えば、読み上げ利用者も見出し単位で内容を移動できます。
フォームでは、各入力欄に目的の分かるラベルを付け、必須かどうか、どの形式で入力するかを説明します。
入力エラーが起きたときは、エラーの存在だけでなく、どの項目をどのように直すのかを文字で伝えます。
標準設定とカスタマイズを分けて改善する
最初に、フィールド名、説明文、選択肢、必須表示など、アプリ設定で整えられる部分を修正します。
標準設定で対応できる範囲を先に整理すると、追加開発が必要な問題だけを残せます。
HTMLやCSS、JavaScriptを使わない改善方法とカスタマイズが必要な場面は、kintoneで専門知識がなくてもできるWebアクセシビリティ対応でも整理しています。
プラグインやJavaScript、CSSは画面の動作や見た目を変えられますが、導入しただけでアクセシビリティ対応が完了するわけではありません。
追加した要素について、名前、読み上げ順、キーボード操作、色、エラー表示を最終画面で確認します。
自動チェックと人による操作確認を組み合わせる
WAVEやaxe Accessibility Checkerのようなツールは、代替テキストの不足、コントラスト、HTML構造など、確認すべき候補を見つけるために使います。
ツールの詳しい選び方は、Webアクセシビリティチェックツールのガイドも参考になります。
ただし、自動チェックだけでは、代替テキストの内容が適切か、操作順が分かりやすいか、エラーメッセージが理解できるかまでは判断できません。
- レコード作成、編集、一覧、検索など、確認する操作を決める
- 自動チェックツールで問題の候補を洗い出す
- キーボードだけで同じ操作を完了できるか試す
- スクリーンリーダーでラベル、見出し、エラーの伝わり方を確認する
- 修正後に同じ手順をもう一度試す
問題が見つからなかったという自動チェック結果は、アプリ全体が使いやすいことの証明にはなりません。
日常業務の操作から改善を始める
一度にすべての画面を直そうとせず、利用頻度の高いアプリと、入力や保存を妨げる問題から順に改善します。
新しいフィールドやカスタマイズを追加した後も同じ確認手順を繰り返せば、変更による問題を早い段階で見つけやすくなります。
アクセシビリティ改善を補助するサービスを検討する場合は、UUU ウェブアクセシビリティウィジェットツールの案内もご確認ください。