Sakai Accessibility Working Group

Sakai Accessibility Working Group

Brian Richwine, Accessibility Working Group Lead, Indiana University

12th Sakai Conference – Los Angeles, California – June 14-16 2

About the PresenterAbout the Presenter

Brian Richwine, has a BSEE from Kettering University (’91) and has worked for the Adaptive Technology and Accessibility Center (ATAC) at Indiana University for 10+ years. Brian has been the lead of the Sakai Accessibility Working Group for 1.5 years.

About the Adaptive Technology and Accessibility CentersThe Adaptive Technology and Accessibility Center (ATAC) is part of the University Information and Technology Services (UITS) at Indiana University. The ATAC serves students, faculty and staff with and without disabilities by providing access to specialized adaptive technologies that help with reading, writing, studying, and information access.

The ATAC also promotes IT accessibility through performing accessibility evaluations, giving presentations, working on campus and professional committees, and providing other guidance as requested. Margaret Londergan, Director [email protected] http://iuadapts.indiana.edu/ (812) 856-4112

mailto:[email protected]

http://iuadapts.indiana.edu/

http://iuadapts.indiana.edu/



The Sakai Accessibility Working Group focuses on addressing Accessibility issues in Sakai. We can be found at:

https://confluence.sakaiproject.org/display/2ACC/Accessibility+Working+Group

Or, simply Google: Sakai Accessibility Working Group




What is Web Accessibility?

“Web accessibility means that people with disabilities can use the Web. More specifically, Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web.” – W3C Web Accessibility Initiative


What is Web Accessibility?

Simply put:Accessibility means all users (regardless of disability) can obtain the same information and perform the same functions.

An accessible Web site can equal freedom, independence, and privacy for someone who is disabled.


What is a Disability?

Disability is defined by the ADA as:

"a physical or mental impairment that substantially limits a major life activity.“

For many developers, Web accessibility consists of coding techniques that ensure accessibility for blind users and to screen reading software.

But, there is more to Web accessibility than that…


Disability Types

Types of disabilities:

• Low Vision, Blindness, Color-Blindness

• Deaf / Hard of Hearing

• Mobility and physical disabilities

• Cognitive or learning disabilities

• Epilepsy/Seizure disorders

• Medical disabilities


What is Adaptive Technology (AT)?

Section 508 defines “assistive technology” as any item or system — whether acquired, modified, or customized — used to increase, maintain, or improve functional capabilities of people with disabilities.

Adaptive Technology is also commonly referred to as Assistive Technology.


Adaptive Technology - Hardware

• Refreshable Braille Displays• Touch screens / Touch Pads• Alternative keyboards: One handed, configurable

keyboards• Alternative mice: Head mice, foot mice,

trackballs, joy sticks• Mouth sticks and head wands• Key guards• Single-switch inputs


Adaptive Technology – OS Features

• High Contrast Display Modes• Screen Magnification• Voice Recognition• On Screen Keyboards• Keyboard Settings (Sticky Keys, etc.)• Pointer Settings (Mouse, Input Text Caret)• Visual indication of system alerts


Adaptive Technology - Software

• Screen Magnifiers• Screen Readers• Voice Recognition• Reading / Writing Assistance


Adaptive Technology – Browser

• Page Zoom• Text Enlargement• Font Substitution• Caret Browsing Mode• Semantic Navigation• Custom CSS• Ad Blockers / Script Disabling


Adaptive Technology - App Features

• Synchronous closed / open captions for video• Visual indication of system alerts• Remote transcription• Accessible content creation


Screen-Reading SoftwareScreen reading programs help low vision or blind users complete tasks such as browsing the Web, sending and reading e-mail, utilizing spreadsheets, and accessing databases.Screen readers work alongside popular applications, reading information on the computer screen using synthesized speech. Screen readers can provide Braille output to refreshable Braille displays in addition to, or instead of, speech.An array of features and customizable options let users tailor a screen reader to their individual needs, preferences, and skill level.An example screen reader is JAWS by FreedomScientific.


Screen-Reader Demo

Here is a 4 minute video of Mary Stores using Sakai 2.7 with the JAWS Screen-Reading Software

http://www.screencast.com/t/MTlhMGMxMDg




Screen-Reader Demo

What did you get from that video?


Screen-Reader Demo

• Sakai is mostly accessible• Screen-reader users usually don’t read a

page through from top to bottom to find what they are looking for


More Disability Awareness

• How People with Disabilities Use the Web: http://www.w3.org/WAI/intro/people-use-web.php

• Web Accessibility: The User’s PerspectiveWebAIM: http://webaim.org/articles/

http://www.w3.org/WAI/intro/people-use-web.php

