Links to images being failed with `html-has-lang` and `image-alt` when scanning local files

[flcdrg]

Describe the bug

It seems like when you use the action to scan local files then links to image files are resulting in false positives.

My guess is that this could be because loading files from a directory does not provide MIME types like they would get if scanning over HTTP, or how the plain images are rendered by the browser.

To Reproduce

1. Given a page that has a link to a local image from another image (eg. like a thumbnail image that has a link that lets you load the full image
2. Run the scanner on the original page
3. Notice errors are returned for the URL to the image.

eg.

Calling the action in a workflow like this:

      - uses: actions/checkout@v2

      - uses: ./.github/actions/jekyll-build-pages
        with:
          verbose: false

      - run: |
          sudo find -type f ! -regex ".*\.\(html\|svg\|gif\|css\|jpg\|png\)" -delete
        name: Remove non-HTML
        
        # https://github.com/microsoft/accessibility-insights-action
      - name: Scan for accessibility issues
        uses: microsoft/accessibility-insights-action@v2
        with:
            repo-token: ${{ secrets.GITHUB_TOKEN }}
            site-dir: ${{ github.workspace }}/_site
            scan-timeout: 6000000
            max-urls: 1500
            localhost-port: 12345
            scan-url-relative-path: /

and there's one or more pages that render HTML like this:

<a href="/images/fullimage.png"><img src="thumbnail.png"></a>

Expected behavior

Non-HTML pages should not be scanned

Screenshots

Context (please complete the following information)

• OS Name & Version: ubuntu-latest
• AI-Action Version & Environment: v2

Are you willing to submit a PR?

Depends how easy it would be to fix

[jlperkins]

Hello! Thanks for reaching out. Would you be able to provide a bit more information about the structure of the pages where the images are displayed? From your example, it seems that you have some html pages which solely display a link to an image. Your example was: <a href="/images/fullimage.png"><img src="thumbnail.png"></a> If this is all that's included on the page, you may be able to fix these issues by adding alt text to the thumbnail image and wherever you display the full one, and by ensuring that you have set the language attribute at the top of the page. If I've misunderstood the setup of your html, please feel free to correct me and we can dig deeper into this issue.

[msftbot[bot]]

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

[flcdrg]

Hi @jlperkins, the original page does contain more HTML than that, and it does include alt text.

For example, the first URL flagged in the screenshot above is a URL for an image linked to on this page - https://david.gardiner.net.au/2015/01/2014-in-review.html

eg. this bit:

<p><a href="/assets/2015/01/wp_20150102_001%5b4%5d.jpg"><img src="/assets/2015/01/wp_20150102_001_thumb%5b1%5d.jpg" alt="Smoke rising from bushfire" /></a></p>

And as I understand it, it isn't https://david.gardiner.net.au/2015/01/2014-in-review.html being flagged, but rather it is https://david.gardiner.net.au/assets/2015/01/wp_20150102_001%5b4%5d.jpg (the direct URL to the image, not a HTML page at all!).

If I load https://david.gardiner.net.au/assets/2015/01/wp_20150102_001%5b4%5d.jpg a browser, and then press F12, I can see what I assume is the browser's internal way of rendering an image file. eg.

The HTML I can see there looks pretty much the same as what is being flagged by the action.

[flcdrg]

To be clear, this is nothing to do with my content. This will be true for any image URL. eg. you can see the same thing for this image (currently linked to from www.microsoft.com)

[msftbot[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!

[asksep]

The Accessibility Insights team understands the problem you are experiencing, we are investigating next steps on how to handle these cases where the scanner is scanning some files (non-html) it perhaps should not.

[jlperkins]

Thank you for following up! I hadn't understood your situation correctly but that makes sense--we don't intend for our accessibility rules to be run against any pages besides HTML. We will investigate further how we will best exclude those pages. Thank you for bringing this to our attention.

[karanbirsingh]

Hi @flcdrg - I took a closer look this week and was hoping you can help. I made this demo repository using the latest action release (v3). I'm unable to reproduce accessibility errors on the image URL itself, only on the home index.html page.

Do you have a link handy to your repository or a modified version of my demo that fails? That would help me debug further. So far I'm seeing valid MIME types when I use the GitHub action to host the website. Thanks!

[msftbot[bot]]

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

[msftbot[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!

[flcdrg]

Let me take another look and see if I can still reproduce it.