Accessibility · 2026
Just A Plane Dashboard
Audited 6 major airport flight tracking interfaces, and found an average of 13 WCAG violations and a 6/10 AIM score. Built a responsive web app with airport search, real-time arrivals/departures, and keyboard-first navigation.
Just A Plane Dashboard design experiment
By the numbers
Jump in
Observation
As a frequent traveler and aviation enthusiast, I've noticed that flight data is presented so differently across airports. Each has their own method of presenting flight information, all include the same critical information (flight number, arrival/departure time, airline, status, gate). Yet, the way this information is presented varies, and is not always accessible.
For an industry this large, flight data deserves a centralized, accessible home. Whether you're tracking your own flight, picking someone up, or just enjoy the data!
Gather Background Info
Market Research
Commercial aviation is a growing industry. OAG reported ~2.9% more passengers on the busiest travel day in 2025, and Bain predicts 2.4% annual fleet growth. More travelers means more people hitting these interfaces.
Airport Research
I audited 6 of the busiest airports for design and accessibility (3 global hubs: ATL, DXB, HND; 3 domestic: DFW, ORD, DEN) using WAVE, axe DevTools, and keyboard navigation.
Some balanced visuals with function (DXB); others didn't (ATL). None let users fully accomplish the task on both desktop and mobile while staying accessible.
Design Patterns
Information Overload:
Tables repeat column headers in rows, field labels clutter every entry, and unnecessary information (codeshare animations, color theme overlays) add visual noise without helping users.
Control Placement Matters:
Arrival/Departure toggles vary wildly: sometimes above the table (ORD), sometimes in the search bar far from data (ATL). Users have to hunt for controls (HND).
Mobile ≠ Scaled Desktop:
Most airports degrade on mobile: missing fields (ATL drops codeshare), table headers disappear (DEN repeats labels per card), data doesn't load without a secondary action (ORD), airlines get replaced by logos (DXB).
Accessibility Patterns
Keyboard Nav Missing/Broken:
Many airports fail keyboard navigation. ATL's accessibility button isn't tabbable, ORD's flight entries aren't keyboard-reachable, and DFW has no visible focus indicators.
Tables Semantically Unclear:
Most airports lack comprehensive row labels. Contrast errors are rampant (WAVE shows 97 errors at HND, 37 at ORD, 21 at ATL).
Inaccessible Accessibility:
ATL's built-in accessibility menu creates more errors rather than fixing them. The menu button itself isn't tabbable, and color themes add contrast errors instead of fixing them.
Create a Hypothesis
If accessibility is treated as a structural design constraint from the start rather than a compliance checklist applied at the end, then flight information interfaces can meet WCAG standards without sacrificing visual hierarchy or scannability.
Test Hypothesis
Design Pattern Decisions
I styled the mobile cards so that they look like paper boarding passes with primary flight info on the left, logistics on the right, organically echoing a boarding pass structure.
Before locking these patterns, I used Composer 2 in Cursor to pressure-test the rationale, like airport selection methodology, excluding decorative green, and color hierarchy for status, so each decision had to survive cross-examination, not just sound good in a deck.
- Show only essential fields: Flight, airline, time, status, gate/terminal/baggage. No unnecessary animations or repeated labels. One flight = one readable unit.
- Controls adjacent to data affected: Tabs are above the flight schedule, not hidden in navigation. Data refresh is above the table.
- Mobile design should be intentional: Fields scale logically, and core fields should always be visible. Same data, different presentation.
Style Sheet
I wanted a sleek, professional, and legible typeface - so I opted for a Neo-Grotesque sans serif font. One of the key criteria is legibility, can users differentiate between capital I, lowercase l, and 1? If not, then no. Does the typeface have italic fonts? If not, then it’s also not an option.
As for the brand color, I aimed to revolve around blue (#2F5781). It is professional, calm, and trustworthy choice. I also associate blue with speed, and it’s not a farfetched association either - JetBlue, United, KLM use blues in branding. Blues along with greys and a white background make for the basic color palette used.
Accessibility Pattern Decisions
- Keyboard Navigation Required: All interactive elements tabbable in logical order. Clear, visible focus states. Airport section, flight entries, controls all reachable via Tab key.
- Semantic Correctness: Comprehensive label per flight (code, route, airline, times, terminal, gate, status). Proper contrast ratios (WCAG AA minimum). Real semantic tabs (not links pretending to be tabs).
- Accessibility is structural: High contrast built into the default design. No color themes that introduce new accessibility problems. Focus on semantic HTML, not overlay features.
Final Experiment
Connected AirLabs for live flight data and shipped on Vercel. Post-launch WAVE and axe DevTools audit: 0 violations, 10/10 compliance score.
Analyze Results
Accessibility Audit
After building in Cursor and connecting AirLabs API, I audited with macOS and iOS VoiceOver to catch gaps between Figma and implementation.
Keyboard users navigate airport and flight info in logical order. Screen reader users get one complete announcement per flight. Time is stable (minutes accessible, seconds visual). Desktop and mobile stay consistent.
Key Fixes
Headline finding: VoiceOver treated the live clock as time spam, aria-live re-announced every second and drowned out flight announcements. The fix was removing the live region and exposing minute-only time via aria-labelledby.
Time spam:
aria-live on the clock re-announced every second — removed the live region, added a stable minute-only label via aria-labelledby so seconds stay visual-only.
One announcement per flight:
Generic row labels missed context — built flightSrSummary() for a single aria-label per row/card.
Tabs vs. links:
Arrivals/Departures used links, not tabs — converted to semantic tablist/tab/tabpanel, kept shareable URLs.
VoiceOver flow:
Airport header was readable but not tabbable — added tabIndex, composite aria-labelledby, and a skip link for ?iata= URLs.
Considerations and Conclusions
KPIs and Future Features
- WCAG Compliance Score: WAVE audit gives 10/10, and axe DevTools reports 0 issues.
- Task Completion Rate (Keyboard Navigation): 100% of core tasks completable using keyboard/Tab key alone.
- Mobile Accessibility Parity: Same announcement per flight (desktop row = mobile card). Keyboard navigation works on mobile.
Conclusion
My first 0-1 build with Figma, Cursor (MCP), and Notion for research notes. AI accelerated implementation; the real work started when I audited with VoiceOver and fixed what automation couldn't see.
"Technically correct" ≠ semantically correct: Tabs used link elements; tables used divs. Code must match expected behavior.
Device-aware accessibility is overlooked: Mobile needs its own specifications and fixes, desktop audit fixes don't automatically translate.
AI as workflow collaborator, not shortcut: Cursor sped up shipping, but also introduced semantic gaps with link-based tabs, div tables, a clock that spammed VoiceOver. Only human judgment and assistive-tech testing could catch and fix.