Accessibility — WheelsUp

Conformance status

In plain terms: partially conformant with WCAG 2.1 Level AA. Most of it we have measured; some of it we have not, and we would rather say so than imply otherwise.

WheelsUp is partially conformant with WCAG 2.1 Level AA. "Partially conformant" means most of the standard is met, but not all of it has been verified.

We are not claiming full conformance, for one honest reason above all others: we have not tested WheelsUp with a screen reader. Automated measurement and keyboard testing can show that a name exists; they cannot show that it reads sensibly. Until we have done that testing, a full conformance claim would be a claim about work we have not done.

This statement covers militarywheelsup.com (the marketing site, guides and legal pages) and app.militarywheelsup.com (the planner).

What we measured

In plain terms: real numbers, from the running site, on a stated date.

An accessibility audit on 2026-08-04 produced ten findings. All ten have been addressed, and a second measurement pass the same day re-checked them and went looking for what the first pass missed. Specifically:

Colour contrast. 2,632 text-and-background pairs measured across 18 pages, with every colour resolved from what the browser actually paints — including text sitting on gradients and see-through panels, where the effective background was computed layer by layer rather than guessed at. Text now meets the 4.5:1 minimum (3:1 for large text) everywhere we measured.
Keyboard. Every interactive control is reachable and operable by keyboard. We tabbed through the site with a real keyboard rather than simulating it in script — 25 presses, 25 different destinations, nothing trapped.
Reflow and zoom. No horizontal scrolling at 320 px, or at the equivalent of 200% browser zoom.
Text spacing. Applying the standard's own spacing overrides (line height, letter, word and paragraph spacing) clips or overlaps nothing.
Structure. Every page has one <h1>, no skipped heading levels, a <main> landmark, named navigation regions, and a "skip to main content" link as the first thing you reach.
Status messages. The planner's calculators announce their result when it changes, so a screen-reader user is told the numbers they asked for have arrived.
Moving content. The scrolling list of tools on the home page has a pause button, stops entirely if your system asks for reduced motion, and pauses on hover.
Images and graphics. Every image has alternative text. The transition timeline — which is drawn as a chart — also publishes every event, with its full name and real dates, as a table for screen readers.

What we have not tested

In plain terms: the honest gaps. We would rather you know these than discover them.

Assistive technology. Nothing has been tested with NVDA, JAWS, VoiceOver, Dragon, or a switch device. This is the largest gap on this page and the main reason our claim is partial.
Independent audit. No third-party accessibility audit has been carried out. Everything here is our own measurement.
Users with disabilities. We have not run usability testing with disabled users. Conformance is a floor, not a substitute for that.
Cognitive and low-vision testing beyond the mechanical checks described above.

Not applicable: WheelsUp contains no audio or video, so the captions and audio-description criteria (WCAG 1.2.x) do not apply.

Known gaps

In plain terms: what we know is imperfect right now.

Screen-reader wording is unverified. Controls, the timeline table and the calculator announcements have programmatic names, but we have not heard them read aloud. Some will be clumsier than they should be.
Contrast on layered backgrounds is computed, not sampled. Where text sits on a gradient we tested against the worst-case point of that gradient. This is a conservative method, but it is arithmetic rather than a photograph of the screen.
PDF and CSV exports have not been assessed for accessibility.
Third-party components. Sign-in uses Cloudflare Turnstile and payments use Stripe Checkout; those interfaces are theirs, and we have not audited them.

If you rely on any of these and hit a wall, please contact us — a specific report from a real user moves an item up this list faster than anything else.

What should work

In plain terms: what to expect if you use WheelsUp with a keyboard, zoom, or a screen reader.

You can reach every control with Tab, and the focused item is always visibly outlined.
A "skip to main content" link is the first thing you reach on every page, so you don't have to tab through the navigation on every view.
You can zoom to 200%, or use a 320 px-wide screen, without the page scrolling sideways.
Sign-in, onboarding and the calculators report errors in text, mark the specific field that needs fixing, and move focus to it.
When a dialog opens, the rest of the page is taken out of the tab order until you finish or close it.
If your system asks for reduced motion, animations stop.
The site follows your operating system's light or dark preference.

Tell us about a barrier

In plain terms: if something blocks you, tell us and we will fix it.

We want to hear about it — especially the things this page does not list. Our user base is, by definition, more likely than most to include people with disabilities: we ask you for your VA rating.

Contact us about an accessibility barrier, and please include the page you were on, what you were trying to do, and the browser and any assistive technology you were using.

We aim to respond within five business days. WheelsUp is run by one person, so a fix may take longer than a reply — we will tell you which it is and when to expect the other.

How we test

In plain terms: so you can check our work.

Assessment was carried out by the WheelsUp team (self-assessment) on 2026-08-04, using three deliberately different methods, because each one is blind to something the others catch:

Source inspection across the 31 marketing pages published at that date, and the planner, for the failures that are decidable from markup — missing alternative text, unlabelled controls, heading order, language attributes.
Live measurement in a browser for anything that depends on rendering: contrast against the actually-painted background, layout at 320 px and at 200% zoom, text-spacing overrides, landmark structure.
Real keyboard input for everything focus-related. We learned this the hard way: focus behaviour driven by script does not always match what happens when a person presses a key, and testing it the wrong way produced a confidently wrong result in both directions before we caught it.

The checks are pinned by automated tests that run before every release, so the things we fixed cannot quietly regress.

Those tests run against every page we publish, not only the ones that pass measured. The marketing surface has grown from 31 pages to 36 pages since 2026-08-04. On 2026-08-15 we re-ran the second and third methods above — live measurement in a browser, and real keyboard input — across all 34, so no page here is published on assurance inherited from a page that was measured instead of it. That re-run was 11,690 text-and-background pairs measured in both light and dark, none of them failing, and 1,505 real Tab presses: every page tabbed from top to bottom by a browser receiving actual key events, not a script calling focus(), because the two do not behave the same and only one of them is what a person experiences.

That re-run found something, and it is worth naming rather than quietly fixing. Our contact dialog told assistive technology it was modal while leaving the page behind it in the tab order — so a screen-reader user had the rest of the page correctly hidden, and a keyboard user could press Tab three times and end up on a link underneath the dialog they thought they were in. It is fixed, and the test that is supposed to hold us to the sentence above now checks every dialog we ship, on the site and in the planner, instead of the one place the fix already happened to be.

Standard applied: Web Content Accessibility Guidelines 2.1, Level AA.