@colinxfleming I'd like to tackle this. Here's what I'm thinking:

• Generate reports on a subset of pages
• Assess and prioritize fixes
• Potentially add a11y linting step to CI process

@valeriecodes I think that's a wonderful game plan, and consistent with how we've done reviews on this project. (Personally, I take it to be a good sign that our approach matches yours!) I also think that this can be done independently of case management feedback, so no need to wait on that if you've got the energy to tackle this.

in short, thumbs up, this is a great plan. Is there a way I can be helpful on any of the parts you've identified?

@colinxfleming I'm gonna take a run at generating some reports and then I'll loop you in. ✨

@colinxfleming Here's what I came up with: https://docs.google.com/spreadsheets/d/1qh08MwZhg6ILWrzx-rMKJK3hbNv4RI8Z4s1k0osNieE/edit?usp=sharing

These are generated using axe and axe-reports, with a Selenium script that I wrote and ran locally. There's certainly more surface area to cover.

I ran the report on a handful of pages and sorted by severity of issue. There are a lot of duplicates for items that are shared between pages. The critical issues all seem to be: images missing alt text or form fields missing labels. In the serious category are a few color contrast issues and lack of link label/text.

honestly I think if we get the main stuff that CMs interact with (login page, main dashboard, patient edit page) that gets us pretty far! and it seems that this does, so I think this is a wonderful list that makes a significant stride toward making DARIA much more accessible for CMs. (I think doing it for the other views is awesome too but the bulk of our users are case managers.)

It also looks like these are all pretty squashable -- I think either we can spin them up as small scope individual hacknight issues (which I'm happy to write) or @valeriecodes you are more than welcome to do the honor of knocking them out if you're so inclined. Which approach would you prefer to take?

If you still have the script handy, having that checked in would be dreamy, but NBD if you don't anymore or don't want to check it in for whatever reason.

I'll knock 'em out! The script is here: https://gist.github.com/valeriecodes/459cf5e4039cc5b0ec3034cd0236b4c3
I did it semi-manually and would require some additional work to turn into something that could be run and have it spit out something useful on any computer, but with that caveat I'm happy to check it in still if you'd like.

I def don't think it's necessary to make it reproducible, but I do think it's good news to have some reference to what happened in case we do decide we need to look at it again someday. thank you very much for checking that into a gist!

@valeriecodes feels like the meat of this got resolved in #1704, but I'm curious about the a11y linting step - would you recommend we implement that (and if so, can you recommend a strategy?), or does that feel like more trouble than it's worth?

not to minimize the importance of this but I think at this point we won't be doing much on this further unless a fund specifically asks for it and IDs specific problems. Not sure we have the expertise to do this properly independently (to say nothing of the engineering headroom). Closing as a wontfix for the time being, and big thanks to @valeriecodes for doing some wonderful work on this.

I can pick this up now. Will create separate issues for the findings and add the appropriate "Beginner-friendly" label so that Code for DC folks can pick them up.