From the Accessibility 360 spreadsheet, we have 53 rows handled, and 59 more to go.

All "Critical" items (Accessibility 360 report) are now accounted for.

Developer plan for handling issues.

This could be a good opportunity for community developers to learn about UI accessibility issues and standards.

It could also be a good opportunity for pair programming, to tackle / break down issues between devs.

How should we proceed working through rest of the spreadsheet?

Currently all Github accessibility issues are "critical", and logically the ones devs should tackle first. If we keep creating new Github issues for "serious" or "warning", will these get worked on first by mistake?

See what Steve thinks about this situation.

If Steve or community thinks these issues should be the current focus, we as a sub-group still want to finish refining/creating/editing issues for triage and keep making good progress. Should we start working on a new Hyrax Accessibility Milestone to house "serious" and "warning" Accessibility 360 issues? And then prioritize that once "criticals" are done?

Guesstimate on remaining work refining/creating issues.

Our sub-group could have all the remaining report items turned into Github issues within 3 weeks if we carry on (by end of May).

Action items

Re-request creating the "blacklight" label. It's helpful for a dev to know a particular UI partial/component is coming from Blacklight.

Update Steve that the most critical issues as of Hyrax 2.1 are refined to a point in Hyrax Github where they are actionable by any developer.

Now could be a good time to advertise to the community that there are 31 issues, pre-groomed, and critical. It's a manageable number, and they're all at the highest priority.

Get feedback from Steve/community on how our sub-group should move forward.