Tie in user feedback through accessibility statements

Accessibility statements should be a feedback loop that allows users to identify barriers that they face.

These user-generated issues need to be verified, and often translated into a more technical language so that it can be easily repeated. If a developer can't repeat the problem, they can't fix it.

Ideally the developer would find some work-around the problem and then begin the work of resolving it.

They would also need to triage the problem to understand it's severity, but also to understand what the source of the problem is. If it is for a website, the problem might be at the theme level, modules/plugins, custom code, or the core product. Each of these would require a different set of actions to see that the owners of that code are aware of the problem and resourced to act on it.

These should contain detailed reports and ideally until the problem is resovled it should be part of the ACR.

In https://github.com/GSA/open-product-accessibility-template/issues/94 describe a bit about how linked ACRs could be helpful in tracking these effectively.

All of these should be tied to org commitments to meet accessibility requirements, even if it was a phased approach. We don't have a means to address pledges, but just tying in this effort to align the roadmap here https://github.com/GSA/open-product-accessibility-template/issues/129

No file, test, or entry point is named. Start by reading linked issues 94 and 129, then define how user-reported barriers are verified, translated into reproducible technical reports, triaged, linked to ACRs, and connected to organizational commitments. Done should be a decided workflow with an agreed implementation location and scope.

Written by the indexing model from the issue text.