第508条への準拠が実際にはより優れたエンジニアリングである理由
ほとんどのチームは第508条を土壇場での法的ハードルのように扱っていますが、アクセシビリティを考慮して構築するには、よりクリーンなコードを書き、誰にとってもより良いUXを作成する必要があります。
しかし、私たちはそれを違った見方をしています。
サイトが 508 に準拠していない場合、基本的には壊れていることになります。Chrome ユーザーに [送信] ボタンが機能しないサイトを出荷することはありませんよね？では、キーボードや点字ディスプレイを使っているユーザーには役に立たないサイトを出荷しても問題ないのはなぜでしょうか。508条は、あると便利な追加機能ではありません。これは機能的なソフトウェアのベースラインです。Sweent LLCでは、Kaiser Permanente向けの医療機器パッチツールからDeloitte向けのマーケティングサイトまで、エンタープライズグレードのシステムを多数構築してきましたが、教訓は常に同じです。アクセシブルなコードほどコードの方が優れているということです。
実際には何の話をしているのでしょうか？
第508条は、1973年のリハビリテーション法の一部です。連邦政府機関は、障害者が自社の電子技術や情報技術を利用できるようにしなければならないと定められています。ウェブの世界では、これは通常、ウェブコンテンツ・アクセシビリティ・ガイドライン (WCAG) に従うことを意味します。
私たちのような企業にとって、これは私たちの基本です。私たちはサービス障害のある退役軍人が経営する中小企業（SDVOSB）で、GSA MAS契約（47QRAA25D0024）を結んでいます。政府向けに構築する場合、508 コンプライアンスはお勧めできません。それは法律です。しかし、連邦政府との契約を追いかけていなくても、508 の背後にある原則は、あなたのソフトウェアを誰にとってもより良いものにします。
考えてみてください。明るい日差しの中で携帯電話を使おうとして、コントラストの低いテキストが見えなかったことはありませんか？これはアクセシビリティの問題です。一時的に怪我をして、片手で現場をナビゲートしなければならなかったことはありませんか？アクセシビリティの問題。コントラストの向上とキーボードショートカットは、永続的な障害を持つ人だけでなく、すべての人に役立ちます。これは歩道の縁石をデジタル化したものです。車椅子用に設計されていますが、ベビーカーやスケートボード、重い荷物を持っている人の生活も楽になります。
私が死ぬことになるセマンティック HTML ヒル
将来の自分のためにできる最大の利点の 1 つは、セマンティック HTML を使用することです。これは、試さなくてもコンプライアンスへの道のりの 70% を達成できる最も簡単な方法です。これはよくあることです。開発者はボタンの見た目を決めたいので、<div> のスタイルを設定してクリックハンドラを追加します。
<div class="my-custom-button" onclick="submitForm()">
</div>送信
目の見えるユーザーがマウスを持っていると、それはボタンのように見えます。しかし、スクリーンリーダーには汎用的なコンテナが表示されます。インタラクティブだとは認識していません。ボタンのリストには表示されません。ボタンのように動作させるには、手動で tabindex= "0"、role=" button "を追加し、「Enter」キーと「Space」キーイベントを処理する必要があります。
あるいは、単に `` タグを使うこともできます。
<button class="my-custom-button" type="submit">
</button>送信
ブラウザはボタンの扱い方をすでに知っています。デフォルトではキーボードでアクセス可能です。適切な役割が組み込まれています。これが、私が 508 コンプライアンスはまさに優れたエンジニアリングだと言うときの意味です。ツールを本来の用途どおりに使用しています。私たちがデロイトのエンタープライズマーケティングチームをサポートしていたとき、忠実度の高いFigmaデザインをコードに変換するには、すべての「ボタン」が実際にはボタンであり、監査に失敗するようなスタイルのスパンではないことを確認する必要がありました。
そして、それは単なるボタンよりも奥が深いのです。<nav> をメニューに、<main> をメインコンテンツに、<header> をブランディングに使用すると、ブラウザに地図が表示されます。これらを正しく使用すると、スクリーンリーダーに役立つだけでなく、コードを他の開発者が読みやすくなります。ブラウザーを開かなくても、よく構造化された HTML ファイルを見て、何が起こっているのかを正確に把握できます。これにより、メンテナンスの時間と費用を節約できます。
マウスフリーテスト
簡単な実験です。現在のプロジェクトに移動し、マウスを床に置き、「Tab」キーと「Enter」キーのみを使用してコアユーザーフローを完成させてみます。
フォーカスがどこにあるかわかりますか?デザイナーが「見苦しい」と思ってフォーカスリングを隠してしまったなら、もう失敗したことになります。フォーカスがヘッダーからフッターに移動してからサイドバーに戻ると、DOM の順序が乱れます。
カイザー・パーマネンテのプロジェクトに取り組んでいるときに、このような状況に遭遇しました。私たちは、IBM BigFixを使用して数千台のデバイスの医療機器へのパッチ適用を管理するツールを構築していました。医療環境では、わかりにくいUIや操作が難しいUIを使うわけにはいきません。技術者が急いでいて、フォーカスの状態が見えないために「確認」ボタンが見つからない場合、それは大きな問題です。すべてのアクションが、明確でコントラストの強いフォーカスインジケーターを備えたキーボードでトリガーできるようにするために、多くの時間を費やしました。それはコンプライアンスだけの問題ではなく、安全性に関するものでした。
しかし、最新の React アプリではフォーカス管理が難しくなります。シングルページアプリケーション (SPA) で「ページ」を変更しても、ブラウザは実際にはリロードされません。スクリーンリーダーのユーザーには何も起こりませんでした。クリックしたばかりのリンクにはまだ座っていますが、周囲のコンテンツは変わっています。手動でフォーカスを新しいコンテンツに移動するか、「aria-live」領域を使用してページの変更をアナウンスする必要があります。そうしないと、目の見えないユーザーにとっては「モダン」なアプリになってしまいます。
ARIA は魔法の杖ではありません
アクセシブル・リッチ・インターネット・アプリケーション (ARIA) 属性は強力ですが、しばしば誤用されています。ARIA の最初のルールは、代わりにネイティブ HTML 要素を使用できるのであれば、それを行うことです。
開発者がステーキの味付けをするように、何にでも aria-label と aria-live を散りばめているのを見てきました。その結果、スクリーンリーダーのユーザーにとってノイズの多い混乱を招くような体験になってしまいます。複雑なタブパネルやダッシュボードのリアルタイムのステータス更新など、ネイティブ HTML では処理できないギャップを埋めるには ARIA を使用する必要があります。
カスタムのデータビジュアライゼーションを構築する場合 (ソーシャルメディア分析スイートで多く行っていること)、チャートで何が起こっているかを説明するために ARIA が必要になるかもしれません。しかし、標準フォームの場合は？シンプルにしてください。ラベルと入力はあなたの友達です。
そして、聖なるものすべてを愛するために、<label> タグを正しく使ってください。入力の横にテキストを置くだけではいけません。これらをリンクするには for 属性を使用してください。これにより、ユーザーはクリック対象を拡大し、その入力が何のためにあるのかをスクリーンリーダーに正確に伝えます。この小さなディテールが、サイトのプロフェッショナルな印象を大きく左右します。
##「醜い」アクセシブルサイトの神話
アクセシブルなサイトは1994年のプレーンテキスト文書のように見える必要があるという奇妙な考えがあります。ただ、そんなことはない。完全に準拠した美しい UI を作成できます。必要なのはある程度の意図性だけです。
つまり、通常のテキストの 4.5:1 のコントラスト比を満たすカラーパレットを選ぶということです。つまり、情報を伝える唯一の方法として色を使用しないということです。エラーメッセージがボックスの周りの赤い枠だけの場合、色覚異常のユーザーはそのメッセージを見逃す可能性があります。わかりやすいように、アイコンまたは「Error:」のようなテキストラベルを追加してください。
リタ・ゴンザレス率いる私たちのデザインチームは、初日からこのことに重点を置いています。Figma では、コードを 1 行記述する前にコントラストとフォントサイズをチェックしています。リリースの 3 週間前に React コンポーネントをリファクタリングするよりも、モックアップで設計上の欠陥を修正する方がはるかに安価です。サウスカロライナ大学と NMSU との共同作業で、この成果が見えてきました。クリーンでアクセシブルなデザインは、実際にはよりプロフェッショナルで信頼できるものに見えます。優れたデザインとは、インクルーシブなデザインです。
実際に使っているツール
自動テストは素晴らしいですが、始まりに過ぎません。WAVE、Axe、Lighthouse などのツールは、代替テキストの欠落、コントラストの低さ、ID の重複など、手っ取り早い成果を捉えるのに最適です。これらを GitHub Actions を使用して CI/CD パイプラインに統合し、リグレッションを早期に検出できるようにしています。単体テストでは「jest-axe」を使ってアクセシビリティチェックも行っています。
しかし、アクセシビリティ問題のうち、自動化ツールで解決できるのは約 30% から 40% にすぎません。画像に代替テキストが含まれているかどうかはわかりますが、そのテキストが実際に役立つかどうかはわかりません。
<!--Bad: Not helpful-->
<img src="chart.png" alt="image">
<!--Good: Descriptive-->
<img src="chart.png" alt="Bar chart showing a 20% increase in social media engagement over Q3.">
``
これが、手動テストが譲れない理由です。私たちはWindowsではNVDA、MacではVoiceOverのようなスクリーンリーダーを使っています。また、「マウスを使用しない」テストやズームテストも行っています。サイトを 400% のズームで使ってみたことはありますか？WCAG 2.1 では、そのレベルで水平スクロールしなくてもサイトが機能し続ける必要があります。そのため、よりレスポンシブな CSS を書かなければなりません。これは弱視の人だけのものではありません。小さなデバイスやおかしなブラウザウィンドウサイズを使っている人が対象です。サイトが 400% のズームで壊れてしまったら、とにかくレイアウトロジックが壊れやすいのではないでしょうか。
## ビジネスケース (法外編)
道徳的、法的な議論に感動しないなら、お金の話をしましょう。アクセシブルなサイトを構築すると、市場が拡大することになります。米国だけでも、何百万もの人々が何らかの障害を抱えています。サイトが彼らにとって使用できなければ、文字通り顧客を遠ざけることになります。なぜ潜在的なオーディエンスを減らしたいのでしょう？
検索エンジンもアクセシブルなサイトが大好きです。Google のクローラーはスクリーンリーダーとよく似ています。ページの内容を理解するために、ヘッダー、代替テキスト、セマンティック構造を探します。508 準拠に最適化していれば、実質的に大量の SEO 作業を無料で行っていることになります。より良いサイトを構築したからこそ、ランキングも上がります。
そして、メンテナンスの面もあります。セマンティックで構造化されたコードは読みやすく、デバッグも簡単です。新しい開発者がチームに加わって ``、`` <nav>、``、<main>`<footer>を見れば、すぐにレイアウトを理解できます。`div-1`、`div-2`、`div-3` と表示されたら、ナビゲーションがどこで終わり、どこからコンテンツが始まるかを調べるのに1時間を費やす必要があります。アクセシビリティとは、決して時代遅れにならないドキュメンテーションの一形態です。
## 私たちがSweentを大切にする理由
私たちはこのようなもので窮地に立たされてきました。Adobe Analytics for Deloitteの統合であれ、NMSU向けの複雑なダッシュボードの構築であれ、アクセシビリティが収益にどのように影響するかを見てきました。
NMSU の IT アプリケーション近代化プロジェクトでは、従来の Rails アプリケーションを最新の React と Node.js スタックに移行しています。私たちの大きな目標の 1 つは、セキュリティとコンプライアンスの改善です。古いアプリは、アクセシビリティが後回しにされていた時代に構築されました。最初から 508 の標準を新しい React コンポーネントに組み込むことで、大学が今から 5 年後に同じ問題に対処しなくて済むようにしています。私たちは、よりインクルーシブな未来を築くことで、過去の技術的負債を修復しています。
大切なのは職人技への誇りです。退役軍人が経営する企業として、私たちは手抜きをするのは好きではありません。私たちは、一部の人にしか役に立たないようなものを作りたいとは思いません。私たちは、誰にとっても役立つものを作りたいと思っています。創設者のジュリアン・テヘラは、海兵隊で過ごしました。そこでは、任務の成功は細部に至るまで正確かどうかにかかっています。私たちはそれと同じ規律を私たちの規範にも取り入れています。
## 始め方
大規模なレガシーサイトを見て圧倒されていると感じているなら、すべてを一度に修正しようとしないでください。ヘッダー、フッター、メインナビゲーションなどのグローバル要素から始めましょう。これらにアクセスできなければ、ユーザーは正面玄関を通り抜けることができないため、サイトの他の部分は問題になりません。
次に、フォームを見てみましょう。誰でもサインアップできますか？彼らは何かを買うことができますか？彼らはあなたに連絡できますか？最初に価値の高いパスを修正してください。
難しいですか？時々。すべての複雑な UI コンポーネントに最適な答えはありますか?必ずしもそうとは限りません。しかし、努力する価値はあります。最後に実際にスクリーンリーダーを使って自分のサイトをナビゲートしようとしたのはいつですか？最近やっていない場合は、今すぐ試してみてください。これは目を見張るような経験であり、おそらくコードの記述方法を永遠に変えるでしょう。これまで追いかけてきた「バグ」は、実際には基盤が壊れていることの兆候にすぎないことに気付くかもしれません。
よくあるご質問
第508条は、1973年のリハビリテーション法の一部であり、障害者が連邦政府の電子およびITにアクセスできるようにすることを義務付けており、実際にはWCAGのガイドラインを通じて施行されています。アクセシビリティは、法律の枠を超えて、よりクリーンなセマンティック HTML、より強力なキーボードサポート、より優れたコントラスト、より弾力性のあるレスポンシブレイアウトを実現するものであり、ソフトウェアの保守が容易で、新しい開発者の採用が早く、検索エンジンにとって使いやすくなるのと同じ性質です。これはベースラインとなるエンジニアリング品質の代用となります。
常に最初にネイティブ要素に手を伸ばしてください。A は、キーボードの起動、フォーカス、および適切な支援技術のセマンティクスをそのまま処理します。
Axe、WAVE、Lighthouse、jest-axeなどの自動化ツールは、問題（代替テキスト、コントラスト、重複ID）の30〜40％をキャッチし、CIで実行します。それ以外の場合は、WindowsではNVDA、macOSではVoiceOverを使用し、キーボードのみで操作して、ブラウザが 400% ズームすることを確認してください。特に SPA ルートを変更する場合、手動で新しいページの見出しにフォーカスを移動するか、aria-live 領域を使用して変更を通知します。そうしないと、スクリーンリーダーのユーザーには何かが起こったというシグナルが届きません。
まず、グローバル要素:ヘッダー、フッター、およびプライマリナビゲーション。ユーザーが正面玄関を通り抜けることができなければ、ページ上の他のことは何も問題になりません。その後、サインアップ、チェックアウト、連絡先などの価値の高いフォームを修正してください。これらは直接変換されるパスだからです。すべての入力に適したセマンティック HTML、可視のフォーカスリング、4. 5:1 のコントラスト比を実現すれば、アリアを散りばめたどんなエクササイズよりもさらに効果が高まります。
いいえ。アクセシブルなデザインの制約は、コントラスト比、状態を伝えるために色だけを使わないこと、そしてキーボードとズームをサポートすることの 3 つだけです。しっかり構築された UI ライブラリと意図的なデザインシステム (まず Figma でコードを書く前にコントラストとフォントサイズをチェックする) によって、監査にも合格する、洗練された最新のインターフェースが生成されます。これらの決定をモックアップで修正する方が、リリース前に React コンポーネントをリファクタリングするよりも格段に安価です。