Accessibility WG Teleconference Minutes 07-29-2010

Sakai Accessibility Usability WG Teleconference Minutes

July 29, 2010

Brian has a fix for the onchage event handlers.
Since onselect won't work for people who use the mouse, jQuery will be used instead since Sakai 2.7 has a jQuery library.
Next week Brian will send an example to test on a static page.
Brian submitted the first patch for form elements on the Permissions widget.
Regarding Sak8169: Sakai should provide alternative presentations such as high contrast mode.
Brian tested this using high contrast support with several browsers.
In Sakai and found high contrast mode unusuable, especially using Windows with IE and Firefox.
Background images go away.
Brian was looking at how much work it would take to provide high contrast skin.
Drupal provides accessibility handbook and skins.
Brian sent e-mail to Eli asking if Fluid skinning system is being used for Sakai 3, and if that can be used in high contrast mode.
High contrast modes don't seem to be spelled out in new Section 508 and WCAG, so there may be a need to convince the Sakai community that this is a very important issue.
*90% of visually impaired people don't use screen-readers.
In Fixing high contrast mode could help with mobile audience.
Brian has screen shots of before and after contrast mode.
When in highmode, black screen appears with footer text being the only thing visible.

Buttons that have ASCII symbols: common in list and object navigators. Using input elements with type = submit.
Brian is looking into changing those using the button tag so that there is English on it. there's no alt atribute that can be used. Brian tried labeling the button, but it did not read the label.
Possible to use CSS to hide child text

tool tips - Links that are not meaningful out of or in context.
On permissions, the headings are all links for each role. It's a link that says instructor. JAWS reads screen text links.
We need to write a style guide with incidents like this.
When keyboard only user get to link and that gets focus, using CSS to put in contextual text. Lucy will find example. UC Berkley doesn't hide anything that doesn't appear when being tabbed to it.

Sakai 2.8 will be implemennting CK Editor.
Roadmap for 2.8 release shows code freeze in August, 2 or 3 weeks away. It's being looked at as an advanced maintanence release.
Brian hopes to look at jira tickets to see activities between 2.7 and 2.8.
He also is planning on attending release meetings such as the teleconference this morning in order to stay current with changes being made.
If the tool has been tested before and not much change is going to be made by the developers, the need for the Accessibility WG to test it is not very great.
If there are changes that occur, though, the group can test the tool for accessibility.
A goal would be to have the tests occur thoughout the year, instead of at code freezes or during times such as right before Fall Semester begins.

Sakai 3 is implementing TinyMCE.
We will need to give feedback to the UI developers to see that they are implementing the accessible version of TinyMCE, since there are multiple versions and not all of them are accessible.
Sakai 3 keyboard accessibility needs attention.
We need to prepare a list of Sakai 3 specific check lists and guidelines.
Regarding testing of Sakai 3, it's unclear which pieces even work because the dev server gets rebuilt every four hours.