2018-05-14 Meeting notes

Date

14 May 2018

Attendees

Goals

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.
	Identical issues found discussion.		From the ‘serious’ category, 14 issues are identical/similar to https://github.com/samvera/hyrax/issues/1268 1268 can be closed
	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?
	How to ensure focus on accessibility in Hyrax moving forward?		Maybe sub-group re-groups every 2 months to get current status on new features? If we can provide examples to developers of how to write tests which verify accessibility, can we make that a part of writing tests for new work items? Is it too much to ask of developers to require at least some tests which address accessibility, with code contributions? Create a "Lessons learned" document of what we know now post audit, and how and why this is important.
	Automated accessibility testing?		Is there any kind of accessibility automated testing which can be introduced into the build process? Given a set of UI inputs?
	Introduce some accessibility view tests into Hyrax.		"Lead by example" approach.
	General discussion about UX Interest Group		What does it do exactly? Should it be more of a parent Interest group for sub-groups? Accessibility sub-group has momentum. Could also fire up a "DURT" sub-group. Is the monthly meeting content too general or spaced too far apart for general topics? Seems like maybe more specific, focused, targeted topics (like Accessibility, DURT, JavaScript, CSS, etc)? Does Hyrax's heavy reliance on Blacklight impact reach of Hyrax UX concerns?

Action items

Adam will announce the current Accessibility sub-group progress in the UX Interest Group meeting tomorrow (Tuesday, May 15th).
Keep working on the "Serious" issues in the Google Sheets page.