Two Ways to Build an Accessible DatePicker with AI: 80/20 AI-First vs. Systematic Agent Design

I’ve been building accessible UI components for over a decade. Last month, I needed a DatePicker that works with screen readers, supports keyboard navigation, and doesn’t break under heavy localization. I tried two radically different approaches with AI. Here’s what happened. **The problem**: A DatePicker seems simple until you need it to be truly accessible. WCAG 2.2 requires focus management, ARIA roles, live region announcements, and support for both mouse and keyboard. Doing this manually takes days. AI promised speed. But which approach actually delivers? ## Approach 1: The 80/20 AI-First Sprint I gave GPT-4o a single prompt: “Build an accessible DatePicker in React with TypeScript. Use aria-live, handle keyboard navigation, support month/year selection.” No specs. No wireframes. Just a clear outcome. **What I got in 15 minutes**: - A working component with month navigation - Basic ARIA labels on buttons - Keyboard handling for arrow keys - A popover that opens on focus **The reality check**: The first version passed automated Axe checks but failed real screen reader tests. NVDA announced “button” for every day cell without the date. Focus trapped incorrectly. The localization was hardcoded to English. I iterated. Three more prompts fixed focus trapping and added aria-selected. A fourth prompt added i18n support with moment.js. Total time: about 45 minutes. Result: a functional DatePicker that worked for 80% of use cases. **What worked**: Speed. I had a demo-ready component in under an hour. For internal tools or prototypes, this is gold. **What broke**: Edge cases. Month boundaries where the first day is Sunday? The AI generated incorrect grid logic. Leap year handling? Missed. High-contrast mode support? Not even attempted. ## Approach 2: Systematic Agent Design with a Planning Agent I switched to a structured workflow. I used an AI agent (Claude + custom tooling) that first generated a full spec: component tree, ARIA states, keyboard map, test cases. Then it built the component in layers. **The spec phase** (20 minutes): - Defined all 14 keyboard shortcuts (Tab, Enter, Escape, Arrow keys) - Mapped ARIA roles: grid, gridcell, button, dialog - Listed required states: default, focused, selected, disabled, today, out-of-range - Documented localization keys for 5 languages **The build phase** (2 hours): - Layer 1: Basic grid layout with semantic HTML - Layer 2: Keyboard navigation with roving tabindex - Layer 3: ARIA live region for announcements - Layer 4: Screen reader testing with VoiceOver and NVDA - Layer 5: Edge cases — past dates disabled, RTL support, high-contrast **The result**: A production-ready component that passed both automated and manual accessibility audits. It handled 30+ edge cases. The agent also generated unit tests and a Storybook story. ## The Trade-offs: A Practical Comparison | Aspect | 80/20 AI-First | Systematic Agent Design | |--------|----------------|------------------------| | Time to first demo | 15 minutes | 2.5 hours | | Time to production | ~3 hours (iterative fixes) | 2.5 hours (built right) | | Accessibility quality | 80% passes Axe, fails manual | 100% passes both | | Edge case coverage | ~50% | ~95% | | Documentation | None | Full spec + tests | | Maintainability | Fragile, needs manual refactor | Clean, modular | | Best for | Prototypes, MVPs, internal tools | Customer-facing production | ## Real Case: Which One I Shipped? I used the 80/20 version for an internal dashboard where the team needed a quick date filter. It worked fine. Three months later, a QA engineer reported that screen reader users couldn’t select dates in Hebrew localization. The fix took two hours because the code was a mess. For the customer-facing booking widget, I used the agent approach. It went live in two weeks (including design review). Zero accessibility tickets in six months. **The lesson**: AI can generate code fast, but accessibility is not a “first pass” feature. It’s a system property that requires deliberate design. ## When to Use Each Approach **Use 80/20 AI-first if**: - You’re building for a technical audience that can tolerate imperfections - The component is temporary or internal - You need to validate a concept quickly - You have a human accessibility expert who can polish later **Use systematic agent design if**: - The component faces end users - You need WCAG compliance (legal requirement in many jurisdictions) - The team lacks accessibility expertise - You’re building a design system component used across multiple products ## My Takeaway After Two Months AI is not a replacement for accessibility knowledge. It’s a force multiplier. The 80/20 approach gave me speed but left the hardest 20% — the edge cases that make accessibility real — for later. The agent approach took longer upfront but delivered a component I could trust. For most real products, I now default to the agent workflow. The extra hour upfront saves days of bug fixes later. And for clients who need to ship fast? I use the 80/20 version, but I always budget time for a manual accessibility review. **Want to see the actual code?** I’ve open-sourced both versions on GitHub. The agent version includes full test coverage and documentation. *This article is based on real work I did in June 2026. The news that inspired this comparison is from a recent discussion on accessible UI patterns with AI.* [Source](https://habr.com/ru/articles/1052932/?utm_campaign=1052932&utm_source=habrahabr&utm_medium=rss) *Target audience: Frontend developers, accessibility engineers, product managers building accessible interfaces. Basic React and accessibility knowledge assumed.*

Two Ways to Build an Accessible DatePicker with AI: 80/20 AI-First vs. Systematic Agent Design

Comments

Recent articles

How to Supercharge Your Shopify Store with an AI Agent: No-Code Automation via ASI Biont

The Forbidden Fruit of Vibe Coding: Why Bad Code Isn't the Real Risk

How to Connect Twitter/X to ASI Biont: An AI Agent That Manages Your Account Without Code

Microservices Architecture: How to Stop Fearing Docker and Kubernetes and Start Building Production Systems

NVIDIA Powers Over 400 of the World’s 500 Fastest Supercomputers: What This Means for AI and HPC in 2026

Golang from Scratch: The Language That Will Change Your View of Backend Development in 2026

QuickBooks and ASI Biont: How an AI Agent Automates Accounting Without Code or Manual Entry

How a Beginner Can Enter the Oil and Gas Industry: A Review of the 'Oil and Gas Engineering and Energy' Course on Asibiont

Soft Skills and Career: How Boosting Soft Skills Helped a Manager Become an IT Director