v2.5.1

Fixed

• A scan refused by the per-address daily limit now says why. A
  workflow that sends neither accessibility-pro-token nor a GitHub
  OIDC token (no id-token: write permission) is limited per network
  address as well as per repository. When that limit was reached the
  action printed "Scan quota exhausted for this repository", which was
  wrong and left out the fix. It now prints the scanner's own reason,
  "Too many scans from this address today", which says to add an
  accessibility-pro-token or use OIDC (the id-token: write
  permission in this README), followed by when to retry. When the
  repository's own 10 scans a day or 10 an hour are used up, the
  message is unchanged.

v2.5.0

Added

• ai input. ai: false keeps the scan away from every AI provider:
  no page content is sent to a model, and only the plain-language
  explanations are skipped. The comment titles the notice "AI was not
  used for this scan" and it never fails the build. An account with AI
  switched off on its Account page gets no AI whatever the input says.
  A scan sent with cf-access-client-id / cf-access-client-secret is
  a signed-in scan and uses no AI unless the account opted in on its
  Account page.
• read-only input. A scan that uses a Cloudflare Access service
  token is read-only: the scanner blocks every request that could
  change data and skips the form error check. read-only: false
  switches that off for a test site. Default true.

v2.4.4

Fixed

• Uploading the SARIF file to code scanning no longer fails when there
  is a finding. Since 2.0.0 each result's location was the scanned
  page's web address. Code scanning accepts only paths in the
  repository, so github/codeql-action/upload-sarif failed with
  "unrecognized SARIF location URI scheme" whenever a scan had at least
  one finding. A scan with no findings uploaded fine, which is why our
  own CI stayed green until 2.4.3. The location is now the page's host
  and path as a repository-relative path, for example
  www.example.com/pricing, with any port written as _3000 and the
  query string left out. The full address moves to the result's
  page_url property. Fingerprints are unchanged.

v2.4.3

Fixed

• The action's description says what the comment contains. It read
  "one sticky comment with sandbox-validated Copy-as-PR fixes", but the
  comment links to the hosted report, where Copy-as-PR fixes are
  generated for a signed-in account on the Developer plan or above. It
  now reads "one sticky comment linking to verified code fixes". No
  change to inputs, outputs, the comment or the SARIF.

v2.4.2

Fixed

• A saved dismissal is no longer reported as an ignore-rules match.
  Since 2026-09-20 the scanner also applies the dismissals saved on your
  account for the scanned site (POST /api/account/dismissals) to runs
  that carry accessibility-pro-token. The verdict was always right, but
  the comment, the log and the SARIF suppression said every skipped
  finding "matched ignore-rules", including on workflows that set no
  ignore-rules at all. Each skipped finding is now labelled by where
  its acknowledgement came from: ignored via ignore-rules: <entry> or
  saved dismissal: <entry>, with a separate count for each in the
  comment and in the log. SARIF results carry gate_ignored_source
  (ignore-rules or saved).

Added

• "Your saved dismissals could not be applied" heading for the
  scanner's dismissals_unavailable notice, which used to print as a
  generic "Scan notice". It explains a red build on a finding you had
  already dismissed; it does not fail a build on its own, because the
  gate it describes is stricter than you asked for, never looser.

v2.4.1

Added

• Four scan notices now print their real heading. time_budget,
  language_variants_sampled, probe_budget_adapted and the new
  consent_not_dismissed rendered as a generic "Scan notice" in the job
  summary and the PR comment, while the report page named them. None of
  them fails a build; they explain a number that moved.

Scanner

• A site's own language is no longer scanned as a translation. A URL
  that carries its locale in the file name rather than a directory
  (/it.html, /en.html, common on Adobe Experience Manager and on
  government sites) was unreadable to the crawler, so the site's own
  pages were sampled three per language as if they were translations of
  something else. trenitalia.com audited 4 Italian pages out of 30 and
  reported 2,489 as skipped. The language now comes from the page's own
  <html lang>, region subtags are validated against ISO 3166 so a
  section like /uk-news/ is not read as Ukrainian, and a crawled page
  that declares the site's language retires a wrong guess for the rest
  of the scan.
• A cookie banner is dismissed in far more languages, and the result
  is checked. Dismissal now reads the class and id of each control
  rather than only its words, which answers in languages no phrase list
  carries; it reaches into the iframe that Sourcepoint and other
  consent vendors render their dialog in; it follows the second panel
  that hides the refusal behind "more options"; it repeats while a
  banner is still up, because some sites stack two; and it treats a
  refusal that costs money as an acceptance, so the scan stays on the
  page it was asked to audit. Every click is verified against the
  viewport the dialog covered, so a control that answers and leaves the
  dialog standing is no longer reported as a dismissal. Verified live
  across 26 languages including Arabic, Hebrew, Greek, Hungarian,
  Croatian, Polish, Swedish and Finnish.
• An Experience Manager page is no longer reported as a consent
  wall. cmp-container, the class Adobe's Core Components give every
  layout container, sat in the scanner's list of consent-manager roots,
  so the page's own wrapper measured as a full-screen dialog. Every page
  of an affected scan carried "this scan may not reflect the real page"
  with the banner correctly dismissed — and with fail-on-unrepresentative
  set, that failed the build.
