Accessibility-insights for azure devops not working and throw exception about accessibility-insights-action HOT 6 CLOSED

This issue has been marked as ready for team triage; we will triage it in our weekly review and update the issue. Thank you for contributing to Accessibility Insights!

from accessibility-insights-action.

This issue has been marked as ready for team triage; we will triage it in our weekly review and update the issue. Thank you for contributing to Accessibility Insights!

from accessibility-insights-action.

Hi @SafaaAccount ,

The first error is likely due to a mismatch between the globally installed version of Node and the version that the build agent is using to run our task. Like you identified, explicitly adding a task to install a matching version of node before running Accessibility Insights is the recommended workaround for the issue; we hope to remove the need for the workaround with #1559.

I'm not sure what the root cause of the second error is. I am able to reproduce it locally using the underlying scanner's CLI package (node C:\repos\accessibility-insights-service\packages\cli\dist\ai-scan-cli.js --crawl --url https://shopin3d-ppe.azurefd.net/en-us/store/shop-in-3d/surfaceprox.html --maxUrls 1 --restart). However, when attempting to load the page locally in a headful Edge/Chrome instance outside the scan CLI, I am able to load the page locally and don't see any obvious persistent network traffic that might be confusing the crawler into thinking the page hasn't finished loading, so I don't think this is an issue of the page legitimately being unreachable or slow to load in your specific CI environment.

This will require further investigation to root cause; the next step for us would probably be to hook up a debugger to the headless browser instance (possibly after reducing the repro to a simpler puppeteer script). We'll try to look more closely into this next week.

from accessibility-insights-action.

This issue requires additional investigation by the Accessibility Insights team. When the issue is ready to be triaged again, we will update the issue with the investigation result and add "status: ready for triage". Thank you for contributing to Accessibility Insights!

from accessibility-insights-action.

This issue requires additional investigation by the Accessibility Insights team. When the issue is ready to be triaged again, we will update the issue with the investigation result and add "status: ready for triage". Thank you for contributing to Accessibility Insights!

from accessibility-insights-action.

I'm able to reproduce the second error with a plain Puppeteer test script, both v18.1.0 (used by the current extension) and v19.7.2 (latest as of writing). The issue repros only under old-headless Chromium (ie, not in headful mode, and not with headless: 'new'). The issue repros when asking Puppeteer to waitUntil: 'networkidle2' (what the scanner uses) or networkidle0, but not load or domcontentloaded. The issue does not repro in latest Playwright (v1.31.1) waiting for networkidle.

I'm still not sure why the problematic Puppeteer configuration times out - I took a trace of the interaction and there are several periods of network inactivity present in the trace which I'd have expected to trigger either of the two networkidle lifecycle events.

Unfortunately, we likely won't prioritize debugging this particularly, since:

• It doesn't repro in Playwright, and we'd already like to migrate from Puppeteer to Playwright in the future for other reasons (eg, microsoft/accessibility-insights-service#2170)
• This doesn't appear to be a pattern of issue common to multiple users of Accessibility Insights for Azure DevOps

As a workaround, we'd encourage you to automate testing of this site by using a Playwright-based end to end test (docs, sample), rather than using the Azure DevOps task for this specific site.

from accessibility-insights-action.