(posted on behalf of Matt Clare, Brock University, Chair of Sakai Accessibility Working Group)

 

Thursday, May 18 2017 is Global Accessibility Awareness Day.

 

Sakai should have a positive impact on all who encounter it, a key part of this goal is how accessible Sakai is.

 

Today is Global Accessibility Awareness Day (GAAD) and part of GAAD is building awareness of what we all can do to promote access for, and inclusion of, people with different abilities.

 

Sakai has a good history of accessibility but recent versions of Sakai have not been released with a thorough review of the accessibility and to what degree it meets recognized international standard like the WCAG 2.  I’m pleased to share that thanks to community efforts in fundraising over $61,000 and 60 hours of development work Sakai’s accessibility has been reviewed by a recognized accessibility reviewer, SSB Bart, and our plans are to deliver Sakai 12 with an accessibility compliance statement.

 

This project, code named the rA11y plan, has lead to the review results have been reported publicly and work to address all the issues is almost complete.  Familiar members of the Sakai community have worked on the issues and experts such as TPG have contributed as well.

 

Developers and users of Sakai are learning how to create code and content that does not construct barriers for others.

 

The details of how the Sakai interface is constructed is important.  Sakai’s use of HTML and methods that meet the WCAG 2 Level AA specifications are important.  This includes a functional interface for persons who use screen readers and keyboard navigation.  It also includes making sure the persons who are blind or have otherwise low vision can perceive what they are presented and the Sakai supports scaling up to a 200% or more magnification and keeps colour contrast perceivable.  There are many other accommodations that are not always obvious, which is why being responsive to feedback and meeting agreed upon standards like WCAG 2, while not relying on a single method of access is the best approach.

 

The critical next step is helping those that use Sakai to teach and learn to create accessible content.

 

  • When you add content to Sakai, consider the POUR principle.  Is what you're creating:

    • Perceivable - Is the content presented to users in a way that they can perceive?  Does it rely on one sense? Have you considered how someone who isn’t well sighted might read that information, or how someone colourblind might?

    • Operable - Can the content be interacted with by someone not using a mouse?

    • Understandable - Are items like structural elements, like lists and headings, used in a meaningful way?

    • Robust - Content must be robust enough so that it can be interpreted reliably by a wide variety of technologies and devices, including assistive technologies.

Sakai’s help documentation includes recommendations on how create accessible content.

 

There is also a way for local administrators to include an accessibility checker into their instance of Sakai.  This separate plugin for the Sakai Rich Text Editor (CKEditor) performs a role like a spell checker for accessibility.  The results are useful, and have similar imperfections to a spell checker.  But perhaps the best outcome of the accessibility checker is the way it can build awareness of one's own bad and better practices in creating content.

 

On GAAD we’re encouraged to experience an alternative method of using the web such as:

 

Sakai is a tool that users often encounter during their own discovery and learning process.  Sakai is also a tool that almost everything added to it by a user will be encountered by at least one other user.  Today is a great day to discover and learn new ways of encountering the web and reflect on how others might encounter the content you create.