 | This page is to capture discussion about open Sakai 2.x Accessibility Jira Tickets |
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:
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. Last updated 03/09/10.
Action required: clarification for work to proceed
Please read the comments to each issue to each issue
I am going to go with the following heuristic, and close this so that the issue gets the attention it needs.
1 - Reserve headers for delimiting semantic blocks to which screen reader navigation might be needed. Once inside the block, screen reader should be provided with navigation/markers native to that block: labels and inputs, properly constructed tables, text block markup, etc.
2 - Do not double up headers with any other markup that has screen reader meaning on its own.
3 - The maximum depth/number of headers should be constrained to 2 and 5 (at each level) respectively. This is somewhat arbitrary - the aim of a limit here is to provide enough information but no overwhelm.
Generally speaking: This issue is too generic. If the above heuristic is acceptable it should be tested against specific functionality/tools and separate JIRAs opened to deal with them specifically
Action required: explore system wide alternatives. FCK editor issues
This needs addressing systemically.
Action required: decide on one mechanism. Select menu issues
Needs a common solution for this common problem. See the email thread in Nabble
Action required: review to make sure is an issue.
Pseudo problem or workaround offered that needs reviewed. Please read comments
In gradebook the user cannot tab to the calendar image/graphic while in JAWS Forms Mode.
A complex issue. An action from a user reveals a block that has either been hidden, or added to the DOM as a result, in this case a calendar panel.
The action is not accessible (relies on an onclick on the image). This can be addressed (changing the renderPopupButtonAsImage to "false") by rendering the control as an input item.
But - is the calendar panel needed? User can just input the date manually and the date format is given in the input label. Calendar itself is not accessible in any case.
Please review - this widget has been worked on since this issue was filed to add keyboard accessibility.
See new permissions editor for 2.7 - improved table structure, human readable labels, please close if 2.7 addresses the issues.
This issue is pretty generic. A Cancel (live a Save or an Edit) is a POST - hence a new page is retrieved. In some cases (like when a validation error happens or when a success message is displayed for high stakes actions) the new page focus should land on the message, but this is not necessarily always the case - I would vote for closing this issue and opening specific issues to deal with specific cases.
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.
Access keys are explained in the accessibility document linked to in the portal. Is this sufficient? What technique would be appropriate to describe an accesskey if not?
Access keys are explained in the accessibility document linked to in the portal. Is this sufficient? What technique would be appropriate to describe an accesskey if not?
The contextual help has been changed for 2.7 - please evaluate.
Action required: apply patches.
Issues for which patches are provided, awaiting review and application, verification
Patch supplied may not fully address the issue - just provides a pattern.
Patch supplied may not fully address the issue - just provides a pattern.
Action required: verify fix.
Issues that have been resolved, awaiting verification
Action required: provide a fix.
Issues that will be worked on this iteration (starting on 02/25)
Note: as of 03/09/10 all issues that have clarity have either been closed or a patch has been supplied for them.
E-mail
Reopened
Open
Resolved
Closed
