Replies: 2 comments
-
私の方で検討している解決案2つのうち、2を推しています。 検討中の解決案1. キーボードフォーカスで到達不可能にするそもそもの
というアクセシビリティ要件を変更して
にし、https://github.com/openameba/spindle/blame/main/packages/spindle-ui/src/Toast/Toast.tsx#L115 の実装箇所を しかしToastは自動で表示が消えてしまう性質上、「読む時間が足りず延長したいユーザーに延長の手段を提供する」ことは重要です(参考:2.2.1 コンテンツに制限時間を設けない)。マウスを使わ(え)ずキーボード(あるいはSwitch Controlなどの支援技術)を使うユーザーを考慮すると、「キーボードでfocusしている時には、時間制限を停止します。フォーカスが離れたのち、再度0秒から計測します」という要件を捨てて良いとは思えません。 とはいえ、DOM順序的にToast Componentを表示するボタンの直後にToast Componentを配置しない限り、ユーザーがキーボードフォーカスでToast Componentに到達することは難しいです。(実質不可能) ということから修正案2を考えています。 2. Toast ComponentのDOM配置位置を変更し、非表示のときはキーボードフォーカスで到達不可能にする上記のAmeba Newsでは、記事urlコピーボタンを押したときにToastを表示しているため、DOM順序的にこのボタンの直後にToast Componentを配置しておくことで、「コピーボタン→Toast」にキーボードフォーカスを移すことができます。
という要件を、キーボードユーザーでも恩恵を受けやすくなります。 このために必要な修正として
が必要ですが、1がなくても件の事象は発生しなくなるため、先に2を修正しておいても問題はないと考えています。 相談したいこと解決案2が良いかな?と思っていますが、解決案2-1がサービス側の実装に依存します。
|
Beta Was this translation helpful? Give feedback.
-
提案ありがとうございます!まだ解決策まで考えきれてないですが、気になりポイントだけ先にリストアップしておきます。
理想や推奨はこれで良さそう。だだ、直後に置くと都合がよくないアプリケーションもありそうなのでそのケースを実際には考えないとな感じはします。
これは対応して良さそう。spindle-uiで対応した時にアプリ側で予期しない影響がないかだけ一応想定したいかもです。 |
Beta Was this translation helpful? Give feedback.
-
今回、Ameba Newsでの導入事例で、Toastが非表示にもかかわらずToast Componentにキーボードフォーカスできてしまい、スクリーンリーダーで思わぬ読み上げが発生するなど意図しない挙動が見られました。
解決したいこと
下記2つの解決案を模索したいです!
(Ameba Newsでは、ヘッダーナビゲーションの後ろにToast Componentを配置しており、ヘッダーナビゲーションの「ランキング」の次にToastにフォーカスが移る。その際にスクリーンリーダーでは謎の読み上げ「グループ ...(ページ上のテキストを順に)」が発生している。)
ref: 議論の余地がありそうだったので、 #290 からdisscussionsに移行しました。
Beta Was this translation helpful? Give feedback.
All reactions