Attending:
Matt Clare
Neal Caidin
Tiffany Stull
Candace Girard
Rob Egan
rA11y Plan - Review accessibility plan
Receive SSB Bart audit results (E-Mail if you don't have access now)
- Begin verification and triage process
Ways we could get this information back to community/JIRA
- Dump 'em all into JIRA
- Tool-by-tool
- Severity/Triage
Need to consider Ways to get community engagement, Make sure community is both aware and ready for all of these issues - webinar, talk to core team,
We need ways to track Jira -> SSB
We should be watching for simple changes that A11y team can update directly in Github? For example alt tags (though need to think about internationalization). "Low hanging fruit".
Working plan:
Dump into to JIRA via CSV, per project
Label for SSB, Label for SSB's severity
Engage community
We talked on the Sakai Accessibility WG call about adding some labels and importing the export we have from SSB to JIRA through it’s CSV import functionality. We plan to do some additional triage, import the issues per-project AND alert the community while offering some more information in form yet to be determined.
Can we try this plan out on JIRA’s TEST project https://jira.sakaiproject.org/projects/TEST, owned by the Core Team? Matt C has written to core team about this.
Sakai accessibility help doc
UVa wants to break it up, it's probably too long and not in the Sakai help's current style - looks like everyone would benefit from this approach
Of concern:
Need to slice the main accessibility document up. Some issues/ideas:
Place some back with their associated tool/area of Sakai ie: Rich Text Editor's access keys etc.
Some content is simply out of date (refrences to iFrames)
There is too much content and some is redundent - there APPEARS to be examples of the access key c (jump to content) being explained for diffrent content contexts - this only seems confusing.