WCAG 1.3.5: 入力目的の特定

このルールの意味

WCAG 1.3.5 — 入力目的の特定 は、WCAG 2.1 で導入され、WCAG 2.2 にも引き継がれているレベル AA の達成基準です。これは、ユーザーに関する情報を収集するあらゆる <input>、<select>、<textarea> 要素について、その目的がプログラム的に伝達されていることを求めるものです。これにより、ブラウザや支援技術がその目的を自動的に特定し、動作できるようにします。

この基準を満たすための仕組みは、HTML 仕様で定義された公式リストから正しいトークン値を組み合わせて用いる autocomplete 属性です。フィールドがユーザーの氏名、メールアドレス、電話番号、郵送先住所、クレジットカード番号などの個人情報を収集する場合、そのフィールドの目的を正確に表す値を autocomplete 属性に指定しなければなりません。たとえば、名のフィールドには autocomplete="given-name"、メールアドレスのフィールドには autocomplete="email" のように指定します。

この達成基準は、特にユーザー本人に関する情報を収集する入力に適用されます。ユーザーが他人に関するデータを入力するフィールド（たとえば、ユーザーが別の人のために予約を行う際に旅客の氏名を尋ねる旅行予約フォーム）には適用されません。また、オートコンプリートがセキュリティリスクを生むフィールド、たとえばワンタイムパスワードや CAPTCHA 形式のチャレンジなどにも適用されません。これらでは autocomplete="off" や autocomplete="one-time-code" を正当な形で使用できます。

合格とするには、(1) 対象範囲内のすべての入力フィールドに autocomplete 属性が付与されていること、そして (2) その属性値が HTML の自動入力仕様で認識される有効なトークンであることが必要です。任意の文字列であってはならず、有意味な値が必要な場面で空値であってもならず、スペルミスのトークンであってもなりません。不合格となるのは、対象範囲内の入力に autocomplete 属性がない場合、正当な理由なく autocomplete="off" が指定されている場合、あるいは autocomplete="firstname"（正しいトークンは given-name）や autocomplete="phone"（正しいトークンは tel）のような無効なトークンが指定されている場合です。

有効な autocomplete トークンの完全なリストは WHATWG HTML Living Standard によって管理されており、氏名（given-name, family-name, additional-name）、住所（street-address, address-line1, postal-code, country-name）、連絡先情報（email, tel, tel-national）、認証情報（username, current-password, new-password）、支払い情報（cc-name, cc-number, cc-exp, cc-csc）などの値が含まれます。トークンには、単一ページ上で複数の住所グループを扱うために、セクション識別子（例: section-billing）や shipping / billing キーワードを前置することもできます。

なぜ重要か

この達成基準は主に、ディスレクシア、記憶障害、注意欠如の状態、学習障害などを含む認知障害のあるユーザーのために存在します。これらのユーザーにとって、名、姓、番地、市区町村、郵便番号、電話番号、支払い情報などの別々のフィールドを持つ複雑なチェックアウトフォームに正しく入力することは、大きな認知的負担となり得ます。autocomplete トークンが正しく設定されていれば、ブラウザはユーザーの保存済みプロファイルからワンアクションでフィールドを自動入力でき、摩擦とエラーのリスクを劇的に減らせます。

運動障害のあるユーザー、たとえば手の機能が限られていてスイッチアクセス、視線追跡ソフトウェア、シップ・アンド・パフ装置などを使用する人々にも同様の利点があります。これらのユーザーにとって、文字入力は遅く、労力がかかり、ときには苦痛を伴います。信頼性の高い自動入力が機能すれば、10 分かかる苦行がほぼ瞬時の作業に変わり得ます。世界保健機関によると、世界で約 13 億人が何らかの重大な障害を抱えており、その中でも手先の細かな制御に影響する運動障害は最も一般的なものの一つです。

自動入力にとどまらず、正しい autocomplete トークンは、ブラウザや支援技術がカスタムアイコン、ラベル、拡張入力インターフェイスを提示することを可能にします。たとえば、モバイルデバイス上で tel フィールドに対して自動的に電話キーパッドを表示したり、cc-number フィールドにクレジットカードのグラフィックを表示したりできます。記憶障害のあるユーザーにとって重要なアクセシビリティツールであるパスワードマネージャーも、認証情報フィールドを正しく特定・入力するためにこれらのトークンに依存しています。

