User Testing integration

[cskchao]

Is your feature request related to a problem? Please describe.
Equalify does not presently have a way to include the findings compiled from user testing. The reporting/testing process can occasionally feel cumbersome and needlessly labor-intensive for some access technology users.

Describe the solution you'd like
Testers are provided a streamlined and standardized method of logging accessibility issues they experience directly within Equalify by way of a browsers extension. The extension would also assist in gathering context pertaining to the accessibility issue at hand. Testers can suggest steps for remediation.

How does this feature satisfy Equalify project goals?
Including the user experience will result in a more nuanced understanding of product accessibility and help to identify and avoid user-hostile patterns

Describe alternatives you've considered
Existing tools facilitate the process of manual accessibility testing to varying degrees, but none directly integrate with Equalify.

Additional context
Add any other context or screenshots about the feature request here.
Building on issue #535
Questions/considerations:
 How can/should logged issues be treated/represented? Allow for more nuanced usability data to be included which may not yet strictly adhere to the audit format
 Review process for issues, reformatting?
 Clear yet brief messages and alerts, especially those conveying information to screen reader users
 Robust semantic structure and optimal keyboard accessibility
 Customizable keyboard shortcuts to avoid conflicts with screen readers and external apps
 No to screen reader detection
 How might we interface with existing AT in the future to facilitate the secure sharing of information? Scripts/addons for screen readers? This can potentially enhance the testing process and serve to further assist disabled testers.

suggested features:
 Future integration with existing ticketing systems
 A way to isolate and include a code snippet of the currently-focused area/where the a11y issue or blocker resides
 Ability to traverse the a11y tree to ensure inclusion of proper context in the code snippet
 An efficient, accurate and keyboard-driven way to take a screenshot of the problem area
 Ability to easily start and stop screen recording (either internally or through another tool) to document a11y-related behaviors
 Ability to document the AT, browser and platform being used
 Multiple ways of filing issues including the ability to select among a predetermined list of common a11y barriers, and a search field with future support for shorthand syntax for power users
 Field for steps to replicate the problem
 Fields for expected and actual result
 Field for suggested remediation steps
 “Copy last” or “create new with…” feature for recurring issues elsewhere on a page following a common pattern

[bbertucc]

Assigning @heythisischris who will shepherd this to completion.