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
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:
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:
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.
Overall compliance with WCAG 2.0 Level AA success criteria is generally good. Some of the accessibility features include:
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).
jump to content link doesn’t work on this page
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.
Error messages and form fields
Tables - general
Form labels and keyboard accessibility
Form field labeling is inconsistent:
Keyboard accessible and logical order is inconsistent:
Matching questions are not accessible.
Not all images have unique alt-text.
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.
WCAG Checkpoint(s): 1.3.1 Information and relationships (A)
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;
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:
<label for=” txtCName” ...>
<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
WCAG Checkpoint(s): 3.3 Input Assistance (A & AA)
1.3.1 Information and relationships (A);
4.2 Name, Role, Value (A)
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:
Usable and Accessible Form Validation and Error Recovery
Accessible Forms - Nomensa
Scotiabank Visa Application - Accessible form validation example
WCAG Checkpoint(s): 1.1.1 Non-text content (A),
1.3.2 Meaningful sequence (A),
2.1.1 Keyboard (A)
Remediation Effort: TBD
A modal dialog is used to present the tutorial in a Welcome window.
Requirements for an accessible modal dialog include;
Possible solution: Use jquery modal dialogs; many accessibility features already incorporated into the framework. E.g. http://hanshillen.github.com/jqtest/#goto_dialog
This linked Google Sheet tracks the progress of issues identified in this audit moving into Sakai's JIRA bug tracker and into production.