Error identification

Silktide examines required form fields that appear to use custom validation instead of the browser's built-in checking, and warns when there is no apparent way for the error message to reach people using assistive technology.

Why this matters

When a form rejects an invalid answer, sighted users usually see a red outline or a message near the field. A user gets none of that unless the page exposes the error in code: the form just refuses to submit, with no explanation of what went wrong or where. The result is a form that silently locks some visitors out.

Browsers announce their own built-in validation messages automatically. The risk appears when a page turns that off or replaces it with its own validation, and forgets to wire the replacement up for .

How to fix it

Give each custom-validated field a programmatic route for its error message, using :

<!-- Problem: custom validation with no accessible error channel -->
<form novalidate>
  <input type="text" required>
  <span class="error">Enter your name</span>
</form>

<!-- Fix: the field points at its error message -->
<form novalidate>
  <input type="text" required aria-describedby="name-error">
  <span id="name-error" class="error">Enter your name</span>
</form>

Any one of these satisfies the check:

aria-errormessage on the field, pointing at the element you populate with the error text (set aria-invalid="true" when the error shows).
aria-describedby on the field, pointing at the message element.
A inside the form - an element with role="alert", role="status", or aria-live - that your validation writes error text into.

Alternatively, remove the customization and let the browser's native validation report errors, which is accessible by default.

How Silktide tests this

Find visible required fields - inputs, text areas, and select menus marked required or aria-required="true".
Keep only fields with evidence that native browser validation is bypassed or replaced: the form has novalidate, a submit control has formnovalidate, the field is marked aria-invalid, it uses aria-required without the native required attribute, or the field or form carries custom-validation hints (such as error-related attributes or error message containers).
For each such field, look for any accessible error channel: a valid aria-errormessage reference, a valid aria-describedby reference, or a live region within the form.
Warn about fields that have none. This is a warning rather than a confirmed failure, because runtime validation behavior cannot be fully observed from the page's code.

Troubleshooting

My errors are announced correctly

The check looks for the structure that makes announcements possible, not the announcement itself. If your framework injects a live region or the ARIA references only at the moment an error occurs, the loaded page shows no channel and the field is flagged. Adding the (empty) message element and reference up front resolves this, and is also more robust.

The referenced message element does not exist yet

References must point at elements that exist in the page. An aria-describedby pointing at an id that is only created later counts as no channel.