学習コンテンツアクセシビリティガイドライン

概要

GitLab は、1990年の障害を持つアメリカ人法(Americans with Disabilities Act)を含む、適用されるすべての法律と規制への準拠に取り組んでいます。私たちは多様性・包括性・帰属意識のバリューが、誰もが私たちの世界を動かすソフトウェアの貢献者および共同創造者となれる環境を可能にするという私たちのコミットメントの基盤を提供すると信じています。これらの信念とコミットメントを支援するために、GitLab はチームメンバーが GitLab コミュニティ全体にとって可能な限りアクセスしやすい学習・開発体験を作ることを奨励しています。これを促進するために、GitLab はウェブコンテンツをよりアクセスしやすくするための最も広く受け入れられている推奨事項のセットである、World Wide Web Consortium(「W3C」)のウェブコンテンツアクセシビリティガイドライン(「WCAG」)2.2のレベル AA に準拠することを目指しています。

GitLab の倫理・コンプライアンスプログラムとアクセシビリティワーキンググループは、WCAG の推奨事項に沿って、GitLab が使用するトレーニングプラットフォームにおいてアクセシビリティの高いウェブ学習体験(社内・社外を問わず)を作成するのを支援するための以下のガイドラインを共同作成しました。そのために、ガイドラインでは使用または設計する可能性のある様々な種類のコンテンツ、それぞれがユーザーに生じさせる可能性のある課題、およびそれらの課題を防止または軽減するためにできることを概説しています。

これらのガイドラインはスタート地点を意図しており、WCAG の推奨事項をより詳細に探求し、コンプライアンスが何を意味するかについてより深い理解を達成できるよう、ガイドライン全体に追加リソースへのリンクが提供されています。これらのガイドラインまたはそれが促進するコンプライアンスについての質問は、#ethics_compliance Slack チャンネルを通じて倫理・コンプライアンスチームに送ることができます。また、ブランドのボイス、トーン、文法、句読点についてのガイダンスはGitLab コンテンツスタイルガイドをご参照ください。コンテンツスタイルガイドに関する質問は、#brand Slack チャンネルを通じてマーケティングチームに送ることができます。

アクセシブルな体験

よりアクセスしやすい学習体験を提供するとはどういうことでしょうか?簡単に言えば、これはコンテンツや機能へのアクセスが何らかの重要な方法で制限されるユーザーがいないことを意味します。これは、コンテンツを複数の形式で利用可能にすることと、ユーザーがコースコンテンツを使用・操作する様々な方法を考慮することを含む場合があります。

プラットフォーム

コンテンツを議論する前に、学習・開発プラットフォームについて話しましょう。学習・開発プラットフォームはコース資料の提供方法であり、コンテンツをナビゲート、読む、視聴する、操作する機能を含みます。アクセシブルでないプラットフォームや特定の機能が欠けているプラットフォームは、一部のユーザーにとって障壁となり、コースに完全に参加したり、伝えることを意図した情報を吸収したりすることを妨げる可能性があります。

GitLab の主な学習管理システムは LevelUp です。異なる学習・開発プラットフォームを使用することを検討する前に、そのプラットフォームがアクセシブルな学習体験を提供しているかどうかを調査してください。多くの会社はまた、その意図と問題の解決方法を概説するアクセシビリティコンプライアンスステートメントを提供します。関連テクノロジーがアクセシビリティ要件をどのように満たしているかを説明する自発的製品アクセシビリティテンプレート(VPAT®)を提供しているところもあります。

平易な言葉

書面または口頭での形式で平易な言葉でコミュニケーションすることは、アクセシブルな体験の重要な要素になりえます。平易な言葉の一貫した使用は、あらゆる形式のメディアとすべてのユーザーに利益をもたらします。

plainlanguage.gov から:

平易な言葉(プレインライティングまたはプレインイングリッシュとも呼ばれる)とは、対象者が初めて読んだり聞いたりした際に理解できるコミュニケーションです。

考慮事項

人は情報を異なる方法で吸収するため、ある読者には平易に感じる言葉が他の読者には平易でない場合があることを認識しなければなりません。しかし、平易な言葉に共通する以下のテーマと属性を考慮することができます:

  • 言語はすべてのユーザーに身近であり、適切な理解レベルで書かれている;
  • 専門用語、珍しい言葉、または略語には説明または定義が提供されている;
  • コンテンツは文法や綴りのエラーを修正するために編集されている;
  • 見出しは論理的な順序(見出しレベル1〜6を使用)に従い、視覚的なユーザーとスクリーンリーダーユーザーのための走査可能で構造化されたアウトラインを作成する;
  • 見出しは続くセクションでユーザーが期待できる内容を明確に伝える;および
  • 行動を促す文言は明確で明瞭である。例えば、「続きを読む」の代わりに「パイプラインについて詳しく知る」など。

書かれた素材が平易な言葉であるのは、対象者が:

  • 必要なものを見つけられる;
  • 見つけたものを理解できる;および
  • 見つけたものをニーズを満たすために使用できる場合。

