Show Axe images of offending elements

[joelhsmith]

Idea for a paid version of the app. Show images of offending elements. The data for the bounding rectangle exists.

"duplicate-id-active": {
    "details": {
        "items": [
          {
            "node": {
                boundingRect {
                "top": 102,
                "bottom": 127,
                "left": 175,
                "right": 282,
                "width": 107,
                "height": 25
             }
          ]
       }
    }
}

From visually contains.

I think this would only work for the Axe based version of the API. Maybe its available in WAVE. I have not looked.

[bbertucc]

This is a great idea. I've been testing integration with https://github.com/A11yWatch and @j-mendez too, that possibly could reproduce the offending element visually

[bbertucc]

Equalify is focusing on issue management (see EqualifyEverything/equalify#198) vs scanning. This issue should therefore be dealt with by a third-party scanning service, like https://github.com/dequelabs/axe-core/. You can also check out an experimental scanning service that we are building: https://github.com/EqualifyApp/scan

[bbertucc]

I'm re-opening this with a caveat... Since none of the automated scanning APIs offer screenshots, someone must either update a scanning API to include screenshots or write/find a new service for screenshotting offending elements.

I did a bit of looking and haven't been able to find any service that currently does this and it doesn't seem to be on the axe-core roadmap, see: https://github.com/dequelabs/axe-core/issues/2560

[mgifford]

That was a neat feature of OpenAssessIt @joelhsmith would be great to see it here.

[bbertucc]

I did a bit more scoping out of this. It would probably be best built as a plugin for axe core on our hosted axe distribution.

[joelhsmith]

The failed element images would certainly be a big driver to get people to subscribe to a hosted version. What was the tipping point in complexity that moved it out of the scope of the locally hosted version?

[j-mendez]

This is now built into kayle https://github.com/a11ywatch/kayle#clips. More efficient than axe and htmlcs with major changes and bug fixes. Will be released in A11yWatch later this week.

[j-mendez]

[j-mendez]

@joelhsmith I thought this issue was on the a11ywatch repo since I was tagged, looks like this is for something else. Ignore the post sorry!

[bbertucc]

The failed element images would certainly be a big driver to get people to subscribe to a hosted version. What was the tipping point in complexity that moved it out of the scope of the locally hosted version?

@joelhsmith - We're focusing this Equalify core on reporting instead of scanning. Lots of folks work on scanning, as @j-mendez exemplifies (hi Jeff!).

That's not to say we wouldn't build the feature. I'm keeping this ticket open because it is necessary. The work just wouldn't be in this repo - though I'm not quite too sure where yet.

My ;ast comment came after I spent a day experimenting with how to update unlighthouse to show clips instead of full pages. After digging into that, I realized that I could just use axe with Puppeteer's screenshot() menthod. In theory, someone would just have to write an axe plugin that delivered screenshotting into the axe output when Pupetteer was running.

If someone publishes that plugin, we could link to it in our core docs so that others can benefit from it.

[j-mendez]

@bbertucc hey! Nice, yeah the plug-in makes sense. One thing kayle does is use the html element bounding box directly for the screenshot position. For the plug-in you can use the axe object with Object.extendPropertyDescipter to extend the issue gathering with the raw element. Getting the box info upfront with ele.getBoundingRect will help avoid having to recall CDP to find each element and waste tons of bandwidth etc.

[j-mendez]

@bbertucc hey! Nice, yeah the plug-in makes sense. One thing kayle does is use the html element bounding box directly for the screenshot position. For the plug-in you can use the axe object with Object.extendPropertyDescipter to extend the issue gathering with the raw element. Getting the box info upfront with ele.getBoundingRect will help avoid having to recall CDP to find each element and waste tons of bandwidth etc.

I meant https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty for extending axe to get the element clip bounds.

[bbertucc]

This is still a great idea. Our Chrome extension, Project Raga, relies on screenshots, so this could be realized sooner than later.

I'm going to transfer it to our API repo because the first step to realizing this dream would be to include screenshots in API requests. (I assume we'll also need to update the Equalify Schema to support screen shots.)

[bbertucc]

This is an important feature, but we're not going to get it into Version 1. Tagging @wilsuriel03 on this ticket so future mockups represent a screenshot of offending elements for each node