🎨 Palette: [UX improvement] Improve accessibility of disabled buttons - #675
🎨 Palette: [UX improvement] Improve accessibility of disabled buttons#675seonghobae wants to merge 2 commits into
Conversation
|
👋 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. |
📝 WalkthroughWalkthrough내보내기 모달의 접근 관리 버튼이 네이티브 Changes내보내기 모달 접근성
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
frontend/src/components/modals/ExportModal.test.tsx (1)
167-174: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win포커스 가능성과 클릭 차단 동작도 검증해 주세요.
현재 테스트는
aria-disabled와aria-describedby만 확인하므로, 접근 관리 버튼이 포커스를 받을 수 있는지와onClick에서 기본 동작이 실제로 취소되는지는 회귀를 잡지 못합니다. 두 동작을 함께 검증해 주세요.🤖 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 `@frontend/src/components/modals/ExportModal.test.tsx` around lines 167 - 174, Extend the “exposes access-control guidance for disabled button” test to verify that the access-management button remains focusable and that activating it invokes its click handler while preventing the default action. Use the existing button identified by the “접근 관리” role/name and preserve the current accessibility attribute assertions.
🤖 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.
Outside diff comments:
In `@frontend/src/components/modals/ExportModal.test.tsx`:
- Around line 167-174: Extend the “exposes access-control guidance for disabled
button” test to verify that the access-management button remains focusable and
that activating it invokes its click handler while preventing the default
action. Use the existing button identified by the “접근 관리” role/name and preserve
the current accessibility attribute assertions.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 442a6433-b866-4861-b36d-e7c3ef75207e
📒 Files selected for processing (4)
.jules/palette.mdfrontend/src/components/modals/ExportModal.test.tsxfrontend/src/components/modals/ExportModal.tsxfrontend/src/styles.css
💡 What
Modified the "접근 관리" (Access Management) disabled button in the Export modal to use
aria-disabled="true"instead of the native HTMLdisabledattribute, while manually applying visual disabled styles and preventing click propagation. Also updated the corresponding unit tests to verify thearia-disabledbehavior.🎯 Why
The native
disabledattribute completely removes an element from the browser's tab order and accessibility tree for interactive exploration. As a result, thearia-describedbyhint (which explains why the button is disabled: "접근 권한 관리는 프로젝트 권한 설정에서 처리합니다.") was completely undiscoverable by screen readers or keyboard-only users. Usingaria-disabledallows the button to receive focus so assistive technologies can read its helper text, without making it functional.📸 Before/After
Before: The "접근 관리" button used
<button disabled>. It could not receive focus, so screen reader users tabbing through the modal would bypass it entirely and miss the guidance text linked viaaria-describedby.After: The button uses
<button aria-disabled="true">with visual styling in CSS[aria-disabled="true"]. It now receives keyboard focus, and screen readers will announce its label followed by thearia-describedbytext, explicitly informing the user why the button is currently inactive.♿ Accessibility
aria-describedbyhelper text for screen readers.onClick={(e) => e.preventDefault()}) to maintain true disabled behavior safely.PR created automatically by Jules for task 3426923303645699969 started by @seonghobae
Summary by CodeRabbit