Accessibility-insights-web: Scan fails when a page does not have a body tag

[haonliu]

Describe the bug

Scan fails when a page does not have a body tag

To Reproduce

1. Create a page with the following html:
   ````
   
   
   
   
   

Hello world

````

1. Open AI-web
2. Run automated checks
3. See error in the console

Expected behavior

The scan should be able to run.

Extension (please complete the following information)

• OS: any
• Version any
• Browser Version any
• Target Page N/A

[msft-github-bot]

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!

[ferBonnin]

From conversation with Peter, @waabid did a bit of investigation. @waabid is this our limitation or axe-core's?

[msft-github-bot]

The team requires additional author feedback; please review their replies and update this issue accordingly. Thank you for contributing to Accessibility Insights!

[msft-github-bot]

This issue has been automatically marked as stale because it is marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. Thank you for contributing to Accessibility Insights!

[dbjorge]

I don't think we intended to close this or tag it as needs author feedback, looks like this was just lost in upkeep.

I found that the repro steps from the original bug didn't work as-is; Chrome normalized the repro content as having a body tag. However, using content of <frameset></frameset> does cause the issue, where running a fastpass hangs with a scanning spinner and the injected page shows the following error:

injected.bundle.js:97 Uncaught (in promise) TypeError: Cannot read property 'appendChild' of null
    at n.create (injected.bundle.js:97)
    at ae.initialize (injected.bundle.js:97)
    at ae.initialize (injected.bundle.js:97)
    at Object.<anonymous> (injected.bundle.js:97)
    at Object.<anonymous> (injected.bundle.js:97)
    at n (injected.bundle.js:2)
    at Object.<anonymous> (injected.bundle.js:97)
    at n (injected.bundle.js:2)
    at injected.bundle.js:2
    at injected.bundle.js:2

To clarify on @ferBonnin 's last question, this is our limitation, not axe-core's; I verified on the above minimal test page and the internal page that the same issue was recently re-raised for that reproduces the issue that axe-core and axe's chrome extension work fine.

[msft-github-bot]

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!

[ferBonnin]

@dbjorge no. It needed a reply from Wahaj.
.@waabid is this our limitation or axe-core's?

[msft-github-bot]

The team requires additional author feedback; please review their replies and update this issue accordingly. Thank you for contributing to Accessibility Insights!

[msft-github-bot]

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!

[dbjorge]

@ferBonnin, I already clarified in the reopening comment: this is our issue, axe-core and axe's web extension both work fine on all repro variants.

[msft-github-bot]

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!

[waabid]

Sorry, I must have missed this from before! Dan is correct: we should be able to function even without a body element. My guess is we make this assumption in a few places and can likely replace it with html element (but this is just an educated guess).

[ferBonnin]

per conversation with Peter, there are 2 issues:

1. we hang
2. we don't scan framesets.

Suggestion for this is (in parallel)

• add a fix so we dont hang
• either scan the frameset or create a rule (contribute back to Deque) that tells the users that framesets are obsolete

[msft-github-bot]

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!