無限スクロール機能により、ユーザーがフッターに到達できないという問題について、以前に閉じられたスレッドをもう一つ読みました。その問題は解決されませんでした。これは確かにUX上の問題であるという懸念が提起されましたが、私のもとには、それがアクセシビリティ上の問題であるとして報告されました。
問題点:
ユーザーはスクロールという入力を行っていても、必ずしも無限スクロールを活性化させる意図を持っているわけではありません。むしろ、追加情報やサポートを得るためにフッターに到達しようとしている可能性があります。
この構成を採用しているコミュニティは、WCAG 2.1 のレベルAを満たすことができません。
レベルAは、ウェブアクセシビリティにおいて最も基本的かつ不可欠なレベルとされています。
私はコミュニティの監査を行っており、この問題を以下の成功基準の違反と分類します。
2.2.2 一時停止、停止、非表示(レベルA)クリティカル
自動更新される情報で、(1) 自動的に開始され、(2) 他のコンテンツと並行して表示されるものについては、自動更新が不可欠な活動の一部でない限り、ユーザーがそれを一時停止、停止、非表示にするか、更新頻度を制御できるメカニズムが存在する必要があります。
3.2.5 リクエストによる変化(レベルAAA)シリアス
コンテキストの変化は、ユーザーのリクエストによってのみ開始されるか、そのような変化をオフにするためのメカニズムが利用可能でなければなりません。
解決策:
ユーザーに制御権を戻すため、フィードに「さらに投稿を読み込む」ボタンを追加する。
ユーザーが一度に表示する投稿数を選択できるようにする。これにより、より無限スクロールに近い体験を望むユーザーもそれを実現できます。
「この構成が気に入らないなら他を選べ」と言うのは、あまりにも受け入れがたいです。この構成は十分に使いやすくすることが可能であり、そうあるべきです。これは多くのクライアントにとって道徳的かつ法的な要件です。
これが、必要な変更の必要性を説く一助となれば幸いです。
Falco
(Falco)
2021 年 9 月 12 日午後 3:33
2
Claudia_Sarah:
ユーザーがフッターにアクセスできないという事実
ここで言われているフッターとは何ですか?
Discourse は標準ではフッターを持っていません。Categories - Discourse Meta のようなページをご覧いただければお分かりいただけるはずです。
これは意識的なデザイン上の判断です。無限スクロール式のウェブサイトにフッターを追加すると、アクセシビリティが損なわれてしまうためです。
迅速なご対応、ありがとうございます。
はい、現状では無限フィードとフッターを組み合わせると、アクセシビリティに問題のある解決策となってしまいます。
しかし、それが唯一の答えである必要はありません。フィード上にコントロールを配置し、ユーザーが「さらに投稿を読み込む」か「フッターに移動する」かを選択できるようにすることは可能です。この点について検討の余地はありますか?
フッターは非常に一般的なウェブパターンです。一貫性があり、認識しやすいウェブ体験を構築することは、使いやすく理解しやすい体験を作る上での基本原則です。
フッターは、以下の成功基準(SC)をサポートします:
2.4.5 複数の手段(AA)
ウェブページがプロセスの結果またはステップである場合を除き、一連のウェブページ内の特定のウェブページに移動する方法が複数用意されていること。
特定のページでフッターを無効にしないことは、以下の成功基準(SC)をサポートします:
3.2.3 一貫したナビゲーション(AA)
一連のウェブページ内の複数のウェブページで繰り返されるナビゲーション機構は、ユーザーによって変更が開始されない限り、毎回同じ相対順序で配置されること。
Discourseの立場として、「その組み合わせを選択した場合、それは利用者の問題である」という考えなのでしょうか?
また、ドキュメントなどに「無限スクロールのウェブサイトにフッターを追加するとアクセシビリティが損なわれる」という事実を明記する助言がどこか存在するかどうかご存知でしょうか?
私は難しい立場にいます。運営している大規模なコミュニティの一部に対して、再設計を提案せざるを得ないからです。そのため、この問題の全体像を把握する必要があります。
Falco
(Falco)
2021 年 9 月 12 日午後 11:29
4
この分野に関する既存の研究は存じ上げませんが、無限スクロールのウェブサイトにフッターを配置すべきではないという点はよく知られた事実です。Facebook、Twitter、LinkedIn、Instagram、GMail など、多くの人気事例があります。これらはいずれもフッターを備えておらず、数十億人が利用しているにもかかわらず、すべての Web アプリケーション機能が利用可能です。
それは当社のロードマップに含まれておらず、また現在のお支払いいただいている顧客からそのような要望を聞いたこともありません。
これまでの経緯を正しく理解できていれば、あなたの課題は以下の通りです。
メインの不動産サイトにはフッターがある
メインの不動産サイトと Discourse インスタンスの外観を統一したい
Discourse には一部のページで目立つフッターが存在しない。無限スクロールによりフッターが画面外へ追いやられてしまうためだ
一部のページのみフッターを配置したくない
複雑な状況であることは理解できますが、Discourse を使用したいという前提であれば、ストイック に考えれば選択肢は 2 つしかありません。
フッターを配置する
無限スクロールのないページをホームページとして使用します。例えば Categories - Discourse Meta のように、フッターを目立つ場所に配置し、/latest ルートでは到達できないことを気にしないことです。
フッターを配置しない
discourse.org のページや当社のブログにはフッターがありますが、ここでは同じフッターを配置していません。多くの企業が同様の対応をしており、逆を行おうとすることは「四角い釘を丸い穴に嵌めようとする」ようなものかもしれません。
私は、既存の有料顧客の一部を代表しています。また、最初の投稿で述べたとおり、この組み合わせや懸念について議論している他のスレッドもあり、それらはあなたの最近の回答と同様に却下されています。
Falco:
あなたの問題は
それは私の個人的な問題ではありません。多くのコミュニティが直面しているアクセシビリティの欠陥であり、チームがその修正に前向きであることを期待していました。
Discourse を使い続け、自前でカスタムソリューションの一部を構築していく方針です。現状、この機能はあなたのロードマップからあまりに遠く離れているためです。
フッターが存在しないことを考えると、もしかすると見当違いのことを言っているのではないでしょうか?
ページ上部に「フッターのない無限スクロールページであること」を説明するテキストを追加するのはどうでしょうか。
やや偏見に満ちた発言になることを承知で申し上げますが、Discourse を単なる「ウェブページ」と分類するのは、必ずしも公平ではないと思います。
Discourse はウェブアプリケーションであり、その性質上、ウェブページとアプリの境界を曖昧にしています。
もしこれを「アプリ」として捉えれば、状況は大きく変わるはずです。
PWA として開けば、それは確かにアプリのように振る舞います。
iOS のメールアプリを開いてみてください。フッターはどこにありますか?
(はい、はい、下部に浮かぶパネルに基本的なコントロールはありますが、それは Hub モードの Discourse にも当てはまります)
Apple がフッターがないことを理由に糾弾されているでしょうか?
Gmail についてはどうでしょうか?
なぜ Gmail やメールアプリではメールの無限スクロールが許容されるのに、トピックリストの場合は認められないのでしょうか?それらは意味論的に非常に似ていませんか?
もし Gmail や iOS メールの開発者が「さらにメールを表示」ボタンを導入したら、ユーザーは喜ぶでしょうか?
なぜこれらのアプリのアクセシビリティ専門家たちは、無限スクロールが許容されると結論づけたのでしょうか?
では、これらのガイドラインは、このケースにおいて本当に適用可能なのでしょうか?
https://thepavilion.io/ のフォーラムには、参考になる追加のフッターがあります。iOS Safari では問題なく機能しますが、iOS 版 Discourse アプリでは、あまりうまく機能しないか(少なくとも動作が異なります)。