The Accessibility of Course Management Systems: Can You Read This If You’re Blind? Joe Wheaton, The Ohio State University Ken Petri, The Ohio State University Alan Foley, The University of Wisconsin-Madison Mike Elledge, Michigan State University Kostas Yfantis, The University of Illinois- Champaign/Urbana

Why Accessibility? Accessible…  Content design improves learning for all users  Interface usability improves for all users  Page code is more portable, semantically rich (i.e., minable), & lighter  It’s [probably] the law “It’s the right thing to do”

Four Main Categories of Disability Accommodation  Visual (blindness, low-vision, color-blindness)  Motor (traumatic injuries, congenital disorders and diseases)  Auditory (full or partial hearing loss)  Cognitive (attention deficits, learning disabilities in reading, comprehension, memory, problem-solving, math or graphic interpretation)

Visual Impairments  Screen readers can render well formatted pages well  See an example at ibility/video/intro.asp ibility/video/intro.asp

Motor Impairment  A famous scientist at your university has ALS and is unable to use the mouse  He navigates the web with the special software that activates the keyboard

Auditory Impairment  A student researching famous speeches in American history  Student locates site with only audio clips of many speeches  Alternately, the student finds a great speech that is captioned

Cognitive Disability  Professor who struggles with reading comprehension understands much better through listening  Professor listens to websites through a screen reader like Kurzweil

Sakai Mike Elledge

Sakai Accessibility Elements  Navigation: Accesskeys, skip links, headings  Content: Titles, summaries  Functional: Label For/ID, Fieldset/Legend, Scope  Presentation: CSS  Mostly Section 508/WCAG 1.0 Compliant  JavaScript must be enabled  Scale > 200% not useable  JSF “Accessibility”  Content scrolling (CSS)  Miscellaneous “Bugs”  Natural language not identified in header  Code burps

Annotated Screenshot Jump to Worksites (h1) Jump to Tools (h1) Jump to Content (h1) (h2) (h3) (h4) (s)(x) “Table contains a list of announcements.” Label for / id “Sort by Audience” Go to Accessibility Information (h1)

Sakai Accessibility Information  Home Page:   Review Protocol and Templates:   List and Archive:   Compliance:   Repairs:  hide&requestId= hide&requestId=10254

What’s Next*  Eliminate last iFrame (screen resizing and navigation)  StyleAble: User-specified presentation (font size, reverse type, redisplay, etc.)  Identify/Integrate more accessible open source text editor  Enhance JSF widgets  Integrate accessibility reviews with QA process  FLUID Interface  Accessible AJAX  Sakai Materials Assessment and Repair Tool (SMART) *Proposed (“Yes, Virginia, there is a Santa Claus”)

WebCT Kostas Yfanis

WebCT Vista (Blackboard Enterprise Vista)  UIUC’s Flagship Learning Management System  1,100 courses  31,780 unique students  Accessibility Partnership  CITES Educational Technologies   Illinois Center for Instructional Technology Accessibility 

Illinois Compass Home

Sample Course

Accessibility Issues Existing Challenges  Pop-up windows  Java applets  Missing headers & image labels  Others: aborate/webct/problems.php aborate/webct/problems.php Improvements  Heading structure  Added alt text for images  Expanded labels for form controls  Language definitions

A Proactive Approach  Work with your accessibility team  Collaborate with other institutions  Do the versions match?  Can you involve the software developers and quality assurance team of the vendor?  If you use WebCT, then join our group 

Desire To Learn (D2L) Joe Wheaton and Ken Petri

D2L Class Page (v. 7.4)

2 Frames, No Headings

Fangs Add-on for Firefox

OSU’s Web Accessibility Center

D2L User-Vendor Collaborations  First accessibility audits by OSU Web Accessibility Center  Spring 2005 and 2006  Active collaboration begun June 2006  Accessibility panel at D2L 2006 Users Conference (UC06)  Current round of evaluations on pre-production version (v. 8.2)  Looking at specific interfaces and widgets/tools  Evaluations by “expert users”  Using matrix of UIUC “best practices” ( practices/) practices/  Semi-monthly teleconferences (  Collaborations using Google Apps for document sharing (

“Consortium” model for collaboration

Facilitating Remote Collaboration Functional testing using UIUC “best practices” matrix on Google Apps

Current Status and the Future  Improvements between versions 7.4 and 8.1  More consistency in markup of graphics (part of D2L build process)  Some improvements in naming conventions of graphics and tools  The future: Usability testing (if improvements merit)

Conclusions  All have many problems  All say they are trying  Much still depends on the accessibility of the content developed by faculty  We need accessibility checks as material is uploaded  Keep asking questions of the vendors  Get involved in the product selection  The Big Question: Open Source or Commercial?

Accessibility Enhancements  Version 2.01  Rewired auto-refresh  Skip links & accesskeys  Headings, titles, table and form elements  Version 2.1  Accessibility page and help information  Improved linearization, markup, labeling, link, hidden links  Added onkeypress

Accessibility Enhancements  Version 2.2  Accesskeys to common functions (save, delete, add, copy)  Enhanced title tags  Extended heading tags into table content  Captions to data tables  Version 2.3  Eliminated two frames  Increased use of CSS  Eliminated onkeypress code  Revised portal accesskeys to reflect UK eCommerce guidelines

Sakai 2.3 Accessibility  Mostly Section 508/WCAG 1.0 Compliant  JavaScript must be enabled  Scale > 200% not useable  JSF “Accessibility”  Content scrolling (CSS)  Miscellaneous “Bugs”  Natural language not identified in header  Code burps

Example - Visual Impairment

Accessibility is a Process  Accessibility can’t be learned in a day…  Training should extend over a long period…  Leaving accessibility to the end is NEVER a workable strategy. Accessibility is a design parameter, not a feature request.