Challenge 3: A Div That's Both Untestable and Inaccessible — Possible Solution ==================================================================== THE TESTING PROBLEM: a plain
Invalid email
has no ARIA role at all (a generic div has no meaningful role) and is not associated with any form field. This means it can only really be found with getByText("Invalid email") or, worse, getByTestId/querySelector against the "error-message" class — exactly the last-resort/anti-pattern queries this chapter's warn-box flagged. There's no getByRole query that could find it meaningfully, because it doesn't present itself as any recognizable semantic element. THE ACCESSIBILITY PROBLEM: this is the EXACT SAME underlying defect, just described from a different angle. A screen reader user filling out this form would have no way to be automatically notified that an error appeared — a plain div with no role and no association to the input it's describing is functionally invisible to assistive technology, even though a sighted user can see it rendered on screen. This is a real, common accessibility failure, not just a theoretical one. THE FIX THAT SOLVES BOTH AT ONCE: give the error message a proper ARIA role — role="alert" (or the more specific aria-live="polite" / "assertive" region) so it's announced automatically when it appears — AND associate it with the actual input field via aria-describedby pointing at the message's id. Once this change is made, the exact same markup becomes queryable with getByRole("alert") (or similar), AND becomes genuinely perceivable by a screen reader user, exactly illustrating this chapter's tip-box: fixing the accessibility gap and fixing the testability gap are, in this case, literally the same single code change.