🎨 Palette: Add accessibility contexts to Writing Pad tools#282
🎨 Palette: Add accessibility contexts to Writing Pad tools#282RileyTheRiler wants to merge 1 commit into
Conversation
- Added `role="group"` and `aria-label` to stroke color and width tools - Added `aria-label`, `aria-pressed`, and `aria-hidden` attributes to child elements - Added `focus-visible` styling for keyboard navigation Co-authored-by: RileyTheRiler <153484434+RileyTheRiler@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.
|
📝 WalkthroughWalkthroughWritingPad component's Tools UI controls enhance accessibility semantics. The stroke color picker and stroke width selector now wrap their buttons in ChangesAccessibility Enhancements for Tools UI
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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. Review rate limit: 0/1 reviews remaining, refill in 60 minutes.Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/components/WritingPad.jsx`:
- Line 449: Replace the Tailwind utility focus-visible:outline-none with
focus-visible:outline-hidden in the button group className strings inside the
WritingPad component to preserve forced-colors (Windows High Contrast Mode)
focus outlines; specifically update the className used for the stroke color
buttons (the JSX element that builds the color swatches where strokeColor ===
color.value is checked) and the stroke width buttons (the similar JSX element
around the stroke width controls) so both use focus-visible:outline-hidden
instead of focus-visible:outline-none.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 386e6058-53d6-4428-8625-394d7208d217
📒 Files selected for processing (1)
src/components/WritingPad.jsx
| key={color.value} | ||
| onClick={() => setStrokeColor(color.value)} | ||
| className={`w-8 h-8 rounded-full border-2 transition-transform ${strokeColor === color.value | ||
| className={`w-8 h-8 rounded-full border-2 transition-transform focus-visible:ring-2 focus-visible:ring-purple-400 focus-visible:outline-none ${strokeColor === color.value |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, verify the code exists and check lines 449 and 467
if [ -f "src/components/WritingPad.jsx" ]; then
echo "=== Lines around 449 ==="
sed -n '445,453p' src/components/WritingPad.jsx
echo ""
echo "=== Lines around 467 ==="
sed -n '463,471p' src/components/WritingPad.jsx
else
echo "File not found"
fiRepository: RileyTheRiler/French-Game
Length of output: 1389
🌐 Web query:
Tailwind CSS v4 outline-none vs outline-hidden forced-colors HCM
💡 Result:
In Tailwind CSS v4, the key difference is how the utilities behave under forced colors mode (CSS @media (forced-colors: active)). 1) outline-hidden - Tailwind docs describe it as “hide the default browser outline on focused elements, while still preserving the outline in forced colors mode” [1]. - Mechanically, it makes the outline style effectively “hidden” by default in normal rendering, but in forced-colors it still allows focus indication instead of fully removing it (Tailwind’s docs and the original PR explain this accessibility goal) [1][2]. 2) outline-none - In v4, Tailwind has a simplified outline-none which sets outline-style: none (i.e., it truly removes the outline style, rather than leaving an invisible outline that could appear in forced colors) [2][3]. - Consequently, outline-none will remove the default outline even in forced colors scenarios where you’d otherwise want the browser to still indicate focus [1][2]. Practical takeaway for “HCM” (high contrast / forced colors): - Prefer outline-hidden when you want to suppress the default focus outline for most users but still retain focus visibility for high-contrast / forced-colors users [1]. - Use outline-none only if you intentionally want to remove the outline entirely, knowing that forced-colors focus visibility may be impacted [2][3]. If you’re upgrading from Tailwind v3: - The Tailwind team renamed the old behavior by moving the v3-style “don’t fully remove outline; keep it for forced colors” into outline-hidden, and added a new outline-none that matches the intuitive “set outline-style: none” expectation [2][3].
Citations:
- 1: https://tailwindcss.com/docs/outline-style
- 2: Replace
outline-nonewithoutline-hidden, add newoutline-nonetailwindlabs/tailwindcss#14926 - 3: [v4] :focus-visible no longer overrides default outline for some reason tailwindlabs/tailwindcss#15152
🌐 Web query:
Tailwind CSS v4 upgrade codemod outline-none outline-hidden
💡 Result:
Tailwind CSS v4 upgrade codemod: it should rename outline-none to outline-hidden. What the upgrade is supposed to do - Tailwind’s official upgrade guide says to replace any usage of outline-none with outline-hidden when migrating to v4 (including variants like focus:outline-none → focus:outline-hidden) [1]. - The rationale is that outline-none previously didn’t actually set outline-style: none and instead produced an invisible outline to keep it visible in forced-colors mode for accessibility; Tailwind renamed it to outline-hidden and introduced a new outline-none that truly sets outline-style: none [1]. How the codemod behaves (evidence from implementation + community reports) - A Tailwind v3→v4 codemod repository documents the “Outline Migration” mapping across all variants, including outline-none → outline-hidden and focus:outline-none/focus-visible:outline-none variants [2]. - Tailwind issue discussion confirms the intended behavior: the upgrade guidance maps to outline-hidden for accessibility in forced-colors mode, while outline-none exists in v4 to actually remove the outline (outline-style: none) [3]. - Some third-party codebases have observed cases where not all outline-none usages were migrated, indicating this rename is a common codemod expectation but can depend on how/what the upgrade tool scans and applies [4]. Recommended search/verification step in your codebase - After running the upgrade, verify whether any legacy utility remains: - grep for outline-none and ensure it’s been replaced with outline-hidden where appropriate [1]. How to run the official upgrade codemod (high level) - Tailwind’s v4 upgrade tool is provided as @tailwindcss/upgrade and is run via npx @tailwindcss/upgrade`` [5] / [6].
Citations:
- 1: https://tailwindcss.com/docs/upgrade-guide
- 2: https://github.com/zan-maker/tailwindcss-v4-codemod
- 3:
outline-hiddenonly applies transparent outline whenforced-colorsis active? tailwindlabs/tailwindcss#16926 - 4: [bug]: v4 registry incomplete outline-none to outline-hidden migration (19 components) shadcn-ui/ui#10101
- 5: https://mintlify.com/tailwindlabs/tailwindcss/upgrading/codemods
- 6: https://mintlify.com/tailwindlabs/tailwindcss/upgrading/upgrade-guide
Use focus-visible:outline-hidden instead of focus-visible:outline-none for Windows High Contrast Mode compatibility
In Tailwind CSS v4, outline-none sets outline-style: none and does not preserve the transparent outline that enables focus visibility under @media (forced-colors: active) (Windows High Contrast Mode). outline-hidden produces the same visual result in standard rendering but additionally preserves a visible outline in forced-colors mode. The official Tailwind v4 upgrade guide explicitly maps outline-none → outline-hidden for this reason.
Since this PR specifically targets accessibility, this affects HCM users on both button groups.
♿ Proposed fix for both button groups
- className={`... focus-visible:ring-2 focus-visible:ring-purple-400 focus-visible:outline-none ...`}
+ className={`... focus-visible:ring-2 focus-visible:ring-purple-400 focus-visible:outline-hidden ...`}Apply the same change to the stroke width buttons (line 467).
Also applies to: 467-467
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/components/WritingPad.jsx` at line 449, Replace the Tailwind utility
focus-visible:outline-none with focus-visible:outline-hidden in the button group
className strings inside the WritingPad component to preserve forced-colors
(Windows High Contrast Mode) focus outlines; specifically update the className
used for the stroke color buttons (the JSX element that builds the color
swatches where strokeColor === color.value is checked) and the stroke width
buttons (the similar JSX element around the stroke width controls) so both use
focus-visible:outline-hidden instead of focus-visible:outline-none.
💡 What: Grouped the stroke color and stroke width buttons in
WritingPad.jsxinto logical groups withrole="group"andaria-label. Added descriptivearia-labels andaria-pressedstates to individual buttons, andfocus-visiblerings for keyboard users. Decorative internal elements were givenaria-hidden="true".🎯 Why: To ensure screen reader users can navigate and understand the purpose of these interactive tools, and to provide clear visual feedback for keyboard-only navigation.
📸 Before/After: The visual appearance remains exactly the same for mouse users. Keyboard users now see a clear purple ring (
ring-purple-400) when tabbing through the tool buttons. Screen readers now announce the groups and the state (pressed) of each button clearly.♿ Accessibility: Solves a major accessibility gap where a row of visually distinct buttons had no semantic meaning, labels, or clear focus states.
PR created automatically by Jules for task 13041229929443143392 started by @RileyTheRiler
Summary by CodeRabbit