結論から言えば、HTMLやCSS、JavaScriptの知識がなくても、kintoneアプリのWebアクセシビリティを改善することはできます。
ただし、アプリをノーコードで作成できることと、完成した画面が自動的にすべての利用者にとって使いやすくなることは別です。
アプリ管理者が対応しやすいのは、フィールド名や説明の見直し、必須項目の伝え方、色の使い方、実際の操作確認です。
画面の構造や動作そのものに問題がある場合は、プラグインの検討やJavaScript、CSSによるカスタマイズが必要になることがあります。
kintoneでアクセシビリティ対応を考える前提
Webアクセシビリティとは、利用者の見え方や操作方法が異なっても、情報を取得し、必要な機能を利用できるようにする考え方です。
文字が読めるだけでなく、入力項目の意味がわかること、キーボードで操作できること、エラーから復帰できることも含まれます。
kintoneでは、用意されたフィールドを配置して業務アプリを作成できます。
この仕組みにより、コードを書かずにフォームを整えられますが、業務固有のフィールド名や入力手順まで自動的にわかりやすくなるわけではありません。
| 対応方法 | 主にできること | 注意点 |
|---|---|---|
| 標準設定と運用 | フィールド名、必須設定、配置、説明の見直し | 実際の画面で伝わり方と操作性を確認する |
| ブラウザのチェックツール | コードやコントラストなどの問題候補を検出する | 結果の判断と手動確認は別に必要になる |
| プラグイン | 標準機能にない機能を追加する | 対象となる問題、対応画面、保守状況を確認する |
| JavaScriptやCSS | 画面の表示や動作を個別に調整する | 実装と更新後の再確認に専門知識が必要になる |
標準設定と追加カスタマイズを分けて考える方法は、kintoneでWebアクセシビリティに対応する実務ポイントでも整理しています。
コードを書かずに見直せる5つの項目
1. フィールド名を具体的にする
フィールド名は、その入力欄だけを見ても目的がわかる言葉にします。
たとえば「内容」だけでは対象が曖昧ですが、「問い合わせ内容」なら入力すべき情報を判断しやすくなります。
社内だけで通じる略語や記号を使う場合は、初めて操作する人にも意味が伝わるかを確認します。
フィールド名を非表示にすると意味をつかみにくくなることがあるため、見た目だけを理由に隠さないほうが安全です。
2. 必須項目を色や記号だけに頼らず伝える
必須項目が色の違いやアスタリスクだけで示されていると、その意味を見落とす利用者がいます。
実際の入力画面を開き、「どの項目が必須か」「記号が何を意味するか」が文字でもわかるかを確認します。
標準表示だけでは伝わりにくい場合は、フィールド名や画面上の説明で補う方法を検討します。
フォームの入力支援とエラー設計を確認すると、必須表示を含む見直し方を把握できます。
3. エラーの原因と直し方を確認する
未入力や形式違いの状態で保存を試し、エラーがどこにあるかを見つけられるか確認します。
メッセージを読んだ利用者が、対象の項目と修正方法を判断できることが確認の目安です。
業務上の入力ルールが複雑な場合は、利用者が失敗してからエラーを出すだけでなく、入力前に短い説明を示す方法も検討します。
4. 色だけで状態を区別しない
背景色と文字色の差が小さいと、文字や状態表示を読み取りにくくなります。
また、「赤は未対応、緑は対応済み」のように色だけで意味を分けると、色の違いを判別しにくい利用者に情報が伝わりません。
色を使う場合も、「未対応」「対応済み」のような文字を併記します。
テーマや配色を変更したときは、実際の一覧画面、詳細画面、入力画面を確認します。
5. キーボードだけで一連の操作を試す
マウスを使わず、TabキーとShift＋Tabキーで入力欄やボタンを移動します。
操作する場所を示す枠が見えるか、移動順が画面の流れに合っているか、保存やキャンセルまで実行できるかを確認します。
一覧からレコードを開き、入力し、保存して戻るまでの一連の流れで試すと、個々の画面だけでは気づきにくい問題も見つけやすくなります。
確認項目の詳細は、キーボード操作の実装チェックを参照してください。
WAVEやaxeを使うときの注意点
WAVEやaxe DevToolsなどのブラウザ拡張機能は、画面に含まれるアクセシビリティ上の問題候補を見つける手がかりになります。
ログイン後のkintone画面を確認する場合は、ブラウザに表示しているページを拡張機能で調べる方法が使いやすいでしょう。
チェックツールで警告が出なかったとしても、それだけでWebアクセシビリティへの適合を確認したことにはなりません。
フィールド名が業務上わかりやすいか、キーボードで一連の作業を完了できるか、エラーの直し方が伝わるかといった点には、人による判断が必要です。
- 利用頻度の高いアプリと作業手順を選ぶ
- チェックツールで問題候補を確認する
- キーボード操作と実際の入力で手動確認する
- 修正後に同じ手順をもう一度試す
この順番なら、ツールの結果を眺めるだけで終わらず、利用者が行う作業に沿って改善を確認できます。
プラグインやカスタマイズが必要になる場面
標準設定でフィールド名や説明を整えても、フォーカスの移動順、エラーの通知方法、独自の画面操作などを改善できない場合があります。
この段階で、プラグインやJavaScript、CSSによるカスタマイズを検討します。
プラグインを選ぶときは、「アクセシビリティ対応」という名称だけで判断せず、どの問題をどの画面で改善するのかを確認します。
導入後も、対象ブラウザでの操作とkintone更新後の動作を継続して点検する必要があります。
JavaScriptやCSSで画面を変更するときは、実装前に解決したい問題を具体的にします。
たとえば「入力エラーが表示されたことを認識しにくい」「キーボードでは特定のボタンに移動できない」のように整理すれば、開発者へ依頼する範囲と確認方法を決めやすくなります。
kintoneのアクセシビリティ改善を続けるには
コードの知識がなくても、わかりやすいフィールド名、必須項目の伝え方、色に依存しない表示、キーボード操作の確認から改善を始められます。
一方、標準機能やチェックツールだけで、あらゆる利用者への対応を保証することはできません。
まず利用頻度の高いアプリを一つ選び、実際の作業手順で確認します。
標準設定で直せない問題だけを切り分けて専門担当者に相談すると、必要なカスタマイズを具体化できます。
当社では、Webアクセシビリティ対応を支援するUUU ウェブアクセシビリティウィジェットツールを提供しています。
継続的な改善方法を検討している場合は、サービスの詳細もご覧ください。