Child pages
  • Sakai CLE Current Accessibility

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

Web Accessibility Compliance

Compliance to Section 508 (and the stated goal of meeting WCAG 2.0 A & AA Success Criteria) varies from tool to tool, and to a certain extent depends on how tools are configured. It's also true that much of a disabled user's experience --and how accessible Sakai feels to that user -- will be determined by the content uploaded to it, and so a course with good accessibility will also require some forethought on the part of an instructor or course designer.

Compliance Standards


Since the current Section 508 standards were implemented in 1999, the WCAG 2 Level A and AA Success Criteria, and their associated techniques for success, have become the internationally recognized standards to meet for accessibility conformance. If the WCAG 2 Level A and AA Success Criteria are met, then the Section 508 §1194.22 Standards will be met. It is possible to meet all Section 508 §1194.22 Standards, and not meet the WCAG 2 Level A and AA Success Criteria.

Generally Accessible Sakai Tools

Tools that follow most accessibility guidelines include:

  • Announcements
  • Assignments
  • Chat Room
  • Gradebook
  • Home
  • My Workspace--Membership
  • My Workspace--Preferences
  • News
  • Permissions
  • Resources
  • Site Setup
  • Syllabus
  • Web Content
  • Worksite Setup

WYSIWYG editors


Any tool or task that requires the student to use the JavaScript WYSIWYG editors, and the other Rich Text Editors found in Sakai, will pose challenges to non-mouse users (low-vision, blind, and users of alternate input devices).

No one has perfected an accessible JavaScript WYSIWYG editor. The CKEditor – which is expected to be included with Sakai 2.8 – is generally accessible, however can require significant effort on the part of an adaptive technology user to learn how to use it effectively. It is the most accessible WYSIWYG editor we have tested. A less obvious, but big plus with the CKEditor, is that users would gain the advantage of being able to paste documents into the editor from more accessible external editors (like MS Word) that they are likely much more competent at using with their adaptive technologies.

Sakai Tools Requiring Improved Accessibility

Some tools still need work to improve their accessibility. These include the following:

  • Administrative Tools (Users, Aliases, Sites, Realms, M, On-Line, Memory, Site Archive)
  • Calendar
  • Drop Box
  • Forums
  • My Workspace--Profile
  • Roster
  • Tests & Quizzes
  • Wiki

Sakai has been tested with current versions of JAWS using both Internet Explorer and Firefox. Compliance has also been evaluated using manual code inspection, the Firefox Accessibility Extension add-on, the WAVE Web Accessibility Evaluation tool, and W3C Validator in order to continually improve accessibility.

Sakai 2.8 Accessibility Improvements

For 2.8, an attempt was made to resolve the most serious issues that were identified during the Accessibility team's review of a 2.8 beta QA server. In particular, all issues of the highest two levels of severity (critical and blocker) are resolved in 2.8.0 (as long as the the installation uses CKeditor as the default WYSIWYG editor).

Note that Sakai has many optional tools. The review looked only at 11 core tools.

There is one exception: there is a problem in the way Internet Explorer handles pulldown menus (the select element). This problem is considered to be at the critical level. This problem does not occur with Firefox, Safari, or Chrome. It may also be dealt with by asking users to open the pulldown menus with Alt+Down Arrow in Internet Explorer. Hidden text has been placed in the tools to remind screen-reader users of this.

Sakai 2.7 (current release) Accessibility Improvements

Cleaned up table mark-up, added context to ambiguous link texts, improved keyboard accessibility

Sakai 2.6 Accessibility Issues and Enhancements

Sakai 2.6 is accessible to persons using most adaptive technology, although it has several issues we are continuing to address.

Please note that the compliance pages refer to the Sakai Enterprise tools and not provisional tools such as OSP, which have not been evaluated for accessibility.

Results from Accessibility Reviews by Version:

Accessibility Issues


As we find problems, we put them in the Jira queue for repair (jira is the system used for issue and bug tracking related to Sakai development).

Note: The lists may contain some items that do not relate to accessibility, due to Jira's text based search mechanism.

Several issues remaining to be resolved:

Content Generation

The WYSIWYG editor does not provide a keyboard-based exit from the text input box.


Sakai does not enlarge well beyond 2 times due to a problem with its use of frames. Sakai currently has an iFrame for page content. We are hoping to provide a frameless version of Sakai in the near future, which would improve usability for persons using screen magnifiers. Also, tools that are refactored to be JSR-168 compliant will work without frames. A schedule for either implementation has not been established.


Sakai relies on JavaScript for some basic top of page operations, including setting permissions and options. It is our understanding that javascript will be permitted under the upcoming WCAG 2.0 guidelines, so at this point we have chosen not to provide alternative, non-script functionality. Instead we will note within the Accessibility page in Sakai's help that JavaScript needs to be enabled (per WCAG 2.0 baselines) for Sakai to work.

You can view other general issues:

Accessibility Enhancements

Making Accessibility Usable

We have also included a variety of skip links, accesskeys, headings, titles, form and table attributes, and utilized stylesheets in Sakai to improve usability for adaptive technology (AT) users. For a description of how to take advantage of them, please take a look at the Accessibility section in Sakai Help.

Future Enhancements

Some tools rely on Java Server Face (JSF) widgets. Although they incorporate accessibility attributes, it is best to customize JSF widgets to make them fully WCAG compliant. This will be done as time and resources permit. University of Toronto is working on an interface that will enable users to customize Sakai presentation (such as enlarged text, white font on black background, etc.). And there are plans to introduce a content repository and device-dependent authoring system piloted by the University of Toronto. Sakai 2.4 contain provisional tools that do not require iFrames, and can serve as templates for future iFrame-free development (written using JSR-168).

You can view other enhancements by version: