アクセシビリティ
about.gitlab.com 上のアクセシビリティ問題を表面化する
マーケティングサイトリポジトリへ Issue を作成し、dex-category::accessibility ラベルを追加します。
アクセシビリティ問題の解決
簡易対応（まずはここから）
Axe Devtools を実行した
Google Lighthouse を実行した
ブラウザー間のタブ移動に関する注記
異なるブラウザーは、ページ上のインタラクティブな要素（リンク、ボタン、フォーム入力など）をタブ移動する際に異なる動作をします。Chrome および Chromium ベースのブラウザーでは、tab キーで次のフォーカス可能な要素へ移動し、shift + tab でフォーカス可能な要素を 1 つ前へ戻ります。これはスクリーンリーダーをご利用の方を支援するためです。
Safari はデフォルトではタブナビゲーションを使用しません。ユーザーは Safari の設定に入り、タブナビゲーションを有効にするチェックボックスを有効にする必要があります。Mozilla は Mac OS のオペレーティングシステム設定に忠実なので、こちらも有効にする必要があります。
関連リソース: https://stackoverflow.com/questions/52783375/anchor-with-href-not-taking-focus-in-safari-even-with-all-accessibility-keyboard https://stackoverflow.com/questions/11704828/how-to-allow-keyboard-focus-of-links-in-firefox
タブ移動に関連するアクセシビリティの課題への取り組みのガイダンス
tabindexを適切に設定する: ユーザーがtabキーを使用したときに要素がフォーカスを受け取る順序を指定するためにtabindex属性を使用できます。ARIA ロールを適切に使う: ARIA ロールは、ウェブコンテンツを障害のある人にアクセシブルにする方法を提供します。要素のロールを定義するために使用でき、支援技術がそれとどのように対話するかを理解するのに役立ちます。
一貫したデザイン: 現在キーボードフォーカスを持っている要素を視覚的に示すように設計してください（例: 色やアウトラインを変える）。この視覚的な手がかりは、支援技術を使用している方だけでなく、すべてのユーザーに役立ちます。
より包括的なテスト
Axe や Google Lighthouse のようなツールには限界があり、私たちにとっては良い出発点に過ぎません。AA 準拠を達成するには、MacOS で VoiceOver のようなスクリーンリーダー技術を使用して実際のウェブページでテストすることが必要です。
次のアクセシビリティスプレッドシートを実行: https://docs.google.com/spreadsheets/d/1pCfGv8xHjY39Oeft37pGjgot_lg0_j3cSyty0H9njv8/edit#gid=0
ホームページでアクセシビリティをテストする例: https://www.youtube.com/watch?v=jtVMFUQLJEE
