Mockups for Candidate Test Plan Review

[isaacdurazo]

Candidate Test Plan Review Process - AT Developer User Journey

Candidate Test Plans Queue

This is the page where an AT Developer begins a Test Plan review process. It has a table listing all Test Plans in the Candidate phase as well as the percentage of passing tests for each AT and Browser combination the Test Plans were run with.

 UI Characteristics and details

• Heading: Comprised of a <h1> with the name of the page. I'm using "Candidate Test Plans" as a placeholder.

• Introduction: Comprised of an <h2> with the word "Introduction" and a <p> with a short description of the page 

• Candidate Tests table: This table has one column for Candidate Test Plans and one column for every AT and Browser combination used.

  • Candidate Test Plans column: the header cell of this column proposes a tabbed navigation, where the AT Developer can switch between Candidates and Recommended Test Plans. These two options are preceded by the number of Test Plans available under each. E.g. "5 Candidates - 3 Recommended". The "active" tab in this header cell is in bold, while the inactive one is in normal text. The Test Plan names in this column are links and next to them there is a label. There are three different labels depending on the step in which the review process is at:

    • Ready for Review: When a Test Plan reaches the Candidate phase, it would automatically be added to this page and a "Ready for Review" label is displayed next to its name

    • X number of open issues: If an AT Developer requests changes for a Test Plan, that request culminates in the creation of a Github Issue. This is also reflected in this label so users can see how many issues there are for a given Candidate Test Plan

    • Ok: once an AT developer approves a Candidate test plan an "Ok" label is displayed next to its name

  • AT and Browser column: there is a column for every AT and Browser combination available. The cell contents of these columns could either be the word "None" if there are no test results, or a progress bar showing the percentage of passing tests for a given Test Plan under a given AT and Browser combination.

---

Single Candidate Test Plan

Once the AT Developer selects a Candidate Test Plan they would land on this page. Here we have a header containing UI elements to display different statuses and actions the user can utilize for reviewing. The main content of this page has a table listing every Assistive Technology used for every Candidate Test Plan and a column for each Browser used for each AT. 

 UI Characteristics and details

• Header: The header in this page is comprised of 4 different elements, breadcrumbs, an <h1>, a row for different "status" indicators and a row for actions. It is important to mention that from this page the user can navigate two more levels deeper in their user flow while reviewing a Test Plan and its Test Results. This Header is persistent on each page. These are the details:

  • Breadcrumbs: similar to the Reports page, at the top of this page we have breadcrumbs to let the user know where they are at and provide another way to navigate. The breadcrumbs in this page would look like this: Candidate Tests > Disclosure Navigation Menu Example

  • Heading: Comprised of a <h1> with the name of the Test Plan, e.g. "Disclosure Navigation Menu Example".

  • Status row: There are 3 different "status" indicators in this row. One for the phase in which the Test Plan is (Candidate in this case), another one for the number of open issues, and lastly one for the kind of review an AT Developer might have left. For the latter, there are 3 different kinds:

    • Approved: When an AT Developer approves a Candidate Test Plan, we display a green checkmark icon followed by the text  [username] Approved this Test Plan.

    • Requested Changes: When an AT Developer requests changes on a Candidate Test Plan, we display a red x icon followed by the text: [username] requested changes.

    • Left Comments: When an AT Developer leaves feedback on a Candidate Test Plan, we display a blue bubble text icon followed by the text: [username] Left comments.

  • Actions: There are four different actions an AT Developer can take from here to complete their review of a Candidate Test Plan

    • Open Test Plan Run: Takes the user to the Test Plan Run page. There they are able to navigate back and forth between tests and experience what a Tester goes through when executing a Test Plan.

    • Design Pattern: Takes the user to the Test Plan's Design Pattern page on the Aria Authoring Practices website.

    • Design Pattern Example: Takes the user to the Test Plan's Design Pattern Example page in the Aria Authoring Practices website.

    • Add your Review: Clicking this opens a Dropdown with three checkboxes to choose from depending on the type of review and text area. The three checkbox options are: Approve, Provide Feedback, and Request Changes. Each of these labels has a short one-line description underneath.

