Skip to content

解説書 達成基準 3.3.8: アクセシブルな認証 (最低限) (レベル AA)

要約

目標
より少ない知的努力でログインできるようにする。
何をすればよいか
ログインの際に、人々に何かを解かせたり、思い出させたり、転記させないようにする。
なぜそれが重要か
認知障害のある人々の中には、パズルを解くこと、ユーザ名及びパスワードを記憶すること、又はワンタイムパスコードを再入力することができない人もいる。

意図

この達成基準の目的は、既存のアカウントにログインするときに、アクセシブルで、使いやすく、安全な方法で利用者が認証するのを保証することである。最も広まっている認証形式として、ウェブサイトは通常、ログインするためにユーザ名及びパスワードに依存する。しかし、ユーザ名及びパスワードを記憶することは、認証プロセスにしばしば追加される追加手順と同様に、特定の認知障害のある人々にとって非常に大きな負担、又はひどく困難な負担となる。例えば、ワンタイム認証コードを転記する必要がある場合や、パズルを解く必要がある場合などである。

ウェブサイトは、この達成基準を満たすために、物体を認識させる、又は利用者が提供する非テキストコンテンツを認識させてもよいが、そのような技術は、認知アクセシビリティを必要とする人々を完全にはサポートしておらず、可能な限り避けるべきである。より包括的でアクセシブルにするためのガイダンスについては、アクセシブルな認証 (高度) を参照すること。

この達成基準は、既存の利用者の認証に焦点を当てたものである。ユーザ名の作成又はアカウントの開始については対象としていない。多くのウェブサイトでは、最初のユーザ名及び資格情報を確立することは、そのユーザ名でログインすることとそれほど変わらない場合がある。この基準を満たすために使用される技術 (特に、入力欄へのペーストを許可し、転記に依存しない) によって、アカウント作成時の認知的負担も軽減できる。ただし、この達成基準の焦点は、利用者がログインするたびに、又はその他の方法でアカウントを認証するたびに、以前に提供された情報を思い出す必要性を軽減することにある。

認知機能テスト

サイト固有のパスワードを記憶することは、認知機能テストの一つである。そのようなテストは、多くの認知障害のある人々にとって問題となることが知られている。ランダムな文字列を記憶する場合でも、タッチスクリーン上で実行するパターンジェスチャを記憶する場合でも、認知機能テストは一部の人を排除する。認知機能テストを使用する場合、認知機能テストではない他の認証方法が少なくとも一つ使用可能でなければならない。

一部の CAPTCHA システムには、可視テキストの音声代替がある。利用者がこの音声を転記する必要がある場合、代替手段の例外を満たすものとしては、使用することができない。

多要素認証のように、認証プロセスに複数のステップがある場合、合格するには全てのステップがこの達成基準に適合する必要がある。認知機能テストに依存しない認証のパスが必要である。

電子メール及びパスワードを回復又は変更できることは、認証の重要な部分である。利用者がアカウントを回復するために代替情報で認証している場合、認知機能テストではない方法が必要である。

多くの組織は、利用者の身元を確認するために、独立したソースを組み合わせた 2 要素認証を使用することが要求される。これらのソースは、次の認証を組み合わせて構成できる:

  • 知識 (例えば、パスワード、パスフレーズ内の文字、又は記憶されたスワイプの軌跡)。
  • 所有 (例えば、デバイス上で生成もしくは受信された検証コード、又は外部デバイス上の QR コードのスキャン)。
  • 生体認証 (例えば、指紋スキャン、顔認識、キーストロークダイナミクス)。

ほとんどの知識ベースの認証方法は認知機能テストに依存しているため、利用者を支援するメカニズムが利用可能でなければならない。認証が別のデバイスでのアクションの実行に依存している場合、情報を転記することなくアクションを完了できるべきである。利用者がどのようなデバイスベースの認証方法を利用可能かを知ることができない場合がある。方式の選択肢を提供することで、利用者が最も適したパスを選択できるようになる。

認証アプローチ

