アクセシビリティに向けて

金曜日は勤務日の終わりです。 悪いニュースはいつも金曜日の勤務時間の終わりに届きます。

あなたはオフィスを出ようとしていますが、別の組織再編に関する新しい手紙が郵便で届きました。

ありがとう xxxx、yyy 今日から zzzz を報告します
...
そして、ヒュー氏のチームは、障害を持つ人々が当社の製品を利用できるようにしていきます。

なんてこった！ なぜ私がこれに値するのでしょうか？ 彼らは私に去ってほしいのでしょうか？ 報われない努力をし、他人の間違いを正そうと努めましょう。 これは間違いなく失敗です…

数年前にはこれが利用可能でした。 一部の哀れな人々には、障害を持つ人々がアクセスできるようにするために UI を「クリーンアップ」する仕事が与えられました。

これが実際に意味することは非常に曖昧でした。おそらく、フォーカス インジケーターが表示され、フィールド間をタブで移動でき、代替テキストといくつかのフィールドの説明があれば、アプリケーションはアクセス可能であるとみなされるでしょう...

しかし突然、「虫」が雪崩のようなスピードで増殖し始めました。

さまざまなスクリーン リーダー (ENG。 スクリーン リーダー) とブラウザーはまったく異なる動作をします。

ユーザーからはアプリが使用できないとの苦情が寄せられている。

ある場所でエラーが修正されるとすぐに、別の場所で別のエラーが発生しました。

また、ユーザー インターフェイスのエラーを変更および修正するだけでも大変な労力が必要でした。

私はそこにいた。 私は生き残りましたが、「成功」しませんでした。技術的には、多くのクリーンアップを行い、多くのフィールドの説明と役割を追加し、ある程度のコンプライアンスを達成しましたが、誰も満足しませんでした。 ユーザーからは依然としてアプリケーションを操作できないという苦情が寄せられていました。 マネージャーは依然としてエラーが絶え間なく続くことに不満を述べていました。 エンジニアらは、すべてのケースで機能する明確に定義された「正しい」解決策がなく、問題の提起が間違っていると不満を述べた。

アクセシビリティを理解するまでの私の旅の途中で、明らかに目を見張るような瞬間がいくつかありました。
おそらく最初は、完成した製品にアクセシビリティ機能を追加するのは難しいという認識だったでしょう。 そして、それが非常に難しいことであることをマネージャーに納得させるのはさらに困難です。 いいえ、「タグをいくつか追加する」だけで UI が正常に動作するわけではありません。 いいえ、これは XNUMX 週間では完了できません。XNUMX か月でも十分ではありません。
次の真実の瞬間は、視覚障害のあるユーザーが実際に私たちのアプリをどのように使用しているかを直接見たときに起こりました。 これは、エラー メッセージを見ることとはまったく異なります。

これには何度も戻りますが、人々が私たちのアプリをどのように使用するかについての私たちの「思い込み」はほとんどすべて間違っていました。

キーストロークを使用した複雑なユーザー インターフェイスの操作 Tab/Shift+Tab –これは最悪です！ もっと良いものが必要です。 キーボード ショートカット、ヘッダー。

UIを変更するときにフォーカスを失うことは大きな問題ではありませんね。 もう一度考えてみましょう - これは非常に混乱を招くものです。

私は続けて、しばらくさまざまなプロジェクトに取り組み、その後、複雑なユーザー インターフェイスと明確なインストールを備えた新しいプロジェクトを開始し、今回ようやく適切なアクセシビリティを実現しました。

そこで、私たちは一歩下がって、これを別の方法で実装して成功させ、プロセスを退屈でなくする方法を検討しました。

私たちはすぐに次のような結論に達しました。

1. 私たちは、ユーザー インターフェイスを開発する人々に、aria のラベル/ロール、そしてもちろんコンポーネントの HTML 構造をいじってほしくありませんでした。 私たちは、すぐにアクセシビリティを構築できる適切なコンポーネントを彼らに提供する必要がありました。
2. アクセシビリティ == 使いやすさ – つまりこれは単なる技術的な課題ではありません。 設計プロセス全体を変更し、UI 設計を開始する前にアクセシビリティが考慮され、議論されていることを確認する必要がありました。 ユーザーが機能をどのように発見するか、どのようにナビゲートするか、キーボードの右クリックがどのように機能するかを早い段階で検討する必要があります。 アクセシビリティは設計プロセスの不可欠な部分である必要があります。一部のユーザーにとって、アクセシビリティは単なるアプリケーションの外観以上のものです。
3. 私たちは当初から、視覚障害者やその他の障害のあるユーザーからアプリケーションの使いやすさについてフィードバックを得たいと考えていました。
4. アクセシビリティの回帰を捉えるための本当に優れた方法が必要でした。

そうですね、エンジニアリングの観点から見ると、アーキテクチャの開発とコンポーネントのライブラリの実装という最初の部分は非常に楽しそうです。 そして実際その通りでした。

一歩下がって見てみると、 ARIA の例 そしてこれを「適合」問題ではなく設計上の問題として考えることで、いくつかの抽象化を導入しました。 コンポーネントには「構造」(HTML 要素で構成される) と「動作」(ユーザーとの対話方法) があります。 たとえば、以下のスニペットには、単純な順序なしリストがあります。 「動作」を追加すると、対応する役割がリストに追加され、リストのように機能します。 メニューについても同じことを行います。

実際、ここではロールが追加されるだけでなく、キーボード ナビゲーション用のイベント ハンドラーも追加されます。

