The checker accepts WR-204 and DA-105 under the fictional code format. WR204 exposes a specific associated error, while a corrected code clears the error reference and keeps the help. The Check format button and input-scoped Enter handler work without form submission.
Work through the example
Enter WR204 and select Check format. The input gains aria-invalid true and description references code-help code-error. Change it to WR-204 and check again: the visible status accepts the syntax, aria-invalid becomes false, and only code-help remains associated. Nothing claims that the code identifies an available session.
Keep the format instruction visible below the field. A placeholder disappears during entry and should not carry the only explanation. The error should name the required correction instead of merely saying invalid. Successful syntax does not establish registration. This example checks visible behavior and references; native assistive speech and mobile keyboard behavior require their own testing.
Give the label and description different jobs
The label answers "What is this?" The description answers "What do I need to know to use it?" Label the input Session code and place "Use two uppercase letters, a hyphen, and three digits, such as WR-204" beneath it. Associate the label with for and the instruction with an ID referenced by aria-describedby.
This is a fictional format for the exercise, not a claim about a real registration system. WR-204 and DA-105 match it. wr-204, WR204, and WR-20 do not. A syntactically valid code does not establish that a session exists or has space available.
Leave the format instruction visible. Readers using magnification, unfamiliar with the code, or returning after a correction should be able to find it without reopening a tooltip. Do not move essential information into placeholder text that disappears during entry.
Add the error without losing the instruction
Start the input with aria-describedby="code-help". After an invalid Check format action, reveal a paragraph with ID code-error, set aria-invalid="true", and change the description references to code-help code-error.
Both referenced elements belong in the same document as the input. These values are element IDs separated by spaces, not URLs to a help page. Keep IDs unique, especially if the form later contains more than one code input.
On any input edit, hide and clear the previous error, remove its description reference and retire the invalid state. Refresh the attribute readout and ask for another check; editing alone does not accept the syntax. On a successful check, keep the stale error reference removed and the invalid state cleared. The format help should remain associated. After a reader corrects WR20 to WR-204 and checks again, only the current result should remain associated with the field.
Choose errors that tell the reader what to change
For a blank value, say "Enter a session code." For any nonblank value outside the exercise format, say "Use two uppercase letters, a hyphen, and three digits." Do not silently uppercase or insert characters. Show the person what was accepted and let them correct what was not.
Keep long reference material outside the field description. A paragraph containing links, headings, and a table needs its own navigation structure. A brief plain-text description is a better fit for this attribute than a whole registration manual.
Recreate this example
Build one self-contained responsive HTML example titled “aria-describedby: connect help and current errors” for readers completing the stated task. Return the complete HTML with embedded CSS and JavaScript. Use no remote fonts, libraries, images, requests, account connections, or saved-state claims.
Input Session code associated label and visible code-help: Use two uppercase letters, a hyphen, and three digits, such as WR-204. Start aria-describedby code-help and aria-invalid false. Use a type=button click handler for Check format and input-scoped Enter keydown that ignores isComposing. Empty => Enter a session code; nonblank regex mismatch => exact format error. Invalid reveals code-error, references code-help code-error, aria-invalid true and focuses input. Valid WR-204/DA-105 clears error and references only help, invalid false, syntax accepted status. Never coerce case or insert hyphen, no server/registration. On input edits, hide and clear the error, reference only code-help, set aria-invalid false, update the attribute readout and request another check. Attribute readout supports inspection.
Use a focused session-code checker with persistent format help and a specific associated error design with a compact header. Keep the actual sample data, controls, and useful default result visible early on a 360px-wide screen. Use readable text at least 16px, generous paragraph spacing, strong contrast, semantic labels, visible keyboard focus, and wrapping source blocks. Stack records on narrow screens rather than forcing a wide table.
Wire each action to an explicit type=button click handler using element selectors; the host permits scripts but blocks form submission. Update the visible result when the described action occurs. Show specific error feedback for invalid or missing input and clear stale feedback after dependent inputs change. Use plain text when displaying user values.
A local syntax check and ARIA associations do not verify session existence, registration or actual spoken output. Keep the source fixture and worked teacher or developer example distinct from actual user records. Include the domain-specific explanation and next check beside the result. Provide no fake download, send, deployment, approval, or persistence button. Everything operates locally for the current page session.
Review the prepared copy in NOS
After the invalid-to-valid correction, inspect the current description IDs and test the intended keyboard and speech experience. An HTML explanation in NOS can help a reviewer suggest clearer eligible static help text. Keep session lookup, registration and actual assistive checks outside this syntax-only result.