a11y(1.4.10): activity-options drawer — make width responsive so it reflows at 320 px#3476
Open
canvanooo wants to merge 1 commit into
Open
a11y(1.4.10): activity-options drawer — make width responsive so it reflows at 320 px#3476canvanooo wants to merge 1 commit into
canvanooo wants to merge 1 commit into
Conversation
…eflows at 320 px The activity-options-update-drawer passed class="w-[480px]" to the Holocene <Drawer> primitive. tailwind-merge resolves the conflicting width utilities in favor of the consumer's class, overriding the primitive's responsive default (w-screen sm:max-w-fit). At a 320 CSS px viewport the drawer was anchored right-0 and extended 160 px off the viewport's left edge, triggering horizontal page scroll. WCAG 1.4.10 explicitly requires content to reflow without horizontal scrolling at 320 CSS px. The two-breakpoint form (w-screen sm:w-[480px]) keeps the drawer full-width below the sm: breakpoint (< 640 px) and at 480 px from sm: and above, matching the original desktop intent. No primitive change; the other three Drawer consumers in the repo pass viewport-relative widths or no override and are already correct. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
|
Contributor
|
Author
|
Verified locally. |
ardiewen
approved these changes
May 29, 2026
13 tasks
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
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.
Description & motivation 💭
The Holocene
<Drawer>primitive's default (w-screen sm:max-w-fit) reflows correctly at narrow viewports. The activity-options drawer atsrc/lib/components/activity/activity-options-update-drawer.svelte:126passedclass="w-[480px]", whichtailwind-mergeresolved over the primitive'sw-screenbecause the consumer'sclassNameis the later argument and both belong to thewidthconflict group. Result: drawer was 480 CSS px wide at every viewport width.At a 320 CSS px viewport (the WCAG 2.2 reflow threshold — small phone in portrait), the drawer is
right-0anchored, so the 480 px width pushed its left edge 160 px off the viewport's left side. That triggered horizontal page scroll, violating SC 1.4.10 Reflow.This PR swaps the consumer's class to the two-breakpoint form
w-screen sm:w-[480px].w-screenandsm:w-[480px]are in different responsive groups, so they coexist cleanly: drawer is full-width belowsm:(< 640 px) and 480 px atsm:and above, matching the original desktop intent.The diff:
One line in
src/lib/components/activity/activity-options-update-drawer.svelte:126.Other Drawer consumers verified safe (no parallel fix needed):
workflow/configurable-table-headers-drawer/index.svelte:44w-[35vw] min-w-min max-w-fitworkers/serverless-worker-form/setup-guide-toggle.svelte:25event/event-shortcut-keys.svelte:25activity/activity-options-update-drawer.svelte:126w-[480px]The primitive does not change.
Screenshots (if applicable) 📸
Screenshots to be captured by the PR author from the Vercel preview build (link appears once the
Vercelcheck passes). Include light-mode and dark-mode captures for each affected primitive.Design Considerations 🎨
No visual change on desktop. Behavior change only at small viewports (< 640 px wide), where the drawer now fills the available width instead of extending off-screen. If the design team has an explicit preference for how drawer content should reflow on small screens (e.g., a different layout for the inner form), that's a follow-up — this PR closes the WCAG 1.4.10 failure without changing the form structure inside the drawer.
Testing 🧪
How was this tested 👻
Automated checks performed locally on
a11y/1.4.10-activity-options-drawer-reflowbefore pushing:pnpm lint— 0 errors (148 pre-existing warnings, none on the touched file)pnpm check(svelte-check) — 0 errors (84 pre-existing warnings, none on the touched file)pnpm test -- --run— 142 test files / 2023 tests passlint-staged: eslint --fix, prettier --write, stylelint --fix) cleanManual visual testing in DevTools device mode is the responsibility of the PR author after the preview deploy is ready (see "Steps for others to test" below).
Steps for others to test: 🚶🏽♂️🚶🏽♀️
pnpm installif needed.pnpm dev— open Chrome DevTools, toggle device mode, set viewport to 320 × 568 portrait.examples/a11y-badge-demo/in the audit workspace produces one).document.body.scrollWidth === document.body.clientWidthshould returntrue.sm:breakpoint). Re-open the drawer. Confirm: drawer is now 480 px wide.Checklists
Draft Checklist
src/lib/components/activity/activity-options-update-drawer.svelte:126pnpm lint,pnpm check,pnpm test -- --runall passMerge Checklist
document.body.scrollWidth === document.body.clientWidthconfirmed at 320 px viewportIssue(s) closed
A11y-Audit-Ref: 1.4.10-activity-options-drawer-width
Closes the activity-options drawer reflow defect documented in the May 2026 audit (manifest bucket 1, severity serious, scope ui-main). See
scripts/a11y/manifest.ymlfor the canonical entry.Docs
Any docs updates needed?
No external docs (
docs.temporal.io) need updating — this is a consumer-side CSS class change with no API surface change.🤖 Generated with Claude Code