🎨 Palette: フォームの動的エラーメッセージのアクセシビリティを向上#986
Conversation
Add `role="alert"` (or `role="status"`) to dynamically rendered form and submission error messages across several pages to ensure they are immediately announced by screen readers when they appear in the DOM. Files updated: - apps/web/src/app/collections/new/page.tsx - apps/web/src/app/orgs/new/page.tsx - apps/web/src/app/papers/[id]/edit/page.tsx - apps/web/src/app/upload/page.tsx - apps/web/src/app/settings/page.tsx Co-authored-by: is0692vs <135803462+is0692vs@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
|
Warning Review limit reached
More reviews will be available in 49 minutes and 11 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (6)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
このリポジトリでは staging 先行フローを採用しています。PR のターゲットを |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
Code Review
This pull request improves form error rendering accessibility by adding role="alert" (or a dynamic role attribute) to error and status message elements across several pages, and documents this practice in .Jules/palette.md. The review feedback suggests a further improvement to ensure robust accessibility: instead of conditionally mounting the error elements, they should always remain in the DOM with their content updated dynamically, using Tailwind's empty:hidden utility to hide them when empty. This prevents certain screen readers from failing to detect the dynamically created live regions.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| {error && ( | ||
| <p role="alert" className="text-sm text-red-600"> | ||
| {error} | ||
| </p> | ||
| )} |
There was a problem hiding this comment.
スクリーンリーダーのアクセシビリティを高めるための role="alert" の追加は素晴らしい改善です。
さらに堅牢なアクセシビリティを実現するための改善案として、role="alert" を持つ要素を初期レンダリング時から常にDOM上に存在させておくことが推奨されます。
理由
一部のスクリーンリーダー(特にVoiceOverなど)やブラウザの組み合わせにおいて、要素自体が動的にマウント・アンマウントされる({error && <p role="alert">...)と、新しく出現したライブリージョン(role="alert")を正しく検知できず、エラーメッセージが自動的に読み上げられない場合があります。
対策
要素自体は常にDOM上に配置しておき、中身のテキスト(error)のみを動的に更新するようにします。
Tailwind CSSの empty:hidden ユーティリティクラスを使用することで、エラーメッセージが空のときは要素を非表示(display: none)にし、レイアウト崩れを防ぎつつ、スクリーンリーダーにライブリージョンを事前に登録させることができます。
※注意点として、:empty 疑似クラスは空白文字(改行やスペース)が存在すると「空ではない」と判定されてしまうため、JSXタグの間には改行を入れず {error} のみを直接記述する必要があります。
| {error && ( | |
| <p role="alert" className="text-sm text-red-600"> | |
| {error} | |
| </p> | |
| )} | |
| <p role="alert" className="text-sm text-red-600 empty:hidden">{error}</p> |
| {error && ( | ||
| <p role="alert" className="text-sm text-red-600"> | ||
| {error} | ||
| </p> | ||
| )} |
There was a problem hiding this comment.
スクリーンリーダーのアクセシビリティを高めるための role="alert" の追加は素晴らしい改善です。
さらに堅牢なアクセシビリティを実現するための改善案として、role="alert" を持つ要素を初期レンダリング時から常にDOM上に存在させておくことが推奨されます。
理由
一部のスクリーンリーダー(特にVoiceOverなど)やブラウザの組み合わせにおいて、要素自体が動的にマウント・アンマウントされる({error && <p role="alert">...)と、新しく出現したライブリージョン(role="alert")を正しく検知できず、エラーメッセージが自動的に読み上げられない場合があります。
対策
要素自体は常にDOM上に配置しておき、中身のテキスト(error)のみを動的に更新するようにします。
Tailwind CSSの empty:hidden ユーティリティクラスを使用することで、エラーメッセージが空のときは要素を非表示(display: none)にし、レイアウト崩れを防ぎつつ、スクリーンリーダーにライブリージョンを事前に登録させることができます。
※注意点として、:empty 疑似クラスは空白文字(改行やスペース)が存在すると「空ではない」と判定されてしまうため、JSXタグの間には改行を入れず {error} のみを直接記述する必要があります。
| {error && ( | |
| <p role="alert" className="text-sm text-red-600"> | |
| {error} | |
| </p> | |
| )} | |
| <p role="alert" className="text-sm text-red-600 empty:hidden">{error}</p> |
| {error && ( | ||
| <div className="mb-6 rounded-md bg-red-50 p-4 text-sm text-red-700 dark:bg-red-900/30 dark:text-red-400"> | ||
| <div role="alert" className="mb-6 rounded-md bg-red-50 p-4 text-sm text-red-700 dark:bg-red-900/30 dark:text-red-400"> | ||
| {error} | ||
| </div> | ||
| )} |
There was a problem hiding this comment.
スクリーンリーダーのアクセシビリティを高めるための role="alert" の追加は素晴らしい改善です。
さらに堅牢なアクセシビリティを実現するための改善案として、role="alert" を持つ要素を初期レンダリング時から常にDOM上に存在させておくことが推奨されます。
理由
一部のスクリーンリーダー(特にVoiceOverなど)やブラウザの組み合わせにおいて、要素自体が動的にマウント・アンマウントされる({error && <div role="alert">...)と、新しく出現したライブリージョン(role="alert")を正しく検知できず、エラーメッセージが自動的に読み上げられない場合があります。
対策
要素自体は常にDOM上に配置しておき、中身のテキスト(error)のみを動的に更新するようにします。
Tailwind CSSの empty:hidden ユーティリティクラスを使用することで、エラーメッセージが空のときは要素を非表示(display: none)にし、レイアウト崩れを防ぎつつ、スクリーンリーダーにライブリージョンを事前に登録させることができます。
※注意点として、:empty 疑似クラスは空白文字(改行やスペース)が存在すると「空ではない」と判定されてしまうため、JSXタグの間には改行を入れず {error} のみを直接記述する必要があります。
| {error && ( | |
| <div className="mb-6 rounded-md bg-red-50 p-4 text-sm text-red-700 dark:bg-red-900/30 dark:text-red-400"> | |
| <div role="alert" className="mb-6 rounded-md bg-red-50 p-4 text-sm text-red-700 dark:bg-red-900/30 dark:text-red-400"> | |
| {error} | |
| </div> | |
| )} | |
| <div role="alert" className="mb-6 rounded-md bg-red-50 p-4 text-sm text-red-700 dark:bg-red-900/30 dark:text-red-400 empty:hidden">{error}</div> |
| {error && ( | ||
| <div className="rounded-2xl border border-red-200 bg-red-50 p-4 text-sm text-red-700 dark:border-red-900/50 dark:bg-red-950/40 dark:text-red-300"> | ||
| <div role="alert" className="rounded-2xl border border-red-200 bg-red-50 p-4 text-sm text-red-700 dark:border-red-900/50 dark:bg-red-950/40 dark:text-red-300"> | ||
| {error} | ||
| </div> | ||
| )} |
There was a problem hiding this comment.
スクリーンリーダーのアクセシビリティを高めるための role="alert" の追加は素晴らしい改善です。
さらに堅牢なアクセシビリティを実現するための改善案として、role="alert" を持つ要素を初期レンダリング時から常にDOM上に存在させておくことが推奨されます。
理由
一部のスクリーンリーダー(特にVoiceOverなど)やブラウザの組み合わせにおいて、要素自体が動的にマウント・アンマウントされる({error && <div role="alert">...)と、新しく出現したライブリージョン(role="alert")を正しく検知できず、エラーメッセージが自動的に読み上げられない場合があります。
対策
要素自体は常にDOM上に配置しておき、中身のテキスト(error)のみを動的に更新するようにします。
Tailwind CSSの empty:hidden ユーティリティクラスを使用することで、エラーメッセージが空のときは要素を非表示(display: none)にし、レイアウト崩れを防ぎつつ、スクリーンリーダーにライブリージョンを事前に登録させることができます。
※注意点として、:empty 疑似クラスは空白文字(改行やスペース)が存在すると「空ではない」と判定されてしまうため、JSXタグの間には改行を入れず {error} のみを直接記述する必要があります。
| {error && ( | |
| <div className="rounded-2xl border border-red-200 bg-red-50 p-4 text-sm text-red-700 dark:border-red-900/50 dark:bg-red-950/40 dark:text-red-300"> | |
| <div role="alert" className="rounded-2xl border border-red-200 bg-red-50 p-4 text-sm text-red-700 dark:border-red-900/50 dark:bg-red-950/40 dark:text-red-300"> | |
| {error} | |
| </div> | |
| )} | |
| <div role="alert" className="rounded-2xl border border-red-200 bg-red-50 p-4 text-sm text-red-700 dark:border-red-900/50 dark:bg-red-950/40 dark:text-red-300 empty:hidden">{error}</div> |
|
|
||
| {message && ( | ||
| <p | ||
| role={messageType === "error" ? "alert" : "status"} |
There was a problem hiding this comment.
role 属性をすでにレンダリング済みの要素上で動的に変更することは、ARIA 仕様上推奨されていません。message が truthy のまま messageType だけが変わるケース(例:保存成功後すぐにバリデーションエラーが続けて発生する場合)では、スクリーンリーダーが変更後のロールを正しく解釈しない可能性があります。
{message && ...} の条件付きレンダリングにより、message が null → 値 に変化する際は要素が新規マウントされるため通常問題ありませんが、より確実にするには key プロップを活用してロールが変わるたびに要素を再マウントさせる方法が有効です(例:key={messageType})。
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/web/src/app/settings/page.tsx
Line: 176
Comment:
**ARIA ロールの動的切り替えに関する注意**
`role` 属性をすでにレンダリング済みの要素上で動的に変更することは、ARIA 仕様上推奨されていません。`message` が truthy のまま `messageType` だけが変わるケース(例:保存成功後すぐにバリデーションエラーが続けて発生する場合)では、スクリーンリーダーが変更後のロールを正しく解釈しない可能性があります。
`{message && ...}` の条件付きレンダリングにより、`message` が null → 値 に変化する際は要素が新規マウントされるため通常問題ありませんが、より確実にするには `key` プロップを活用してロールが変わるたびに要素を再マウントさせる方法が有効です(例:`key={messageType}`)。
How can I resolve this? If you propose a fix, please make it concise.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
💡 What: 各ページのフォームで動的に表示されるエラーメッセージ要素に対して、
role="alert"(または成功/情報メッセージの場合はrole="status")を追加しました。🎯 Why: フォームの検証エラーやAPI送信エラーなど、画面上に動的に表示されるメッセージに
role="alert"を付与することで、スクリーンリーダーユーザーに対して自動的かつ即座にエラー内容が読み上げられるようになり、ユーザー体験とアクセシビリティが向上します。♿ Accessibility: 動的に表示されるエラー表示部に
role="alert"を追加することで、スクリーンリーダーがDOMへの変更を監視し、フォーカスを移動させなくてもユーザーにエラーを通知できるようになります。PR created automatically by Jules for task 17973489122644666835 started by @is0692vs
Greptile Summary
各フォームページの動的エラーメッセージ要素に
role="alert"(成功メッセージにはrole="status")を追加し、スクリーンリーダーによる自動読み上げを実現するアクセシビリティ改善 PR です。collections/new・orgs/new・papers/[id]/edit・uploadの 4 ページで、条件付きレンダリングされるエラー<p>/<div>にrole="alert"を付与し、DOM へのマウント時にスクリーンリーダーへ即時通知されるようになりました。settingsページでは、エラーはrole="alert"、成功・情報メッセージはrole="status"と動的に切り替える実装を採用し、メッセージの重要度に応じた読み上げ優先度を適切に区別しています。Confidence Score: 4/5
変更は各フォームへの role 属性追加のみで、既存の表示ロジックやスタイリングには一切手を加えていないため、マージは安全です。
settings ページで
messageTypeとmessageが独立して変化した場合に既存 DOM 要素のrole属性が動的に書き換えられる可能性があり、一部のスクリーンリーダーで意図しない挙動を引き起こすリスクが小さく残っています。それ以外の 4 ファイルはシンプルな属性追加のみです。apps/web/src/app/settings/page.tsx — role 属性の動的切り替えロジックを確認してください。
Important Files Changed
要素に role="alert" を追加。条件付きレンダリング構造はそのまま維持されており変更は最小限
要素に role="alert" を追加。collections/new と同パターン
Sequence Diagram
sequenceDiagram actor User participant Form as フォーム UI participant DOM participant SR as スクリーンリーダー User->>Form: フォーム送信 Form->>Form: バリデーション / API 呼び出し alt エラー発生 Form->>DOM: "role="alert" の p/div をマウント" DOM-->>SR: "aria-live="assertive" により即時通知" SR-->>User: エラーメッセージを読み上げ else 保存成功 (settings) Form->>DOM: "role="status" の p をマウント" DOM-->>SR: "aria-live="polite" により通知" SR-->>User: 成功メッセージを読み上げ endPrompt To Fix All With AI
Reviews (1): Last reviewed commit: "feat(web): add role="alert" to dynamic e..." | Re-trigger Greptile