Summary of Brock University’s Audit of Sakai CLE 2.9.1

In the summer of 2013  Brock University  commissioned a partial Accessibility audit on  Isaak, Brock University's Sakai-Based LMS . What follows are some of the results of this audit conducted by  AccessIbility Advantage .

The report is the property of  Brock University . Brock University is sharing some of the findings of this audit with the broader Sakai CLE community in the hope that the success the Sakai CLE has achieved in accessible design can be noted and that work to resolve ongoing issues can begin.

This report was created in the context of the recent updates to the Access of Ontarians with Disabilities Act (AODA) and its  Integrated Accessibility Standard Regulations  (IASR) Information and Communication Standard ( s14 ) which outlines accessibility requirements for public facing websites.  According to this act, Internet websites must meet WCAG 2.0 Level A initially, progressing to WCAG 2.0 Level AA. This applies to static websites, web applications, mobile websites and web applications.

The work conducted by AccessIbility Advantage was well received at Brock University.

Accessibility Advantage can be contacted through the follow information:

10 Overlea Boulevard, Toronto, Ontario, M4H 1A4, 416-425-3463 x7286,  http://www.AccessAbilityAdvantage.ca

Test Scope and Methodology

The intent of this evaluation is to provide a gap analysis to assist Brock University with determining the current state of accessibility of the site and to determine the work effort required to bring the website into compliance within the prescribed AODA timelines and WCAG 2.0 Standards.

The following process and tools were used to conduct the website evaluation:

•  Automated testing tools

•   Vision Australia AIS Toolbar
•   Deque  FireEyes accessibility plug-in  www.deque.com
•  WebAIM  WAVE Accessibility Toolbar

•  Manual Testing including keyboard test and HTML, CSS & JavaScript code review
•  Assistive technology testing: JAWS, NVDA & VoiceOver screenreaders & ZoomText Screen Magnification.
•  Review of University of Illinois at Urbana-Champaign research study: A Comparison of Learning Management System Accessibility;  http://blog.bargirangin.com/2013/03/a-comparison-of-learning-management.html
•  Review of the SAKAI Accessibility Working Group notes.

Matt Clare, Elearning Manager, Centre for Pedagogical Innovation configured a workspace for the accessibility audit and provided both student and instructor accounts.

The evaluation included a review of:

•  Workspace Home
•  Schedule
•  Tests and Quizzes
•  Forums
•  Resources
•  Announcements
•  Assignments
•  DropBox
•  Lessons
•  Chat
•  Messages
•  Course Modules (Brock University original content)

Summary of Findings

Overall accessibility of the SAKAI Learning management system is good. For the most part the user interface meets WCAG 2.0 standards and is accessible and usable with assistive technology with some exceptions. Modern web accessibility techniques such as WAI-ARIA , are used effectively throughout the application to enhance navigation and convey user interface behaviours and semantic, structural information to screenreader users. There is, however, some inconsistency in the application of accessibility standards within certain tools or elements of the LMS. 

Sakai Accessibility Features

Overall compliance with WCAG 2.0 Level AA success criteria is generally good. Some of the accessibility features include:

• WAI ARIA landmarks are used to enhance navigation (e.g. role: banner, navigation, main)
• WAI ARIA roles are used to make the pull down menus more accessible for screenreader users.
• Skip navigation links become visible on focus and include hotkeys for quicker navigation.
• The majority of the form fields have programmatic labels.
• A visible keyboard focus is present.
• Frames have meaningful titles.
• Menus are keyboard accessible and are understandable with JAWS.
• Relative font sizes are used allowing a user to scale to 200% without loss of context.
• The calendar is coded as a table and table headers are marked up to facilitate understanding of relationship of data cells to headers
• Windows system colours are inherited allowing the user to set their own colour themes.
• Colour contrast is generally good.
• Headings are marked up.
• The Rich Text Editor includes accessibility help.
• Overall the user interface is consistent and relatively easy to navigate and understand.
• Each page has a unique title and language indicator.
• Table headers are marked up and table summaries and captions are relatively consistently used.
• Table sort functionality is keyboard accessible.

Sakai Accessibility Issues

