Conversation
Button computed disabled-looking styles from the disabled prop but never set the native disabled attribute, so a visually disabled button (e.g. Previous/Next Page at a document boundary) still received keyboard focus and could still be activated by other means.
|
@etuan is attempting to deploy a commit to the CloudPDF Team on Vercel. A member of the Team first needs to authorize it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Hello, we've been working through an accessibility audit which flagged a few issues with your amazing library.
The shared
Buttoncomponent (viewers/snippet/src/components/ui/button.tsx) computes disabled-looking styles (opacity-50,cursor-not-allowed, ...) from itsdisabledprop, but never applies the nativedisabledattribute to the rendered<button>. As a result, a visually disabled toolbar button — e.g. Previous Page at the start of a document, Next Page at the end — remains in the Tab order and can still be reached and activated by keyboard.Fix
Pass
disabled={disabled}through to the native element. One line.Steps to reproduce (before this fix)
WCAG 2.4.3 (Focus Order) — focus should not land on a control that cannot be activated.
Testing
No test suite currently exists for
@embedpdf/snippet, so this is manually verified per the repro steps above. Happy to add a test if there's a preferred harness/pattern for this package I should follow.