Skip to main content

Submit Feedback to Creators

When accessibility barriers block interaction, users may attempt to notify creators -- developers, designers, organizations -- that something is inaccessible or broken. This compensation shifts the burden to the end-user to identify issues, articulate them clearly, and hope for a response. Feedback can be submitted via email, forms, app stores, GitHub issues, or social media DMs -- any place where creators might listen.

Users resort to this when systems do not work as expected and there is no other recourse for accessing content or functionality. Instead of the system accommodating their needs by design, users must advocate for themselves.

Role in the ENABLE Model​

Post-launch feedback is a last resort after care has failed at every upstream stage. This is a downstream compensation in the ENABLE model. When care is not exercised in requirement-setting, design, development, or testing, the burden of identifying and communicating shortcomings is placed on the user. Post-launch feedback is an act of labor that fills the gap left by upstream neglect.

Why it happens​

When accessible requirements aren't set, inclusive design isn't practiced, and no meaningful testing is done, users are forced to take on the role of informant, advocate, and debugger -- often without compensation or acknowledgement.

Systems expect users to educate creators about their own oversights. Feedback mechanisms often serve as safety nets for organizations -- yet for users with disabilities, they become the only viable pathway to access. With no proactive channels for accessible experiences, the burden and labor shifts to the individual to report failures and request change. That's not a feature; it's a failure.

Examples​

  • Submitting a support ticket because a signup form doesn't work with a screen reader.
  • Filling out the “Report a problem” form after a video lacks captions.
  • Filling out a “Contact Us” form after a screen reader fails to interpret key navigation links.
  • Emailing a product team to ask if their dashboard can be used with a keyboard.
  • Sending an email describing an inaccessible modal on a government website.
  • Writing a GitHub issue describing a missing aria-label on a navigation element.
  • Using the in-app feedback widget to request contrast improvements for low-vision users.
  • Emailing a university IT department because their online class portal doesn't support captioned videos.
  • Recording a video walkthrough to show developers where the tab order fails.

Compensation sounds like​

“I emailed the team asking if there's another way to access the form -- no response yet.”
“I submitted a bug report with screenshots showing the missing labels... I hope someone reads it.”
“I tagged them in a thread and said, ‘This isn't usable with a screen reader.'”
“I DMed the dev team after struggling with their form for 30 minutes.”

Burden sounds like​

“It shouldn't be my job to explain basic accessibility to a billion-dollar company.”
“I keep reporting the same issue every semester. Nothing changes.”
“I don't have the energy to write another feedback email just to use this site.”
“I'm tired of always being the one who has to say something.”
“I don't even know if anyone reads these messages.”

Real-world Scenario​

Amira, a blind screen reader user, found herself unable to select a shipping method during checkout on an independent clothing store's site. Frustrated but persistent, she emailed the support team with a detailed explanation and offered to retest the fix if implemented. The team responded a few days later, thanked her, and pushed a fix live within a week. Not only was the checkout flow made screen reader-accessible, but they also invited Amira to help review other parts of their site. For once, feedback wasn't just a shout into the void -- it became a catalyst for lasting improvement.