ガイドライン

WCAG 2.2 の成功基準の多くはある形でコンテンツに適用されますが、以下は平易な言葉の概念とテキストの提示に最も関連するものです:

画像

画像のテキスト代替は、何らかの理由で画像を見たり理解したりすることができないユーザーに非テキストコンテンツを伝えるために重要です。画像には3種類あります:シンプル、複雑、装飾的です。

シンプルな画像

シンプルな画像は、数語または短い文章で説明できるものです。例としては、製品のスクリーンショットや会話をする人々の写真などがあります。シンプルな画像は最も一般的に「alt テキスト」で説明されます。これはコード内の alt 画像属性からその名前を取っています。alt テキストは次のようになります:テキスト代替。「テキスト代替」は、スクリーンリーダーが読み上げることができるテキストベースの形式で画像を説明し、ユーザーが画像が伝えようとしているものを理解するのを助けます。テキスト代替を書くことは困難で主観的な場合があります。alt テキストをより説明的にする方法を理解するために以下の例を比較してください:

  • 悪い alt テキスト:<img src="/images/legal/ethics-compliance-program/team.jpg" alt="image">
  • 良い alt テキスト:<img src="/images/legal/ethics-compliance-program/team.jpg" alt="Four team members discussing a project around a conference table.">

どちらの例でも、alt テキストは画像の使用をユーザーに通知しますが、最初のものは画像を説明せず、2番目は画像が伝えようとしているもの(「4人のチームメンバーが会議テーブルを囲んでプロジェクトについて話し合っている…」)を説明しています。もう一つの例を示します:

  • 悪い alt テキスト:<img src="dog.jpg" alt="dog">
  • 良い alt テキスト:<img src="dog.jpg" alt="My golden retriever dog, Scully, posing for a photo in the living room">

どちらの例も「犬」について言及していますが、悪い alt テキストは犬をまったく説明していないのに対し、良い alt テキストはユーザーに役立つコンテキストを提供するほど詳細に犬を説明しています。意味のある alt テキストの作成方法の詳細については、WebAIM のテキスト代替ガイドをお読みください。

複雑な画像

複雑な画像は、より情報的な性質を持つビジュアルで、単純な説明以上のものを必要とします。例としては、フローチャートやデータビジュアライゼーションがあります。シンプルな画像と同様に、複雑な画像は簡単な説明として機能する alt テキストを必要としますが、画像に含まれる重要な情報をより詳細に説明するより長い説明(「long text」とも呼ばれる)も必要です。複雑な画像がデータで構成されている場合は、長い形式のテキストの代わりにデータのテキストテーブルを使用することを検討してください。W3C の長い説明方法についての詳細はこちらをご覧ください。

データビジュアライゼーション(情報とデータのグラフィカルな表現)は、ユーザーが伝えようとしていることを理解するために色だけに依存する必要がないよう、十分なコントラストの色と図表内のラベルを使用する必要があります。アクセシブルな学習体験を作成しながらデータビジュアライゼーションを考慮する他の方法を理解するために、GitLab の Pajamas デザインシステムに文書化されたデータビジュアライゼーションカラーパレットを確認するか、Kent Eisenhuth と Kai Chang によるチャートビジュアルデザインへのアクセシビリティファースト アプローチをお読みください。

装飾的な画像

装飾的な画像は意味のあるコンテンツ価値を持たず、スクリーンリーダーによって読み上げられる必要はありません。例としては、背景のパターンや視覚的なアンカーとして使用されるアイコンなどがあります。装飾的な画像に対しては、不必要に読み上げられないよう空の alt 属性を使用してください。

考慮事項

  • alt 属性が空(alt="")であっても、すべての画像に alt 属性を含める。
  • 複雑な画像を説明するためにより長いテキストおよび/またはテーブルを使用する。
  • データを視覚化する場合は、高コントラストの色、ラベル、その他のデータビジュアライゼーション技法を活用する。
  • 画像内にテキストを使用することは避けるべきですが、存在する場合は特別な書式のない文字で構成されるテキストであるプレーンテキストでも利用可能にする。
  • ユーザーが再生を制御できないため、アニメーション GIF の使用を避ける。

ガイドライン

WCAG 2.2 からの以下の成功基準が画像に適用されます:

動画と音声

動画と音声の録画は、コンテンツを取得するための代替手段を持つ必要があります。これにより、難聴または聴覚障害のあるユーザーがキャプションまたはテキスト書き起こしを使用してコンテンツを読むことができ、視覚障害のあるユーザーはスクリーンリーダーまたはその他の支援技術を使用できます。

キャプション

キャプションは音声および音のテキスト版であり、可能な限りすべての動画に提供する必要があります。クローズドキャプションはユーザーによってオン・オフを切り替えられますが、オープンキャプションは常に表示されます。キャプションのサイズ要件はありません(プレーヤーに合わせてスケールされる場合があります)が、読みやすく十分なコントラストが必要です。キャプションは動画を見ることができるが、障害または選択によって音声を使用できないユーザーに利益をもたらします。自動キャプションを使用する場合は、特に「DevSecOps」や「Kubernetes」などの専門用語について、話されたコンテンツを正確に反映していることを確認するためにレビューしてください。

