How to use the HTML Accessibility Fix Assistant.
Semantic HTML fixes should preserve functionality and be tested in context. Adding ARIA is not a substitute for choosing the correct native element.
Make the workflow fit your task.
Identify the control's real purpose and choose appropriate native semantics, preserving its existing behavior. Add necessary names or state information, then verify keyboard, focus and form interactions in the complete context.
- What you provide
- HTML snippet and specified accessibility issue.
- What you get
- Proposed semantic markup correction with review notes.
See the input and the result.
Illustrative input and output · a teaching example, not a live WebAct run
Example input
Replace <div onclick="submitForm()">Send message</div> in an existing HTML form. The form's submit handler already performs validation and calls submitForm().
Completed example
<button type="submit">Send message</button> The native submit button uses the existing form submission path. Verify Enter/Space interaction, visible focus, validation errors and prevention of duplicate sends. Do not retain a second click handler that also calls submitForm().
Load this input into the prompt, then copy it to WebAct to try the task. Your result may differ from the illustration.
Decisions and troubleshooting.
Can adding an ARIA role alone turn a div into a complete button?
It does not automatically implement keyboard behavior or form semantics. Prefer a native button where that matches the intended control.
Why does replacing a clickable element unexpectedly submit the form?
Check the button type. A control intended for an ordinary action may need type="button" rather than submit behavior.
Try it with your own source.
Replace the example with your material in the task prompt. Keep the requirements you need, then copy the task into WebAct.
Customize and copy the task ↑