Skip RSS & other non-HTML pages

[mgifford]

Is your feature request related to a problem? Please describe.

If a user evaluates a URL that isn't in HTML, then the tool should be smart enough to identify that and not display errors for HTML. I've seen instances with both RSS & images (without proper extensions) where errors were reported that confused less technical users.

Describe the desired outcome

If someone runs across a mimetype or structured data format like CSV, JSON or RSS, then Accessibility Insights should say, "this page does not appear to be in HTML" instead of errors for missing Titles & page language.

Describe alternatives you've considered

I suppose no errors could be displayed or perhaps "This is an RSS file, so we can't run the HTML scan"

Additional context

We can't assume that web developers are using Accessibility Insights. Others are often involved in adding issues to JIRA from Accessibility Insights.

What is the assumed workflow for the use of this great tool?

[ghost]

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]

@DaveTryon checked this on image files, we learned that the browser auto generates HTML and the HTML generated doesn't have accessible properties; for users using assistive technologies, this would present an inaccessible solution. PDFs also have an HTML wrapper which is what Accessibility Insights detects and scans.

[ghost]

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!

[ghost]

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]

beyond this, the question is can we provide some additional information when users try to scan PDFs or RSS?

[ghost]

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!

[DaveTryon]

@peterdur, I've researched this by opening opening various non-HTML files in Chrome then inspecting the generated html files. For each file:

1. Open it via Ctrl+O
2. Go to inspect view
3. Right-click on the HTML, select Copy > Copy outerHTML
4. Paste the result into a text editor
5. Save the text file to disk

I wasn't able to get the RSS File to load, potenttially due to user error on my part. I opened https://blogs.microsoft.com/feed/, saved the content to test.rss, thentried to open the file--no joy. Here are the results from the files that I was able to successfully load:

File Extension	Action	Generates HTML?	document.contentType
jpg	Open	Yes	image/jpg
bmp	Open	Yes	image/bmp
png	Open	Yes	image/png
gif	Open	Yes	image/gif
pdf	Open	Yes	application/pdf
docx	Save	No	n/a
xlsx	Save	no	n/a

I've included all of the files in this zip file: test_files.zip. You can open index.html into your browser, then open the other files from there. The HTML files are the auto-generated versions based on the file that was loaded (reflected in the name)

Assigning this back to you for now, since I really don't know what to do with it beyond this point

[ghost]

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]

Based on @DaveTryon investigation, we could detect PDF files and provide messaging. Leaving as needs investigation as this needs PM input on messaging / design. Some early thinking would be using the banner at the top (similar to how we notify of iframes)

[ghost]

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]

Note that for some variants of this (specifically, scanning image files), https://github.com/dequelabs/axe-core/issues/3465 will cover avoiding one of the more extraneous failures (where axe-core complains that the boilerplate page doesn't have a lang attribute).

[DaveTryon]

@mgifford, we're taking the position that if a user clicks on a link and gets an inaccessible HTML page, that's an accessibility bug. The user knows nothing about how that HTML was created, and they shouldn't need to--the end result is simply broken. The best answer here is arguably to teach the browser how to generate a more accessible boilerplate page, which helps the user at no cost to the developer. For example, if the browser were to copy the parent page's lang tag and the alt text from the original link, that would cover most of the errors that get reported.

Thanks for using Accessibility Insights!

[mgifford]

Thanks @DaveTryon. There is a lot to be said for that approach. However, it would be a lot better if Edge & Chrome were actively working on a feature like you describe. I wish more browsers cared about UAAG. 

From a very practical perspective. Less is more. Accessibility teams need to be focused on actual violations. 

axe evaluates HTML. If the page isn't HTML, what value is an axe assessment?