現実のシナリオを考えてみましょう。脳性まひのあるユーザーが、政府の給付申請書を記入しています。フォームには、氏名、住所、国民 ID、連絡先情報に関する 12 個のフィールドがあります。正しい autocomplete 値が設定されていなければ、すべてのフィールドを手入力しなければなりません。たった 1 つのトークンのスペルミス、たとえば autocomplete="family-name" の代わりに autocomplete="surname" としてしまうだけで、ブラウザはそのフィールドを認識できず、ユーザーは姓を一文字ずつ入力することになります。正しいトークンが設定されていれば、フォーム全体を数秒で自動入力でき、労力とエラー率の両方を減らせます。

また、組織にとってはユーザビリティやコンバージョン率の向上という利点もあります。自動入力に対応したフォームは、放棄率が低く完了率が高いことが一貫して研究で示されており、autocomplete トークンを修正することはアクセシビリティの改善であるだけでなく、直接的なビジネス改善でもあります。

関連する axe-core のルール

• autocomplete-valid — これは WCAG 1.3.5 に対応する主要な axe-core ルールです。<input>、<select>、<textarea> のうち autocomplete 属性を持つすべての要素を検査し、その属性値が HTML の自動入力仕様で認識される有効なトークンかどうかを確認します。このルールは、トークンがスペルミスである場合（例: ハイフンの代わりにスペースを使った given name）、非標準の独自値が使われている場合（例: autocomplete="first-name"）、複数トークン値においてトークンの順序が誤っている場合（例: 必須のセクション接頭辞より前にフィールド名を置いている）に要素をフラグします。このルールは、autocomplete 属性がまったく欠落しているフィールドはフラグしません。その状況は手動レビューが必要です。なぜなら axe-core は、あるフィールドがこの達成基準の対象範囲内かどうか（すなわち、ユーザーに関する情報を収集しているかどうか）をプログラム的に判断できないからです。
• なぜ手動テストも必要なのか — axe-core のような自動化ツールは、存在する autocomplete 値が構文的に正しいかどうかだけを検証できますが、選択されたトークンがフィールドの目的を正確に表しているかどうかを判断することはできません。たとえば、請求先電話番号フィールドに autocomplete="email" が設定されている場合、email は有効なトークンであるため自動ルールは合格と判定しますが、トークンがフィールドの実際の目的と一致していないため、この達成基準としては不合格になります。同様に、自動化ツールは autocomplete 属性が欠落しているが本来は必要なフィールドを特定できません。あるフィールドがユーザー本人に関する個人情報を収集しているかどうかを判断するには、文脈に基づく人間の判断が必要だからです。そのため、ユーザー固有のデータを収集するすべてのフォームフィールドについて手動レビューを行うことが、1.3.5 を完全に順守するために不可欠です。

テスト方法

1. axe DevTools または Lighthouse で自動スキャンを実行する。フォームを含むページを Chrome または Firefox で開きます。axe DevTools では「Analyze」をクリックし、ルール ID autocomplete-valid で結果をフィルタリングします。Lighthouse ではアクセシビリティ監査を実行し、autocomplete に関する違反を探します。フラグされたすべての要素を記録し、報告された無効なトークン値を控えます。フラグされた各要素を修正し、修正が確認できるまで再スキャンします。
2. 対象範囲内のすべての入力フィールドを手動で特定する。フォームを確認し、現在のユーザーに関する情報を収集するすべてのフィールド（氏名、住所、メール、電話、支払い情報、認証情報）を列挙します。各フィールドについて、autocomplete 属性が存在すること、およびそのトークンが HTML の自動入力トークンリストに従ってフィールドの実際の目的と一致していることを確認します。他人に関する情報を収集するフィールドは対象外であり、除外できます。
3. ブラウザの自動入力動作をテストする。Chrome または Firefox で、ブラウザに保存済みプロファイルがあることを確認します（設定 > 自動入力）。フォームページに移動し、最初の個人情報フィールドをクリックします。ブラウザが自動入力候補を提示し、それを選択すると正しいフィールドに正しい値が入力されることを確認します。住所フィールド、支払いフィールド、認証情報フィールドについても同様に繰り返します。自動入力が値を提案しない、または誤ったフィールドに値を入力する場合、autocomplete トークンが誤っている可能性が高いです。
4. スクリーンリーダーとブラウザの組み合わせでテストする。NVDA と Firefox を使用し、Tab キーで各フォームフィールドに移動します。NVDA はフィールドのラベルと目的を読み上げるはずであり、スクリーンリーダーとブラウザの組み合わせによっては autocomplete の目的も読み上げます。macOS の VoiceOver（Safari）では、Tab でフィールドを移動し、VoiceOver が自動入力の利用可能性を読み上げるかを確認します。JAWS と Chrome でも同様に Tab でフィールドを移動し、JAWS が期待どおりのフィールドコンテキストを読み上げることを確認します。スクリーンリーダーが常に autocomplete トークンを明示的に読み上げるわけではありませんが、キーボード操作と組み合わせて自動入力が正しく機能することを確認することで、プログラム的な目的が公開されていることを検証できます。
5. ブラウザの DevTools で autocomplete 属性を確認する。各フォームフィールドを右クリックし、「検証」を選択します。Elements パネルで autocomplete 属性が存在し、その値が有効なトークンと完全に一致していることを確認します。特に複数トークンの値（例: autocomplete="shipping street-address"）に注意し、トークンの順序が仕様（セクション名、次に "shipping" または "billing"、次にフィールド名）に従っていることを確認します。

