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

Navigator-side 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. Navigator-side 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

In the news

YouTube Allows Viewer-Suggested Corrections to Auto-Generated Captions (March 2024)
-- Logie.ai

• YouTube launched a feature allowing viewers to submit feedback by suggesting corrections to auto-generated captions. While this crowdsources caption improvement, it also shifts labor to users -- particularly deaf and hard-of-hearing viewers who must first struggle through inaccurate captions, then spend additional time reporting errors that builder-side content teams should have caught.

Charles Schwab Web Accessibility Settlement via Structured Negotiation (November 2024)
-- Law Office of Lainey Feingold

• Four blind clients of Charles Schwab worked with disability rights attorney Lainey Feingold to reach a settlement improving website and mobile app accessibility without filing a lawsuit. Structured negotiation -- triggered by client feedback -- resulted in Schwab committing to WCAG 2.2 Level AA compliance. This case shows how persistent, documented feedback can lead to meaningful change, though the burden of initiating that process fell entirely on affected users.

EU Web Accessibility Directive Requires Feedback Mechanisms (Ongoing)
-- Tiny.cloud

• The EU Web Accessibility Directive requires public websites to publish accessibility statements with contact methods for users to report issues, plus an escalation process if responses are unsatisfactory. This legal protection ensures that when users submit feedback, there's a mandated pathway for response -- shifting some accountability back to builders who might otherwise ignore accessibility reports.

• 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.