Webアクセシビリティとは、障害を持つユーザーがウェブコンテンツを利用可能にすることである。開発チームは、Webコンテンツアクセシビリティガイドラインの成功基準を使用してアクセシビリティを向上させ、インクルーシブなWebサイトを作成することができる。
Joanna Falkowska氏は、DEV: Challenge AcceptedでアクセシブルなWebサイトの作成について講演した。
Falkowska氏は、さまざまな種類の障害があると言った。感覚の制限（視覚、聴覚など）、身体的な制限（手足の欠損など）、神経疾患（パーキンソン病など）、認知障害（ダウン症など）を持つユーザーを思い浮かべてほしい。
WHOは、世界の人口の約16%が重大な障害に影響されていると推定している。
軽度の障害や、高齢者のように通常は自分を障害者と見なさないが同様の問題に直面する可能性があるグループをすべて加えると、その数はさらに多くなります。
Falkowska氏は、アクセシビリティの取り組みをどこから始めたらよいかわからない開発チームは考慮すべき障害の数に圧倒される可能性があると述べた。彼らは、障害を持つさまざまなユーザーがWebアプリを開くときに直面する制限について、全くアイデアがない場合もある。
必要なのはアプリがアクセシブルであることを示す、明確な基準を提供するベンチマークです。
Webコンテンツアクセシビリティガイドライン（WCAG）はWebアプリを作成する人々のために作成された文書である。このガイドラインはWebをアクセシブルにするために作成されており、人々が使用する技術の進化に合わせて随時更新されるとFalkowska氏は述べた。オフラインの世界が障害者にとってより友好的であるかどうかと同様に、私たちが閲覧するWebサイトも同様にアクセシブルであるかどうかが異なると彼女は付け加えた。
WCAGは、適合レベルが割り当てられた一連の成功基準を提供する。Falkowska氏によると：
もっとも低く、もっとも基本的なレベルはAです。WCAGの作成と更新を担当するWeb Accessibility Initiative（WAI）は、私たちが閲覧するすべてのWebサイトが少なくともこの適合レベルを満たすべきだと述べています。
AAは少し複雑だが、同時に著者（および多くの法的行為）が従うことを推奨するレベルであるとFalkowska氏は述べた。3番目は、一般的に達成するのがもっとも難しいAAAである。通常、AAAに対応するのは政府機関や特定の障害者グループにサービスを提供する企業や団体であるとFalkowska氏は述べた。
レベルは木製の入れ子人形「マトリョーシカ」のようなものだとFalkowska氏は述べた。WebサイトでAAAに対応したい場合、AAおよびAの成功基準もカバーする必要がある。
Falkowska氏はもっともよく見落とされる成功基準の1つとして、目で認識できるコンテンツに代替テキストを追加することだと述べた。例えばWebサイトに画像が含まれている場合、視覚障害者がスクリーンリーダーを使用すると無意味な数字や文字列の可能性があるファイル名が読み上げられることがある。このコンテンツを意味のある方法で認識できるようにするために開発者はhtmlに「alt」属性を追加する、とFalkowska氏は述べた。この属性のコンテンツはWebサイトに表示されないが、スクリーンリーダーがそれを読み上げて支援技術を使用している人に伝える。
InfoQはJoanna Falkowska 氏にアクセシブルなウェブサイトの成功基準についてインタビューした。
InfoQ: 成功基準の例をいくつか教えていただけますか？
Joanna Falkowska氏:例としては、キーボードフォーカスがあります。ユーザーがすべてのインタラクティブ要素をキーボードで操作できる必要があり、これはhtmlの「tabindex」属性で実現されます。これは視覚障害者だけでなく、パーキンソン病などで手の震えがあるためにマウスを使用できない人にも有益です。これは、成功基準が障害のないユーザーをサポートできる非常に良い例でもあります。マウスの充電が切れて、マウスのバッテリー充電中にキーボードだけでウェブをナビゲートする必要があった状況を数え切れないほど経験しました...。
もう一つの例は、画面の向き（主にタブレットやスマートフォンで重要）です。横向きや縦向きのみに限定すべきではありません。一部のユーザーは特定の向きでしかモバイルデバイスを使用できないかもしれません。四肢麻痺のユーザーが特別なハンドルや三脚にスマートフォンを取り付けている場合を考えてみてください。彼らはスマートフォンを回転させることができません。CSSのrotateやtransformプロパティで画面表示を特定の向きに固定すべきではありません。
最新の成功基準のひとつでは、ユーザーが直面する認証の問題について議論しています。認証は短期記憶に負担をかけるパズルを含むべきではないため、ログイン機能がコピー＆ペーストやパスワードマネージャーの使用を許することを確実にする必要があります。入力フィールドに適切な「label」、「type」、「autocomplete」html属性を提供することを確実にしましょう。それに加えて、ユーザーが内容を解読して入力フィールドに入力する必要があるCAPTCHaを要求するべきではありません。オブジェクト認識はAAレベルでは許可されていますが、AAAを達成したい場合、このタイプのCAPTCHaも除去する必要があります。