This page is to capture discussion about open Sakai 2.x Accessibility Jira Tickets
- Existing Accessibility Jira Tickets
- Guidelines for Creating New Accessibility Jira Tickets
- Getting a Confluence – Jira Account and Joining the Accessibility Working Group Email List
- Issues by action required. To be updated weekly.
- Consider Closing - Won't Fix
- Action required: clarification for work to proceed
- Action required: Explore system wide alternatives
- Action required: review to make sure is an issue.
- Action required: Provide a Fix
- Action required: apply patches.
- Action required: verify fix.
- Closed – Need to change fix version
- Waiting to be Merged
- Closed Issues
Existing Accessibility Jira Tickets
Sakai uses Atlassian's Jira software for issue management. It is used to track a variety of issues, including bug reports, suggestions for new functionality, tasked work, among others. As we find accessibility issues, we put them in the Jira system. At this time, there are many open Accessibility Jira Tickets. Several that have been open for some time. Due to variations in the way Jira tickets for accessibility issues have been created, it is difficult to create a search that lists them all. Two searches that bring up accessibility tickets are listed below:
- "Accessibility Issues" list in Jira (searches text for "accessibility")
- Alternate Accessibility Issues view in Jira (Issues with Component=Accessibility)
Note: The lists may contain some items that do not relate to accessibility, due to Jira's text based search mechanism.
Guidelines for Creating New Accessibility Jira Tickets
As an effort to provide a consistent point of contact and to bring a consistency to the Accessibility tickets issues, all new accessibility issues should be brought to the accessibility working group lead for entering into the Jira system.
An excellent brief and to the point list of steps for creating Jira tickets can be found on the "Reporting a Bug in Jira" page. A considerably longer document on Sakai Jira tickets is the "Sakai Jira Guidelines" page. If you have questions regarding Sakai Accessibility Tickets in Jira, please send them to Accessibility Working Group email list, or email the working group lead.
Getting a Confluence – Jira Account and Joining the Accessibility Working Group Email List
To comment on / edit this page or work on Jira tickets, you will need an account. Go here to signup for an account (One account for both the Confluence Wiki and Jira systems). Go here if you forgot your password. Go here to join the accessibility working group email list.
Issues by action required. To be updated weekly.
Please read the comments to each issue to each issue
Consider Closing - Won't Fix
Action required: clarification for work to proceed
Modern browsers handle page / text enlargement very well. Windows and OS-X offer screen magnification features (Linux desktop screen magnifiers are still considered under development).
Unfortunately, Sakai 2.x is not very usable on Windows when running in the Windows OS's high contrast modes – see comments posted to issue. Need to look at updating help information.
Need to explore a good solution for this.
Need to find the root of this problem and fix it.
Action required: Explore system wide alternatives
FCK editor issues
This needs addressing systemically. Work is proceeding on switching over to the CKEditor for Sakai 2.8
This is the Jira ticket covering the conversion from the FCKeditor to the CKEditor.
Select menu issues
Needs a common solution for this common problem. See the email thread in Nabble
Punctuation in Buttons (Usually the List Navigator)
Input elements with type="button" or type="submit" used in the item and list navigators usually have symbols like "|<", "<", ">", "|>" instead of meaningful text that can be read by adaptive technology.
Implicit instead of Explicit Form Control Labeling Issues
The following can be fixed by a jQuery routine that adds id and for attributes as needed. See SAK-18851:
Action required: review to make sure is an issue.
Please review - this widget has been worked on since this issue was filed to add keyboard accessibility.
Changing these settings results in a POST - hence a new page is retrieved. I understand that this could be extremely frustrating - but short of replacing the whole workflow with something less POST-y and more stateful, I do not think we can address this.
The flash object has a very simple purpose - to store the data during an autosave, I believe. As such it need not be accessible by anyone - it is there solely as part of a background mechanism. Maybe a screen reader message to that effect? ("Please ignore the Flash object") It is hidden in any case.
The contextual help has been changed for 2.7 - please evaluate.
Action required: Provide a Fix
Action required: apply patches.
Issues for which patches are provided, awaiting review and application, verification
Action required: verify fix.
Issues that have been resolved, awaiting verification