Child pages
  • Summary of Brock University’s Audit of Sakai CLE 2.9.1
Skip to end of metadata
Go to start of metadata

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,

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
  •  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;
  •  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




Left navigation

Colour contrast should be 4.5:1 at minimum.

The Active menu item is indicated with a different colour than the other menu items. The colour contrast is insufficient (2.67:1).


My workspace

Skip link

jump to content link doesn’t work on this page


Modal dialog

When a user first logs in they get a welcome dialog that includes a tutorial. The cursor focus is not moved to the modal dialog when it first appears, making it very difficult for a screen reader to find it. It is actually added to the DOM at the very end of the code order. It is the last thing that you navigate to on the page after going through all the footer links.

In addition the persistence (always visible) of the modal window means it appears to ‘jump’ as you scroll down the page. This is very visually distracting.

The keyboard focus will need to be managed. Further discussion about creating accessible modal dialogs is included in section 5.3.3.


Mouse only rollover

The edit button becomes visible only when the mouse is rolled over a specific profile item. The edit button should be visible at all times, or it should, at minimum become visible on keyboard focus as well as on mouse hover. A screen magnifier user (ZoomText) would have difficulty finding the button as they pan their view window across the screen. A voice recognition user would not be able to activate the edit button because it is not visible.

The information ‘buttons’ are also activated only on mouse hover. They take keyboard focus but do not open.




  • The form fields in the editor are missing the label for / id association.
  • Tables are used to lay out the form.
  • TinyMCE editor not fully keyboard accessible.
  • Datepicker is not keyboard accessible.
  • Keyboard trap. Cannot back-tab once focus is in the text editor.


Error messages and form fields

  • Form fields are missing explicit labels
  • Error messages do not take focus and might be difficult to find for some users. 

Add Event

Error messages

  • Some form fields have labels. This can be improved by including the mandatory notification (*) in the form label.
  • Form fields without visible labels should still have either hidden programmatic labels or titles. Related fields should be wrapped in a fieldset E.g.


  • Error messages do not take focus and appear in the middle of the screen making it difficult for screen reader or users of screen magnification software to find the message.  


Instructor workspace


  • The table summary does not match the table contents.

Tables - general

Table markup

  • In general the table header rows are marked with TH. Row headers are not marked up. For simple data tables this has minimal impact for end users however the schedule and calendar tables often have a blank row header for ½ hour time slots. This is most likely to reduce visual clutter but the lack of a row header makes it difficult for a non-visual user to orient themselves.
  • Tables often have hidden columns. A screen reader will announce the total columns in a table and this does not match the actual table makeup. Etc. Resources table; 10 columns but only 7 have content.


Form labels and keyboard accessibility

Form field labeling is inconsistent:

  • Radio buttons have a label for / id association. These should also be part of a fieldset with the question as a legend.
  • Text input fields are missing the label for / id association.


Keyboard accessible and logical order is inconsistent:

  • Error messages should take keyboard focus to facilitate discovery.
  • Tab and reading order is not logical for multiple choice questions.

Matching questions are not accessible.

  • The select boxes are missing programmatic labels. A non-visual user would have difficulties determining what the matching options are because of how the interactive and static text is displayed.



Not all images have unique alt-text.


Link names

The design of some tables and tools is such that there are multiple links or buttons with the same name. Differentiation using off-screen text or titles would significantly improve accessibility.

Possible Solutions 

1.1.1        Input Fields

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

Severity:                           Critical



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.




1.           Add an explicit label to every input field.


<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)



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.




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”  ...>*



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



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



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.


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


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


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.

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.

  • No labels