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.
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:
- Chat Room
- My Workspace--Membership
- My Workspace--Preferences
- Site Setup
- Web Content
- Worksite Setup
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)
- Drop Box
- My Workspace--Profile
- Tests & Quizzes
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:
- Sakai 2.2 Accessibility Review
- Sakai 2.3 Accessibility Review
- Sakai 2.4 Accessibility Review
- Sakai 2.5 Accessibility Review
- Sakai 2.6 Accessibility Review
- Sakai 2.7 Accessibility Review
- Sakai 2.8 Accessibility Review
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).
- "Accessibility Issues" list in Jira (searches text for "accessibility")
- Alternate Accessibility Issues view in Jira (Issues with Component=Accessibility)
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:
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.
You can view other general issues:
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.
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).