http://www.w3.org/WAI/intro/people-use-web.php

http://webaim.org/articles/


How is Web Accessibility Achieved?

Accessibility is accomplished by mindfully designing software to accommodate the widest range of users, including those with disabilities.



What the AWG does:• Accessibility consulting to the Sakai

Community• Performs accessibility reviews• Tracks accessibility issues (+ writes JIRAs)• Works to resolve issues• Writes accessibility documentation


Goal = Accessibility

Problem:• What does it mean for Sakai to be

accessible? • What are we striving for?• How do we know when we’ve done it?

Answer: • Accessibility Statements


Sakai CLE Accessibility StatementConsistent with the goal to make Sakai the most innovative and powerful Collaboration and Learning Environment, the Sakai community with the support and encouragement of the Sakai Foundation will ensure that all of the core features of the CLE are accessible and usable by the greatest number of potential users, including people with disabilities.

Ensuring that the CLE has as few accessibility barriers as possible provides a rich and enjoyable user experience for all users. Therefore, we will continue developing the CLE core to meet or exceed the accessibility design principals found in recognized international standards. Our goal is to meet all of the W3C Web Content Accessibility Guidelines (WCAG) 2.0 Level A and AA Success Criteria and to use emerging standards and best practice design techniques (such as the WAI-ARIA Suite) that support existing and emerging adaptive technologies.

Leveraging accessibility experts in the Sakai Community, all future development on tools intended for inclusion in the CLE core will undergo regular, documented usability and accessibility evaluations throughout the design and development process to ensure that it meets these goals.


Sakai OAE Accessibility StatementConsistent with the goal to make Sakai the most innovative and powerful Collaboration and Learning Environment, the Sakai community with the support and encouragement of Sakai Foundation will ensure that all of the features of the OAE (the next generation of Sakai) are accessible and usable by the greatest number of potential users, including users with disabilities.

To ensure this high level of accessibility for the greatest number of users, our goal is to design OAE to meet or exceed the accessibility design principals found in recognized international standards. Our goal is to meet all of the W3C Web Content Accessibility Guidelines (WCAG) 2.0 Level A and AA Success Criteria and the Authoring Tool Accessibility Guidelines (ATAG).

To ensure that the OAE has as few accessibility barriers as possible and to provide a rich and enjoyable user experience for all users, Sakai will be developed using emerging standards and best practice design techniques (such as the WAI-ARIA Suite), and support existing and emerging adaptive technologies.

Leveraging accessibility experts in the Sakai Community, all future development in the OAE will undergo regular, documented usability and accessibility evaluations throughout the design and development process to ensure that it meets these goals.


Sakai’s Accessibility GoalsSo, Sakai is striving to:• Meet W3C WAI Web Content Authoring Guidelines

(WCAG) 2.0 Level AA Compliance• Use of WAI (Accessible Rich Internet Applications)

ARIA Technologies where appropriate• Meet W3C ATAG Authoring Tool Accessibility

Guidelines (ATAG) ComplianceWAI = Web Accessibility Initiative of the World Wide Web Consortium (W3C)


Development of Accessibility Laws

In the absence of clear standards and guidelines that specify how accessibility can be achieved, technology has often been designed with only able-bodied people in mind.

Just as a multi-level building without ramps or elevators can exclude people with mobility impairments, information technology can be a barrier too.



Section 508:• Section 508 was added as an amendment to the

Rehabilitation Act of 1973 in 1986. The original Section 508 required federal agencies to make their electronic and information technology (EIT) accessible to people with disabilities.

• In 1997, the Federal Electronic and Information Technology Accessibility and Compliance Act was proposed in the U.S. legislature to correct the shortcomings of the original section 508.



Section 508:• Section 508 §1194.22 covering web sites was

presented as a draft in December, 2000; approved in April, 2000; became enforceable on June 25th, 2001.

• April, 2006 the Access Board announced its intent to make recommendations for updating and revising Section 508. This work is still ongoing.


Section 508’s Technical Standards

Primarily, the standards describe the use of information with the disabilities of:• Vision• Hearing• Mobility


Where to find the Section 508 Standards

• The United States Access Board is a federal agency devoted to accessibility for people with disabilities.

• Responsible for issuing the standards under Section 508 of the Rehabilitation Act belongs to the US Access Board.

• The Section 508 Standards can be found on the US Access Board’s Web site at:http://www.access-board.gov/508.htm

http://www.access-board.gov/508.htm


Americans with Disabilities ActThe internet as we know it today certainly did not exist when Congress enacted the ADA in 1990.

On the 20th anniversary of the ADA, the Department of Justice announced they are considering revising title III of the ADA to establish requirements for making the Internet accessible to individuals with disabilities.

