Update w3c/aria-at Feedback Issues

[howard-e]

#753 includes functionality to support a standard Raise an issue operation throughout the app and is expected to land soon. With this change, the app will expect to show issues from w3c/aria-at/issues once they have included a specific formatted string in the body and included applicable labels.

The following body content (preferably hidden) and labels is expected in the following cases:

• Issue raised against a specific test in a Test Plan:

  • Body includes: <!-- Feedback: "{TEST_NAME}" ({TEST_PLAN_NAME}, Test {NUMBER}, {VERSION_STRING}) -->
  • Expected labels: app, feedback, nvda | jaws | vo (matching to the AT being filed against), candidate-review (if this was raised from the Candidate Review Page)
  • Eg. <!-- Feedback: "Navigate backwards to a menu button" (Action Menu Button Example Using element.focus(), Test 6, V21.10.13) --> in body, with the labels: app, feedback and vo

• Issue raised as general feedback from the Candidate Review Page:

  • Body includes: <!-- {AT_NAME} General Feedback: {TEST_PLAN_NAME} {VERSION_STRING} -->
  • Expected labels: app, feedback, nvda | jaws | vo (matching to the AT being filed against), candidate-review
  • Eg. <!-- JAWS General Feedback: Action Menu Button Example Using aria-activedescendant V22.03.17 --> in body, with the labels: app, feedback, candidate-review and jaws

• Issue raised with changes requested from the Candidate Review Page:

  • Body format: <!-- {AT_NAME} Changes Requested: "{TEST_NAME}" ({TEST_PLAN_NAME}, Test {NUMBER}, {VERSION_STRING}) -->
  • Expected labels: app, changes-requested, nvda | jaws | vo (matching to the AT being filed against), candidate-review
  • Eg. <!-- VoiceOver for macOS Changes Requested: "Read information about a pressed toggle button" (Toggle Button, Test 18, V22.05.18) --> in body, with the labels: app, changes-requested, candidate-review and vo

This intentional body content (preferably hidden) and labeling will now mean that several existing w3c/aria-at feedback issues' titles and labels need to be updated so it can be successfully tracked by the app. More examples of the expected issues can be found here.

[howard-e]

@mcking65 said in #761 (comment):

As discussed in our meeting, I prefer not to update the titles or have dependency on the titles. I'd like the freedom to edit titles for clarity and brevity when working with vendors. As we work with the vendors, I've wanted the titles to be more descriptive of some of the details in the issues.

Let's please go for labels only, or if necessary, tags in hidden comments. . If using hidden comment strings, let's standardize the strings so humans could potentially manipulate them.

[howard-e]

@mcking65 said in #761 (comment):

As discussed in our meeting, I prefer not to update the titles or have dependency on the titles. I'd like the freedom to edit titles for clarity and brevity when working with vendors. As we work with the vendors, I've wanted the titles to be more descriptive of some of the details in the issues.
Let's please go for labels only, or if necessary, tags in hidden comments. . If using hidden comment strings, let's standardize the strings so humans could potentially manipulate them.

Will check this out.

[howard-e]

@mcking65 the application will now search for the previously described strings in the body (along with the applicable labels) in hidden text included in the issues, and the title isn't considered. It is included in the generated template as hidden text when any of the application's Raise an Issue button is used.

Examples:

• https://aria-at-staging.w3.org/data-management/menu-button-actions-active-descendant has an issue title which matches no formats
• https://aria-at-staging.w3.org/data-management/horizontal-slider has a closed issue

This will still require including the known format as hidden content in the existing issues if we'd like the application to find them.

Using labels alone would have made searching using version strings and test numbers difficult for specificity, as they would require the labels to already exist and aren't auto generated.

These functional updates are included as a part of #767

[alflennik]

Hi @mcking65 I recently opened #775 to enhance the hidden comment by using JSON, which is more predictable to both parse and hand edit. Assuming that sounds good to you, I am planning to go through all the previously created issues and add the comment, allowing them to appear in the app. Any concerns before I proceed?

[mcking65]

No concerns; this is an excellent solution!! It will be extremely helpful to have the existing issues linked.

[alflennik]

The issues have been updated and will appear once #775 is merged. Thanks!