By Accessible.org · Reviewed
Product reference: Free 1.4.0 / Pro 1.3.2
Someone reporting an accessibility problem has already encountered friction. A useful feedback form lets them explain what blocked their task without first proving technical knowledge or sharing personal details they do not want to provide.
Accessible Forms Free includes a Report an accessibility barrier starter. It requires only the problem description and makes the other questions optional. The guidance below explains how to adapt that starter and the surrounding page, then put a workable response process behind it.
Ask for an experience, not a diagnosis
W3C WAI's reporting guidance identifies useful context: the affected page, what the person was trying to do and the difficulty they encountered. Device or assistive technology details can help an investigation, but an incomplete technical description can still be valuable. Your form can invite those details without making them an entrance requirement.
Keep the introduction welcoming and practical: “Tell us about something that made this website difficult to use. Describe it in your own words.” Avoid requiring a WCAG criterion, browser version or disability category. A report such as “I cannot reach the submit button after increasing the text size” already gives the team a concrete place to start.
Keep the core report small
The starter is a useful baseline, but you should still review its wording and required settings. These are example adaptations, not a request to collect every possible diagnostic detail. Preserve a path for a person who wants to report the problem without receiving a reply.
Example questions to build or adapt
- What were you trying to do? — Message, required
- Help text: “Describe the task and what prevented you from completing it.” One open question can hold both the intended action and the barrier.
- Page address — URL, optional
- Help text: “Paste the page address if you have it. You can also describe the page in your message.” Do not demand a URL from someone unable to retrieve it.
- Browser, device or tools — Text, optional
- Invite information the person already knows. They can leave it blank; your team can investigate the reported behaviour first.
- Email address — Email, optional
- Explain that it is needed only if they would like a reply. Review the starter's separate reply-preference question if you keep it.
Make the reporting route easy to find and use
Link the form from your accessibility statement using a clear label such as “Report an accessibility problem”. WAI recommends providing contact information in an accessibility statement and making the statement easy to find. Put an alternative contact route near the form so someone affected by a problem with the form itself can still reach you.
Treat the reporting page as part of the product you test. Use the keyboard, increase text size and inspect missing-answer errors in the real WordPress theme. Ask someone unfamiliar with the site to find the reporting route from a page with a problem. Check whether they understand what will happen after sending their report.
Give each report an owner
Choose a person or team who checks the inbox and stored entries. Separate the immediate need from the underlying repair: a visitor may need help completing a task while the website issue is being investigated. Capture a brief internal reproduction note, the affected page and the next action in the team's existing work process.
Use confirmation wording that matches this process. For example: “Your report has been received. Our website team will review it. If you provided an email address, we may contact you for more detail.” Do not promise that every issue will be fixed within a particular time unless that is an established commitment.
After a change, repeat the action described in the report and reply when requested. Review report access and retention alongside the rest of your form settings. The starter's privacy defaults are a starting configuration to assess for your organisation, not a substitute for deciding who needs these reports and for how long.
Before you publish
- The problem can be reported without technical terminology or mandatory contact details.
- An alternative contact method is available near the reporting form.
- The reporting page has been tested in the actual theme with keyboard and enlarged text.
- A named team owns review, follow-up and the decision to close each report.
Using Accessible Forms
Begin with the Report an accessibility barrier starter and adapt the questions manually.
In Free: Free includes this starter, optional contact fields, linked error feedback, stored submissions and a manual accessibility test record.
With Pro: Pro can add an optional private screenshot upload. Keep a text-only reporting path usable so an attachment never becomes a barrier to sending feedback.
Sources & further reading
The examples and field plans are suggestions to adapt to your form. These references explain the underlying design and accessibility guidance.
- W3C WAI: Contacting organizations about inaccessible websites
Supports useful diagnostic context while allowing people to share only the details they know.
- W3C WAI: Developing an accessibility statement
Supports clear contact information and a discoverable accessibility statement.