ウェブサイトでは、コンテンツ制作者がユーザエージェント (ブラウザ及びサードパーティのパスワードマネージャー) によるフィールドへの自動入力の許可を与えている場合、認証方法としてユーザ名 (又は電子メール) 及びパスワードの入力を使用できる。一般的に、ログインフォームが達成基準 1.3.5 の入力目的の特定を満たし、かつフォームコントロールに達成基準 4.1.2 名前 (name)・役割 (role)・値 (value) に従って適切なアクセシブルな名前 (name) がある場合、ユーザエージェントは期待通りにフィールドを認識し、自動的に入力できるようにすべきである。ただし、ユーザエージェントが (スクリプトなどによって) フィールドへの入力を積極的にブロックしている場合、メカニズムが機能しないため、ページはこの基準に合格しない。

コピー＆ペースト

転記を避けるには、コピー＆ペーストを利用できる。利用者は、ローカルソース (例えば、スタンドアロンのサードパーティパスワードマネージャー) からログイン資格情報をコピーし、ログインフォームのユーザ名及びパスワードのフィールドにペーストする、又はパスワードを要求するウェブベースのコマンドラインインタフェースにペーストすることができる。認証フィールドへのペーストをブロックする、又はコピーしたテキストと入力フィールドとの間で異なる形式を使用すると (例えば、「パスワードの 3 番目、4 番目、および 6 番目の文字を入力してください」)、利用者は情報を転記する必要が生じるため、別の方法が利用できない限り、この基準に失敗する。

2 要素認証システム (検証コード)

一部のサイトでは、ユーザ名とパスワード以外に 2 要素認証を使用し、利用者に検証コード (パスコード又はワンタイムパスワードとも呼ばれる) の記入を求める場合がある。検証コードを手作業で転記する必要があるサービスは準拠していない。ユーザ名とパスワードと同様に、利用者が少なくとも (スタンドアロンのサードパーティのパスワードマネージャー、テキストメッセージアプリケーション、ソフトウェアベースのセキュリティキーなどから) そのコードをペーストする、又はユーザエージェントがフィールドを自動的に埋められるようにする必要がある。

検証コードをセカンダリーデバイスで受信又は生成しなければならないシナリオがある。例えば、ラップトップ上のウェブブラウザで認証する際に、携帯電話に SMS テキストメッセージとして送信される検証コードが必要になる場合がある。しかし、ほとんどの場合、コードをプライマリーデバイスに直接送信し、コピー＆ペーストできる (例えば、セカンダリーデバイス上のコードをコピーしてプライマリデバイスに電子メールで送信したり、共有のクロスデバイスクリップボードを使用して、セカンダリーデバイス上のコンテンツをコピーすると、そのコンテンツをプライマリーデバイスに貼り付けできる)。コードをセカンダリーデバイスからプライマリーデバイスにシームレスに転送できるかどうかの評価は、この達成基準の範囲外である。このようなタイプのセカンダリーデバイスシステムを使用した認証に依存するウェブコンテンツを評価する目的の場合、利用者のクリップボードでコードを利用できるように準備が整っていることが前提となる。したがって、この基準の評価に必要なのは、そのウェブコンテンツが、関連する認証チャレンジフィールドへのクリップボードのコンテンツのペーストを許可していることを検証することだけである。

コードに依存しない 2 要素システムは、認知機能テストではないことに注意する。これには、ハードウェア認証デバイス (YubiKey など)、実際にログインしようとしているのが本人であることを利用者が確認することを期待するセカンダリーアプリケーション (同じプライマリーデバイス上か、セカンダリーデバイス上のいずれか)、利用者のオペレーティングシステムによって提供される認証方法 (Windows Hello、macOS 及び iOS の Touch ID/Face ID など) などが含まれる。

物体の認識

CAPTCHA が認証プロセスの一部として使用される場合、例外を満たさない限り、認知機能テストを含まない方法が存在しなければならない。単語を記憶したり転記する、ウェブサイトが提供する画像の認識など、ウェブサイトが設定したものに基づいているテストである場合、それは認知機能テストになる。物体、又は利用者が提供した画像の認識も認知機能テストではあるが、AA レベルでは例外となる。

この文脈における物体とは、一般的な英語の定義 (「見て触れられる物質的なもの」) を意味し、乗り物及び動物を含むことがある。テストが認識の範囲を超える場合 (例: 猫の数に犬の数を掛けてください)、例外を満たさない。

物体の認識の一部の形式では、特定の文化の理解を必要とする場合がある。例えば、タクシーは地域によって外観が異なる場合がある。これは多くの人々にとって問題であり、その中には障害のある人も含まれるが、アクセシビリティ特有の問題とはみなされていない。

