Gravity UIデザインシステムでYandex Cloudをよりアクセシブルにした方法

こんにちは、私はウラジーミル・ティモフェーエフ、Yandex Cloudのテクニカルプロジェクトマネージャーです。この記事では、クラウドプラットフォームのサイトをよりアクセシブルにした方法、何回のイテレーションを経たか、そしてGravity UIがどのような役割を果たしたかを共有します。

すべてのサービスのアクセシビリティの基盤は、スクリーンリーダー（Screen reader）との連携をどれだけサポートしているかにあります。これらのプログラムを通じて、制限のあるユーザーはインターフェースを認識し、操作します。

ウェブサイトも例外ではありません。そして、Yandex Cloudがすべてのユーザーにとってどれだけアクセシブルかを調査する必要がありました。

Yandexでは、アクセシビリティとは、一時的または永続的な身体的制限に関係なく、すべての人が快適にサービスを利用できることを意味します。例えば、現在、視覚障害のあるユーザー向けに16のYandexサービスが適応されています：Lavka、Go、検索、ブラウザ、メールなど。各サービスのアクセシビリティ作業には、非視覚テストチームが支援しています。この記事で紹介するケースでも、彼らの助けなしには実現できませんでした。

ネタバレ：テストの結果、スクリーンリーダーとの連携でいくつかの問題点が見つかり、それらは作業タスクとなりました。

それでは、順を追って説明します。

すべてはGravity UIから始まった

Gravity UIは、Yandex Cloudのサイトや他の数十の製品で使用されているデザインシステムおよびコンポーネントライブラリです。オープンソースとして公開されており、誰でも利用できます（この半年でコミュニティチャットの活動が著しく増加したことを嬉しく思います）。

私たちが持っているもの：

• 基本的なReactコンポーネントのセット
• ランディングページ用のコンストラクタライブラリ
• コンポーネントの使用に関する詳細なガイド
• Figmaのライブラリ
• 約600の既製アイコンのセット
• ChartKit — データ可視化パッケージ
• Yagr — uPlotベースの高性能チャートレンダリング
• i18n — インターフェースローカライズパッケージ
• その他の便利なライブラリ

2024年3月、主要ライブラリのアップデート — UIKitバージョン6がリリースされました。Listコンポーネントが更新され、すべてのコンポーネントでRTLパラメータのサポートが追加され、アクセシビリティを向上させるa11yの改善パッケージが含まれています。

a11y改善への道のり

非視覚テストチームとそのリーダーであるアナトリー・ポプコの助けがありました。ミーティングでアナトリーは、サンドボックスとGravity UIのサイトをステップバイステップでテストし、現在どのようなアクセシビリティの問題があるかを確認しました。

キーボードとスクリーンリーダーの特別なコマンドを使用してサイトを移動し、コンポーネントのアクセシビリティをテストしました。

視覚的にはこのように見えました：

ミーティング後、チームには作業タスクが、GitHubには基本コンポーネントに関する3つの新しいissueが作成されました。

詳細について。

• ドロップダウンリストで、第2レベルの要素がキーボードから開かない、マウスクリックでのみ開く。

• Selectコンポーネントのマークダウンマーカーリストでどの要素が選択されているか不明。

• テキストラベルのない、グラフィックのみで示されたボタンが、単に「ボタン」または「ラジオボタン」として読み上げられる。このバグはランディングページでのみ発生し、コンポーネント自体はaria-labelをサポートしていますが、使用していませんでした。

結果として、数十の指摘が見つからなかったことから、ライブラリのアクセシビリティはすでに良いレベルにあることがわかりました。実際のコンテキストでコンポーネントをテストすることは非常に難しいため、完成した製品のアクセシビリティチェックを開始することにしました。これにより、追加のa11y改善点を見つけることができました。

Yandex Cloudのアクセシビリティ

Gravity UIのアップデートに触発され、私たちのサービスのアクセシビリティをテストすることにしました：まずYandex Cloudのサイトから始め、その後この経験を他のインターフェースにも展開します。

遵守すべきアクセシビリティ基準がいくつかあります。しかし、Yandex Cloudのインターフェースを確実にテストし、サイトがすべての人にとってどれだけ便利かをよりよく理解するために、監査を実施しました。

アクセシビリティ監査

非視覚テストチームとアナトリーに再度連絡を取り、一緒にサイトをテストし、問題を記録し、改善作業に取り組みました。約1ヶ月の間隔で2回のイテレーション — テストと再テスト — がありました。

