Adds reflow scan plugin

[lindseywild]

Adds a built-in scan that will detect if a page horizontally scrolls on a mobile screen size (320x256).

Example reflow issue:

Updates made:

• Passes in url from the plugin manager so it can be accessed in the plugins (which I can see being needed for most plugins at this point)
• Removes test plugin in favor of pointing to a real plugin, updates docs accordingly
• Updates the pluginManager to account for an edge case with duplicate named plugins running multiple times
• Makes ruleId and html optional in the issue body - handles conditionals if these are not passed in and adds tests
• Adds new error to the sites/site-with-errors 404 page to check in the site-with-errors test.

[Testing - staff only]:

• Workflow test w/no scans input passed in
• Workflow test w/include_screenshots on
• Workflow test w/include_screenshots off

[Copilot]

Pull request overview

Adds a built-in “reflow” scanning plugin and updates the scanner pipeline/types/docs to support plugin findings that may not include element HTML and/or a rule ID.

Changes:

• Introduces a built-in reflow-scan plugin that detects horizontal scrolling at a 320x256 viewport.
• Extends plugin invocation to pass url into plugins, and updates types to make html (and in filing action, ruleId) optional.
• Updates issue body/label generation and tests to handle findings without html/ruleId.

Reviewed changes

Copilot reviewed 12 out of 15 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
tests/types.d.ts	Makes html optional in test result typings.
tests/site-with-errors.test.ts	Adds expected “reflow” finding and issue title assertions.
README.md	Documents the scans input and provides an example value.
PLUGINS.md	Updates plugin docs to point to existing plugin examples.
.github/scanner-plugins/test-plugin/package.json	Removes the old test plugin package metadata.
.github/scanner-plugins/reflow-scan/package.json	Adds package metadata for the built-in reflow plugin.
.github/scanner-plugins/reflow-scan/index.js	Implements the reflow scan plugin logic and exported name.
.github/actions/find/src/types.d.ts	Makes html optional in find-action finding type.
.github/actions/find/src/pluginManager.ts	Passes url through to plugin default functions.
.github/actions/find/src/findForUrl.ts	Supplies url when invoking plugins.
.github/actions/file/tests/generateIssueBody.test.ts	Adds coverage for issue body behavior when html is missing.
.github/actions/file/src/updateFilingsWithNewFindings.ts	Adjusts finding key generation to tolerate missing ruleId/html.
.github/actions/file/src/types.d.ts	Makes ruleId and html optional for filing action findings.
.github/actions/file/src/openIssue.ts	Omits the “rule:” label fragment when ruleId is absent.
.github/actions/file/src/generateIssueBody.ts	Falls back to URL-based wording when html is absent.

Comments suppressed due to low confidence (4)

.github/scanner-plugins/reflow-scan/index.js:7

• This plugin changes the page viewport size to 320x256 but never restores it. Since plugins run before the Axe scan in findForUrl, this will cause the subsequent Axe scan to run at the smaller viewport and may change/introduce findings. Capture the current viewport (page.viewportSize()) and restore it in a finally block (or run this check in a separate page/context) so other scans are unaffected.

This issue also appears on line 1 of the same file.
.github/scanner-plugins/reflow-scan/index.js:16

• The finding is emitted with scannerType 'reflow-scan', but tests and other code paths appear to treat scannerType as a category like 'axe'/'reflow' (e.g. tests/site-with-errors expects 'reflow'). Consider keeping plugin selection name as 'reflow-scan' but using a stable scannerType like 'reflow' for labeling/grouping consistency.
  .github/scanner-plugins/reflow-scan/index.js:3
• This file introduces semicolons and a noisy console.log at plugin startup. The rest of the repo’s JS/TS generally omits semicolons and avoids unconditional logging; consider aligning formatting and either removing the log or gating it behind a debug flag to keep Action logs clean.
  tests/site-with-errors.test.ts:116
• In this test, actual strips problemUrl out of each finding before comparing (const {problemUrl, ...finding} = findings[0]). This new expected reflow object includes problemUrl, so the equality assertion will fail unless you either keep problemUrl in actual or remove it from expected for consistency.

      {
        scannerType: 'reflow',
        url: 'http://127.0.0.1:4000/404.html',
        problemShort: 'Page requires horizontal scrolling at 320x256 viewport',
        solutionShort: 'Ensure content is responsive and does not require horizontal scrolling at small viewport sizes',
        problemUrl: 'https://www.w3.org/WAI/WCAG21/Understanding/reflow.html',
      },

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[lindseywild]

This change was needed because when testing within this repo, the reflow-scan plugin was being loaded and run twice, duplicating issues. This is only going to be an issue when:

1. The tests run within this repo, as loadBuiltInPlugins and loadCustomPlugins both contain a reflow-scan plugin since it's in the same directory,
2. If a user adds a scanner-plugins directory in their own repo where one of them contains the same name.

A slim edge case, but we needed to handle it for the tests in this repo.

[abdulahmad307]

I wonder if we should namespace our plugins. so it would be something like builtin:<name> and it would avoid name clashes?

One of the things we discussed was that it's on the plugin authors to ensure that names are unique - does that apply in this case? or are we saying that it only applies when the name clash happens between two custom plugins (so it doesnt apply if the name clash happens between 1 built-in and 1 custom plugin)?

I don't know if I'm leaning one way or another 🤔

[abdulahmad307]

I think one disadvantage of programmatically removing (skipping) a plugin is we can't control which one gets skipped. With the current change, only the first one in the file-system will load, but what if we want the second one to load? would we not then revert to having to change the name anyway?

I guess I'm realizing that ensuring names are unique is still going to be the end result in many cases, so we should just use that as a criteria for loading plugins

[lindseywild]

We could namespace our plugins, but in the case of any we add to the accessibility-scanner repo we would still run into it loading twice only in our tests -- specifically with the sites-with-errors tests, because it's treating "reflow-scan" as a built-in plugin and a custom plugin when we run the test.yml CI check.

So we'd run into this issue if someone else created a custom plugin called "reflow-scan" in their own scanner-plugins directory if that makes sense.

The alternative to the issue we're running into in our tests is to either:

1. Not add tests for the reflow plugin, or
2. Assume that it will run twice and add the duplicate issue that's created

I'm not really in love with either of these options, though...

I guess a third alternative is if someone does create a naming clash and we are to skip the plugin, it could core.warn with a message stating which plugin is being skipped in that workflow run?

so we should just use that as a criteria for loading plugins

Are you talking about ensuring for unique names?