Possible Solutions 

1.1.1        Input Fields

WCAG Checkpoint(s): 1.3.1 Information and relationships (A)

Severity:                           Critical

Description:           

Some of the form input elements are missing explicit, programmatic labels. Without programmatic labels a screen reader user will not know what the purpose of a field is and a voice recognition user will be unable to directly navigate to the desired field.

There are multiple techniques for adding instructional information to labels depending on the design of the input.

Remediation:

1.           Add an explicit label to every input field.

Example;

<label for="firstname">First name:</label>

<input type="text" name="firstname" id="firstname" />

To test whether an input field is correctly labeled, using the mouse, click on the label and the cursor focus should move to the associated input field.

2.           Group related input fields with fieldset and describe them with a legend

Input fields that logically grouped together should be wrapped with a fieldset attribute and described with a legend.

3.           Each id must be unique and match the label’s for attribute.

4.           “Hide” labels that are not visually displayed

If the design of the input is such that a visible label / advisory information is not desirable, then a CSS technique for “hiding” the label should be used. Please note that while we want the content “hidden” we still want it available for assistive technologies users. e.g. Hiding content visually (but still accessible)

.accessibility-hidden{

position: absolute !important;

clip: rect(1px 1px 1px 1px); /* IE6, IE7 */

clip: rect(1px, 1px, 1px, 1px);

height: 1px; width: 1px;

margin: -1px; padding: 0;

overflow: hidden;

}

The CSS class – .accessibility-hidden – should then be referenced from within the HTML element, as shown:

<label for=”input”  class="accessibility-hidden" >

                 This text is hidden.

</label>

5.           Advisory and error information

Advisory information, like the required info, and the error messages should be included in the label. In order to maintain the design / layout CSS can be used for positioning. In the example below an ARIA & HTML5 technique is being used:

Sample code:

<label  for=” txtCName”  ...>

               Course Name

               <span  title=”required”  ...>*

               </span>

</span>

<input  id="txtCName" aria-required=”true” required  type="text" ...>

Resources:

Accessible form labeling instructions

Web Standards Project Accessible Forms Course

Invisible Content Just for Screenreader users

1.1.2        Form Validation and Error Handling

WCAG Checkpoint(s): 3.3 Input Assistance (A & AA)

1.3.1 Information and relationships (A);

4.2 Name, Role, Value (A)

Severity:                           Critical

Description:           

Error handling and presentation of errors is inconsistent in Sakai, sometimes the message appears below the form and other times it is at the top of the screen. The majority of error messages appear in a red box to increase visibility. However, cursor focus does not automatically move to the cursor message making them hard to find.  

Best Practices for Error Handling:  

• If an error is detected, focus should move to a div containing all the error messages.
• The error section should be preceded with text that tells the user that errors were found. This text should be marked up as a heading.
• Errors should be presented as a list of links. Activating the link takes the user directly to the field with the error.
• The field label should be changed to include instructional text e.g. “this field contains an error”; “phone numer is 10 digits”.
• The field with the error should be visually highlighted using colour.

Resources:

Usable and Accessible Form Validation and Error Recovery

Accessible Forms - Nomensa

Scotiabank Visa Application - Accessible form validation example

1.1.3        Modal Dialogs

WCAG Checkpoint(s): 1.1.1 Non-text content (A),

1.3.2 Meaningful sequence (A),

2.1.1 Keyboard (A)

Severity:                           High

Remediation Effort:   TBD

Description:           

A modal dialog is used to present the tutorial in a Welcome window.

Remediation:

Requirements for an accessible modal dialog include;

• modal can be activated via keyboard,
• focus must be managed so that it is brought to the dialog when launched and that it remains inside the dialog as the user tabs through the controls and reads the content.
• content (including images) is accessible,
• can be closed pressing ESC key,
• focus returns to launching point when the dialog is closed.

Possible solution: Use jquery modal dialogs; many accessibility features already incorporated into the framework. E.g.   http://hanshillen.github.com/jqtest/#goto_dialog

Work Being Done With Results

This linked Google Sheet tracks the progress of issues identified in this audit moving into Sakai's JIRA bug tracker and into production.