テスト中に、作業に取り組むべき修正点のプールを記録しました。

トップページ

• 検索コントロールの改善が必要でした。インターフェースでは、検索コンポーネントは虫眼鏡アイコン付きの検索エリアとして実装されています。クリックすると、クエリ入力フィールドが開きます。以前の実装では、スクリーンリーダーにとってこれらは独立した要素であり、視覚障害のあるユーザーを混乱させていました。

  

• 言語選択では「折りたたみ」状態属性を使用していましたが、実際にはドロップダウンリストではなく選択ボタンでした。「言語」というラベルがなく、「言語 — 地域」の遷移にスペースが不足していました。

• アカウントメニューではフォーカスがトラップされていませんでした：有効化するとユーザーがメニュー項目の外に出てしまいます。

• トップページでmainタグが重複していたため、1つを削除する必要がありました。

• サンプルセクション：ボタンの代わりにタブを使用する必要があります。

ナビゲーション

• フォーカスの問題：トップレベルメニューを展開するとき、フォーカスをサブメニューに移動する必要がある。
• トップレベルメニューからTabIndexを削除する必要がある。現在の形式では、すべてのメニュー項目が2回リストされてしまう。
• ナビゲーションが展開されている場合、キーボードフォーカスをトラップする必要がある。そうしないと、メニューからページ本体に飛び出し、戻ることができなくなる。

フッター

• Yandex Cloudがリストでラップされていた。フッターのリンクリストの見出しがリスト要素でラップされていたため、NVDAがそれらを一部として識別し、同じリストをユーザーに2回読み上げていた。
• AppStore、Google Playへのリンクのラベルが不足していた。テスト時にはURLの断片が読み上げられ、ユーザーには何も理解できなかった。

「ブログ」セクション

• 「すべてのトピック」と「すべてのサービス」ボタンがボタンと関連付けられていなかった。セレクトボタンがその内容を音声で伝えていなかった。
• リストのアクセシビリティサポートが必要：ドロップダウンリストを開くとスクリーンリーダーのフォーカスがそのリストの要素に切り替わり、キーボードショートカットなしで通常の矢印キーを使用した簡略化された移動をサポートする必要がある。

ブログ記事

• パンくずリストに「現在地」要素が不足していた。
• ダイアログにフォーカスをトラップする必要がある。
• お気に入りカウンターに名前がなかった。カウンターはアイコンと数字を持つボタンでした。スクリーンリーダーは数字だけを読み上げ、アイコンがないとボタンが何をするのか理解できなかった。

すべてのタスクをエピックに集め、作業を開始しました。いくつかのタスクにはGitHubでissueが作成されました。

最も興味深いケースについて詳しく説明します。

Selectコンポーネント

テスト中に、キーボードナビゲーション時にスクリーンリーダーがリスト項目の名前を読み上げないことを発見しました。aria-activedescendant属性を使用して問題を部分的に修正できましたが、すべてではありません。

残った問題点

• Safariではこの方法が機能せず、解決方法はまだ不明です。

• 検索フィルターが常にサポートされているわけではない（実際には常にそうで、サポートが実装されていないだけ）。通常、aria-activedescendantはドロップダウンリストのメイン要素にかけられ、リストで選択された要素を指します。現在は、ドロップダウンリストを開くボタンにかけられています。上下矢印を押すと、ボタンのaria-activedescendant値が前または次のリスト要素に変更されます。これにより、スクリーンリーダーは選択されたボタンからどの要素が選択されているかを読み取ることができます。

  検索フィルターの問題は、入力フィールドにaria-activedescendant属性がないことです。フィルター入力フィールドにフォーカスして何かを入力しようとすると、スクリーンリーダーはどのリスト要素がアクティブかを読み取ることができず、矢印キーでのリストナビゲーションが機能しません。

• 選択されたオプションがマークされていない、例えばaria-selectedなどの属性を追加する必要がある。

現在の問題を含むissueはこちらで確認できます。

パンくずリスト

パンくずリスト（Breadcrumbs）は、サイト上のユーザーの経路を示すナビゲーション要素です。私たちのケースでは、スクリーンリーダーが全経路を読み上げ、ユーザーがサイトのどの部分にいるのか理解できませんでした。さらに、コンポーネント全体が単なるリンクの集まりとして表示されていました。

