Challenge 3: What jest-axe Can't Catch — Possible Solution
====================================================================

it("has no accessibility violations", async () => {
  const { container } = render(<CheckoutForm />);
  const results = await axe(container);
  expect(results).toHaveNoViolations();
});

A REALISTIC PROBLEM THIS TEST WOULD NOT CATCH: imagine CheckoutForm's
fields are all individually well-labeled, have correct ARIA attributes,
and pass every automated contrast/markup check — but the visual TAB
ORDER of the fields (controlled by their position in the DOM or an
unusual tabindex setup) jumps illogically, e.g. from the "Card Number"
field straight to the "Submit" button, skipping over the "Expiry Date"
and "CVV" fields entirely, forcing a keyboard-only user to tab
backwards awkwardly to reach them.

WHY axe IS STRUCTURALLY UNABLE TO DETECT THIS: axe's checks operate by
inspecting the STATIC ACCESSIBILITY TREE and markup — looking for
things like missing labels, invalid roles, insufficient contrast
ratios, and similar rule-based, machine-checkable properties. Whether
a keyboard user can navigate through a form in a SENSIBLE, LOGICAL
ORDER is a matter of actual USER EXPERIENCE during real interaction —
it requires literally tabbing through the interface as a human would
and judging whether the resulting order makes sense, which is not a
property axe's static rule-checking approach is designed to evaluate
at all. This is precisely the category of problem this chapter's
warn-box named — and precisely why web-accessibility1's manual keyboard
navigation testing remains necessary regardless of how clean an
automated jest-axe report looks.