Incorperate Use Case Items to Design

[bbertucc]

Overview

The current design does not include updates from user testing. I will incorporate them.

Estimate

I estimate this will take 4 hours.

Bountied

Since this is a bountied issue, Assignees should post an estimate that is then approved as per this note in the handbook: https://github.com/EqualifyEverything/handbook?tab=readme-ov-file#how-are-bounties-budgeted

[bbertucc]

@azdak @wilsuriel03 @kevinandrews1 @heythisischris can you approve/deny this bounty estimate? Again, I feel weird doing it myself.

[heythisischris]

@bbertucc Approved from my end. What are the specific updates from user testing? A bit more specificity could help in estimating.

[bbertucc]

@heythisischris I'm incorperating the stuff from our "EQ2 User study." We have five different users so far. Most of this is just looking at their notes and synthesizing that into what I've learnt from my experience and what we laid out in the Version 2 issue here: #373

[bbertucc]

Okay, I just hit my 4 hours and did a lot of work.

Basic updates:

• Focused on Data Types: Every data type (scan, check, page, node, issue, property) has its own details page.
• Scan Presets: Scans presets include multiple checks and settings of when to run the checks against pages. Users can create new scan presets that include different checks and frequency settings and apply those presets to pages.
• Checks: A check is just a set of Regex requirements and a defined issue when those requirements are found when scanning a page. For instance, a check can create a new issue when the word "accessibility statement" is found. Users can create custom checks. They can also decide if a node should be screenshotted when a node meets a check's requirements
• Page: A page is a unique URL that is scanned. As per our updates, a user can now import multiple pages from a sitemap or add a single URL. A log of when then page was checked, with a screenshot of the last check, is available on the page detail. A list of all the nodes, with available screenshots, is also available on the page detail.
• Node: A node is a code snippet that matches the requirements set by a check. A node is related to a page and an issue. Users can choose to ignore the node. A log of when the node was checked and/or ignored is available on every node detail page.
• Issue: An issue is a message that appears related to a check. Multiple nodes can belong to an issue. Users have said they are primarily interested in how many active nodes are related to an issue. An issue detail page will list all the nodes related to that issue, calling attention to the number of active nodes.
• Property: A property is a way to organize multiple pages. Users can create new properties in the Settings screen. They can also add multiple pages to properties under the Pages list and group pages by properties.

Some other updates:

• Overview Page: The overview page includes content that a user is watching plus a weekly summary. The weekly summary just seems cool, but the watch list is a feature folks told me they need. Basically, accessibility pros want to make sure content is fixed and a watch list can do this.
• Navigation Update: Changed the navigation to focus on basic content items (Pages, Issues, Scans & Checks) plus key links (Reports, Support, Settings)

Those lists should cover my updates, but I've also applied changes to my draft here for sighted users: https://www.figma.com/design/KCShUxju664nU3MNanRsqL/Equalify-(09%2F30%2F2024)?node-id=2128-2474&m=dev&t=El6iKsZAc3cq3sbi-1

[bbertucc]

Note: I'm just going to forfeit any payment from this because I think we started out on the wrong foot. Instead of starting from mockups, we should have started from a screen reader spec and system architecture as described in #492.

[bbertucc]

Closing this in favor of #492.