私たちは標準から離れ、シンプルで最適な方法で問題を解決することにしました — スクリーンリーダー用に「現在地」タグを追加しました。最終的に、標準的なアプローチとタグを組み合わせました。

作業中に、このラベルを読み上げるには、スクリーンリーダーが無視しない要素にかける必要があることがわかりました。従来の構造にラベルをかける方が、それを回避する方法を考えるよりも簡単でした。それでも、ラベルは依然として有用です：ユーザーが今パンくずリストを聞いていることをより早く理解するのに役立ちます。

ラベルのない画像

サイト上の一部の画像にはラベルがなく、スクリーンリーダーは「画像」として読み上げていました。この情報はユーザーにとって有用な情報を提供せず、インターフェースの理解を助けないため、ラベルのない画像をスクリーンリーダーから非表示にすることにしました。

ブロック内のテキストの順序

サイト上のいくつかの場所で、情報が単一のブロックとして表示されています。例えば、イベントカードやブログ記事カードなど。

スクリーンリーダーが情報を読み上げる順序が、視覚的にユーザーが追う順序と異なることに気づきました。イベントカードでは、スクリーンリーダーは登録状況、時間、場所を読み上げ、その後でようやくタイトルと説明を読み上げていました。

通常、ユーザーは線形の経路を追いません：タイトルを見て、次にサブタイトル、そして画像を見ます。問題は、スクリーンリーダーがページのDOMツリー上の要素の順序で読み上げることです。順序を修正するために、再構築する必要がありました。

驚いたことに、一部の「OS — ブラウザ」の組み合わせではこれが機能しませんでした。例えば、macOSのMozilla Firefoxでは、ページツリーの順序を変更しても問題が残りました。Firefoxの開発者が新しいバージョンでこの動作を修正することを期待しています。

モーダルウィンドウ

視覚的なユーザーがインターフェースでポップアップウィンドウを開くと、視線はそのウィンドウの内容に落ちます。しかし、サイト全体のコンテンツは依然としてアクセス可能であり、必要に応じてそこに注意を戻すことができます。

スクリーンリーダーでサイトを操作する場合、状況は変わります。ポップアップウィンドウをモーダルにしないと、境界がありません。その結果、サイトのナビゲーションがより複雑になります：ユーザーは要素ナビゲーションを使用して誤ってポップアップウィンドウから出てしまう可能性があります。

モーダルウィンドウを扱う際には標準があり、それに従えば、インターフェースのすべてのポップアップウィンドウをトラップする必要はありません。

しかし、テスト中に、ポップアップウィンドウをモーダルにすることは、スクリーンリーダーを使用する際のサイト作業を簡素化する良い実践であるという結論に達しました。

すべてのポップアップウィンドウをモーダルにすることにしました。同時に、ユーザーがそのようなウィンドウで代替シナリオを設定できるようにしました。

role="dialog", aria-modal="true"を割り当てることでそのようなシナリオを設定できます。VoiceOver + Firefoxの組み合わせでは、このソリューションはサポートされていません：詳細はクローズされたissueで確認できます。

Diplodoc

私たちの活動に触発され、技術ドキュメンテーションプラットフォームDiplodocの開発者は、製品にいくつかのa11y改善を行いました：

• YFM（Yandex Flavored Markdown）のすべての追加構文要素をチェックし、スクリーンリーダーに見えるように書き直しました。
• キーボードでのドキュメント作業フローを改善：要素選択の順序を修正し、すべてのインタラクティブ要素に選択機能を追加しました。
• インターフェース要素に正しいラベルと指定を追加し、スクリーンリーダーユーザーのサービス利用を大幅に簡素化しました。

ドキュメントの表示にDiplodocを使用しているため、これらの改善はYandex Cloudサイトのドキュメントのアクセシビリティも向上させました。

結果と計画

すべてのユーザーのためにYandex Cloudインターフェースのアクセシビリティを向上させるための最初のステップを踏みました。経験をサービスの他のインターフェースに移し、現在認識している問題を改善する必要があります。

Gravity UIはアクセシビリティ作業を容易にし、a11yタグの付いたオープンissueの改善を続けています。この記事の執筆時点で、14のオープンissueと24のクローズされたissueがあり、こちらで確認できます。

アクセシビリティとサービスの動作に関するPRやコメント、そしてサイトでのGravity UI使用例をお待ちしています。