Accessibility scanner action flags GitHub's own /pages/auth infrastructure page (Actions)

[GrimaceDoesA11y]

When running the scanner action on a private GitHub Pages site, the scanner flags an axe page-has-heading-one violation on the URL /pages/auth. This page is GitHub's own built-in authentication page (the login gate for private GitHub Pages sites), not a page a user can author or control.

The scanned element contains attributes like data-turbo-loaded, data-color-mode, data-a11y-animated-images, and js-focus-visible, which confirm it is GitHub's own UI, not user content. We cannot fix this violation because we do not own the page.

In our case, this triggered 30 duplicate pull requests in our repository (as we ran on a list of URLs), all attempting to create a pages/auth.html file that has no effect on the actual scanned page.

Request:

Please either

• (1) fix the accessibility violation on GitHub's own /pages/auth page, or
• (2) update the github/accessibility-scanner action to exclude GitHub-infrastructure URLs from its scan scope by default, or
• document how to configure URL exclusions for these pages

The private repo with CoPilot's attempts to fix the issue:
https://github.com/mcdonalds-corp-new/ally/pull/84

URL of the workflow run:
https://github.com/mcdonalds-corp-new/ally/actions/runs/24263521708/job/70852992850

Error message:
Set issue Accessibility issue: Heading levels should only increase by one on /pages/auth (mcdonalds-corp-new/ally#25) state to closed Set issue Accessibility issue: Page should contain a level-one heading on /pages/auth (mcdonalds-corp-new/ally#26) state to closed

Workflow file and workflow run log attached.

gh-a11y-scanner.yml

logs_64167249977.zip

[abdulahmad307]

Hi @GrimaceDoesA11y 👋, thanks for reporting this.

So, looking at the workflow file you provided, the list of urls doesn't include pages/auth, which could mean that a redirect is happening from one of the actual urls to the auth page. If this is the case, the scanner will not know that this redirect is unintentional, and will scan the page that the playwright browser lands on (which would be pages/auth after the redirect is complete).

To avoid this redirect (assuming that's the case), you can provide an auth_context input to the scanner in the workflow - see line 35 in the workflow file. This will make the browser think that the session is authenticated (or logged in), and will skip the redirect and land on the intended page url.

Hope that helps. Let us know if you have more questions. Also, have a look through the docs on how to use the auth_context

[GrimaceDoesA11y]

@abdulahmad307 thank you for the clarification. I tried auth_context with my info but it still reports the same issue:

1. https://github.com/mcdonalds-corp-new/ally/issues/103
2. https://github.com/mcdonalds-corp-new/ally/issues/104

I'm not sure if I'm doing this correctly, as I normally login via SSO to an enterprise account. This account is not that account.