Testing

Note

Testing requires the Testing module to be enabled. Go to Settings → Features to turn it on. The module depends on Products and Issues.

A test activity is one occurrence of evaluative work on a product: an automated scan, a manual test, a usability test, or a user-research study. It’s a lightweight sibling of an audit — audits stay the formal, long-lived engagement, while test activities capture everything else that checks a product’s accessibility.

The Testing feed lists test activities together with audits in one chronological stream, per product and across the whole organization, so all testing work shows up in one place. Audits only appear in the feed when the Audits module is also enabled.

Activity types

Type	Counts toward Grade Evidence as
Automated scan	Automated scans
Manual test	Manual audits
Usability test	User testing or reports
User research	Feedback

Logging an activity — even one that finds nothing — counts as that type of evidence on the product’s Accessibility grade.

Logging a test activity

Any member can log a test activity.

1. Open a product and go to its Testing tab.

2. Click New.

3. Fill in the details:

   Field	Description
   Type	Automated scan, Manual test, Usability test, or User research.
   Title	Optional. Defaults to a generated title such as “Automated scan of My Product”.
   Tool	Optional free text naming what produced it, e.g. axe, Lighthouse, manual.
   Target	Optional: URL(s) or scope tested.
   Areas	Optional: scope the activity to one or more areas. You can create a new area here without leaving the dialog.

4. Click Log activity. The activity is recorded with a completion time of now.

Caution

Test activities cannot be logged for archived products.

The Testing feed

Each row shows the product (organization-level feed only), a title, its type or “Audit”, when it occurred, and a Discovered count: issues for both kinds of entry, plus feedback items for test activities. Automated scans raise findings rather than issues, so their discovered count reflects what a person has since promoted. Test activities and audits are merged and sorted by date, and the list is paginated.

An activity reported from CI also shows the run it came from, under its title: the pull request or branch it evaluated, the environment it ran against when the tool named one, and a link to the run itself. Activities logged by hand show nothing there.

Filter the feed by Trigger (what started the run) and Environment (where it ran). They answer different questions, and only the environment tells you whether an activity described your live product — a scheduled run and a manual one can each point at a preview or at production. Pull request previews are grouped into one Pull request preview option rather than listed per pull request.

Deleting a test activity

Only admins and owners can delete a test activity.

Ingest API: connecting external tools

Manual logging covers ad hoc checks, but most automated scans come from external tools — CI pipelines, scanners, or a GitHub accessibility scanner run. The ingest API lets any tool that can make an HTTP request report its own results directly, without a person logging them by hand.

Creating a key

Organization admins and owners manage API keys from Settings → API keys.

1. Go to Settings → API keys.
2. Click New key.
3. Give it a name and select the Ingest scope. Optionally limit it to a single product (the default is all products).
4. Click Create key. The secret is shown once — copy it now. It can’t be retrieved again.

A key acts as the member who created it, so it stops working if that person leaves the organization. Create keys for shared automation from an account that’s staying.

Revoke a key from the same page at any time. Revoking stops it from authenticating further requests but doesn’t touch activity already ingested.

Sending a report

A tool posts a normalized report to:

POST /api/ingest/test-activity
Authorization: Bearer <API key with the ingest scope>

Settings → API keys in Ablebase includes a ready-to-use curl snippet for this, filled in with your organization’s ID. Each finding from an automated scan becomes an Ablebase finding linked back to the activity, waiting in a triage queue until someone promotes it to an issue or rules it out. Reposting the same idempotencyKey for a product returns the existing activity instead of creating a duplicate, which is useful for retried CI jobs.

curl -X POST https://<your-domain>/api/ingest/test-activity \
  -H "Authorization: Bearer $ABLEBASE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "productRef": "your-product-slug",
    "type": "automated_scan",
    "tool": "github-accessibility-scanner",
    "idempotencyKey": "run-12345",
    "coverage": "partial",
    "findings": [
      {
        "title": "Image missing alt text",
        "ruleId": "image-alt",
        "selector": "img.logo",
        "severity": "high",
        "wcag": ["1.1.1"],
        "sourceUrl": "https://example.com/"
      }
    ]
  }'

Note

productRef is only required when the key isn’t already scoped to a single product. tool and ruleId are required for automated scans, because together with selector they identify a finding across runs. See Ingest API for the full request schema.

Recording where a scan ran

Add a context object so a scan of a pull request preview isn’t mistaken for a scan of your live product:

{
  "productRef": "your-product-slug",
  "type": "automated_scan",
  "context": {
    "trigger": "schedule",
    "ref": "main",
    "commitSha": "0c4de91aa7712b35",
    "environment": "production",
    "runNumber": 1249
  },
  "findings": []
}

Tools built on the Ablebase connector SDK fill in the trigger, branch, commit, pull request, and run number when they run in GitHub Actions, the one CI system it reads so far. Elsewhere, send context yourself — a report that already carries one is never overwritten.

environment is never inferred, on any CI. It says where the scan ran, and a job that starts its own server to scan describes no deployment at all. Set ABLEBASE_ENVIRONMENT when a job scans a real one.