Conversation
…ction - update 'Finding' type to include missing fields
abdulahmad307
force-pushed
the
abdul/test-plugins
branch
from
956daeb to
877646f
Compare
lindseywild
left a comment
lindseywild
left a comment
There was a problem hiding this comment.
Just a few small comments, otherwise looks good!
| // - this will be coming soon | ||
| // runAxeScan: () => runAxeScan({page, includeScreenshots, findings}), |
There was a problem hiding this comment.
Is this still relevant?
There was a problem hiding this comment.
🤔 not in this PR. I can remove it and make an issue to capture the need. I just didn't want to lose the intention of how we want to expose the ability to do axe scans.
| // - this will be coming soon | ||
| // runAxeScan: (options: {includeScreenshots: boolean; page: playwright.Page; findings: Finding[]}) => Promise<void> |
There was a problem hiding this comment.
same answer as above
| // runAxeScan: (options: {includeScreenshots: boolean; page: playwright.Page; findings: Finding[]}) => Promise<void> | ||
| } | ||
|
|
||
| export type Plugin = { |
There was a problem hiding this comment.
Does this need to be exported? I didn't see it anywhere (but also search + find for "plugin" returned a ton of results 😅 )
There was a problem hiding this comment.
uhh. things have changed since I created it, so maybe it doesnt need to be anymore. i'll double check
| @@ -0,0 +1,32 @@ | |||
| export default async function test({ page, addFinding, url } = {}) { | |||
There was a problem hiding this comment.
Will this be replaced by the real reflow test once we add it?
There was a problem hiding this comment.
yea, once we have a real plugin, we can get rid of the test one. this is just here to have an example
.github/actions/find/src/types.d.ts
Outdated
| solutionShort: string | ||
| solutionLong?: string | ||
| screenshotId?: string | ||
| ruleId: string |
There was a problem hiding this comment.
Could we make this type optional? There probably won't always be a ruleId
New Context
After validating the plugins idea, we have decided to move forward with this approach.
This PR introduces the idea of 'Plugins' to the scanner. A plugin (as described in the PLUGINS doc) is a custom script that performs an accessibility test/scan. It allows teams to specify their own tests in their own repos to surface accessibility issues. These plugins can be used in combination with existing scans. For example, a team can perform interactions on a page before the axe scan runs.
There will also be built-in scans that will ship with the scanner.
Original Context
This is a very minimal proof of concept around the idea of using plugins to make additional scans and tests modular. Looking for feedback on general approach, pros/cons, etc...
this currently works with the plugins defined in the scanner repo. I'm still working on making this work with plugins defined in the workflow repo (the repo that uses the action). There might be some issues with using absolute paths with the dynamic import() feature - but i'm still testing.
I've taken @lindseywild’s reflow test and added it as a plugin for testing. the idea is each plugin lives under a new folder under the scanner-plugins folder (which lives under .github like actions). and each plugin has a primary index.js file, which we will use to interface with the plugin.
all of this is just how I've built it as a proposal - we can tweak naming/folder-structure, etc... if we feel something else makes more sense