Accessibility WG Teleconference Minutes 03-11-2010

Sakai Accessibility Working Group Teleconference

March 11, 2010 - Notes by Eli Cochran

Attendees:

• Brian Richwine, Indiana University
• Gonzalo Silverio, University of Michigan
• Eli Cochran, University of California, Berkeley
• Lucia Greco, University of California Berkeley

Agenda:

1. Gonzalo's Work on the Accessibility Jira Tickets
2. Sakai 2.7 Accessibility Review Progress
3. Accessibility Statement

Gonzalo's Work on the Accessibility Jira Tickets:

• Gonzalo sent out an summary of the current state of the Sakai 2.7 Accessibility work just before the meeting:

  In the past few weeks, thanks to members of the community, specially Mary
  Stores and Brian Richwine. the list of outstanding accessibility issues has
  changed:

  19 issues have been fixed, and are awaiting verification.

  21 issues have patches supplied which need to be evaluated and applied if
  they pass judgment.

  9 issues have been clarified to the point where they may be evaluated for
  closing, retargeting or some other action that takes them closer to
  resolution.

  A smaller number of issues have been closed as duplicates, non-issues or
  because they were fixed in the process of doing some other work. Some of
  these issues were very old.

  Of the issues remaining the major ones involve the FCKEditor and <select />
  navigation menus. The FCKEditor issue has been receiving some attention in
  the lists in the context of a possible upgrade to the CKEditor, which was
  evaluated positively by Ken Petri. The issue of the upgrade was discussed at
  the product council.

  If you have some spare time your review of the issues that need
  clarification and/or a suggested solution would be much appreciated. This
  list can be found here:

  http://confluence.sakaiproject.org//x/eA0QB

• The 21 patches are currently in a state of limbo. Each patch needs to be reviewed and integrated. We're not sure who can take this on.
  • There is some concern and uncertainty about whether the Release will accept changes that are not "blockers".
  • Eli will contact Alan Berg and Anthony White of the Maintenance Team to see if we can get some clarity and to see if we can find someone to review and commit the patches.
• Decisions need to be made about a half dozen issues at this point. Is there someone else who can participate in the review process?
  • Brian will craft a message out to the community for some help.

[_at this point in the meeting, Gonzalo had to leave and Lucy joined us. what ensued was a fairly free form discussion of a CIC (Committee on Institutional Cooperation) project to develop a unified accessibility protocol for software projects to be used across educational institutions. This project includes a sub-group that is focused on LMSs, defining core/common features, and then testing and documenting the accessibility of each of those features for leading LMS). This project in a fairly early stage. University of Illinois is leading, Indiana University is participating.

We should keep an eye on this process.]

• For the 2.7 release, we have had the help and attention of Gonzalo to get a bunch of bugs fixed or otherwise closed (See notes above). There is concern about who will keep on top of accessibility bugs for future releases.
  • One problem is that accessibility issues are often dismissed, either because developers don't understand the problem, the impact of the problem or a solution to the problem.
    • Gonzalo worked with Brian and Mary Stores to help them understand how to frame an accessibility issue so that it will be understood and acted upon.
  • Another issue is that developers don't have access to adaptive devices or have the expertise to know how those devices are used.
    • Suggested solution is that developers need to know that there are members of the Accessibility WG who can collaborate and work with them to test fixes and improvements.
    • Brian will start a list of people who are available to consult and collaborate with developers. The rest of the community should sign on and sign up.
  • Another problem is that developers sometime do not priorities accessibility problems.
    • While setting hard priorities is always a challenge on open-source projects, having clear criteria supported by the Sakai Product Council should help.
    • The Accessibility WG will work towards developing good criteria and getting buy-in from the Sakai community and leadership.

Sakai 3 Accessibility Statement

• Since we published the statement for review, we've only received one comment (positive).
• We feel that the statement is ready for release and will do so.
• We would like to see if the same statement is applicable for future Sakai 2.x development.
  • Eli will craft an email for the Sakai community proposing that the same standard be applied to all future Sakai development destined for Core release.
  • We need to research if there is a historical statement for Sakai 2.x. Suggested that we ask Mike Elledge

Next Steps

• time to follow up on the statement with clear goals and guidelines.
  • Brian will recruit a smaller group to start to pull these together.
  • Suggested that we use JIRAs as a way to identify common problems.
  • Suggested that we mine existing rubrics and guidelines from other projects.

[Please feel free to make an additions or corrections - Eli]