Signup is the single highest-leverage page in a SaaS product's entire funnel. Every other feature, every integration, every pricing tier, is irrelevant to a prospective customer who cannot get an account created in the first place. We ran a direct test on this exact page across 20 SaaS products, spanning project management, CRM, analytics, and communication tools, using only a keyboard: Tab, Shift+Tab, Enter, Space, and arrow keys, no mouse or trackpad at any point. Thirteen of the twenty signup forms could not be completed and submitted using a keyboard alone.
This was not a test of subtle WCAG technicalities. It was a test of the single most basic functional requirement a signup form has: can a person who cannot use a mouse actually create an account. Thirteen out of twenty means that for a meaningful share of SaaS products on the market today, a keyboard-only user, whether due to a motor disability, a temporary injury, or simply a broken trackpad, cannot become a paying customer through the normal signup flow at all, regardless of how accessible the rest of the product might be once inside.
Context for This Test: WCAG Success Criterion 2.1.1 Keyboard, requiring that all functionality be operable through a keyboard interface, is a Level A requirement, the lowest and most foundational conformance level defined in the standard.
Where the Thirteen Broke
The failures grouped into three recurring points in the flow. The most common single blocker was a CAPTCHA or bot-detection widget that could not be operated without a mouse, an image-grid selection challenge or a slider-drag verification with no keyboard-accessible alternative. Several forms embedded a third-party CAPTCHA provider whose accessible audio-challenge option existed technically but was never surfaced or focusable through the actual page's tab order, meaning it was invisible to anyone who did not already know exactly where to look for it in the underlying widget.
The second cluster was custom dropdown and autocomplete components used for company size, industry, or role selection fields. A number of these were built as styled div-based menus rather than native <select> elements or a properly implemented ARIA combobox pattern, and several could be opened with a mouse click but not with Enter or Space, or could be opened by keyboard but had no way to select an option and close the menu without a click. A required field a user cannot fill in blocks the entire submission, regardless of how well everything else on the form was built.
The third cluster was the submit button itself losing focus or becoming unreachable after a validation error. Several forms that otherwise allowed full keyboard completion moved focus unpredictably after an inline error appeared, sometimes back to the top of the page, sometimes nowhere at all, meaning a user who made one small mistake, a malformed email, a password not meeting a length requirement, then had to hunt through the entire form again by tab order to find their way back to the field that needed correcting.
Why This Cluster of Failures Specifically
CAPTCHA and bot-detection widgets are third-party embeds in the overwhelming majority of cases, which means the product team did not necessarily write the inaccessible code directly, but is still responsible for the fact that their chosen vendor's default configuration blocked keyboard users from ever reaching the product at all. This is a useful distinction operationally: fixing this class of failure is often a configuration or vendor-selection problem rather than a from-scratch development problem, which makes it one of the faster wins available once identified.
Custom dropdowns are the more structurally embedded problem. They are usually built in-house, often because a design team wanted a more visually customized look than a native select element allows, and the accessible version of that same visual design, using a properly implemented combobox or listbox ARIA pattern with full keyboard support, is not meaningfully harder to build. It simply was not built that way the first time, and nobody has gone back to test it since.
The Business Cost of a Broken Signup Form Specifically
Every other accessibility failure inside a product affects users after they have already signed up and are, in some sense, already a customer. A broken signup form is different: it is a pure top-of-funnel loss, indistinguishable in analytics from a prospect who simply decided not to buy. A SaaS company with a keyboard-inaccessible signup form has no visibility into how many keyboard-dependent users hit that CAPTCHA, that broken dropdown, that lost focus after an error, and quietly left, because that failure never generates a support ticket. It just generates a silently lower conversion rate that nobody investigates because nothing looks broken to the person checking it with a mouse.
This connects directly to the pattern covered in our piece on why a signup form is blocking blind users at the first field: the earliest point in a funnel is also the point where an accessibility failure is least likely to ever be reported, because the user who hits it never became a customer with a support relationship in the first place.
What to Test First
If your product's signup form has never been tested end-to-end with a keyboard alone, no mouse, that is the single highest-leverage accessibility test available for a SaaS product, ahead of testing deeper in-product screens. The specific checklist: can every field, including any CAPTCHA or verification step, be reached and operated by Tab and Enter alone; does a validation error move focus to something useful rather than somewhere random; and can the final submit action actually be triggered without a click. Our broader 12-point accessible form checklist covers the full pattern in more depth, and a basic version of this exact keyboard-only test is described in our five-minute keyboard test.
Our team can run this exact keyboard-only test against your live signup flow and tell you specifically where it breaks. Reach us at experts@wcag.world, or review WCAG's own keyboard accessibility guidance and the W3C's testing methodology for the standards this test is based on.
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: request the relevant WCAG review.