http://www.ada.gov/anprm2010/web%20anprm_2010.htm

The notice goes as far as explicitly stating that the ADA Web accessibility requirements should apply to places of public accommodation including bowling alleys, laundromats, restaurants, bars, movie theaters, places of education, and many others.




The Family of W3C WAI Documents• WAI = Web Accessibility Initiative of the World Wide Web

Consortium (W3C)• Five relevant accessibility documents (aka “Essential

Components of Web Accessibility”)• Web Content Accessibility Guidelines (WCAG)• Authoring Tool Accessibility Guidelines (ATAG)• User Agent Accessibility Guidelines (UAAG) • Evaluation and Report Language (EARL)• Accessible Rich Internet Applications (WAI-ARIA)

• Find them at:http://www.w3.org/WAI/guid-tech.html

http://www.w3.org/WAI/guid-tech.html


W3C Web Content Accessibility Guidelines (WCAG)

Recommendations from the W3C, which explain to developers and authors how to make Web content accessible to people with disabilities.

Web Content Accessibility Guidelines (WCAG) 2.0 (released Dec. 2008):http://www.w3.org/TR/WCAG20/

http://www.w3.org/TR/WCAG20/


W3C Web Content Accessibility Guidelines (WCAG)

How to make Web content more accessible• Text and non-text content• Static and dynamic content

Addresses disabilities such as:• Visual• Auditory• Physical• Speech

• Cognitive• Language• Learning• Neurological


W3C Web Content Accessibility Guidelines (WCAG 2.0)

How WCAG 2.0 is organized:• 4 principles• Perceivable• Operable• Understandable• Robust

• 12 guidelines• 61 success criteria• 400 techniques, 89 common failures


WCAG 2.0 Conformance Requirements

• For each of the 12 guidelines, testable success criteria (SC) are provided for determining conformance to the guideline.

• The success criteria come in three levels of conformance: A (lowest), AA, and AAA (highest).

• The guidelines and success criteria are written to be technology neutral.



• For each of the WCAG 2.0 Success Criteria (SC), there are techniques.

• The techniques fall into two categories:• Sufficient: Sufficient for meeting the SC• Advisory: Techniques that go beyond the

requirements


WCAG 2.0 Organization Recap

• Principles• Guidelines• Success Criteria• Understanding & How to Meet Documents• Sufficient Techniques• Advisory Techniques



• In order for a Web page to conform to WCAG 2.0, all of the following conformance requirements must be satisfied:

1. Conformance Level: One of the following levels of conformance is met in full. • Level A: For Level A conformance (the minimum level of

conformance), satisfy all the Level A Success Criteria. • Level AA: For Level AA conformance, satisfy all the Level A

and Level AA Success Criteria. • Level AAA: For Level AAA conformance, satisfy all the

Level A, Level AA and Level AAA Success Criteria.



2. Full pages: Conformance (and conformance level) is for full Web page(s) only, and cannot be achieved if part of a Web page is excluded.

3. Complete Processes: Conformance is not possible at a particular level if any page in the process does not conform at that level or better.


Laws vs. Guidelines

The W3C’s Web Content Accessibility Guidelines are completely voluntary. On the other hand, the US Access Board's Standards are enforceable as law.

Section 508 provides remedies to those aggrieved by violations of the requirements, which, after administrative remedies are exhausted, allow for both private rights of action in court and for reasonable attorneys fees.


WCAG 2.0 vs. Section 508

WCAG 2.0 Level A and Level AA techniques can be used to unambiguously meet every one of the Section 508 guidelines.

A Section 508-compliant page will conform to WCAG 2.0 Level A but won’t necessarily met all WCAG 2.0 Level AA guidelines.


WCAG 2.0 and 508 Checklists

WebAIM publishes checklists with their interpretations of WCAG 2.0 and Section 508:

• WebAIM WCAG 2.0 Checklist:http://webaim.org/standards/wcag/checklist

• WebAIM Section 508 Checklist:http://webaim.org/standards/508/checklist

http://webaim.org/standards/wcag/checklist

http://webaim.org/standards/wcag/checklist

http://webaim.org/standards/508/checklist

http://webaim.org/standards/508/checklist


Authoring Tool Accessibility Guidelines (ATAG)

• Authoring Tool Accessibility Guidelines (ATAG)• 1.0: February, 2000• 2.0: In working draft, anticipated to be approved in 2011

• How authoring tools should help content developers produce accessible content, including• WYSIWYG HTML and XML editors• Tools that save content in Web format• Tools that transform documents into HTML• Tools that produce multimedia for use on the Web• Site management, publication tools (content management systems)• Tools for managing layout (CSS formatting tools)• Websites that let user add content (blogs, wikis photo sharing, social

networking, learning management systems)


