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
The reported URL sent to pa11y-ci reporters can be different for different reporter events (and I believe in pa11y as well). For those run before execution (beforeAll, begin), or without successful execution (error), the reported URL comes from the config.urls, sitemap or CLI input . For those run after successful execution (results, afterAll), the reported URL is document.location.href. While these are frequently the same, redirects, URL normalization, or any actions run that may change the URL can cause them to be different. If reporters are trying to compare results against the original config, it's not always straightforward to relate them, and if the original URL is desired it may not be avaialble.
In addition, pa11y-ci processes URLs differently when specified in config vs CLI. Inputs via CLI are processed initially through protocolify before execution (as are sitemaps). Inputs from config could be strings or object, so are passed on for processing, and eventually sanitized in pa11y here. This becomes more significant for local files, so if a URL is specified in config as './index.html' it will be reported that way before processing, but as 'file:///the/resolved/path/index.html' after execution. For local files like this that may have different absolute paths in different test environments, using the original relative URL is desirable.
There isn't necessarily a simple solution to make these consistent, without a breaking change, and that may not even be desirable (e.g. if actions caused the URL to change, that URL may be more desirable).
As a workaround, the config argument passed to results does contain the original URL if it was specified in config.urls as an object with a url property. Propose updating the confighere where the URL is a string to merge options with { url } so the original URL is at least available for the results event.
The text was updated successfully, but these errors were encountered:
The reported URL sent to pa11y-ci reporters can be different for different reporter events (and I believe in pa11y as well). For those run before execution (
beforeAll
,begin
), or without successful execution (error
), the reported URL comes from theconfig.urls
, sitemap or CLI input . For those run after successful execution (results
,afterAll
), the reported URL isdocument.location.href
. While these are frequently the same, redirects, URL normalization, or anyactions
run that may change the URL can cause them to be different. If reporters are trying to compare results against the original config, it's not always straightforward to relate them, and if the original URL is desired it may not be avaialble.In addition, pa11y-ci processes URLs differently when specified in config vs CLI. Inputs via CLI are processed initially through
protocolify
before execution (as are sitemaps). Inputs from config could be strings or object, so are passed on for processing, and eventually sanitized in pa11y here. This becomes more significant for local files, so if a URL is specified in config as './index.html' it will be reported that way before processing, but as 'file:///the/resolved/path/index.html' after execution. For local files like this that may have different absolute paths in different test environments, using the original relative URL is desirable.There isn't necessarily a simple solution to make these consistent, without a breaking change, and that may not even be desirable (e.g. if
actions
caused the URL to change, that URL may be more desirable).As a workaround, the
config
argument passed toresults
does contain the original URL if it was specified inconfig.urls
as an object with aurl
property. Propose updating theconfig
here where the URL is a string to mergeoptions
with{ url }
so the original URL is at least available for theresults
event.The text was updated successfully, but these errors were encountered: