testaro 60.4.0 → 60.5.0

package/AGENTS.md

@@ -1,11 +1,7 @@
-/*
-  © 2025 Jonathan Robert Pool. All rights reserved.
-  Licensed under the MIT License. See LICENSE file for details.
-*/
-
 # Testaro Agent Guidelines
 
 ## Commands
+
 - **Run all tests**: `npm run tests`
 - **Run single test**: `npm test <testname>` (e.g., `npm test hover`)
 - **Run job**: `npm run run [jobID]`
@@ -14,6 +10,7 @@
 - **Lint**: `npx eslint <file>` (follows `.eslintrc.json`)
 
 ## Architecture
+
 - **Main dirs**: `/tests` (tool test definitions), `/procs` (shared procedures), `/validation` (test validators), root (core modules)
 - **Key files**: `run.js` (main executor), `actSpecs.js` (act specifications), `call.js` (CLI entry), `tests/testaro.js` (Testaro tool rules)
 - **Tools**: Integrates 11 a11y tools (Axe, Alfa, IBM Checker, QualWeb, ASLint, WAVE, WallyAX, Ed11y, HTML CodeSniffer, Nu Validator, Testaro)
@@ -21,8 +18,14 @@
 - **Env vars**: Required for WallyAX (`WAX_KEY`), WAVE (`WAVE_KEY`); optional `DEBUG`, `WAITS`, `JOBDIR`, `REPORTDIR`, `AGENT`
 
 ## Code Style
+
 - **ESLint**: 2-space indent, single quotes, semicolons required, Stroustrup brace style, no use-before-define
 - **Imports**: CommonJS (`require`/`module.exports`), not ES modules
 - **Naming**: camelCase for vars/functions, descriptive names, rule IDs in lowercase
 - **Error handling**: Try-catch blocks, report failures via `prevented: true` in results
 - **Comments**: Explain complex logic, but keep concise
+
+## License
+
+© 2025 Jonathan Robert Pool. All rights reserved.
+Licensed under the MIT License. See LICENSE file for details.

package/README.md

@@ -7,10 +7,12 @@ Ensemble testing for web accessibility
 Testaro is an application for automated web accessibility testing.
 
 The purposes of Testaro are to:
+
 - provide programmatic access to accessibility tests defined by several tools
 - facilitate the integration of the reports of the tools into a unified report
 
 Testaro is described in two papers:
+
 - [How to run a thousand accessibility tests](https://medium.com/cvs-health-tech-blog/how-to-run-a-thousand-accessibility-tests-63692ad120c3)
 - [Testaro: Efficient Ensemble Testing for Web Accessibility](https://arxiv.org/abs/2309.10167)
 
@@ -23,6 +25,7 @@ Testaro can be installed under a MacOS, Windows, Debian, or Ubuntu operating sys
 Testaro accepts _jobs_, performs them, and returns _reports_.
 
 Other software, located on the same or a different host, can make use of Testaro, performing functions such as:
+
 - Job preparation
 - Converting user specifications into jobs
 - Job scheduling
@@ -41,12 +44,14 @@ One software product that performs some such functions is [Testilo](https://www.
 ## Dependencies
 
 Testaro uses:
+
 - [Playwright](https://playwright.dev/) to launch browsers, perform user actions in them, and perform tests
 - [playwright-extra](https://www.npmjs.com/package/playwright-extra) and [puppeteer-extra-plugin-stealth](https://www.npmjs.com/package/puppeteer-extra-plugin-stealth) to make a Playwright-controlled browser more indistinguishable from a human-operated browser and thus make their requests more likely to succeed
 - [playwright-dompath](https://www.npmjs.com/package/playwright-dompath) to retrieve XPaths of elements
 - [pixelmatch](https://www.npmjs.com/package/pixelmatch) to measure motion
 
 Testaro performs tests of these _tools_:
+
 - [Accessibility Checker](https://www.npmjs.com/package/accessibility-checker) (IBM)
 - [Alfa](https://alfa.siteimprove.com/) (Siteimprove)
 - [ASLint](https://www.npmjs.com/package/@essentialaccessibility/aslint) (eSSENTIAL Accessibility)
@@ -65,7 +70,7 @@ Some of the tests of Testaro are designed to act as approximate alternatives to
 
 Each tool accessed with Testaro defines _rules_ and tests _targets_ for compliance with its rules. Testilo has classified the rules into _issues_ and deprecated some rules as poorly implemented. If the deprecated rules are excluded, the counts are:
 
-```
+```text
 Accessibility Checker: 93
 Alfa: 64
 ASLint: 129
@@ -85,6 +90,7 @@ This tabulation may not be exact, because some of the tools are under active dev
 ## Code organization
 
 The main directories containing code files are:
+
 - package root: main code files
 - `tests`: files containing the code defining particular tests
 - `procs`: shared procedures
@@ -134,9 +140,9 @@ All of the tests that Testaro can perform are free of cost, except those perform
 
 ## Jobs
 
-A _job_ is an object that specifies what Testaro is to do. As Testaro performs a job, Testaro reports results by adding data to the job.
+A _job_ is an object that specifies what Testaro is to do. As Testaro performs a job, Testaro reports results by adding data to the job and making that enhanced object available as a _report_.
 
-### Example
+### Example of a job
 
 Here is an example of a job:
 
@@ -201,6 +207,7 @@ This job tells Testaro to perform two _acts_. One performs one test of the Axe t
 Each act includes a `launch` property with a default value. That instructs Testaro, before performing those tests, to launch a new Webkit browser, open a context (window) with some properties of an iPhone 8 and without a reduced-motion setting, create a page (tab), and navigate to a particular page of the `abccorp.com` website.
 
 Job properties:
+
 - `id`: a string uniquely identifying the job.
 - `what`: a description of the job.
 - `strict`: `true` or `false`, indicating whether _substantive redirections_ should be treated as failures. These are redirections that do more than add or subtract a final slash.
@@ -216,13 +223,16 @@ Job properties:
 
 ## Acts
 
-### Introduction
+As shown above, `acts` is a property of a job and has an array value. Each item in the array is an object that specifies an _act_.
+
+### Introduction to acts
 
 Each act object has a `type` property and optionally has a `name` property (used in branching, described below). It must or may have other properties, depending on the value of `type`.
 
 ### Act types
 
 The acts can tell Testaro to perform any of:
+
 - _navigations_ (browser launches, visits to URLs, waits for page conditions, etc.)
 - _moves_ (clicks, text inputs, hovers, etc.)
 - _alterations_ (changes to the page)
@@ -294,9 +304,9 @@ This act checks the result of the previous act to determine whether its `result.
 
 A `next` act can use a `next` property instead of a `jump` property. The value of the `next` property is an act name. It tells Testaro to continue performing acts starting with the act having that value as the value of its `name` property.
 
-#### Tests
+#### Tools
 
-##### Introduction
+##### Introduction to tools
 
 An act of type `test` performs the tests of a tool and reports a result. The result may indicate that a page passes or fails requirements. Typically, accessibility tests report successes and failures. But a test in Testaro is defined less restrictively, so it can report any result. As one example, the Testaro `elements` test reports facts about certain elements on a page, without asserting that those facts are successes or failures.
 
@@ -305,6 +315,7 @@ The `which` property of a `test` act identifies a tool, such as `alfa` or `testa
 ##### Configuration
 
 Every tool invoked by Testaro must have:
+
 - a property in the `tests` object defined in the `run.js` file, where the property name is the ID representing the tool and the value is the name of the tool
 - a `.js` file, defining the operation of the tool, in the `tests` directory, whose name base is the name of the tool
 
@@ -330,7 +341,7 @@ When you include a `rules` property, you limit the tests of the tool that are pe
 
 The `nuVal`, `qualWeb`, and `testaro` tools require specific formats for the `rules` property. Those formats are described below in the sections about those tools.
 
-##### Examples
+##### Examples of test acts
 
 An example of a `test` act is:
 
@@ -393,6 +404,7 @@ The first item in each array is an identifier of a property of the act. The item
 If there is only 1 item in an array, it states the expectation that the specified property does not exist. Otherwise, there are 3 items in the array.
 
 The second item in each array, if there are 3 items, is an operator, drawn from:
+
 - `<`: less than
 - `=`: equal to
 - `>`: greater than
@@ -404,9 +416,7 @@ The third item in each array, if there are 3 items in the array, is the criterio
 
 A typical use for an `expect` property is checking the correctness of a Testaro test. Thus, the validation jobs in the `validation/tests/jobs` directory all contain `test` acts with `expect` properties. See the “Validation” section below.
 
-When a `test` act has an `expect` property, the result for that act has an `expectations` property reporting whether the expectations were satisfied. The value of `expectations` is an array of objects, one object per expectation. Each object includes a `property` property identifying the expectation, and a `passed` property with `true` or `false` value reporting whether the expectation was satisfied. If applicable, it also has other properties identifying what was expected and what was actually reported.
-
-### Tools
+### Tool details
 
 The tools whose tests Testaro performs have particularities described below.
 
@@ -467,7 +477,7 @@ In `node_modules/accessibility-checker/lib/reporters/ACReporterJSON.js`, add the
 results.label = results.label.replace(/:/g, '-');
 ```
 
-These changes were proposed as pull requests 1333 and 1334 (https://github.com/IBMa/equal-access/pulls).
+These changes were proposed as [pull requests 1333 and 1334](https://github.com/IBMa/equal-access/pulls).
 
 The `ibm` tool is one of two tools (`testaro` is the other) with a `withItems` property. If you set `withItems` to `false`, the result includes the counts of “violations” and “recommendations”, but no information about the rules that gave rise to them.
 
@@ -490,6 +500,7 @@ QualWeb allows specification of rules for 3 modules: `act-rules`, `wcag-techniqu
 ```
 
 In that format:
+
 - Replace `mod` with `act`, `wcag`, or `best`.
 - Replace `m`, `n`, `o`, `p`, etc. with the 0 or more integers that identify rules.
 
@@ -505,23 +516,23 @@ The target can be provided to QualWeb either as an existing page or as a URL. Ex
 
 #### Testaro
 
-If you do not specify rules when using the `testaro` tool, Testaro will test for the rules listed in the `evalRules` object of the `tests/testaro.js` file.
+The rules that Testaro can test for are implemented in files within the `testaro` directory.
 
-The `rules` argument for a `testaro` test act is an array whose first item is either `'y'` or `'n'` and whose remaining items are rule IDs. If `'y'`, then only the specified rules’ tests are performed. If `'n'`, then all the evaluative tests are performed, **except** for the specified rules.
+If you do not specify rules when using the `testaro` tool, Testaro will test for its default rules, namely the rules that have `true` values on the `defaultOn` property in the `allRules` array defined in the `tests/testaro.js` file. It will test for these rules in the order in which they appear in the array.
+
+The optional `rules` argument for a `testaro` test act is an array whose first item is either `'y'` or `'n'` and whose remaining items are rule IDs. If `'y'`, then only the specified rules’ tests are performed. If `'n'`, then all the default rules are tested for, **except** for the specified rules.
 
 The `testaro` tool (like the `ibm` tool) has a `withItems` property. If you set it to `false`, the `standardResult` object will contain an `instances` property with summaries that identify issues and instance counts. If you set it to `true`, some of the instances will be itemized.
 
 Unlike any other tool, the `testaro` tool requires a `stopOnFail` property, which specifies whether a failure to conform to any rule (i.e. any value of `totals` other than `[0, 0, 0, 0]`) should terminate the execution of tests for the remaining rules.
 
-Warnings in the `testaro/hover.js`, `testaro/motion.js`, and `procs/visChange.js` files advise you to avoid launching particular browser types for the performance of particular Testaro tests.
-
-Several Testaro tests make use of the `init()` function in the `procs/testaro` module. That function samples elements if the population of elements to be tested is larger than 100. The purpose is to achieve reasonable performance. The sampling overweights elements near the beginning of a page, because of the tendency of that location to have important and atypical elements.
+Some Testaro tests make use of the `init()` function in the `procs/testaro` module. That function samples elements if the population of elements to be tested is larger than 100. The purpose is to achieve reasonable performance. The sampling overweights elements near the beginning of a page, because of the tendency of that location to have important and atypical elements.
 
-You can add custom rules to the rules of any tool. Testaro provides a template, `data/template.js`, for the definition of a rule to be added. Once you have created a copy of the template with revisions, you can move the copy into the `testaro` directory and add an entry for your custom rule to the `evalRules` object in the `tests/testaro.js` file. Then your custom rule will act as a Testaro rule. Some `testaro` rules are simple enough to be fully specified in JSON files. You can use any of those as a template if you want to create a sufficiently simple custom rule, namely a rule whose prohibited elements are all and only the elements matching a CSS selector. More details about rule creation are in the `CONTRIBUTING.md` file.
+You can add custom rules to the rules of any tool. Testaro provides a template, `data/template.js`, for the definition of a rule to be added. Once you have created a copy of the template with revisions, you can move the copy into the `testaro` directory and add an entry for your custom rule to the `allRules` object in the `tests/testaro.js` file. Then your custom rule will act as a Testaro rule. Some `testaro` rules are simple enough to be fully specified in JSON files. You can use any of those as a template if you want to create a sufficiently simple custom rule, namely a rule whose prohibited elements are all and only the elements matching a CSS selector. More details about rule creation are in the `CONTRIBUTING.md` file.
 
 #### WallyAX
 
-If a `wax` test act is included in the job, an environment variable named `WAX_KEY` must exist, with your WallyAX API key as its value. You can request it from [WallyAX](mailto:technology@wallyax.com).
+If a `wax` test act is included in the job, an environment variable named `WAX_KEY` must exist, with your WallyAX API key as its value. You can obtain it from [WallyAX](https://account.wallyax.com/?ref_app=Developer&app_type=npm).
 
 The `wax` tool imposes a limit on the size of a page to be tested. If the page exceeds the limit, Testaro treats the page as preventing `wax` from performing its tests. The limit is less than 500,000 characters.
 
@@ -535,8 +546,6 @@ If you want the stand-alone API to perform the tests, you need to have that API
 
 ### Browser types
 
-The warning comments in the `testaro/hover.js` and `testaro/motion.js` files state that those tests operate correctly only with the `webkit` browser type. The warning comment in the `testaro/focInd.js` file states that that test operates incorrectly with the `firefox` browser type.
-
 When you want to run some tests of a tool with one browser type and other tests of the same tool with another browser type, you can do so by splitting the rules into two test acts. For example, one test act can specify the rules as
 
 ```javascript
@@ -553,7 +562,7 @@ Together, they get all tests of the tool performed. Before each test act, you ca
 
 ### `actSpecs` file
 
-#### Introduction
+#### Introduction to the `actSpecs` file
 
 The `actSpecs.js` file contains rules governing acts. The rules determine whether an act is valid.
 
@@ -588,12 +597,14 @@ The rule is an array with two elements: a string ('Click a link') describing the
 The requirement `which: [true, 'string', 'hasLength', 'substring of the link text']` specifies what is required for the `which` property of a `link`-type act. The requirement is an array.
 
 In most cases, the array has length 4:
-- 0. Is the property (here `which`) required (`true` or `false`)? The value `true` here means that every `link`-type act **must** contain a `which` property.
-- 1. What format must the property value have (`'string'`, `'array'`, `'boolean'`, `'number'`, or `'object'`)?
-- 2. What other validity criterion applies (if any)? (Empty string if none.) The `hasLength` criterion means that the string must be at least 1 character long.
-- 3. Description of the property. In this example, the description says that the value of `which` must be a substring of the text content of the link that is to be clicked. Thus, a `link` act tells Testaro to find the first link whose text content has this substring and click it.
+
+- Item 0. Is the property (here `which`) required (`true` or `false`)? The value `true` here means that every `link`-type act **must** contain a `which` property.
+- Item 1. What format must the property value have (`'string'`, `'array'`, `'boolean'`, `'number'`, or `'object'`)?
+- Item 2. What other validity criterion applies (if any)? (Empty string if none.) The `hasLength` criterion means that the string must be at least 1 character long.
+- Item 3. Description of the property. In this example, the description says that the value of `which` must be a substring of the text content of the link that is to be clicked. Thus, a `link` act tells Testaro to find the first link whose text content has this substring and click it.
 
 The validity criterion named in item 2 may be any of these:
+
 - `'hasLength'`: is not a blank string
 - `'isURL`': is a string starting with `http`, `https`, or `file`, then `://`, then ending with 1 or more non-whitespace characters
 - `'isBrowserType'`: is `'chromium'`, `'firefox'`, or `'webkit'`
@@ -605,45 +616,79 @@ The validity criterion named in item 2 may be any of these:
 
 ## Reports
 
-### Introduction
+Any Testaro job produces a report, which is a copy of the job with additional data produced by Testaro as it performed the job. Like a job, a report is an object that can be serialized to JSON for file storage and network transmission.
+
+### Job-level data
+
+The data that Testaro adds to a job to create a report include job-level data: data describing the how the job as a whole was performed. Examples: when it was completed and how long it took to run.
+
+Properties that were in a job when it was given to Testaro remain unchanged in the report. New data produced by Testaro during its performance of a job are inserted into a new `jobData` property in the report.
 
-Each tool produces a _tool report_ of the results of its tests. Testaro prunes the tool reports for brevity, removing content that is judged unlikely to be useful. Testaro then appends each tool report to the test act that invoked the tool.
+### Act-level data
 
-Testaro also generates some data about the job and adds those data to the job, in a `jobData` property.
+Testaro also adds act-level data to each job. The new act-level data are properties added to each `act` object.
 
-### Contents
+#### Act-level data from `test` acts
 
-A report discloses:
-- results of tests conducted by tools
-- process data, including statistics on:
-    - latency (how long a time each tool takes to run its tests)
-    - test prevention (the failure of tools to run on particular targets)
-    - logging (browser messaging, including about document errors, during testing)
+In a `test` act, one of the 11 tools performs tests and reports the results. Testaro manages this performance with the `reporter` function of a file located in the `tests` directory. Each tool has a corresponding file, such as `alfa.js` for the `alfa` tool.
 
-### Formats
+The `reporter` function returns an object with this structure:
 
-#### Tool-report formats
+```js
+{
+  data: {
+    prevented: boolean (whether the tool failed to perform its tests on the page),
+    error: string (if `prevented` is `true`, a description of the error)
+    … (other tool-specific data)
+  },
+  result: object (the results of the tests performed by the tool)
+}
+```
+
+On the completion of a job, Testaro has added these properties to each `test` act to produce a report:
+
+- `what` (string): the name of the tool
+- `actualURL` (string): the URL of the visited page, after any redirections
+- `startTime` (string): when the tool was started
+- `endTime` (string): when the tool reported its results
+- `data` (object): other tool-specific data:
+  - `prevented` (boolean): whether the tool failed to perform its tests
+  - `error` (string): a description of the failure, if any
+  - other tool-specific data, if any
+
+Testaro may also add these properties to any `test` act:
+
+- `expectations` (object): the results of validations specified by the act in `expect` properties
+- `expectationFailures` (number): the count of failed validations
+
+The value of `expectations` is an array of objects, one object per expectation. Each object includes a `property` property identifying the expectation, and a `passed` property with `true` or `false` value reporting whether the expectation was satisfied. If applicable, it also has other properties identifying what was expected and what was actually reported.
+
+Testaro also adds one or both of these properties to each `test` act:
 
-The tools listed above as dependencies write their tool reports in various formats. They differ in how they organize multiple instances of the same problem, how they classify severity and certainty, how they point to the locations of problems, how they name problems, etc.
+- `result` (object): the results of the tests performed by the tool, in the native format of the tool
+- `standardResult` (object): the `result` property converted to a Testaro-standard structure
 
-A Testaro report can include, for each tool, either or both of these properties:
-- `result`: the result in the native tool format.
-- `standardResult`: the result in a standard format identical for all tools.
+A job specifies whether the report should include, for each `test` act, the `result` property, the `standardResult` property, or both.
+
+#### Act-level data from `testaro` test acts
+
+Each Testaro rule module exports a `reporter` function, which returns an object with `data`, `totals`, and `standardInstances` properties. Testaro combines the values of those properties with the corresponding values of the same properties from the other `testaro` tests to create the `data` and `result` properties added to `testaro` test acts.
 
 #### Standard result
 
 ##### Properties
 
-The standard result includes three properties:
-- `prevented`: a boolean (`true` or `false`) value, stating whether the page prevented the tool from performing its tests.
-- `totals`: an array of numbers representing how many instances of rule violations at each level of severity the tool reported. There are 4 ordinal severity levels. For example, the array `[3, 0, 14, 10]` would report that there were 3 violations at level 0, 0 at level 1, 14 at level 2, and 10 at level 3.
-- `instances`: an array of objects describing the rule violations. An instance can describe a single violation, usually by one element in the page, or can summarize multiple violations of the same rule.
+The `standardResult` property, when added to a `test` act, includes three properties:
+
+- `prevented` (boolean): whether the tool failed to perform its tests on the page.
+- `totals` (array of numbers): counts of rule violations at 4 ordinal severity levels. For example, the array `[3, 0, 14, 10]` reports that there were 3 violations at level 0, 0 at level 1, 14 at level 2, and 10 at level 3.
+- `instances` (array of objects): descriptions of rule violations reported. An instance can describe a single violation, usually by one element in the page, or can summarize multiple violations of the same rule.
 
 If the value of `prevented` is `true`, the standard result also includes an `error` property describing the reason for the failure.
 
 ##### Instances
 
-Here is an example of a standard instance:
+Here is an example of an instance in a standard result:
 
 ```javascript
 {
@@ -664,9 +709,10 @@ Here is an example of a standard instance:
 }
 ```
 
-This instance describes a violation of a rule named `rule01` by a `button` element.
+This instance says that a `button` element violates a rule named `rule01`.
 
 The element has no `id` attribute to distinguish it from other `button` elements, but the tool describes its location. This tool uses an XPath to do that. Tools use various methods for location description, namely:
+
 - `line` (line number in the code of the page): Nu Html Checker
 - `selector` (CSS selector): Axe, QualWeb, WAVE
 - `xpath`: Alfa, ASLint, Equal Access
@@ -678,12 +724,14 @@ The tool also reproduces an excerpt of the element code.
 ##### Element identification
 
 While the above properties can help you find the offending element, Testaro makes this easier by adding, where practical, two standard element identifiers to each standard instance:
+
 - `boxID`: a compact representation of the x, y, width, and height of the element bounding box, if the element can be identified and is visible.
 - `pathID`: the XPath of the element, if the element can be identified.
 
 These standard identifiers can help you determine whether violations reported by different tools belong to the same element or different elements. The `boxID` property can also support the making of images of the violating elements.
 
 Some tools limit the efficacy of the current algorithm for standard identifiers:
+
 - HTML CodeSniffer does not report element locations, and the reported code excerpts exclude all text content.
 - Nu Html Checker reports line and column boundaries of element start tags and truncates element text content in reported code excerpts.
 
@@ -692,6 +740,7 @@ Testing can change the pages being tested, and such changes can cause a particul
 ##### Standardization configuration
 
 Each job specifies how Testaro is to handle report standardization. A job contains a `standard` property, with one of the following values to determine which results the report will include:
+
 - `'also'`: original and standard.
 - `'only'`: standard only.
 - `'no'`: original only.
@@ -701,12 +750,13 @@ If a tool has the option to be used without itemization and is being so used, th
 ##### Standardization opinionation
 
 This standard format reflects some judgments. For example:
+
 - The `ordinalSeverity` property of an instance involves interpretation. Tools may report severity, certainty, priority, or some combination of those. They may use ordinal or metric quantifications. If they quantify ordinally, their scales may have more or fewer than 4 ranks. Testaro coerces each tool’s severity, certainty, and/or priority classification into a 4-rank ordinal classification. This classification is deemed to express the most common pattern among the tools.
 - The `tagName` property of an instance may not always be obvious, because in some cases the rule being tested for requires a relationship among more than one element (e.g., “An X element may not have a Y element as its parent”).
 - The `ruleID` property of an instance is a matching rule if the tool issues a message but no rule identifier for each instance. The `nuVal` tool does this. In this case, Testaro is classifying the messages into rules.
 - The `ruleID` property of an instance may reclassify tool rules. For example, if a tool rule covers multiple situations that are dissimilar, that rule may be split into multiple rules with distinct `ruleID` properties.
 
-You are not dependent on the judgments incorporated into the standard format, because Testaro can give you the original reports from the tools.
+You are not dependent on the judgments incorporated into the standard format, because Testaro can give you the original reports from the tools as the `result` property of a `test` act.
 
 The standard format does not express opinions on issue classification. A rule ID identifies something deemed to be an issue by a tool. Useful reporting from multi-tool testing still requires the classification of tool **rules** into **issues**. If tool `A` has `alt-incomplete` as a rule ID and tool `B` has `image_alt_stub` as a rule ID, Testaro does not decide whether those are really the same issue or different issues. That decision belongs to you. The standardization of tool reports by Testaro eliminates some of the drudgery in issue classification, but not any of the judgment required for issue classification.
 
@@ -755,7 +805,7 @@ In watch mode, Testaro periodically checks for a job to run and, when a job is o
 
 Testaro can watch for a job in a directory of the filesystem where Testaro or your application is located, with the `dirWatch` function.
 
-#### By a module
+#### Directory watching by a module
 
 ```javaScript
 const {dirWatch} = require('testaro/dirWatch');
@@ -768,7 +818,7 @@ Testaro checks for jobs in the `todo` subdirectory of `JOBDIR`. When it has perf
 
 Testaro creates a report for each job and saves the report in the `raw` subdirectory of `REPORTDIR`.
 
-#### By a user
+#### Directory watching by a user
 
 ```javaScript
 node call dirWatch true 300
@@ -809,7 +859,7 @@ Network watching can be repeated or 1-job. 1-job watching stops after 1 job has
 
 After checking all the URLs in succession without getting a job from any of them, Testaro waits for the prescribed time before continuing to check.
 
-#### By a module
+#### Network watching by a module
 
 ```javaScript
 const {netWatch} = require('testaro/netWatch');
@@ -820,7 +870,7 @@ In this example, a module of your application asks Testaro to check the servers
 
 The third argument specifies whether Testaro should be certificate-tolerant. A `true` value makes Testaro accept SSL certificates that fail verification against a list of certificate authorities. This allows testing of `https` targets that, for example, use self-signed certificates. If the third argument is omitted, the default for that argument is implemented. The default is `true`.
 
-#### By a user
+#### Network watching by a user
 
 ```javaScript
 node call netWatch true 300 true
@@ -904,12 +954,14 @@ Some targets prohibit the execution of alien scripts unless the client can demon
 ### Tool duplicativity
 
 Tools sometimes do redundant testing, in that two or more tools test for the same defects, although such duplications are not necessarily perfect. This fact creates problems:
+
 - One cannot be confident in excluding some tests of some tools on the assumption that they perfectly duplicate tests of other tools.
 - The Testaro report from a job documents each tool’s results separately, so a single defect may be documented in multiple locations within the report, making the direct consumption of the report inefficient.
 - An effort to aggregate the results into a single score may distort the scores by inflating the weights of defects that happen to be discovered by multiple tools.
 - It is difficult to identify duplicate instances, in part because, as described above, tools use four different methods for identifying the locations of elements that violate tool rules.
 
 To deal with the above problems, you can:
+
 - configure `test` acts for tools to exclude tests that you consider duplicative
 - create derivative reports that organize results by defect types rather than by tool
 - take duplication into account when defining scoring rules
@@ -935,6 +987,7 @@ The files in the `temp` directory are presumed ephemeral and are not tracked by
 ### Testilo
 
 [Testilo](https://www.npmjs.com/package/testilo) is an application that:
+
 - converts lists of targets and lists of issues into jobs
 - produces scores and adds them to the raw reports of Testaro
 - produces human-oriented HTML digests from scored reports

package/UPGRADES.md

@@ -2802,3 +2802,166 @@ This gives you:
 ✅ No git conflicts
 
 Claude Sonnet 4.5 • 1x
+
+## Cleanup synchronization
+
+Claude Sonnet 4.5 recommendation to handle already-closed error messages on server (but not the local host) after end of a job:
+
+The issue is that forceKillBrowsers() is killing the browser processes immediately, but the async browserClose() calls in the signal handlers are still trying to close already-dead browsers, causing repeated errors.
+
+Solution: Coordinate Async and Sync Cleanup
+Replace the cleanup handlers in run.js:
+
+```
+// CLEANUP HANDLERS
+
+// Track cleanup state.
+let cleanupInProgress = false;
+let forceKillScheduled = false;
+
+// Force kills all Playwright browser processes synchronously.
+const forceKillBrowsers = () => {
+  if (cleanupInProgress) {
+    return;
+  }
+  cleanupInProgress = true;
+
+  const {execSync} = require('child_process');
+  try {
+    // Kill Chromium headless shell processes.
+    execSync('pkill -9 -f "chromium_headless_shell.*headless_shell"', {stdio: 'ignore'});
+  }
+  catch(error) {
+    // Ignore errors - processes may not exist.
+  }
+};
+
+// Graceful cleanup with timeout fallback.
+const gracefulCleanup = async (timeoutMs = 2000) => {
+  if (forceKillScheduled) {
+    return;
+  }
+  forceKillScheduled = true;
+
+  // Try graceful close with timeout.
+  const closePromise = browserClose();
+  const timeoutPromise = new Promise(resolve => setTimeout(resolve, timeoutMs));
+
+  await Promise.race([closePromise, timeoutPromise]);
+
+  // Force kill any remaining processes.
+  forceKillBrowsers();
+};
+
+// Synchronous cleanup on process exit (last resort).
+process.on('exit', () => {
+  if (!cleanupInProgress) {
+    forceKillBrowsers();
+  }
+});
+
+// Graceful cleanup on SIGINT (Ctrl+C).
+process.on('SIGINT', async () => {
+  console.log('\nReceived SIGINT, cleaning up...');
+  await gracefulCleanup();
+  process.exit(130);
+});
+
+// Graceful cleanup on SIGTERM.
+process.on('SIGTERM', async () => {
+  console.log('Received SIGTERM, cleaning up...');
+  await gracefulCleanup();
+  process.exit(143);
+});
+
+// Cleanup on uncaught exceptions.
+process.on('uncaughtException', async error => {
+  console.error('Uncaught exception:', error);
+  await gracefulCleanup(1000);
+  process.exit(1);
+});
+```
+
+And in `doActs`, replace the cleanup:
+
+```
+  console.log('Acts completed');
+  // If standardization is required:
+  if (['also', 'only'].includes(standard)) {
+    // ... existing standardization code ...
+  }
+  // Close the browser gracefully.
+  await gracefulCleanup();
+  // Delete the temporary report file.
+  await fs.rm(reportPath, {force: true});
+  return report;
+  ```
+
+Key changes:
+
+gracefulCleanup(): Attempts async browserClose() but races it against a timeout, then force-kills
+Guard flags: Prevent multiple simultaneous cleanup attempts that cause the error messages
+Timeout: Gives browserClose 2 seconds to complete before forcing kill
+No redundant calls: Only gracefulCleanup() calls both browserClose() and forceKillBrowsers()
+process.on('exit') as fallback: Only runs if other cleanup didn't complete
+This approach:
+
+Tries graceful closure first (avoiding the errors)
+Falls back to force-kill after timeout
+Prevents the async cleanup from running after force-kill
+Works consistently on both macOS and Ubuntu
+
+The above recommendation seems complex. Meanwhile the error message has been suppressed on the basis that context closure is not necessarily an error.
+
+## Heap memory exhaustion
+
+Exhaustion of heap memory occurred when PNG images were added to reports by the `shoot0` and `shoot1` tests. This issue was resolved with the storage of PNG images as buffers in temporary files. A recommendation generated by Claude Sonnet 4.5 was to add a safety net to `doTestAct` to remove any very large properties from the report. This has not been implemented yet, partly out of concern that it might hide defects that create unduly large properties, inhibiting the rectification of such defects. The recommended code changes were:
+
+```javascript
+// ...existing code...
+
+// Remove oversized properties from report to prevent serialization failures.
+const sanitizeReport = report => {
+  const MAX_PROPERTY_SIZE = 10 * 1024 * 1024; // 10MB threshold.
+
+  for (const act of report.acts) {
+    if (act.result) {
+      for (const [key, value] of Object.entries(act.result)) {
+        if (value && typeof value === 'object') {
+          const size = JSON.stringify(value).length;
+          if (size > MAX_PROPERTY_SIZE) {
+            console.log(
+              `WARNING: Removing oversized property '${key}' from ${act.which} result (${Math.round(size / 1024 / 1024)}MB)`
+            );
+            delete act.result[key];
+          }
+        }
+      }
+    }
+  }
+};
+
+const doTestAct = async () => {
+  // ...existing code...
+
+  try {
+    const actReport = await require(`../tests/${which}`).reporter(page, report, actIndex, 65);
+    act.data = actReport.data;
+    act.result = actReport.result;
+
+    if (act.data && act.data.prevented) {
+      report.jobData.preventions[which] = act.data.error;
+    }
+
+    await browserClose();
+
+    // Sanitize report before serialization.
+    sanitizeReport(report);
+
+    const reportJSON = JSON.stringify(report);
+    await fs.writeFile(reportPath, reportJSON);
+    process.send('Act completed');
+  }
+  // ...existing code...
+};
+```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "testaro",
-  "version": "60.4.0",
+  "version": "60.5.0",
   "description": "Run 1000 web accessibility tests from 11 tools and get a standardized report",
   "main": "index.js",
   "scripts": {