Sakai Accessibility Working Group
Accessibility Working Group's Responsibilities
The Sakai Accessibility Working Group (WG) is responsible for ensuring that the Sakai framework and its tools are accessible to persons with disabilities. For further elaboration of the WG's responsibilities, please see the Accessibility Working Group Responsibilities Document.
Sakai's Accessibility Status
To see the results of Sakai 2.8's Accessibility Review, please see the Sakai CLE Current Accessibility page.
Reporting Accessibility Issues
Please feel free to contact Accessibility Team Lead if you have encountered accessibility issues with the Sakai CLE or Apereo OAE. This information is valuable to us and we need your help to understand it. In the email describe the problem in detail, how you expected the tool or function to perform, and suggested remedy. Someone from the Sakai Accessibility Team will look into the issue and then add it to Jira.
If you have a question about Sakai accessibility that isn't addressed in these pages, please contact:
Accessibility Working Group Lead
Current Projects of the Accessibility Working Group
Sakai and Accessibility ANI Office hours presentation on Sakai Accessibility with Matt Clare of Brock University, A11Y chair, and Jeff Pash and Kyle Blythe on the new Sakai Gradebook.
How to Work with Us
- How to Contribute to the Accessibility Working Group
- Solve an issue. Here's a list of all of the accessibility issues we are currently tracking in the Sakai JIRA
Accessibility Working Group Conference Calls
The Sakai Accessibility Working Group meets by phone every other Wednesday at 1:00 PM EDT / 10:00 AM PDT starting June 15, 2009. For more information (including notes from past meetings), see the Sakai Accessibility Teleconference Information page. To participate:
- Default Dial-in Number:+1-323-375-2185
- Conference Code: 8600146
- Find a Dial in number in your city:
Web Accessibility Evaluations/Testing and Consultation
The Sakai Accessibility Working Group performs accessibility reviews as part of the Sakai release process. Besides performing these reviews, the group is available at any time for answering questions on accessibility and for performing accessibility evaluations/tests to support Sakai development.
Results from Previous Accessibility Reviews
- Sakai 2.2 Accessibility Review
- Sakai 2.3 Accessibility Review
- Sakai 2.4 Accessibility Review
- Sakai 2.5 Accessibility Review
- Sakai 2.6 Accessibility Review
- Sakai 2.7 Accessibility Review
- Sakai 2.8 Accessibility Review
- Sakai 2.9 Accessibility Review (2011)
- Interim Sakai 2.9 Accessibility Review Results (2012)
- Summary of Brock University’s Audit of Sakai CLE 2.9.1
- Review commissioned by Longsight Longsight-Accessibility-JT-2013.doc
What is Web Accessibility and How Does that Relate to Sakai?
Web Accessibility refers to the usability of a website by people of all abilities and disabilities. Accessibility often focuses on people with disabilities and can be viewed as their "ability to access", often through use of assistive/adaptive technology. Many education institutions have a legal requirement, or an administrative policy, to make sure the information technology they produce or purchase have accessible interfaces. Disabilities in this context includes, but is not limited to, persons who are blind or visually impaired, hearing impaired or deaf, have limited dexterity, or in some other manner require the use of adaptive technology. The requirements for accessibility have not been defined at this point, but an increasingly common criterion among institutions of higher education is Section 508 of the Rehabilitation Act of 1973, or its equivalent. This legislation, and the spirit of accessibility in general, defines accessibility as the ability of persons with disabilities to "have access to and use of information and data that is comparable to the access to and use of the information and data by such members of the public who are not individuals with disabilities."1
Web Accessibility covers may aspects of user interaction ranging from keyboard navigation (without use of a mouse) to an assisted experience such as a screen reader or voice recognition software. How the interface interacts and behaves depends on the way in which it is coded and how it interacts with the web browser. If, during the creation of the user interface, it was not designed to be accessible and also tested for accessibility, it probably is not accessible and some users may not be able to access information or perform necessary functions.
For more information, see the disability awareness page.
Accessibility Working Group Index
Can't find what you are looking for? Try looking in the Accessibility Working Group Index.