修正方法

氏名フィールド — 誤り

<!-- Invalid: uses non-standard token 'firstname' instead of 'given-name' -->
<label for='fname'>First Name</label>
<input type='text' id='fname' name='first_name' autocomplete='firstname'>

<label for='lname'>Last Name</label>
<input type='text' id='lname' name='last_name' autocomplete='surname'>

氏名フィールド — 正しい例

<!-- Valid: uses the exact WHATWG-specified tokens 'given-name' and 'family-name' -->
<label for='fname'>First Name</label>
<input type='text' id='fname' name='first_name' autocomplete='given-name'>

<label for='lname'>Last Name</label>
<input type='text' id='lname' name='last_name' autocomplete='family-name'>

請求先・配送先セクションを含む住所フォーム — 誤り

<!-- Invalid: missing autocomplete attributes entirely on address fields -->
<fieldset>
  <legend>Billing Address</legend>
  <input type='text' name='bill_street' placeholder='Street Address'>
  <input type='text' name='bill_city' placeholder='City'>
  <input type='text' name='bill_postal' placeholder='Postal Code'>
</fieldset>

請求先・配送先セクションを含む住所フォーム — 正しい例

<!-- Valid: autocomplete tokens include 'billing' prefix and correct field names -->
<fieldset>
  <legend>Billing Address</legend>
  <input type='text' name='bill_street' autocomplete='billing street-address' placeholder='Street Address'>
  <input type='text' name='bill_city' autocomplete='billing address-level2' placeholder='City'>
  <input type='text' name='bill_postal' autocomplete='billing postal-code' placeholder='Postal Code'>
</fieldset>

電話番号フィールド — 誤り

<!-- Invalid: uses 'phone' which is not a recognized autocomplete token -->
<label for='tel'>Phone Number</label>
<input type='text' id='tel' name='telephone' autocomplete='phone'>

電話番号フィールド — 正しい例

<!-- Valid: 'tel' is the correct autocomplete token for a full phone number -->
<label for='tel'>Phone Number</label>
<input type='tel' id='tel' name='telephone' autocomplete='tel'>

ログイン認証情報 — 誤り

<!-- Invalid: autocomplete='off' prevents password managers and autofill from working -->
<label for='user'>Username</label>
<input type='text' id='user' name='username' autocomplete='off'>

<label for='pass'>Password</label>
<input type='password' id='pass' name='password' autocomplete='off'>

ログイン認証情報 — 正しい例

<!-- Valid: 'username' and 'current-password' allow password managers to function correctly -->
<label for='user'>Username</label>
<input type='text' id='user' name='username' autocomplete='username'>

<label for='pass'>Password</label>
<input type='password' id='pass' name='password' autocomplete='current-password'>

よくある間違い

