Sakai UCamp Accessibility Colin Clark Inclusive Software Architect

Sakai U-Camp: Accessibility Colin Clark, Inclusive Software Architect, Adaptive Technology Resource Center, University of Toronto Mike Elledge, Assistant Director, Usability & Accessibility Center, Michigan State University

Topics • • What is disability? What is accessibility? What are Sakai accessibility objectives? What is the state of Sakai accessibility? What resources are available? How do I design accessible interfaces? What does the future hold for accessibility and Sakai?

Defining Disability • In context of a learning environment: • Disability is artifact of a mismatched relationship between a learner and the education offered • Not a personal trait • Thus accessibility is the ability of learning environment to adjust to user needs

Defining Accessibility • Flexibility of education environment, curriculum, and delivery of content • Availability of alternative and equivalent content and activities

Accommodation Strategies • Multiple versions • Single component approach • Adaptable components

Problem with Multiple Versions • “Accessible” version not maintained and becomes outdated (eg. text-only version) • Unequal access to resource • People with disabilities are not a homogenous group

Limitations of Single Component Approach • Accessible for everyone but optimal for no one • Design decisions often do not make the experience better for all users (breaks the “curbcut rule”) • Time and expertise required of all resource creators • Reluctance to use new or innovative technologies • Valuable resources that are not compliant are often rejected

Types of Disabilities • Hearing—Conductive, sensorineural • Visual—Color blindness, low vision, blindness • Cognitive Impairments—ADD, Dyslexia, TBI, environmental • Physiological Impairments—Temporary, permanent

Incidence of Disabilities

Video Clip of Blind User • Web content is read by screen readers (like JAWS) and blind persons navigate with the keyboard • Benefit from keyboard shortcuts, organized content, contextual clues www. webaim. org/media/video/kyle. asx

Sakai Accessibility Objectives • To comply with Section 508 and WCAG 1. 0 Priority One, Two and (partial) Three • To go beyond compliance and be usable to persons with disabilities

Sakai Accessibility Elements • Navigation: Accesskeys, skip links, headings • Content: Titles, summaries • Functional: Label For/ID, Fieldset/Legend, Scope • Presentation: CSS

Sakai Accessibility Issues • • • Magnification > 200% Content i. Frame JSF “Accessibility” Content collapse (CSS) “Bugs” – – Text Editor Code burps Onkeypress clean-up http: //bugs. sakaiproject. org/jira/secure/Issue. Navigator. jspa? mode=hide&request. Id=10254 • Testing new versions and tools

Accessibility: WG • Confluence: Resource, archive – Developers checklist, testing protocol, results – Current accessibility, history, charter – http: //bugs. sakaiproject. org/confluence/display /2 ACC/Home • Collab: Discussion – Accesskeys, AJAX/Dynamic HTML – http: //collab. sakaiproject. org/portal

Designing Accessible Interfaces • Accessibility principles are design principles • Challenges of inclusive design • Inclusive design techniques

Components of the Web • Content: – the user interface – underlying information – application behaviour • • User Agents: a nerdy name for the browser Assistive Technologies Authoring Tools Evaluation Tools

Accessibility Principles • From WCAG 2. 0: – 1. Content must be perceivable – 2. Interface components should be operable – 3. Content must be understandable – 4. Content should be robust & forward-looking

Does this Sound Familiar? • • • These are design principles! Design for consistency Design useful navigation schemes Design and test forms Make things readable and understandable to the user

Challenges for Designers • The Web is a medium that should be plastic and highly adaptive • Need to design multiple user experiences • Design for less-than-ideal circumstances

Inclusive Design Techniques • • • Understand users with disabilities Label everything clearly Design for separability and change Enable different control strategies Provide alternatives or augmentations for everything

Future Sakai Accessibility • • Frameless portal and integrated tools Dynamic content Transform. Able Flexible UIs: the Fluid Design Project

Transform. Able • Web services to help with Web application accessibility • Prefer. Able: allows users to specify personal display and control preferences • Style. Able: restyles user interface • Sense. Able: rearranges and augments content • Currently being integrated into Sakai • We’re behind schedule but moving along

Fluid Design • Responding to the need to improve usability and accessibility in community source projects • Create both technologies and processes • Enable design contributions • Share user interface components • UI components as design patterns

Why Create a Flexible UI? • • To address unique institutional needs To address needs of different disciplines To address cultural differences To simplify internationalization & localization • To ensure accessibility • To accommodate diverse individual needs • To support device independence

Fluid Project Goals • Make it easier for designers to get involved in community source software • Enable pooling of UI resources • Encourage loosely coupled UIs • Facilitate wide-scale testing • Enable transformable user interfaces • Improve consistency of user experience

Provide Technical Supports • Provides a consistent model for UI components across applications • Establishes a single API for configuring components • Provides a consistent way of specifying site-wide customizations such as skins • Decouples UI from application logic • Enables easy switching of components to meet diverse user needs

Q&A