• A sign-in page is caught on multi-page scans too. The check had
  the URL it asked for on the CI path only.

v2.4.0

Added

• cf-access-client-id and cf-access-client-secret. Scan a staging
  site behind Cloudflare Access with a service token stored as repository
  secrets. Both values are masked, sent only to the scanned site's own
  hosts and never across a redirect, and not stored. Needs an
  accessibility-pro-token on the Developer plan or above. Setting only
  one of the two fails the step before anything is sent.

Fixed

• A scan that is refused with a reason prints the reason. An HTTP 422
  from the scanner, such as an unreachable host, used to read "Scan
  request failed: HTTP 422" followed by the detail. It now prints the
  detail alone.

Scanner

• A sign-in page is no longer graded as your site. A URL that
  redirected to Cloudflare Access (or Okta, Microsoft, Google, Auth0,
  Vercel deployment protection, or the site's own /login) was scanned
  as if it were the page: a staging site scored 79 with four failures,
  every one of them a property of Cloudflare's sign-in screen. The
  scanner now stops before grading, stores and counts nothing, and every
  version of the action fails the step with "Blocked by sign-in" and what
  to do about it.

v2.3.1

Fixed

• A rejected token says why. The step failed with only "The supplied
  accessibility-pro-token was rejected". It now prints the scanner's
  reason (not recognised, revoked or malformed) and the link to create a
  new token.

Scanner

These reached every version of the action the day they deployed.

• accessibility-pro-token can now be created. The README and the
  input said a token attributes scans to your plan, but the account page
  issued none, and the scanner only accepted an hour-long session JWT.
  Create one under API tokens at
  https://www.accessibilitypro.app/account#api-tokens and store it as a
  repository secret.
• A token that does not verify fails the step. The scanner used to
  drop it and scan on the anonymous free tier with a green build. It now
  refuses the scan with HTTP 401, so a mistyped, expired or revoked
  secret shows up at once instead of quietly costing you your plan.

v2.3.0

Added

• ignore-rules. Findings you have reviewed and do not want gating
  the build, one per line: a rule id as the report and SARIF print it
  (ibm-input_checkboxes_grouped), optionally followed by @ and a
  fragment of the URL or selector it applies to
  (color-contrast@/pricing). The scanner applies the list before its
  gate, so the verdict still comes from one place. Ignored findings stay
  in the report and the score, carry an "ignored via ignore-rules" chip
  in the comment, are not annotated, and are written to SARIF as
  suppressed results rather than dropped. An entry that matches nothing
  is named in the comment and warned in the log, so a typo cannot pass a
  build silently. Requested in #2: until now the
  only way past a reviewed finding was dropping a whole engine.

Scanner

The verdict comes from the hosted scanner, so these reached every
version of the action the day they deployed; they are listed here
because a fail-on: wcag build sees them.

• Checkboxes are grouped by their form, not by the page. IBM's
  input_checkboxes_grouped collected same-named checkboxes across the
  whole page, so two forms with one consent box each failed as an
  ungrouped pair. The live-DOM verifier now scopes the name to the form
  owner, the way a browser does; a checkbox alone in its form, or whose
  siblings share a fieldset, is contradicted and moved to manual
  review (#2).
• aria_article_label_unique is best practice. article is not a
  landmark and no success criterion asks articles for unique names. It
  is reported as an advisory note and never fails the gate
  (#2).
• Heavy pages under load keep their results. Each live-page filter
  stage has a ceiling and a scan's pages are capped process-wide, so two
  heavy scans running side by side no longer stall a page to its timeout
  and lose its engine results. Ad and measurement hosts are blocked at
  the browser, a page whose renderer crashes is analysed once more, and
  a site that rejects unknown query strings is fetched without the
  cache-buster.
• Fewer wrong findings on overlays and shadow DOM. A marketing
  popup that hides the page with aria-hidden no longer produces a page
  of false findings, and elements inside shadow roots are located for
  verification instead of shipping unverified.

v2.2.1

Security

• Credentials in the scanned URL are no longer published. An
  auth-gated preview URL passed through a secret (https://user:pass@…,
  or a ?x-vercel-protection-bypass=… token) was echoed verbatim into
  the PR comment, the job summary, SARIF, annotations and the results
  file, none of which the runner's log masking covers. On the scanned
  host, a URL's userinfo, query and fragment now read ***
  (https://***@staging.example.com/app?***); the path is kept so the
  page is still recognisable. A URL carrying credentials, and its
  password, are also masked in the run log. Rule help links on other
  hosts are unchanged, and the backend still receives the real URL.
• The sticky comment is only ever this action's own. The comment
  marker is public, so anyone able to comment on a pull request could
  plant it first; the action then wrote its verdict into their comment
  on every run, and they could edit it between pushes. A marker comment
  is now reused only when its author is the token's own identity
  (github-actions[bot] for the workflow token, or the user behind a
  personal access token). With a GitHub App installation token the
  action cannot tell which comments are its own, so it posts a new
  comment on each run instead of updating one.