こちらの方が見た目がすっきりします。 それらを明確に分離することができれば、構造がどのように作成されたかは関係なく、それにビヘイビアを適用して適切なアクセシビリティを得ることができます。

これは実際の動作を次の場所で見ることができます https://stardust-ui.github.io/react/ – UXライブラリ 反応する、最初からアクセシビリティを念頭に置いて設計および実装されています。

XNUMX 番目の部分 - 設計に関するアプローチとプロセスの変更は、最初は私を怖がらせました。組織変革を推進しようとする下級エンジニアが常にうまくいくとは限りませんが、それは私たちがプロセスに大きく貢献した最も興味深い分野の XNUMX つであることが判明しました。 。 簡単に言うと、私たちのプロセスは次のようなものでした。新しい機能は XNUMX つのチームによって開発され、次にリーダー チームが提案をレビュー/反復し、その後承認されると、通常は設計がエンジニアリング チームに引き渡されます。 この場合、エンジニアリング チームは、アクセシビリティ機能に関連する問題を修正する責任があったため、アクセシビリティ機能を事実上「所有」していました。

当初、アクセシビリティとユーザビリティは密接に関連しており、これは設計段階で行う必要があることを説明するのが非常に困難でした。そうしないと、一部の役割の大きな変更や再定義につながることになります。 しかし、経営陣や主要関係者のサポートを得て、私たちはそのアイデアを採用し、実行に移しました。これにより、デザインは経営陣に提示される前にアクセシビリティと使いやすさについてテストされました。

そして、このフィードバックは誰にとっても非常に貴重なものでした。これは、ユーザーが Web アプリケーションとどのように対話するかについての知識の共有/コミュニケーションの演習としては素晴らしかったです。私たちは、UI を構築する前に多数の UI の問題領域を特定しました。現在、開発チームは、より優れた仕様を持っています。デザインの視覚的な側面だけでなく、動作的な側面も含めます。 本当のディスカッションは、技術的な側面や相互作用に関する楽しく、エネルギッシュで、情熱的なディスカッションです。

これら（またはその後の）会議に視覚障害のあるユーザーが参加していれば、これをさらにうまく行うことができます。これを組織するのは困難でしたが、現在は地元の視覚障害者団体と企業の両方と協力しており、実行フローを初期段階で検証するための外部テストを提供しています。コンポーネントと実行フローの両方のレベルでの開発。

エンジニアは現在、かなり詳細な仕様、実装に使用できる利用可能なコンポーネント、実行フローを検証する方法を持っています。 経験が私たちに教えてくれたことの一部は、私たちがずっと見逃してきたもの、つまり退化をどのように阻止できるかということです。 同様に、統合テストやエンドツーエンド テストを使用して、インタラクションや実行フロー (視覚的および動作的) の変化を検出するために必要な機能をテストできます。

視覚的回帰の判断はかなり明確に定義されたタスクであり、キーボードで移動するときにフォーカスが表示されているかどうかを確認すること以外に、プロセスに追加できることはほとんどありません。 さらに興味深いのは、アクセシビリティを扱うための XNUMX つの比較的新しいテクノロジです。

1. アクセシビリティの洞察 は、ブラウザ内で実行することも、問題を特定するためのビルド/テスト サイクルの一部としても実行できるツールのセットです。
2. スクリーン リーダーが正しく動作することを確認することは、特に困難な作業でした。 へのアクセスの導入により、 アクセシビリティ DOM、ビジュアル テストの場合と同じように、アプリのアクセシビリティ スナップショットを取得し、回帰をテストできるようになりました。

そこで、ストーリーの XNUMX 番目の部分では、HTML コードの編集からより高い抽象レベルでの作業に移行し、デザイン開発プロセスを変更し、徹底したテストを導入しました。 新しいプロセス、新しいテクノロジー、新しい抽象化レベルにより、アクセシビリティの状況と、この分野で作業することが何を意味するかが完全に変わりました。
しかしこれは始まりに過ぎない。

次の「理解」は、視覚障害のあるユーザーが最先端のテクノロジーを推進しているということです。彼らは、前述した変化から最も恩恵を受けるだけでなく、新しいアプローチやアイデアが ML/AI によって可能になるということでもあります。 たとえば、イマーシブ リーダー テクノロジを使用すると、ユーザーはテキストをより簡単かつ明確に表示できます。 声に出して読むことができ、文の構造が文法的に分解され、単語の意味もグラフィックで表示されます。 これは、古い「アクセスしやすくする」という考え方にはまったく当てはまりません。これは、誰にとっても役立つ使いやすさの機能です。

ML/AI は、まったく新しい対話方法と作業方法を可能にしており、私たちはこの最先端の旅の次の段階に参加できることに興奮しています。 イノベーションは考え方の変化によって推進されます。人類は数千年、機械は数百年、ウェブサイトは数十年、そしてスマートフォンはさらに存在してきました。テクノロジーは人に適応する必要があり、その逆ではありません。

PS この記事は原文から若干の逸脱を加えて翻訳されています。 この記事の共著者として、私はこれらの余談についてヒューと同意しました。

登録ユーザーのみがアンケートに参加できます。 ログインお願いします。

アプリケーションのアクセシビリティに注意を払っていますか?

• はい

• ノー

• アプリのアクセシビリティについて初めて聞きました。

17 人のユーザーが投票しました。 5名のユーザーが棄権した。

出所： habr.com