音声説明

音声説明は動画の視覚的要素に関する情報を提供します。例えば、シーン、行動とジェスチャー、または表情の説明などです。対話の間に読み上げられます。例を見る。音声説明は動画の音声を聞くことができるが、障害または選択によって動画を使用できないユーザーに利益をもたらします。

書き起こし

テキスト書き起こしは音声のみのメディアと事前録画動画に提供する必要があります。書き起こしは同じページに含めるか、リンクするか、またはアクセシブルな文書として提供できます。書き起こしは、読むことを好むユーザーから、スクリーンリーダーまたはその他の支援技術を通じてテキストコンテンツを取得するユーザーまで、さまざまなユーザーに利益をもたらします。

テキストとデータビジュアライゼーション

テキストとデータビジュアライゼーション(図表)は両方とも、ユーザーがその外観を制御できない状態で動画に埋め込まれているため、最初から明確で識別可能であることを確保することが重要です。識別可能とは、ユーザーが見て、知覚し、理解できるテキストまたはデータビジュアライゼーションを意味します。

テキストは背景に対して十分なコントラストを持つ必要があります。意味のあるコンテンツである場合、テキストコンテンツは音声トラックにも含まれる必要があります。

動画内の図表は、色だけに依存するのではなく、パターンとテクスチャ(ライン、ドット、クロスハッチングなど)を使用する必要があります。以下にパターンとテクスチャを使用した図表の例を示します:

データビジュアライゼーション例

これにより、視聴者は色を識別できなくても図表の異なるセグメントやラインを区別できます。動画中は、特定の図表の領域を議論する際にハイライトまたは拡大を検討し、注意を集中させて特に小さく詳細なグラフィックに苦労する可能性のある視聴者を含むすべての視聴者を助けます。動画に図表が登場する際の主要な要素について口頭で説明を提供してください。この説明は視覚的な表示に伴い、何が示されているかを説明し、使用されているパターンやテクスチャを含む必要があります。

考慮事項

  • 音声と動画メディアには常にテキスト代替を提供する。
  • 動画や音声コンテンツを自動再生しない。スクリーンリーダーも告知を行っている場合、混乱を招く可能性があります。
  • キャプションと書き起こしは元のコンテンツを正確に反映している必要がある。
  • 動画のテキストとグラフィックに十分なコントラストカラーを確保するために WebAIM コントラストチェッカーなどのツールを使用する。
  • 図表を使用する場合は、情報を伝えるためにパターンとラベルを色と組み合わせて使用する。
  • 素早くまたは点滅するコンテンツであるフラッシュコンテンツを避ける。

ガイドライン

WCAG 2.2 からの以下の成功基準が画像に適用されます:

インタラクティブコンテンツ

コンテンツがインタラクティブである場合(学習管理システムのコントロールとは別に)、すべてのアクションとコンテンツがキーボードのみで達成できることを確認してください。例としては、情報を明かすためにめくれる要素や、より多くのコンテンツが含まれた埋め込みウィンドウを開く要素などがあります。多くの支援技術がキーボードの動作をエミュレートするため、すべてのインタラクションがキーボードで行えることを確認することは、幅広い入力方法を活用する幅広いユーザーにとって重要です。

考慮事項

  • すべてのコンテンツとインタラクションは、キーボードのみで行えるようにする。
  • キーボードユーザーが抜け出せないキーボードトラップ(インタラクティブな要素からフォーカスを移動できない場合に発生)がない。
  • フォーカス順序(キーボードがインタラクティブな要素を横断する順序)は、見える読み取り順序と一致する必要がある。
  • 要素がフォーカスを受けると、どのインタラクティブな要素が現在フォーカスされてユーザー入力の準備ができているかを示す視覚的なマーカーである可視フォーカスインジケーターがなければならない。
  • フォーカスを受けることができる要素は他の要素によって隠れることはできない。

ガイドライン

まとめ

より多くのビジネス、学習、コミュニケーションがオンラインで行われるにつれて、ウェブアクセシビリティはますます重要になっています。アクセシビリティは GitLab とそのミッションにとって特に重要です。情報(特に学習コンテンツ)への普遍的なアクセスは、誰もが貢献できるようにするのに役立つからです。アクセシビリティを最初から考慮することで、すべてのユーザーにとってよりインクルーシブで魅力的な体験を提供できる可能性も高まります。

自分たちも少し学ぶことで、GitLab とそのチームメンバーが私たちが提供する情報を人々がどのように消費するかという様々な方法を考慮し、できる限り最高の体験を作っているかどうかを考える準備がより整うことを願っています。チームメンバーがよりアクセシブルな学習体験を作成するために使用すべきこれらのガイドラインに加えて、チームメンバーがこの文書全体に提供されているリンクを探索して、基礎となる WCAG ガイドラインをより深く理解し、準拠できるよう奨励します。