認証に使用される一部の CAPTCHA 及び認知機能テストは、広告ブロッカーが存在する場合、間違ったパスワードを繰り返し入力した場合など、特定の状況でしか表示されないことがある。この基準は、これらのテストが毎回使用されるか、特定のシナリオによってのみトリガーされるかに関係なく、これらのテストが使用されていれば適用される。

スクリプトによる認証プロセスの濫用を防ぐために使用できる技術は多数存在する。

これらのシステムはいずれも 100％有効ではない。しかし、CAPTCHA が表示される可能性を減らすことはできる。

個人特有のコンテンツ

個人特有のコンテンツは、認証の第 2 要素として使用されることがある。例えば、アカウント作成の一環として利用者が写真をアップロードし、ログイン時にいくつかの可能な選択肢からその写真を選択するように求められる。この場合、非正規の利用者が選択肢を提示されたときに正しい個人特有なコンテンツを推測できる可能性があるため、適切なセキュリティを提供するように注意しなければならない。

テキストベースの個人特有のコンテンツは、記憶 (認識ではない) 及び転記 (項目の選択ではない) に依存しているため、この例外の対象にはならない。写真ベースの個人特有のコンテンツが依然として障壁となる人もいるが、テキストベースのバージョンははるかに大きな障壁となる傾向がある。

文字を隠す

認知的負荷につながる可能性のあるもう一つの要因は、タイピングの際に文字が隠れることである。この基準では、利用者がパスワードをタイピング (転記) する必要がないことが求められているが、パスワードマネージャーで保存するパスワードを作成するなど、それが必要となるシナリオもある。オプションでパスワードを表示する機能を提供することで、認知障害のある人、又は正確なタイピングが困難な人の成功の可能性が高まる。

利点

記憶、読解（例えばディスレクシア）、数字（例えばディスカリキュリア）、又は知覚処理制限に関する認知的問題のある人でも、認知能力のレベルに関係なく認証できる。

事例

この達成基準の例は、アクセシブルな認証 (高度) の例と同じである。

  • ウェブサイトは、適切にマークアップされたユーザ名 (又は電子メール) 及びパスワードのフィールドをログイン認証として使用する (達成基準 1.3.5 入力目的の特定及び達成基準 4.1.2: 名前 (name)・役割 (role)・値 (value) を満たしている)。利用者のブラウザ又は統合されたサードパーティのパスワードマネージャー拡張機能は、入力の目的を特定し、ユーザ名及びパスワードを自動的に入力できる。
  • ウェブサイトは貼り付け機能をブロックしていない。利用者は、サードパーティのパスワードマネージャーを使用して資格情報を保存し、コピーしてログインフォームに直接貼り付けることができる。
  • ウェブサイトは WebAuthn を使用するため、利用者はユーザ名/パスワードの代わりにデバイスで認証できる。利用者のデバイスは、利用可能な任意のモダリティを使用できる。ノートパソコン及び携帯電話での一般的な方法は、顔スキャン、指紋、PIN (個人識別番号) である。このウェブサイトは、特定の使用を強制するものではない。利用者が自分に合った方法を設定することを想定している。
  • ウェブサイトは、OAuth メソッドを使用してサードパーティプロバイダーにログインする機能を提供する。
  • 2 要素認証を必要とするウェブサイトは、利用者がボタンを押すだけで時間ベースのトークンを入力する USB ベースの方法など、2 要素認証について複数のオプションを許容する。
  • 2 要素認証を必要とするウェブサイトは、利用者のデバイス上のアプリでスキャンして本人確認できる QR コードを表示する。
  • 2 要素認証を必要とするウェブサイトは、利用者のデバイスに通知を送信する。利用者は、デバイスの認証メカニズム (ユーザ定義の PIN、指紋、顔認識など) を使用して本人であることを確認しなければならない。

関連リソース

リソースは、情報提供のみを目的としており、推奨を意味するものではない。

テクニック

この節にある番号付きの各項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断するテクニック、又は複数のテクニックの組み合わせを表している。しかしながら、必ずしもこれらのテクニックを用いる必要はない。その他のテクニックについての詳細は、WCAG 達成基準のテクニックを理解するの「その他のテクニック」を参照のこと。

十分なテクニック

失敗

以下に挙げるものは、WCAG ワーキンググループが達成基準の失敗とみなした、よくある間違いである。

重要な用語
ASCII アート (ASCII art)

