In 2.8, the Accessibility WG only did 15 tools for the accessibility review.
Tools with some review coverage so far include:
Admin tools:
Become a User
Sites
Users
Worksite Setup
Gateway tools:
About
Acknowledgements
Features
New Account
Site Browser
Training
Welcome
Main Tools:
Announcements
Assignments
Preferences
Neoportal
Profile2
Worksite Setup
Accessibility Timeline
Brian will be going through existing review results this weekend and evaluating priority of issues
Brian, Joe and Mary will be identifying existing Jira's for issues (and updating them as needed to reflect versions affected and assignments) and creating new Jiras as needed next week (12/5-12/15)
The WG promised to have Jira's cut from the issues found in the Accessibility Review by 12/15
Current Efforts
Neoportal
Brian is focusing on Neoportal accessibility issues.
Hopefully SAK-20916 (Accessing a Site from NeoPortal Worksite Navigation Causes Internet Explorer 8 and 9 to Crash when Used with the JAWS Screen-Reading Software) will be in Sakai 2.9.0-A03 so Mary can do more testing of the Neoportal without IE/JAWS crashing.
A3 should be released tomorrow, so Brian hopes to rebuild the server this weekend.
Other Items To Be Tested Next Week
Brian is looking at the action bar ARIA markup this weekend to provide a recommendation on what Is best to work in JAWS and VO. and Need to avoid crashing.
Brian is writing a new jQuery based menu for the "Add" and "Action" menus from scratch instead of using the jQueryUI menu widget - much lighter, cleaner, code using existing CSS and only one js file.
It will have the same look and feel for mouse users as the existing menus.
Mary will test it with JAWS next week.
Assignments and Gradebook Tools
Joe and Mary are working through Instructor personas of Assignments and Gradebook
Concerns
IE and FF are frequently crashing when being used in combination with JAWS 12. Crashing frequently on Sakai CLE and even more frequently with Sakai OAE.
Mary is hearing reports that JAWS 13 has many stability issues as well. A supposedly more stable version of JAWS 13 will be released next week and hopefully we can do some testing with it to see how it performs.
Jiras:
jquery Menu
[Add and Action|https://jira.sakaiproject.org/browse/SAK-20631} - Resource Tool "Add" and "Action" menus difficult for screen-reader users to navigate and operate.
Turns out jQueryUI menu widget is not in current jQueryUI releases. jQueryUI menu depends on several CSS and JS files.
The jquery.ui.menu.js found in the current release of jQueryUI 1.9pre is quite a bit different than what Kiran started with. Has a dependency of jQuery 1.6.3+ (not currently found in Sakai 2.9)
Brian has started writing a much simpler (one file) jQuery based script that uses existing CSS and jQuery libraries in Sakai CLE and has the same look and feel as the existing menus for mouse users while having ARIA and keyboard access for others.
Concerned that the standard ARIA menu operation is different than the top navigation menus found in the NeoPortal. Will try to blend both keyboard interactions if possible.
Brian sent an email to the list regarding these three Jiras on November 29 asking for input on a suggested fix
Testing with Mary shows they work in IE and FF on windows plus have unexpected usability improvements in how the skip navigation works with Firefox.
Concerned over global changes to the CSS ruleset for the .skip selector
Concern is over the testing required to prove global change doesn't cause unwanted problems.
Changes to the .skip ruleset change it from moving text off-screen (left:-999px, top:-999px) to simply masking out the content (height:1px, width:1px, overflow:hidden)
This offers benefits that it allows elements marked up as such to receive keyboard focus in Firefox, Safari, and Chrome
Fixes problem where focus indication (the dotted outline) would flow off the element and off the screen in an attempt by the browser to place the outline around the off-screen content.
Also seeking feedback on changes to the skip nav links themselves
Suggesting addition of an onclick handler with javascript to move the focus directly since many browsers don't actually move the focus when a same page link is activated (FF, Safari, Chrome, Opera)
Suggested onclick handler gracefully falls back to the default link action if the call to focus fails or javascript is disabled
Also requires changes to the same page link target as webkit browsers (Safari, Chrome) will not give focus to empty elements (named anchors are empty elements).
Suggested fix's onclick handler on the skip nav links targets the hidden "Worksites list begins here", "Tools List begins here", and "Content begins here" headings instead of the named anchors.
Leaves the link's href target to the named anchors
Changes to the "#skipNav a" css ruleset in portal.css make the skip navigation links usable to sighted keyboard only users.
Modified CSS with addition of :focus and :active pseudo classes to override the .skip css rules and bring the links into view when they get focus (:active is required for older IE browsers).
Accessibility Discussion: Table Summaries
Explanation
There are several Jiras out there where people have suggested that the table summaries provided are not useful and should be removed.
What makes a useful table summary?
If there is a table with 2 columns and two rows and has a table summary that says, "Assignment details," is it useful?
Because there are an extraordinary number of table summaries and no simple way to ensure that the summaries are up-to-date, keeping table summaries current is problematic.
Brian's Opinion
The table summary would still be useful. Knowing a little bit about the information contained in the table would be preferable to not having that information at all.
IU Student's Opinion
This is a misuse of the table summary feature. It would be better to have "assignment details" as a table caption since you can visually see table captions, the information would be useful for everyone, and table captions are also announced by screen-readers.
Table summaries should give a brief summary of the information contained in a table.
Table summaries are most helpful when tables are complex - with nested tables, for example.
Most screen readers announce by default how many columns and rows are in a table already, so this information is not necessary as part of the table summary.
The table summaries in Sakai are often too long, and some people would lose patience having to listen to a table summary that described ten columns, for example.
While a table summary that describes 10 columns might be useful for first-time users of Sakai, they are not very useful for a frequent user, who will then have to skip over the long summaries to enter the table and start navigating it.
Testing Protocol for Web Developers
Brian started work on a tool for web developers, which would allow them to do some quick accessibility checks.
It is currently a Firefox plug-in.
Gonzalo wwill give this plug-in a test drive next week.