Authoring Tool Accessibility Guidelines (ATAG)

28 checkpoints that cover:• Producing accessible output (conforms to

WCAG)• Prompting authors to create accessible content• Providing ways of checking and correcting

inaccessible content• Integrate accessibility into document “look and

feel,” help and documentation• Making the authoring tool accessible


Accessible Rich Internet Applications (ARIA)

• Accessible Rich Internet Applications (ARIA) Suite• Last call working draft: February, 2009

• Defines how information about application functionality can be provided to assistive technology. The goal is that with ARIA, an advanced Web application can be made accessible and usable to people with disabilities.

• Describes roles for:• Widgets: modal dialogs, menu, trees, sliders, progress meters, spinners, etc.• Landmarks / Structure of a Web page: headings, navigation, content regions, etc.

• Describes properties for:• State of widgets/controls: required, checked (checkbox), haspopup (menu)• Live regions for which updated content should be announced and interruption

policy for alerts• Drag-and-drop sources and targets

• Keyboard navigation


Sakai Accessibility Reviews

• Performed on every major Sakai release.• Perform Accessibility Evaluations of the

Portal and core tools.• Write up results in reporting templates.• Write JIRAs on the issues (bugs) found.• Work to resolve the issues.• Review and update accessibility

documentation.



• Begin as soon as the QA servers are up with the first Alpha release

• We get great support from release management, the maintenance team, and developers for resolving issues


Some Hat Tips to the Sakai Community• Alexandre Ballesté • Alan Berg• Noah Botimer• Matt Clare • Eli Cochran• Jonathan Cook• Steve Githens• Charles Hedrick• David Horwitz• Suhas Jagadeesh• Matthew Jones • Sean Keesler• Kiran Kumar• Jean-François Lévêque

• David Martínez• Stephen Marquard• Chris Maurer• Megan May • Sam Ottenhoff• Savitha Prakash • Zhen Qian• Gonzalo Silverio• Steve Swinsburg• Greg Thomas• Elizabeth Venstra• Michelle Wagner• Ying Wang• Anthony Whyte

And more unsung heroes…


Accessibility Working Group Accessibility Testers

• Eli Cochran• Mike Elledge• Lucy Greco• Joe Humbert• Brian Richwine• Mary Stores

• Walt Stover• Nantanoot

Suwannawut• Scott Williams



• Combined use of two approaches:• Technical Accessibility Evaluation• Functional Accessibility Evaluation

• Goal: Efficient and effective discovery of accessibility issues

• Uses: Accessibility checkers, heuristic evaluation, code reviews, and functional accessibility testing using walkthrough scripts with adaptive technologies



To perform a review it is helpful to know:• Familiarity with Web mark-up languages

(such as HTML),• access to and skill with a variety of

evaluation tools and approaches, and• knowledge and experience in Web

accessibility.


Walkthrough Script

In Sakai CLE (Sakai 2), the walkthrough scripts are usually very tool centric (Chat tool, Resources tool, Syllabus tool, etc.).

In Sakai OAE (Sakai 3), the walkthrough scripts will be use case centric (Create an account, Login and add a research associate as a contact, etc.)


Walkthrough Script Philosophy

• The walkthrough script is a step-by-step description of a series of tasks a user must be able to perform to accomplish a set of objectives.

• The script should examine the user’s ability to perceive associated cues and feedback, navigate the site, operate the UI features, understand the content, and carryout required tasks.


Accessibility Review Process

• Tools / Use Cases get chosen• Accessibility Review is performed• The results get recorded• Issues get filed in the JIRA system as bug

reports• Track and work to resolve the issues• Update the documentation


How You Can Help!

• Share your knowledge of accessibility concerns with using / administering Sakai• Share your knowledge of how best to support

users with disabilities in using Sakai• Let us know which tools are important to you• Help perform accessibility reviews• Help resolve accessibility issues• Help write documentation


How to Get Involved

Join the WG’s email list: [email protected]

Sign up or view the archives by visiting this page:

http://collab.sakaiproject.org/mailman/listinfo/accessibility

mailto:[email protected]





How to Get Involved

Call in for our bi-weekly teleconferencesHow to connect:• Dial: (812) 856-7060• Conference Code: 22348#• An agenda for each meeting is mailed out to the

group’s email list.


Web Accessibility Resources

Sakai Accessibility Resources Listing:http://confluence.sakaiproject.org/display/2ACC/Accessibility+Resources+Listing

http://confluence.sakaiproject.org/display/2ACC/Accessibility+Resources+Listing

