Refine plan of proceeding with refining "Serious" Accessibility report issues.
Discussion items
Time
Item
Who
Notes
What to do next with 'Critical' items? Update on their status in Github.
Any existing Github 'accessibility' issue with both an 'accessibility concern' and 'priority' label maps to 'Critical' issues here: https://goo.gl/uz4Yy3
What to do with 'Serious' items? Proceed as we did with 'Critical'? How to differentiate their priority?
Any existing Github issue with only an 'accessibility concern' label means it's mapped to a "Serious" or "Warning" issue.
What to do with existing Github issues groomed in Hyrax?
Any refined existing issues in Github can be worked on. Not waiting for anything. Plan is to just plug away at the issues, and the progress can be viewed through the Accessibility milestone.
How to make sure all documented accessibility issues do not disappear, or re-appear in the future?
Ensure they don't disappear, write view tests to track current work.
How to ensure it doesn't happen in the future? Through documentation?
Is there an "Accessibility" section in current developer documentation? If not, maybe sum up Accessibilty360 audit report findings into some general guidelines.
How to ensure continued focus on accessibility on new Hyrax features? Does someone or some team do an internal audit, say every 3 months or so? Or do we hire an outside consultancy every 3-6 months? Or does this audit occur before every major release?
Action items
Adam will announce the current Accessibility sub-group progress in the UX Interest Group meeting tomorrow (Tuesday, May 15th).