• Introduction: Comprised of an <h2> with the word "Introduction" and a <p> with a short description of the page.

• Assistive Technology table: This table has one column for Assistive Technology and one for every Browser used to test the Candidate Test Plan being reviewed.

  • Assistive Technology column: The Assistive Technologies in this column are links that when clicked, take the user to a report view of that Assistive technology. More detailed information about this is in the following mockup.

  • Browser column: The cell contents of these columns could either be the word "None" if there are no test results or a progress bar showing the percentage of passing tests for a given Browser and AT.

---

Single Assistive Technology with multiple browsers

After selecting an Assistive Technology, the user would land on this page, where they can look at a dedicated results table for each AT, which lists each of the tests within the test plan and a column for required and optional assertions, and unexpected behaviors 

UI Characteristics and details

• Header: The header on this page looks exactly like the one in the previous one with the exception of:

  • Breadcrumbs: Since the user is one level deeper, the breadcrumbs on this page would look like this: Candidate Tests > Disclosure Navigation Menu Example > JAWS

  • Heading: For the same reason, the header on this page would look like this: "Disclosure Navigation Menu Example with JAWS".

• Introduction: Comprised of an <h2> with the word "Introduction" and a <p> with a short description of the page.

• Browser table: For every browser used to test the Test Plan being reviewed, a results table is included. This table is complemented above by a heading and an Actions section.

  • Heading: Comprised of a <h2> with the name of the Browser

  • Actions: There are two actions in this row, "View Complete Results" and "[x number] Tests were skipped".

    • View Complete Results: this takes the user to the deepest level of the report results of a Candidate Test plan, where they have a more detailed view of the results for every single test. More detailed information about this is in the following mockup.

    • [x number] Tests were skipped: takes the user to a table listing all the skipped tests in the deepest level of the report results of a Candidate Test plan. More detailed information about this is in the following mockup.

  • Table: This table has a main column for every test and three for results, which are "Required Assertions", "Optional Assertions" and "Unexpected Behaviors".

    • Test name column: the cells in this column displays the test name, which is a link that when clicked takes the user to a detail view page. More detailed information about this is in the following mockup.

    • Required Assertions: the cells in this column display the number of passing required assertions of the total, e.g. "3 of 3 passed".

    • Optional Assertions: the cells in this column display the number of passing optional assertions of the total, e.g. "3 of 3 passed".

    • Unexpected Behaviors:  the cells in this column display the number of unexpected behaviors, e.g. "2 found".

---

Single Assistive Technology and Browser combination

Lastly in the review process, on this page, the AT Developer can look at a detailed reports table for each Test for a given AT and Browser.

• Header: The header on this page looks exactly like the one in the previous one with the exception of:

  • Breadcrumbs: Since the user is one more level deeper, the breadcrumbs on this page would look like this: Candidate Tests > Disclosure Navigation Menu Example > JAWS > Chrome

  • Heading: For the same reason, the header on this page would look like this: "Disclosure Navigation Menu Example with JAWS and Chrome".

• Introduction: Comprised of an <h2> with the word "Introduction" and a <p> with a short description of the page.

• Single Test table: For every single test within a Test Plan being reviewed, a results table is included. This table is complemented above by a heading and an Actions section.

  • Heading: Comprised of a <h2> with the name of the test, e.g. "Navigate forwards to a collapsed disclosure button in reading mode"

  • Actions: There are four actions in this row, "Open Test", "Raise an Issue about this Test", "Leave Feedback" and "File an AT bug".

    • Open Test: Opens the test the user is looking at on the Test Run page

    • Raise an Issue about this Test: Takes the user to the project repository on Github where they can start from a pre-populated issue based on their selected action

    • Leave Feedback: Takes the user to the project repository on Github where they can start from a pre-populated issue based on their selected action

    • File an AT bug: Takes the user to the appropriate place where they can file a bug for an Assistive Technology.

  • Table: This table has three columns, which are: Command, Support, and Details. This table looks exactly like the one in the reports page.