• autocomplete="firstname" や autocomplete="first-name" を、正しいトークン given-name" の代わりに使用してしまう。これらの非標準の値は、一見論理的に見えてもブラウザや支援技術には認識されません。必ず HTML の自動入力仕様にある正確なトークンを使用してください。
• autocomplete="tel" の代わりに autocomplete="phone" を使用してしまう。「phone」という語は有効なトークンではありません。仕様では、完全な電話番号には tel を、電話番号の一部には tel-national、tel-area-code、tel-local を使用します。
• 誤ったセキュリティ対策として、認証情報フィールドに autocomplete="off" を設定してしまう。現代のブラウザと WCAG 仕様は、ログインフォームで自動入力を禁止することが障害のあるユーザーに実際の障壁を生み、セキュリティを有意に向上させないことを認識しています。代わりに autocomplete="username" と autocomplete="current-password" を使用してください。
• ブラウザがフィールド名やラベルから目的を推測すると想定して、個人データフィールドに autocomplete 属性をまったく付与しない。ブラウザはヒューリスティックを用いてフィールドの目的を推測しますが、これは信頼性に欠け、ブラウザ間で一貫性もありません。保証されたアクセシブルな体験のためには、明示的なトークンが必要です。
• 特定の住所サブトークンの代わりに autocomplete="address" を使用してしまう。仕様には address トークンは存在しません。street-address、address-line1、address-line2、address-level1（州/都道府県）、address-level2（市区町村）、postal-code を個別に使用する必要があります。
• 複数トークン値で shipping や billing のキーワードを誤った順序で配置してしまう。正しい順序は、任意のセクション接頭辞（例: section-billing）、次に任意の shipping/billing キーワード、次にフィールド名トークンです。autocomplete="street-address billing" と記述するのは無効であり、正しい形式は autocomplete="billing street-address" です。
• 表示されているフィールドにだけ autocomplete を適用し、非表示または動的に表示されるフィールドを無視してしまう。最初は非表示で、ユーザー操作によって表示されるフィールド（追加の住所行や任意フィールドなど）も、アクティブになったときには正しい autocomplete トークンを持っていなければなりません。
• ページ読み込み後に JavaScript で autocomplete 属性を動的に削除または上書きしてしまう。一部のフォームライブラリや UI フレームワークは、コンポーネントのマウントや再レンダリング時に入力属性をリセットし、意図せず autocomplete トークンを削除してしまうことがあります。すべての JavaScript 実行後も、ライブ DOM に属性が残っていることを必ず確認してください。
• type="email" や type="tel" が指定されていれば、autocomplete がなくても目的が伝わると想定してしまう。type はある程度の情報を提供しますが、autocomplete 属性は WCAG 1.3.5 で別個に求められる明示的なシグナルであり、ブラウザや支援技術によって異なる形で利用されます。
• 異なるデータを収集する 2 つのフィールドに同じ autocomplete トークンを使用してしまう。たとえば、勤務先メールフィールドと個人メールフィールドの両方に autocomplete="email" を付与すると、ブラウザが混乱し、誤った自動入力が行われる可能性があります。これを区別するには、section-work email と section-personal email のようにセクション接頭辞を使用します。

トルコのアクセシビリティ規制との関係

トルコの大統領通達 2025/10 は、2025 年 6 月 21 日付官報第 32933 号で公布され、トルコで事業を行う幅広い組織に対して拘束力のあるアクセシビリティ要件を定めています。この通達は、デジタルサービスのベースライン標準として WCAG 2.2 レベル AA への適合を義務付けており、その中には WCAG 1.3.5 — 入力目的の特定 が直接含まれます。

通達の対象となる主体の種類は多岐にわたります。公共機関や政府機関は、市民向けのすべてのデジタルサービスについてこれらの基準を満たすことが求められます。対象となる民間部門の組織には、e コマースプラットフォーム、銀行および金融サービス提供者、病院および医療提供者、20 万人以上の加入者を持つ通信事業者、認可を受けた旅行代理店、民間旅客輸送会社、国民教育省（MoNE）に認可された民間教育機関が含まれます。実務的には、トルコのほぼすべての主要な消費者向けデジタルプロダクト（銀行アプリ、オンライン小売のチェックアウト、医療予約ポータルなど）が、すべての個人データ入力フィールドに正しく実装された autocomplete トークンを備えていなければならないことを意味します。

特に WCAG 1.3.5 については、トルコのあらゆる e コマースのチェックアウトフォーム、銀行口座開設フォーム、病院の患者登録フォーム、通信契約フォームが、氏名、住所、電話番号、支払い情報などのユーザー情報を収集する場合、関連するすべての入力フィールドに有効な autocomplete 属性値を含めなければならないことを意味します。これを怠るとレベル AA の不適合となり、組織はアクセシビリティロゴ（Erişilebilirlik Logosu）を取得または維持できなくなる可能性があります。アクセシビリティロゴは、組織のデジタルサービスがアクセシビリティ基準を満たしていることを証明する、家族・社会サービス省による公式マークです。

アクセシビリティロゴには評判上および規制上の重みがあり、e コマースや銀行など競争の激しい消費者市場にいる組織には、これを取得・維持する強い動機があります。WCAG 1.3.5 は実装が容易（autocomplete 属性値の追加や修正にはアーキテクチャの変更が不要）でありながら、認知障害や運動障害のあるユーザーに大きな利益をもたらすため、2025/10 通達の下でレベル AA 完全適合を目指す組織にとって、最小の労力で最大の価値を生むアクセシビリティ改善の一つとなっています。

組織は、自社のすべてのデジタルプロパティ（モバイル Web インターフェイスやレスポンシブレイアウトを含む）にわたるすべてのフォームを監査し、あらゆるフォーム実装の標準として正しい autocomplete トークンを要求する開発ポリシーを確立すべきです。これは axe-core などのツールを用いた CI/CD パイプラインでの自動テストによって強制し、本番環境に到達する前にリグレッションを検出する必要があります。