A financing calculator is one of the most consequential interactive tools on a car dealership's website. It is often the moment a shopper decides whether a vehicle is actually within reach, adjusting down payment, loan term, and trade-in value to see a monthly payment estimate before ever speaking to a salesperson. We tested this exact tool across 30 dealership websites, spanning independent lots and franchise dealer groups, using a keyboard only. Not one of the thirty could be fully operated without a mouse.
The specific point of failure was consistent across every single site: the down payment, loan term, and trade-in value inputs were built as draggable slider controls, and every one of the thirty sliders could be reached by keyboard Tab but could not be adjusted using arrow keys once focused. A sighted mouse user drags the slider handle to a value in about a second. A keyboard-only user can Tab directly to the exact same control, sees it receive a visible focus outline, presses the arrow key that would move any properly built slider, and nothing happens. The control looks reachable and interactive. It simply does not respond to the only input method available to that user.
Context for This Pattern: A native HTML
<input type="range">element receives full keyboard support, arrow keys, Page Up and Page Down, Home and End, automatically from the browser with no additional code required. Every calculator in this test was instead built from a custom div-based slider that reimplemented the visual behavior without reimplementing this default keyboard support.
Why This Failure Is Especially Costly
A financing calculator differs from most inaccessible widgets in one important way: it usually does not block a purchase directly, since the actual purchase or loan application typically happens through a separate flow or in person. What it blocks is information a shopper needs before deciding whether to engage at all. A keyboard-only user who cannot adjust the calculator's inputs cannot see how a larger down payment or a different loan term changes their estimated monthly payment, meaning they either have to guess, call the dealership directly to ask, or abandon the site having formed an inaccurate impression of what they can afford. Every one of those outcomes puts a keyboard-dependent shopper at a real disadvantage compared to a mouse user working through the same decision independently.
The Fix Does Not Require Custom Slider Code at All
The most direct fix for every one of these thirty implementations would have been to not build a custom slider in the first place. A native <input type="range"> element supports full keyboard interaction automatically, arrow keys to adjust by a step, Home and End to jump to the minimum or maximum, with zero additional JavaScript required for that behavior, and it can be styled visually to match nearly any design system's slider appearance using standard CSS. The custom div-based sliders used across all thirty sites in this test were, in every case reviewed, solving a problem, custom visual styling, that a native range input combined with CSS could have solved without sacrificing keyboard access at all.
For teams that have already built a custom slider and cannot easily swap to a native input, the correct accessible pattern requires the control to have role="slider", aria-valuemin, aria-valuemax, and aria-valuenow set and kept in sync with the visual position, and, critically, actual keydown event handlers that respond to arrow keys, Home, End, Page Up, and Page Down by updating that value. Adding the ARIA attributes alone, without the keydown handlers, produces a control that announces its current value correctly to a screen reader but still cannot be operated by keyboard, a distinct but related failure to the one found on every site in this test.
A Broader Pattern in Dealer Website Platforms
The consistency of this exact failure across 30 different dealerships is notable, and it points to a platform-level explanation rather than 30 independent mistakes. Automotive dealer websites overwhelmingly run on a small number of shared dealer website platforms and third-party financing calculator widgets licensed across the industry, rather than fully custom-built sites per dealership. A keyboard-inaccessible slider baked into one of these shared widgets would explain why the exact same failure, not just a similar one, showed up across sites with otherwise completely different branding and layout. This is a useful diagnostic detail for any dealership group evaluating vendors: the fix, in many cases, needs to happen at the platform or widget vendor level, not by asking each individual dealership's marketing team to rebuild their own calculator from scratch.
What to Test First
If your dealership or dealer group licenses a financing calculator widget from a third-party vendor, Tab to each input in that calculator and try adjusting it with arrow keys alone before assuming it works. This is a fast, five-minute test that directly mirrors the broader five-minute keyboard test we recommend as a first pass for any interactive tool, and it is exactly the kind of test that a purely automated accessibility scanner is unlikely to catch, since the slider's ARIA markup can look correct in isolation while the actual keyboard behavior is completely broken.
If you operate a dealership website or manage a dealer platform vendor relationship, our team can test your actual financing calculator and tell you whether the problem sits in your site's code or in a licensed widget. Reach us at experts@wcag.world, or review WCAG's keyboard accessibility guidance and ADA.gov's web guidance for the standards this test is measured against.
A practical review loop
Start with the task a person needs to complete, not with the score produced by a single automated scan. Write down the entry point, the expected focus order, the announcement a screen reader should receive, and the recovery path when something goes wrong. Then repeat that task with a keyboard and at least one assistive technology setup. This turns a vague accessibility concern into an observable acceptance test.
The useful evidence is specific. Capture the URL, the control label, the keystrokes, the browser state, and the expected result. Separate a defect from a design choice, and separate both from a limitation in the test environment. Give the product owner a short reproduction and a clear severity rationale. A developer can fix a named interaction. Nobody can reliably fix a general instruction to make a page more accessible.
Finally, put the check into the delivery process. Add the scenario to a pull request checklist, retest it after JavaScript changes, and keep a small set of representative pages available for regression testing. That routine protects the people who depend on the workflow and gives the team a defensible record of what was tested, when it was tested, and what happened.
For the next review, use these related resources: accessible form 12 point checklist devs skip.
For the next review, use these related resources: request the relevant WCAG review.