---\ntitle: Error identification\ncheck: error-identification-structural\nnavHidden: true\ncategory: Accessibility\nstandard: WCAG 2.0 A 3.3.1\ncreated: 2026-07-16T02:59:36Z\nupdated: 2026-08-23T19:10:16Z\n---\n\n# Error identification\n\nSilktide examines required form fields that appear to use custom validation\ninstead of the browser's built-in checking, and warns when there is no\napparent way for the error message to reach people using assistive\ntechnology.\n\n## Why this matters\n\nWhen a form rejects an invalid answer, sighted users usually see a red\noutline or a message near the field. A screen reader\nuser gets none of that unless the page exposes the error in code: the form\njust refuses to submit, with no explanation of what went wrong or where. The\nresult is a form that silently locks some visitors out.\n\nBrowsers announce their own built-in validation messages automatically. The\nrisk appears when a page turns that off or replaces it with its own\nvalidation, and forgets to wire the replacement up for assistive technology.\n\n## How to fix it\n\nGive each custom-validated field a programmatic route for its error message,\nusing ARIA:\n\nhtml\n<!-- Problem: custom validation with no accessible error channel -->\n<form novalidate>\n <input type=\"text\" required>\n <span class=\"error\">Enter your name</span>\n</form>\n\n<!-- Fix: the field points at its error message -->\n<form novalidate>\n <input type=\"text\" required aria-describedby=\"name-error\">\n <span id=\"name-error\" class=\"error\">Enter your name</span>\n</form>\n\n\nAny one of these satisfies the check:\n\n1. aria-errormessage on the field, pointing at the element you populate\n with the error text (set aria-invalid=\"true\" when the error shows).\n2. aria-describedby on the field, pointing at the message element.\n3. A live region inside the form - an\n element with role=\"alert\", role=\"status\", or aria-live - that your\n validation writes error text into.\n\nAlternatively, remove the customisation and let the browser's native\nvalidation report errors, which is accessible by default.\n\n## How Silktide tests this\n\n1. Find visible required fields - inputs, text areas, and select menus\n marked required or aria-required=\"true\".\n2. Keep only fields with evidence that native browser validation is bypassed\n or replaced: the form has novalidate, a submit control has\n formnovalidate, the field is marked aria-invalid, it uses\n aria-required without the native required attribute, or the field or\n form carries custom-validation hints (such as error-related attributes or\n error message containers).\n3. For each such field, look for any accessible error channel: a valid\n aria-errormessage reference, a valid aria-describedby reference, or a\n live region within the form.\n4. Warn about fields that have none. This is a warning rather than a\n confirmed failure, because runtime validation behaviour cannot be fully\n observed from the page's code.\n\n## Troubleshooting\n\n### My errors are announced correctly\n\nThe check looks for the structure that makes announcements possible, not the\nannouncement itself. If your framework injects a live region or the ARIA\nreferences only at the moment an error occurs, the loaded page shows no\nchannel and the field is flagged. Adding the (empty) message element and\nreference up front resolves this, and is also more robust.\n\n### The referenced message element does not exist yet\n\nReferences must point at elements that exist in the page. An\naria-describedby pointing at an id that is only created later counts as no\nchannel.\n\n## Learn more\n\n- Understanding Success Criterion 3.3.1: Error Identification (WCAG 2.2)\n- aria-errormessage (MDN)\n- Suggested form corrections\n