Keep the finding specific
Illustrative keyboard users cannot identify which control currently has focus.
Product and software research / Survey guide
Product and software research · Practical field guide
Accessible product use feedback survey
Discover practical barriers in a product task without claiming compliance.
Opens product registration. Example questions are not imported automatically.
FOLLOW THE FEEDBACK
- Understand the context
Which task was difficult to access or complete?
- Investigate the friction
Which control or instruction caused difficulty?
- Choose a next check
How would you prefer to report an access need?
A planning aid, not automated analysis of your answers.
A worked interpretation example
From a comment to a practical next step.
Illustrative scenario. These are not customer results.
Choose an action to test
Investigate focus visibility and verify the relevant task with keyboard navigation.
Check the experience again
After testing the action, revisit this original observation: Illustrative keyboard users cannot identify which control currently has focus. Repeat the relevant experience prompts with people who encountered the change. Compare specific explanations and sample differences; do not claim causation from the before-and-after responses.
Choose the response format
Make room for the explanation.
| Question | Suggested format | What to preserve |
|---|---|---|
| Which task was difficult to access or complete? | Short open text | Let people explain the experience in their own words. Review this answer for: which task was difficult to access or complete. |
| Which control or instruction caused difficulty? | Short open text | Let people explain the experience in their own words. Review this answer for: which control or instruction caused difficulty. |
| What alternative interaction would help? | Short open text | Let people explain the experience in their own words. Review this answer for: what alternative interaction would help. |
| Could you recover when a step did not work? | Short open text | Let people explain the experience in their own words. Review this answer for: could you recover when a step did not work. |
| How would you prefer to report an access need? | Short open text | Let people explain the experience in their own words. Review this answer for: how would you prefer to report an access need. |
Make questions optional where appropriate. If you add a rating scale, label its endpoints, keep one idea per question, and retain a follow-up for reasons. These examples are not a validated measurement instrument.
Read the answers carefully
What the answers cannot tell you.
Feedback is not an accessibility certification or a request for medical details.
Illustrative keyboard users cannot identify which control currently has focus. This is an illustrative interpretation problem rather than a real customer result. Investigate focus visibility and verify the relevant task with keyboard navigation.
A useful starting point
A questionnaire for accessible product use.
Discover practical barriers in a product task without claiming compliance. Choose the questions that fit the experience you are investigating; avoid asking people to evaluate a step they did not encounter.
If nothing was unclear or difficult, say so. Skip questions about steps you did not experience; use not applicable where appropriate.
Which task was difficult to access or complete?
Task context identifies the practical outcome blocked by an access barrier. Preserve the affected step and conditions without asking for diagnoses or treating one response as a compliance assessment.
Which control or instruction caused difficulty?
A specific control or instruction links a barrier to something the team can inspect. Check the interaction independently rather than attributing difficulty to the respondent's abilities.
What alternative interaction would help?
Alternative interactions reveal ways to complete the same task when the current route fails. Evaluate the proposed method with affected users and technical checks; preference alone does not prove accessibility.
Could you recover when a step did not work?
Recovery experiences show whether users remain blocked after a failed interaction. Inspect persistent instructions, focus and available alternatives rather than assuming the first successful route works for everyone.
How would you prefer to report an access need?
Reporting preferences reveal whether the feedback route itself creates an access barrier. Offer an appropriate assisted or alternative channel without requiring respondents to disclose medical information.
If nothing was unclear or difficult, say so. Skip questions about steps you did not experience; use not applicable where appropriate. Which task was difficult to access or complete? Which control or instruction caused difficulty? What alternative interaction would help? Could you recover when a step did not work? How would you prefer to report an access need?
Download the questions as text ↓
Examples to adapt, rather than a validated research instrument.
From question to next step
Make the feedback useful.
Set the decision
Write down the decision you want this questionnaire to support: discover practical barriers in a product task without claiming compliance.
Invite relevant voices
Invite people who experienced the relevant situation. Explain response handling and include an optional skip or not-applicable route. Feedback is not an accessibility certification or a request for medical details.
Choose an action
Investigate focus visibility and verify the relevant task with keyboard navigation.
Before you send it
Check what your wording assumes.
Would you agree that accessible product use feedback was a completely positive experience?
Which task was difficult to access or complete?
The initial wording assumes a positive evaluation. The revised question asks about the actual situation so a respondent can describe difficulty, uncertainty, or a different experience.
Build with SurveyTeams
Build your own accessible product use questionnaire.
Use these examples to draft your questionnaire. Create a survey draft, add questions, and check the respondent preview in SurveyTeams. Additional features depend on your account and plan.
Create your survey in SurveyTeams
Opens product registration. Example questions are not imported automatically.
Learn about the product ↗Before you send it
Questions, answered.
What should I learn from this accessible product use questionnaire?
Discover practical barriers in a product task without claiming compliance. Start with one decision you can act on rather than using the survey to confirm a preferred answer.
How should I interpret answers to “Which control or instruction caused difficulty?”?
Read this answer for the concrete issue behind the response. Feedback is not an accessibility certification or a request for medical details. Compare specific explanations instead of reducing every response to one average.
What would a practical next action look like?
Investigate focus visibility and verify the relevant task with keyboard navigation. This is an example action to investigate, not a guaranteed improvement.
When should I send this questionnaire?
Ask after respondents have experienced the specific situation in the first prompt: “Which task was difficult to access or complete?” Allow enough time after a proposed change for people to experience it before repeating the questionnaire.
What should I check after changing the process?
After testing the action, revisit this original observation: Illustrative keyboard users cannot identify which control currently has focus. Repeat the relevant experience prompts with people who encountered the change. Compare specific explanations and sample differences; do not claim causation from the before-and-after responses.
Can I use these questions in SurveyTeams?
Copy the questions or download TXT, CSV, JSON, or a Markdown worksheet and adapt them in your own survey. The product CTA opens registration and does not import the example. Verify the features and terms available in your account.
Continue exploring