You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## 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](https://github.com/github/accessibility-scanner/pull/133/changes#diff-8286e7365a5a84367dd51372b6b4565edb1146925ff6f5fc126a9d7d39fc94a9))
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
0 commit comments