User Testing integration #578

**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