Custom Widgets, Zero Scan Violations, Ten Days to Release
Your team ships a React web app and companion iOS/Android apps for booking lab equipment. A faculty member who is blind reports that the mobile date picker announces “button” for every day and cannot select a date. A keyboard-only user reports that the desktop modal traps focus and that the Close control is reachable only by mouse. Automated scans report zero violations because both components are custom. The release is in 10 days. The team proposes adding ARIA labels and shipping.
1. Why do automated scans report zero violations, and what does that imply for the release decision?
Read the worked answer
Automated scanners check detectable rules, such as missing alternative text or contrast, but they cannot judge whether a custom widget's interaction model works. A canvas-like or div-based date picker can have no scan-detectable violation while exposing every day as an unnamed button with no selected state or keyboard grid behavior. Zero violations therefore means “no detected rule failures,” not “accessible.” For release, the team needs manual keyboard testing and screen-reader testing on real devices. Shipping with a date picker that blocks selection for blind users is a high-severity defect, not a cosmetic ARIA gap.
2. How should the team triage the date picker and modal defects with 10 days left?
Read the worked answer
Triage by task blockage and severity. The mobile date picker blocks a core booking task for screen-reader users, so it is release-blocking for that platform unless a working alternative is provided. The desktop modal focus trap also blocks keyboard users if Close cannot be reached. Fix first: implement a proper date grid with accessible names, selected state, keyboard movement, and a text-entry fallback; make the modal cycle focus correctly, support Escape, ensure Close is keyboard reachable, and restore focus on close. Do not merely add ARIA labels to a broken interaction model. If the full date-picker rewrite cannot be finished, ship behind a feature flag or provide an accessible fallback path, and document the known limitation.
3. What verification plan would you require before declaring the fixes complete?
Read the worked answer
Require task-based verification, not just code review. Test the booking flow with a keyboard-only user, VoiceOver on iOS, TalkBack on Android, and at least one desktop screen reader. Verify that a user can open the picker, understand the current date, move by day/week/month, select a date, and confirm the selection. For the modal, verify focus enters, stays within while open, reaches Close, exits with Escape, and returns to the trigger. Add regression tests or component-level checks where possible. Record the assistive technology and browser/device combinations. If real-user testing is not possible before release, state that the fix is unverified and keep the limitation visible.