UX design for alt text report

@kellysmith thank you. Yes I worked initially with the Accessibility team and did a loose round of requirements gathering. I left off filters for host entity and for title mainly because there are less important. It is really easy on a View like this to completely overwhelm by filters for everything. So I was trying to be.a little selective. Keep in mind if any site determined that they needed to be able to search title, they could add the filter themselves later, or if it was important to filter by node VS taxonomy they could also add the filter. If you feel they are important, please call it out and we can add them.

I'm not totally sure the "chip" idea (where I list the filters I searched for directly above the results) is possible, but I thought having just a quick view of what I filtered by could be useful to the end user.

The chip idea is a nice improvement in general to Views filters, but I don't see a contrib module that does that. (There might be one, I just haven't seen it). Even if there was one I don't think we'd want to include it because it would likely force chips on to all Views, and would be kind of opinionated for this module to add. So that change is pretty far out of scope I think.

will all the data in the table populate even if I don't filter by it? Or does it only populate when no filters/that specific filter is employed?

Views in Drupal usually start fully populated and then filter from there. Having a View start as empty and then populate when filtered would create a couple concerns.

1. It would change the nature of the "report" to being acting more like a "search", which would be an anti-pattern.
2. How would you ever get a complete / full report if the only way to make it populate is to add at least filter?

It will report every img tag that it can find. The filters should/would allow you to restrict it to only things with errors or warnings.

Good question. Every img tag < img > discoverable within the "content" will show in the report regardless of any alt or title attributes. Usually, true "decorative images" are on templates directly and are not discoverable as content. However, if someone puts a decorative image in the WYSIWYG it will appear in the report.

I think there are a few reasons to have them in the report:

1. An audit is not helpful if it lacks the ability to surface all things.
2. It could be vital to be able to filter for all "decorative" images so they can be examined to see if an editor was being disingenuous and taking the easy way out by labeling them decorative.
3. Yesterdays decorative may need to become tomorrow's content
4. alt attributes on a given media image are the same everywhere they are used, so in the original use of the image it might have been decorative, but in a subsequent instance it might have been intended as content.

This is looking fantastic. Thank you @adriancooke

This was fantastic work adriancooke and kesmith. It makes this report so much more useful. Your contributions are much appreciated.