文字又はグリフの空間的配置によって作られた図画 (典型的には、ASCII で定義されている 95 の印字可能文字から作られる)。

支援技術 (assistive technology)

障害のある利用者の要件を満たすために、主流のユーザエージェントが提供する機能を超えた機能を提供するような、ユーザエージェントとして動作する、又は主流のユーザエージェントと共に動作するハードウェア及び／又はソフトウェア。

注記

支援技術が提供する機能としては、代替の提示 (例: 合成音声や拡大表示したコンテンツ)、代替入力手法 (例: 音声認識)、付加的なナビゲーション又は位置確認のメカニズム、及びコンテンツ変換 (例: テーブルをよりアクセシブルにするもの) などを挙げることができる。

注記

支援技術は、API を利用、監視することで、主流のユーザエージェントとデータやメッセージのやりとりをすることが多い。

注記

主流のユーザエージェントと支援技術との区別は、絶対的なものではない。多くの主流のユーザエージェントは、障害のある個人を支援する機能を提供している。基本的な差異は、主流のユーザエージェントが障害のある人もない人も含めて、広く多様な利用者を対象にしているのに対し、支援技術は、特定の障害のある利用者という、より狭く限られた人たちを対象にしているということである。支援技術により提供される支援は、対象とする利用者に特化した、よりニーズに適したものである。主流のユーザエージェントは、プログラムオブジェクトからのウェブコンテンツの抽出、マークアップの識別可能な構造への解釈といった、重要な機能を支援技術に対して提供する場合がある。

認知機能テスト (cognitive function test)

利用者に情報の記憶、操作又は転記を要求するタスク。例には、次のものが含まれるが、これらに限定されない:

  • 記憶させること、たとえばユーザー名、パスワード、文字の一式、画像、パターンを覚えさせるなど。一般的な識別子である名前、電子メール及び電話番号は、利用者にとって個人特有のものであって、ウェブサイト間で一貫しているため、認知機能テストとはみなされない。
  • 転記させること、たとえば文字をタイピングさせるなど。
  • 正しい綴りを使わせること。
  • 計算を実行させること。
  • パズルを解かせること。
適合 (conformance)

与えられた規格、ガイドライン、又は仕様のすべての要件を満たすこと。
自然言語 (human language)

人間とコミュニケーションをとるために話される、書かれる、又は (視覚的もしくは触覚的な手段で) 手話にされる言語。

注記

手話も参照。

メカニズム (mechanism)

結果を得るためのプロセス又は手法。

注記

メカニズムは、コンテンツ内で明示的に提供されることもあれば、プラットフォーム又は支援技術を含むユーザエージェントで提供されるものに依存することもある。

注記

メカニズムは、宣言する適合レベルのすべての達成基準を満たしている必要がある。
非テキストコンテンツ (non-text content)

プログラムによる解釈が可能な文字の並びではないコンテンツ、又は文字の並びが自然言語においても何をも表現していないコンテンツ。

注記

これには、 (文字による図画である) ASCII アート、顔文字、 (文字を置き換える) リートスピーク、文字を表現している画像が含まれる。

プロセス (process)

ある活動を完了させるために必要な利用者の一連の動作。
プログラムによる解釈 (programmatically determined)

支援技術を含む様々なユーザエージェントが抽出でき、利用者に様々な感覚モダリティで提示できるような形のデータがコンテンツ制作者によって提供されたとき、そのデータがソフトウェアによって解釈されること。

依存されている (relied upon)

その技術が無効になっている場合、又はサポートされていない場合に、コンテンツが適合できないこと。

手話 (sign language)

意味を伝えるために、手と腕の動き、顔の表情又は身体の姿勢の組み合わせを用いる言語。

技術 (technology)

ユーザエージェントがどのようにレンダリング、再生、又は実行するかを符号化するメカニズム。

注記

このガイドラインで用いられている「ウェブ技術」及び (単独で用いられている) 「技術」という用語は、どちらもウェブコンテンツ技術を指す。

注記

ウェブコンテンツ技術には、マークアップ言語、データ形式、及びプログラム言語などがあり、これらをコンテンツ制作者が単独で、又は組み合わせて用いることによって、静的なウェブページや同期したメディアによる提示、さらには動的なウェブアプリケーションに至るまでの様々なエンドユーザ体験を作ることができる。

ユーザエージェント (user agent)

ウェブコンテンツを取得して利用者に提示するあらゆるソフトウェア。
Back to Top