デジタル庁デザインシステムβ版 v2.7.0
検索

メニュー

インプットテキスト（アクセシビリティ）

インプットテキストにおけるアクセシビリティ観点での留意点について説明します。

プレースホルダーテキストを使わない

原則としてプレースホルダーテキストを使用しないでください。

プレースホルダーテキストに入力条件や入力例を記述しても、プレースホルダーテキストはコントラスト比が低く、視認性が良くありません。また、ユーザーが入力を開始すると（フォーカスすると）非表示になるため、入力中にユーザーがその入力条件や入力例を確認できないだけでなく、入力エラーがあっても入力条件と見比べてエラーの原因を調べることができません。

そのうえ、スクリーンリーダーによってはプレースホルダーテキストを読み上げなかったり、読み上げる場合でも入力済みのテキストとの判別が困難な読み上げ方になったりする場合があります。

入力条件や入力例は、プレースホルダーテキストではなくサポートテキストに記述します。

無効フィールド（disabled）を使わない

無効フィールド（disabled）を使わないようにします。

参考情報

編集不可フィールド（readonly）を使わない

編集不可フィールド（readonly）は、そのインプットテキストがなぜ編集できないのかという理由が不明確なまま表示されたり、フォーカスしてもキャレットが表示されないため操作に戸惑ったりすることがあります。一部のスクリーンリーダーにおいては「クリック可能」と読み上げるにとどまるなど、そもそも編集不可フィールドであることが明確に伝わらないこともあります。また、フィールドの幅を超える長さの値が入っている場合に、見切れた部分を表示することが困難です。

そのため、以下の場合をのぞき、編集できない項目は編集不可フィールドを使わずに地の文（単なる本文のテキスト）として表示してください。

編集不可フィールドが許容される場合

状況により、編集不可フィールドの使用が許容される場合があります。ただし、編集不可フィールドを使わなくても成立するような文書構造やフロー構成にできないか、設計の再検討の必要性をあらかじめ考慮してください。

  • 既存システムの制約等により使用せざるを得ない場合
  • 複数の連なるインプットテキストにおいて異なるステートが混在する場合
  • ユーザーの操作によって表示モードと編集モードが明示的に切り替わるような場合

編集不可フィールドを使う場合の留意点

やむを得ず編集不可フィールドを使う場合は次の点に留意してください。

  • 入力内容の確認画面で使用しないこと（見切れたテキストを見ることが困難なため）
  • 必ずデジタル庁デザインシステムの編集不可フィールドを使用すること
スクリーンショット：編集不可フィールドの例。項目ラベルは「住所」、要否ラベルは「編集不可」、サポートテキストは「この項目は自動入力されたので変更できません。」と表示されている。

デジタル庁デザインシステムの編集不可フィールドは、フィールド自体を点線のボーダーで表現し、「編集不可」のステートを要否ラベルとして表示し、かつサポートテキストに当該フィールドが編集できない理由を明記します。

最大長の制限にmaxlength属性を使用しない

入力の最大長を制限するHTMLの属性であるmaxlength属性には使用上の問題があるため、使用しないでください。意図しないテキストを送信してしまうなどのユースエラーにつながります。

例えば、下記のようなユースエラーのシナリオが考えられます。

  • パスワード設定フィールドにmaxlengthが設定されているが、パスワードの末尾が切り取られていることに気づかず、意図しないパスワードが設定されてしまう
  • 漢字変換のためのかな入力時に最大長を超過してしまい、意図した文字列を入力できない
  • 外部データを貼り付けてから編集しようとしたが、テキスト全体を貼り付けられない

入力フィールドの最大文字数に制約を持たせる場合は、下記の対応を検討してください。

  • maxlength属性を使用しない
  • サポートテキストを使って最大長を提示する、または超過が稀にしか起こらない程度に長いテキストを受け入れる
  • サーバーサイドでバリデーションを行い、超過の場合、最大文字数および超過文字数をエラーテキストとして表示する

コピー＆ペーストを無効にしない

インプットテキストのコピー操作およびペースト操作を禁止しないでください。ユーザーの利便性を損なう上、記憶や書き写し能力に困難のある人が利用できなくなるおそれがあります。

参考情報

メールアドレスの前半と後半を分割されたフィールドにしない

ユーザーにメールアドレスを間違いなく記述させることなどを目的として、@の前後でインプットテキストを分割しないでください。

ユーザーは定型的な情報を必ずしも毎回入力するのではありません。ブラウザに保存した個人情報、IMEのユーザー辞書、パスワード管理ツールまたはメモ帳などのツールを使用して入力を容易にする工夫がなされる場合があります。フィールドを分割することで、こうしたツールの利用を阻害してしまいます。

メールアドレスの入力間違いを防ぎ、メールアドレスの所有者を確実に特定するためには、メールアドレス宛に実際に確認メールを送信して疎通を確認してください。

参考情報

値の変更で予測できない変化を引き起こさない

入力フィールドの変更をトリガーにして、予測できない変化を引き起こさないようにしてください。予測できない変化があると、視覚障害または認知特性のある利用者は状況の変化を適切に認知できず、コンテンツを利用できなくなるおそれがあります。

予想できない変化の代表例は次の通りです。

  • 新しいウィンドウやダイアログが立ち上がる
  • フォームが送信され新しいページに遷移する
  • ページの一部やフォームの値が書き換わると同時にフォーカスが移動する

上記のような変化を引き起こす場合は、値の変更ではなくボタンやリンクの押下をトリガーにするようインタラクション設計を見直してください。

なお、次に挙げる例は予測できない変化とはみなされません。

  • 入力フィールドの変更によって、次以降のフォームが変化する
  • 入力フィールドに変更があると変化が起きることを、事前にテキストで伝えている

参考情報

エラーテキストの読み上げにaria-liveを使わない

エラーテキストを、aria-live属性を用いてリアルタイムにスクリーンリーダーに通知してはいけません。また、role="alert"は暗黙的にaria-live="assertive"を持つため、alertロールの付与も禁止とします。

aria-live属性を指定すると、操作中または入力中にエラーテキストの読み上げが割り込んでくることになり、スクリーンリーダーユーザーの閲覧や操作の妨げとなります。

エラーメッセージは静的なテキストとして表示するだけで十分であり、スクリーンリーダーに特化した表現（aria-liveやrole="alert"を使用すること）をする必要はありません。どうしても当該エラーメッセージを強く意識させたい場合は、aria-describedby属性で必要なフォームコントロール等と紐づけて注意喚起することで対応してください。