DocumentationReference

Roles and capabilities

The four capabilities, which roles get them by default, and how to let somebody scan without handing them the whole report.

The four capabilities

Capability What it allows
wsak_run_scan Running a scan
wsak_view_reports Reading the dashboard and findings
wsak_apply_fix Applying and reverting fixes
wsak_manage_settings Changing settings and site-wide fixes

They are separate on purpose. Running a scan and reading the site’s whole accessibility report are different acts, and some organisations want to grant one without the other.

Who gets what by default

Role Capabilities
Administrator All four
Editor wsak_run_scan, wsak_view_reports
Everyone else None

So an editor can check a page and read what came back, but cannot change settings, switch on a site-wide fix, or apply a markup change.

Changing the map

add_filter( 'wsak_role_capabilities', function ( array $map ): array {
    // Authors may scan their own work, and see nothing else.
    $map['author'] = array( 'wsak_run_scan' );

    // Editors may also apply fixes.
    $map['editor'][] = 'wsak_apply_fix';

    return $map;
} );

The filter is applied both when capabilities are granted and when they are revoked, so a role you add here is also cleaned up when the plugin is uninstalled. Capabilities added by other means are not, and will linger.

Dismissals need more than a capability

Settling a finding everywhere it appears also requires permission to edit other people’s content, because the decision reaches pages that are not yours. The plugin checks edit_others_posts in addition to its own capabilities.

Two filters give finer control:

  • wsak_can_dismiss — may this user dismiss this finding?
  • wsak_can_dismiss_site_wide — may they settle it everywhere?

Post types respect existing permissions

Only post types the current user is allowed to edit are ever offered for scanning, including from the command line. Adding a type with wsak_post_types makes the plugin aware of it; it does not grant anybody access to it.

REST endpoints

The plugin’s own REST routes check these capabilities too. The report endpoint asks for wsak_view_reports specifically, rather than a broader capability administrators happen to hold — which only matters on a site that has used the filter above to separate the two, and that is precisely the case the split exists for.

Last updated . Something here wrong or missing? Tell us and we will fix it.