DESIGN SYSTEMS FOR ACCESSIBILITY Creating a sustainable methodology for workplaces within web development
要約
- アクセシビリティのためのデザインシステムの持続可能な方法論の構築
- ウェブ開発における職場のための持続可能な方法論
- デザインシステムがアクセシビリティをサポートする方法の調査
- 設計アプローチを使用してアクセシビリティ方法論を作成
- インタビューやアイデアワークショップを通じて問題を理解し、解決策を生み出す
- 専門家による評価、フォーカスグループ、ユーザーテストによる方法論の評価
- アクセシビリティの促進に関する10のガイドラインの結果
- デザインシステムはデザイナーや開発者がアクセシビリティ要件に圧倒されず、現在のタスクに焦点を当てるのを支援
- コンポーネントの保存に留まるデザインシステムはアクセシビリティ要件の一部にしか対応できない
- ガイダンスの提供とテスト手順で言及されることにより、アクセシビリティのプラットフォームになるデザインシステムにはより大きな潜在能力がある
- 5.2段階: 定義
- 5.3段階: 発想
- 5.4段階: 開発
- 5.4.1 四つのサンプル
- 5.4.2 ガイドラインの下書き
- 5.4.3 チェックリストの下書き
- 5.5段階: 評価と修正、第1反復
- 5.5.1 ガイドライン下書きの専門家意見
- 5.5.2 チェックリスト下書きの専門家意見
- 5.5.3 フォーカスグループと補完インタビュー
- 5.5.4 第1反復後の修正ガイドライン
- 5.5.5 第1反復後の修正チェックリスト
- 5.6段階: 評価と修正、第2反復
- 5.6.1 ガイドラインの専門家意見
- 5.6.2 チェックリストの専門家意見
- 5.6.3 ユーザーテスト
- 5.6.4 評価インタビュー
- 5.6.5 第2反復後の修正成果物
- 6 議論
- 6.1 プロセスについて
- 6.2 管理の重要性
- 6.3 自動評価ツールへのアプローチ
- 6.4 日常業務への適合
- 6.5 教育と思い出させること
- 6.6 所有権
- 6.7 チェックリストとデザインシステム
- 6.8 提案された方法論
- 6.8.1 中核概念
- 6.8.2 異なるアクセシビリティの視点
- 6.8.3 アクセシビリティのアンバサダー
- 6.9 研究問題への回答
- 6.9.1 内部問題とする
- 6.9.2 プロセスに適合させる
- 6.9.3 コンポーネントのみでは不十分
- 6.9.4 一度に少ない要件に焦点を当てる
- 6.10 方法の強みと弱み
- 7 結論
- 8 将来の課題
- ガイドラインの最終版
- 本研究では、以下の用語の定義を提供しており、それに従って論文が進行しています。方法論は特定の分野における方法やツールのセットとして理解されています。アクセシビリティはW3Cの標準であるWCAG 2.1レベルAAの達成を指しています。アプリケーションはウェブベースのサービスを指し、モバイルアプリケーションとは同義ではありません。企業はアプリケーションが製造される職場を指し、その組織のタイプには関係ありません。UXはユーザーエクスペリエンスの略です。開発はデザインと実装のプロセスを指す場合と、コーディングのみを指す場合があります。この論文では混同を避けるために、それぞれに異なる用語が使用されています。
- 本論文は、UXデザイナーとフロントエンド開発者を対象としており、バックエンド開発者やコンテンツ作成者は対象外です。デジタルアクセシビリティに関してはウェブに焦点を当てており、デザインシステムのアクセシビリティについては研究されていません。
- 論文はデジタルアクセシビリティに関連する法律、標準、自動テストなどに基づいており、デザインシステムやデザイナーと開発者の協力についても中心的な位置を占めています。
- 障害の定義は簡単ではなく、数字を見つけることが難しいため、デジタルアクセシビリティに関連する障害の数を把握することも難しいです。ウェブサイトとモバイルアプリケーションに関しては、スウェーデンの公共部門のウェブサイトとモバイルアプリケーションにはアクセシビリティの要件があります。また、WCAG 2.1の基準に基づく規制もあります。
- WCAGは、障害を持つ人々がウェブコンテンツをよりアクセスしやすくするための国際基準であり、4つの原則に基づいています。また、WCAG 2.1には13のガイドラインと78の成功基準があり、それぞれがA、AA、AAAのレベルでラ
- 自動ツールは、Webサイトのソースコードを検査し、特定のガイドライン（WCAGなど）に対するウェブサイトの準拠レベルを決定します。フリーツールと商用の定期購読型ツールがあり、ブラウザベースやIDE（統合開発環境）内に配置されたり、独自のソフトウェアとして提供されています。
- Lighthouse、Siteimprove、AChecker、WAVE、TAW、Deque's Axe、Total Validator、ARC Toolkitなどの自動アクセシビリティ評価ツールがあります。
- 自動評価ツールの有効性を測定する試みがされており、これらのツールは100%には遠く及ばないことが示されています。
- 過去の研究では、自動評価ツールがWCAG 2.0に対して23-50%のカバレッジと0-48%の完全性を持つことが示されています。
- デザインシステムは、再利用可能なコンポーネントのコレクションであり、ボタンやアイコンからフォーム、ナビゲーションエリア、テキストスタイルなどが含まれます。
- デザインシステムは、デザイナーと開発者の間の時間の効率性、一貫性、コミュニケーションを向上させます。
- 問題追跡システム（ITS）は、ソフトウェア会社の開発タスクを管理するためのソフトウェアであり、新機能やバグ修正などのタスクを追跡および管理します。
- アクセシビリティ手法の開発方法は、外部パートナー企業Metriaのケーススタディを行い、その結果を取得することで、アクセス方法論を作成しました。
- プロジェクトのフェーズをグラフで表現した図4によると、Discoverフェーズでは範囲が広がり、次にDefineフェーズで狭まる。Ideateフェーズでは再び範囲が広がり、アイデアが選ばれ、Developフェーズで再び範囲が狭まる。Evaluateフェーズではさらに範囲が広がり、そしてModifyフェーズで再び狭まる。最後の2つのフェーズは繰り返され、合計26人がプロジェクトに参加し、15週間続いた。ターゲットグループから3人のデザイナーと10人のフロントエンド開発者が参加し、5回の機会でプロジェクトに参加した。 Discoverフェーズでは、ユーザーの理解を目的としてインタビューが行われ、Affinity diagrammingが使用された。Defineフェーズでは、問題の声明が定義され、5 WsテクニックとUser Need Statementsが実施された。Ideateフェーズでは、2つのワークショップが開かれ、最終的なアイデアがDevelopフェーズに進むために選別された。
- プロジェクトの声明が提示され、参加者は単語連鎖の中の単語に関連した問題の解決策を関連付けました。
- 最初に、これらのアイデアは簡単に付箋に書かれ、発想のエネルギーを高く保つために保管されました。
- 演習の最後に、いくつかのアイデアが選ばれ、より具体的に詳細に説明されるようになりました。
- この演習では、参加者がお互いに自分の考えを表現することに非常に快適である必要があります。
- 第二の演習は「ロータス・ブロッサム」と呼ばれました。
- プロジェクトの問題声明が大きな紙の9x9グリッドの中心に書かれました。
- 次に、8つのアイデアが考え出され、簡単に付箋に書かれ、中央の四角い周りに配置されました。
- これらのアイデアはその後、グリッドの端に移動しました。
- これらの8つのアイデアは新しい付箋に囲まれました。しかし、これらの新しい付箋は新しいアイデアではなく、中心のアイデアをどのように実装するかを答えることが期待されていました。
- ステークホルダーのワークショップには4人の参加者がおり、デザインシステムを担当するメトリアの2人の従業員と、クリエイティブなスキルを持つメトリアの従業員が含まれていました。
- ワークショップでは2つの発想の技術が使用されました。まず、ラテラル・シンキングを使用した「ノーリミッツ」と呼ばれる最初の技術がありました。
- 2つ目の技術は「ブレインウォーキング」と呼ばれ、参加者が部屋を歩き回り、お互いのアイデアを発展させる変種でした。
- アイデアは、著者によってワークショップ後にフィルタリングされました。
- マインドマップにまとめられた残りのアイデアは、方法論への変換の前に一部が抽象的であるため、追加の手順が必要でした。
- 第4段階の目標は、第3段階で発想された1つまたは複数のアイデアを、方法とツールのセットから成る方法
- 1対1のインタビューおよびフォーカスグループを使用して、ユーザーテストが実施された。専門家によるレビューとフォーカスグループでツールの評価が行われた。ユーザーテストでは、4人の参加者が2つのツールを試し、30分間の使用後にインタビューを受けた。最後に、1人の従業員による評価が行われた。これらの評価に基づいて、ツールに小さな変更が加えられた。また、6つのプロジェクトフェーズの結果が提示され、最終的な提案としてアクセシビリティに関するガイドラインが作成された。
- プロジェクトの最初の段階で、Metriaのデザイナーと開発者からのインタビュー回答が収集され、51の発見が15の主要な発見にまとめられた。これらの主要な発見には、アクセシビリティに関する取り組み、ユーザーの状況、デザインシステムに関する意見などが含まれていた。
- インタビュー対象者は、”メニュー”のような機能に関連付けられたガイドラインを見たがっている。
- Metria社の従業員は、アクセシビリティ評価ツールを利用することを重要視しているが、日常業務でそれを行うためにはリマインドが必要だと考えている。
- Metriaの既存のデザインシステムの検査により、ガイドラインとコンポーネントの2つの主要セクションがあることが判明した。
- アクセシビリティの情報は他のリソースから分離されており、すべてのデザインシステムにある程度含まれている。
- フェーズ2では、アクセシビリティ対策を体系的に行うことが問題であり、デザインシステムがその解決策として適切であると結論づけられた。
- フェーズ3では、100以上のアイデアが生成され、それらが10のトピックに縮小された。
- フェーズ4では、アクセシビリティに関するデザインシステムの一般的なアドバイスを含むガイドラインとチェックリストが開発された。
（全19個の部分に分割されているため、これは最初の部分の要約です。）
- 文書はスウェーデン語で書かれていた。
- 四つのツールのサンプルが開発され、調査に使用された。
- 回答者に各ツールのコンテンツのボリュームを理解させるために、それぞれの写真の横に推定された項目数や簡単な説明が書かれていた。
- 四つのアイデアは、新しいデザインやコードを作成する際に考慮すべきことのリスト、WCAGの並べ替え、アクセシビリティのテスト用の対話型チェックリスト、Metriaの12のアクセシビリティルールである。
- アクセシビリティのテスト用の対話型チェックリストが最も高い得点を獲得し、プロジェクトの第2の成果物として選ばれた。
- ガイドラインの下書きが開発フェーズで作成され、それぞれに20-200語の説明がついていた。それらはDiscoverフェーズとIdeateフェーズの調査結果に基づいていた。
- 6つのガイドラインが作成され、それぞれがDiscoverフェーズで特定された問題を解決することを意図していた。
- チェックリストの下書きは、webbriktlinjer.seとWCAGを参考に作成された。
- チェックリストの構造は同じで、コンテンツが異なっていた。各チェックリスト項目には、説明、要件タイトルと例外、テスト手順、WCAG成功基準番号、要件が関連する機能のリストが含まれていた。
- 最初の評価と修正のフェーズでは、ガイドラインとチェックリストに対する専門家の意見が収集され、それに基づいて改訂が行われた。要約の続きがありますか？
- アクセシビリティの所有権を持つことが重要であり、経営陣の参加が不可欠であるとの意見がありました。
- デザインシステムの定義とサポートの重要性について議論がありました。
- アクセシビリティの取り組みはしばしば一時停止する傾向があり、アクセシビリティの専門家に依存する危険性も指摘されました。
- 専門家は、デザイナーや開発者向けに異なるチェックリストを作成し、自動テストや手動テストの重要性について議論しました。
- チェックリストの改善点として、デザインシステムへの参照や重要な要件の明示が挙げられました。
- フォーカスグループでは、プロジェクト間の合意形成や時間の節約、アクセシビリティ向上を目的とするガイドラインとチェックリストに対する肯定的な意見が述べられました。
- チェックリストを実践的に使用するために、参加者は情報を折りたたんで拡張し、フィルターすることが重要と考えた。
- デザインとコードのために別々のチェックリストを持つことが論理的であり、それには利点があると結論付けた。
- チェックリストは、自分の作業をチェックするために使用されるべきであり、ほとんどの参加者がそのように考えた。
- チェックリストはインタラクティブになり、説明とテスト方法を1つのフィールドに折りたたむことができるようになった。
- コードのチェックリストには7つの新しい要件が追加され、合計20の要件が含まれるようになった。
- ITSのチェックリストには、説明が折りたたまれる機能があり、フィルターやコメントは特定のアイテムにはサポートされていない。
- 専門家は、一般的なガイドラインを持つことの重要性を強調し、それらを企業固有のものにすることを勧めた。
- 目標と優先順位付けが最も重要であり、アクセシビリティに取り組みたい企業にとっては「メガネの比喩」が良いとされた。しかし、アクセシビリティには無視してもよい場合もあると説明された。アクセシビリティ要件から逸脱する場合を理解することが重要であり、プロトタイプをすぐにテストする必要はないと暗示された。特定の要件については、10分でアクセシビリティテストを行うことも可能であると強調された。
- アクセシビリティに関しては、チェックリストのシンプルさや対象グループへのアプローチが強みとされた。しかし、WCAGへのリンクは問題があるとされ、代わりにブログ記事など外部リソースへのリンクを推奨した。また、デザイナーにとって視覚的に魅力的なものにすることが提案された。
- ユーザーテストでは、ITS（Issue Tracking System）に配置されたチェックリストがスプレッドシートよりも好まれた。ユーザーはITS内に配置されたチェックリストを毎日目にすることや進捗状況が見えることを利点として挙げた。チェックリストの改善に関する提案もあり、コンポーネントのテストには適さないとされたため、全体ページのテストにチェックリストを推奨することとなった。また、別企業のデザインシステム内に配置されたチェックリストについても意見が述べられたが、ITS内に配置されたチェックリストの方が好ましいとの結果が得られた。
- ユーザーテストの結果から得られた提案は、今回のプロジェクトでは開発されないことが決定されたが、別のプロジェクトでITSのチェックリストの改善に活かされる可能性がある。
以上の要約は、19個に分割された研究論文の一部から抜粋したものです。
- ユーザーテスト後のガイドライン変更が表7に示されています。ユーザーは全体のページをテストしたが、コンポーネントをテストするよう指示されていた。そのため、テストコンポーネントを使用することを推奨するガイドラインが削除された。また、ITS内のチェックリストの配置は好意的に受け取られた。ITS内のチェックリストはユーザーを圧倒せず、アクセシビリティに関連してもっと作業を行うようにインスピレーションを与えた。また、ユーザーはITS内のチェックリストが導入されれば使用されると確信していた。ユーザーはITS内のチェックリストにフィルターを要求しなかった。他の変更には、アプリケーションの機能やコンテンツに関するチェックリストの分解を推奨するガイドラインが削除されたことがある。
- インタビューの評価では、ガイドラインの順序が変更され、1つのガイドラインが調整され、2つの新しいガイドラインが追加された。ガイドラインには、会社のアクセシビリティ目標を設定し、不要な要件を優先順位付けする、設計システムを独自のプロジェクトとして定義する、わかりやすく説明する言語を使用する、小さく始めて設計システムを構築する、アクセシビリティの大使を手に入れる、作業の異なる段階でサポートを分解する、既存のリソースとプロセスにサポートを組み込む、可能なものについて自動テストを利用する、動機づけに基づいてアクセシビリティ対策を延期する、という10のガイドラインが含まれていた。
- プロジェクトは、アクセシビリティ方法論を提供し、10のガイドラインからなる最終結果をもたらした。また、プロジェクトの強みと弱みについても議論されている。また、プロセスの重要性や管理の重要性についても議論されている。
- 法律によって彼らの地図アプリケーションが免除されるかどうかも検討しており、一般向けのアプリケーションにおいてアクセシビリティが専門家よりも重要であると述べられた。自動評価ツールのアプローチも議論され、既存のツールの効果が評価された結果、自動評価ツールは利用すべきだが、その限界も認識する必要があることが示唆された。さらに、WCAGの要件の多くは人間によって解釈される必要があり、自動評価ツールの制限がユーザーテストで浮かび上がり、信頼性に疑問が投げかけられた。また、WCAGは開発チームの日常業務に適合せず、アクセシビリティ向上のための日常的な訓練と議論が必要であると示唆された。さらに、アクセシビリティの所有概念についても言及があり、顧客のニーズを理解し、それに基づいた意思決定を行うことが強調された。
- アクセシビリティを会社のアイデンティティの一部にすること、個人にアクセシビリティの所有権を与えないことが重要である。
- 法律がデジタルアクセシビリティを要求することが増えており、Metriaは次に適用される法律の影響を把握する必要がある。
- チェックリストはプロジェクトの中で様々なバージョンが作成され、ユーザーテストでも評価されたが、最終的にはチェックリストは提供されなかった。
- チェックリストはWCAG全体をカバーする理論上のものではなく、実際に使用されなければデザイナーや開発者、エンドユーザーにとっては有益ではない。
- アクセシビリティ手法の中心的な概念は、会社固有の目標を設定し、デザインシステムに基づいて設計されたツールを作成することである。
- アクセシビリティを支援するためのツールは、プロジェクトの異なる段階で異なる「アクセシビリティグラス」が必要とされる。
- ドキュメンテーションはWCAGの多くの要件を満たすための適切なコンテキストであると結論づけられた。
- アクセシビリティは理想的には100％実現すべきだが、部分的な達成も意欲づけるとされる。
- アクセシビリティを進めるためには、チェックリストを短くし、従業員が取り組みやすいようにすることが推奨される。
- 6.4節で議論されたように、アクセシビリティ眼鏡を着用する必要がない2つの状況を具体例を挙げて説明している。それは、プロトタイプのユーザーテストを行う際と、少数のユーザーによって使用され、顧客サポートとの代替手段がある機能の場合である。障がいを持つユーザーは、テストファシリテーターが彼らがアクセスできないことを説明すれば、プロトタイプにフィードバックを提供できる。プロトタイプのアクセシビリティを高めることに時間を費やすのは賢明ではない。なぜなら、それらがリリースされる可能性すらないからである。
- 6.8.3節のアクセシビリティアンバサダーは、企業内の関与した個人を活用する方法に基づいている。彼らは自ら教育し、それを設計システムと周辺サポートを通じて共有することで、企業全体のアクセシビリティレベルを向上させる。
- 6.9節では、論文の研究問題は「デザインシステムがデザイナーや開発者がアクセス可能なアプリケーションを制作するのをサポートする方法」についてであり、様々な視点を提供している。
- 6.9.1節では、デザインシステムの導入は、アクセシビリティの所有権を取る機会であり、会社の内部目標を設定し、外部からの要求を待つのではなく、アクセシビリティと関連付けることが重要である。
- 6.9.2節では、アクセシビリティをシステマティックに取り組むことで、アクセシビリティに関する対応を減らすことができる。
- 6.9.3節では、デザインシステムだけでは、完全にアクセス可能なアプリケーションの構築を保証できないことが示されている。
- 6.9.4節では、デザインシステムとそれに関連するサポートは企業固有のものであり、従業員の注意を現在構築中のものに向け、それによって彼らが圧倒されるのを避けることが重要である。
- 6.10節では
- デザインシステムは、アクセシビリティを考慮して作成されたデザインやコード断片を格納するだけでなく、文脈で多くの要件を満たす必要があるため、WCAGの一部しか対応できない可能性がある。
- デザインシステムは、ドキュメントを通じてコンポーネントやパターンの適切な適用方法に関するガイダンスを提供し、アクセシビリティ作業のテスト手順は、デザインシステムに準拠していれば既に満たされている要件を従業員に伝えることができる。
- 今後の研究は、デザインシステム向けのアクセシブルなコンポーネントやパターンの作成に役立つツールや方法を調査し、デザイナーや開発者だけでなく、企業の経営陣や製品所有者の視点も含めて研究する必要がある。
- デザインプロジェクトの最も重要な発見の1つは、問題追跡システム内でアクセシビリティ要件のテスト用チェックリストを実装する高いポテンシャルである。
- 謝辞には、MetriaのJill Aittamaaなど多くの人々への感謝が含まれています。
- 参考文献リストには、Web Content Accessibility Guidelines（WCAG） 2.1や関連する論文が含まれています。
- 最終バージョンのガイドラインでは、デザインシステムに関連する10のガイドラインが示されています。
- この論文の一部では、アクセシビリティについてのガイドラインが提示されています。
- アクセシビリティは、法律や標準だけでなく、実際の製品利用においても重要です。
- デザインシステムをプロジェクトとして確立し、その責任を明確に定義することが重要です。
- 言語は理解しやすく、直接読者に対して話しかけるようなものを使用する必要があります。
- デザインシステムのサポートチームを確立し、新製品だけでなく古い製品にもアクセシビリティの取り組みを適用することも重要です。
- アクセシビリティの大使を育成し、組織内で支援を提供することが重要です。
- アクセシビリティのためのサポート資料を作成し、デザインシステムに組み込むことが重要です。
- 自動テストツールを活用し、アクセシビリティを実現するための取り組みをサポートすることが重要です。
- アクセシビリティを後回しにする場合もありますが、それを正当化する理由を明確にすることが重要です。
- アクセシビリティのバグは他のバグと同様に扱われるべきであり、すべてのアクセシビリティの取り組みは重要です。
評価
この研究は、アクセシビリティを強化するためのデザインシステムに関する持続可能な方法論の構築に焦点を当てています。前提として、デザインシステムはウェブ開発の職場でのタスクの負担を軽減し、アクセシビリティ要件に対応する能力を持つことが示されています。しかし、アクセシビリティの全体的な要件を満たすためには、デザインシステムは単にコンポーネントの保存に留まらず、より大きな潜在能力を持つアクセシビリティのプラットフォームとして機能する必要があります。
研究者は、問題の理解と解決策の産出を助けるために、インタビューやアイデアワークショップを活用しています。その後、専門家、フォーカスグループ、ユーザーテストによる評価が行われ、アクセシビリティの促進に関する10のガイドラインが得られています。
研究プロセスはいくつかの段階に分けられており、定義、発想、開発、評価と修正が繰り返されています。開発段階では、サンプルの作成、ガイドラインとチェックリストの下書きが行われ、その後の段階で専門家の意見を取り入れた修正やユーザーテストが実施されます。
研究の結果として、プロセスの管理、自動評価ツールへのアプローチ、日常業務への適合、教育と思い出させること、所有権などについての議論が提起され、チェックリストとデザインシステムの関係性や提案された方法論の中核概念、異なるアクセシビリティの視点、アクセシビリティのアンバサダーなどについての考察が示されています。
この研究は、ウェブアクセシビリティに焦点を当て、特にUXデザイナーとフロントエンド開発者に対象を絞り込んでいます。ウェブベースのアプリケーションの開発とデザインに関連する法律、標準、自動テストに基づき、デザインシステムと開発者とデザイナーの協力を強調しています。
研究問題に対する回答として、内部問題を考慮し、プロセスに適合させること、単体のコンポーネントだけでは不十分であり、一度に少ない要件に焦点を当てることが提案されています。また、研究方法の強みと弱みについても議論されています。
結論では、デジタルアクセシビリティの重要性と、その達成に向けた具体的な手段と推奨事項がまとめられています。将来の研究課題として、アクセシビリティガイドラインの最終版の作成が挙げられています。
用語の定義では、方法論、アクセシビリティ、アプリケーション、企業、UX、開発といった用語の意味を明確にしています。また、WCAGという国際基準に関しても詳しく説明されており、そのガイドラインと成功基準が述べられています。
研究対象はウェブアクセシビリティであり、障害者のウェブコンテンツへのアクセスを改善することが目指されています。だが、障害の定義が難しく、アクセシビリティに関連する障害の数を把握することが難しいと指摘しています。
このテキストは、ウェブサイトの準拠レベルを判断するための様々なツールと、デザインシステムや問題追跡システム（ITS）の役割について述べています。自動アクセシビリティ評価ツールには、フリーと商用のものがあり、完全性とカバレッジは完全ではないとの研究結果が示されています。デザインシステムは再利用可能なコンポーネントの集合で、デザイナーと開発者の間の効率性と一貫性を向上させます。ITSは開発タスクの追跡と管理を助けるソフトウェアで、新機能やバグ修正などのタスクを管理します。アクセシビリティ手法の開発方法は、外部パートナーのケーススタディにより作成されました。プロジェクトの各フェーズでは、範囲が広がり、狭まるパターンが見られ、多数の参加者が関与し、多様な手法が使用されました。
二つのワークショップが開催され、最終的なアイデアが選ばれてさらに開発されるフェーズに進みました。第一のワークショップでは、参加者が問題解決のアイデアを提案し、それらを付箋に書き留め、選び出したアイデアを詳細に説明しました。第二のワークショップでは、ロータス・ブロッサムという手法を使用し、問題声明を中心に配置されたグリッドに8つのアイデアを書き出しました。これらのアイデアはグリッドの端に移動し、それぞれに実装方法を記入しました。4人の参加者がワークショップに参加し、ラテラル・シンキングとブレインウォーキングという二つの発想の技術が使用されました。ワークショップ後、アイデアは著者によってフィルタリングされ、一部が抽象的なものはさらなる手順を経てまとめられました。最終的には、これらのアイデアを具体的な方法とツールに変換することが目指されました。ユーザーテストは1対1のインタビューやフォーカスグループを用いて行われ、ツールの評価は専門家によるレビューとフォーカスグループで行われました。
この研究は、アクセシビリティに関する改善を目指してMetria社のデザインシステムに実施された一連のプロジェクトフェーズを報告しています。最初の段階では、デザイナーと開発者からのインタビューを通じて51の発見が15の主要な発見にまとめられました。これらは、アクセシビリティへの取り組み、ユーザーの状況、デザインシステムに関する意見などを反映しています。従業員はアクセシビリティ評価ツールの使用を重視しているが、その使用を日常業務に組み込むためにはリマインドが必要だと考えています。また、デザインシステムにはガイドラインとコンポーネントの2つの主要セクションが存在していることが判明しました。
次のフェーズでは、アクセシビリティ対策の体系的な実施が課題であり、これに対する解決策としてデザインシステムが適切であると結論づけられました。その後のフェーズでは、100以上のアイデアが生成され、それらが10のトピックに絞られました。さらに、アクセシビリティに関するデザインシステムの一般的なアドバイスを含むガイドラインとチェックリストが開発されました。
その後、四つのツールが開発され、その中からアクセシビリティのテスト用の対話型チェックリストが最も高いスコアを得てプロジェクトの第2の成果物として選ばれました。また、ガイドラインの下書きも開発フェーズで作成され、それぞれに20-200語の説明が付けられました。これらの評価と改善により、最終的にアクセシビリティに関するガイドラインが提案されました。
この論文は、アクセシビリティに関するガイドラインとチェックリストの作成と改善について述べています。6つのガイドラインが作成され、各ガイドラインは特定の問題を解決することを目指しています。これらのガイドラインとチェックリストは、webbriktlinjer.seとWCAGを参考に作成され、その構造は同一ですが、内容は異なります。初期の評価と修正段階で専門家の意見が取り入れられ、改訂が行われました。
アクセシビリティの所有権は重要であり、経営陣の関与が必要であるとの意見がありました。さらに、アクセシビリティの取り組みは一時停止する傾向があり、専門家への依存性が指摘されました。このため、デザイナーと開発者向けの別々のチェックリストの作成と、自動テストと手動テストの重要性が議論されました。
フォーカスグループからは、チェックリストがプロジェクト間の合意形成や時間節約、アクセシビリティの向上に寄与するという肯定的な意見が得られました。参加者は、チェックリストを実用的に使用するためには情報を折りたたんで拡張し、フィルターすることが重要だと考えていました。また、デザインとコードに対して別々のチェックリストを持つことが論理的であり、それには利点があると結論付けられました。
最終的に、チェックリストはインタラクティブになり、説明とテスト方法を1つのフィールドに折りたたむことができるようになりました。特にコードのチェックリストには7つの新しい要件が追加され、合計20の要件が含まれるようになりました。また、ITSのチェックリストには説明が折りたたまれる機能があり、特定のアイテムに対してはフィルターやコメント機能はサポートされていません。
専門家は、企業固有のガイドラインの重要性を強調し、目標と優先順位が重要としました。アクセシビリティに対する「メガネの比喩」が有用である一方、全ての要件が必ずしも適用するべきではないとされました。アクセシビリティテストは迅速に行うことができるとされ、アクセシビリティチェックリストのシンプルさと対象グループへの適切なアプローチが強調されました。一方で、WCAGへのリンクは問題とされ、代わりに外部リソースへのリンクと視覚的魅力が推奨されました。
ユーザーテストでは、ITS内のチェックリストが好まれ、その透明性と利便性が評価されました。しかし、コンポーネントのテストには適さないと指摘され、全体ページのテストにチェックリストを使用することが推奨されました。得られたフィードバックは、今後のプロジェクトのITSチェックリストの改善の参考になります。
ユーザーテスト後のガイドラインは一部変更され、テストコンポーネントを使用するガイドラインは削除されました。ITS内のチェックリストはユーザーから好意的に受け取られ、より多くのアクセシビリティ作業を促しています。
クリストの導入により、ITS内のチェックリストにフィルターは不要とされ、アプリケーションの機能やコンテンツに関するチェックリストの分解を推奨するガイドラインは削除されました。さらに、ガイドラインはインタビューの評価で再調整され、新たに2つ追加されました。これらのガイドラインには、アクセシビリティ目標の設定、設計システムの定義、言語の明確化、設計システムの段階的構築、アクセシビリティの推進者の確保などが含まれています。
プロジェクトはこれら10のガイドラインを使用してアクセシビリティ方法論を提供し、その強みと弱み、さらにはプロセスと管理の重要性についても議論しました。法律の観点から、地図アプリケーションのアクセシビリティ免除についても検討され、一般向けアプリケーションではアクセシビリティが専門家より重要との結論が出されました。
自動評価ツールの有効性とその限界についても議論され、WCAG要件の解釈は人間によってなされるべきであるとされ、自動評価ツールの制限がユーザーテストで明らかになりました。WCAGは開発チームの日常業務に適合しないという意見があり、アクセシビリティ向上のためには日常的な訓練と議論が必要とされました。また、アクセシビリティの所有権は個人ではなく、会社全体のアイデンティティの一部となるべきとされました。
法律によるデジタルアクセシビリティの要求が増えていることを踏まえ、Metriaは次に適用される法律の影響を把握する必要があります。
論文では、プロジェクトにおけるチェックリストの作成と評価について説明されていますが、最終的には提供されませんでした。チェックリストは理論的にはWCAG全体をカバーしますが、実際に使用されなければデザイナーや開発者にとっては有益ではありません。アクセシビリティの推進には、会社固有の目標を設定し、デザインシステムに基づいたツールの作成が重要であると説明しています。また、プロジェクトの各段階で異なるアクセシビリティ対策が必要とされ、ドキュメンテーションはWCAGの要件を満たすための適切なコンテキストとされています。アクセシビリティは理想的には100％達成すべきですが、部分的な達成も重要とされ、チェックリストを短くし、従業員が取り組みやすくすることが推奨されています。さらに、特定の状況ではアクセシビリティ眼鏡の使用が不要であると説明し、企業内のアクセシビリティアンバサダーが全体のレベルを向上させる方法についても述べられています。論文の主要な研究問題は、デザインシステムがアクセシビリティの制作をどのようにサポートできるかについてで、デザインシステムの導入がアクセシビリティの所有権を持つ機会であると結論づけています。
論文は、デザインシステムを使用してアクセシビリティ対応を減らす方法について説明しています。ただし、デザインシステムだけでは完全なアクセシビリティを保証できないため、その文脈に応じた要件も考慮する必要があります。デザインシステムは、適切なコンポーネントやパターンの適用方法についてのガイダンスを提供し、WCAGに準拠することにより、既に満たされている要件を従業員に伝えることができます。デザインシステムを効果的に利用するためには、それをプロジェクトとして確立し、その責任を明確に定義することが重要です。また、デザインシステムのサポートチームを設立し、新旧の製品にアクセシビリティの対策を適用することも重要です。未来の研究では、デザインシステム向けのアクセシブルなコンポーネントやパターンを作成するためのツールや方法を調査することが求められます。
組織内のアクセシビリティ推進のためには、大使を育成し、支援を提供すること、アクセシビリティ向けのサポート資料の作成とデザインシステムへの統合、自動テストツールの利用が重要である。アクセシビリティを後回しにする場合は、その理由を明確にする必要がある。また、アクセシビリティのバグは他のバグと同様に扱い、すべてのアクセシビリティ取り組みを重視すべきである。
和訳
![]()
1 / 1
100%
付箋を貼る場所をクリックしてください
