Accessibility WG Teleconference Minutes 08-26-2010

Attendees

The webinar provides an opportunity to speak about Sakai and the progress we've made on accessibility.
We can also learn about the accessibility of other LMSs and what other people are doing to implement accessibility

Brian responded to new Jira tickets, especially the one related to the podcasting tool.
Someone filed a Jira that suggested podcasts could be navigated more accessibly.
The tool contains redundant links and unlabeled form fields, which could be easily fixed.
In instructor's mode, there's an edit link. However, nothing describes what you will edit, even for a sighted person because there is no information around the link.
The tool was designed by developers at IU.
Podcasts is a Simple tool.
It's a feed of Resources.
You can schedule when the podcasts will appear.
You can determine whethr or not to listen to it in the student view.
In order to work on improving accessibility of the tool, make a branch, says Gonzalo.
*Make changes, and once that's done, merge it into the trunk.
The first step to create a branch is to talk to the people at IU who own it.
After evaluation, merge it into the trunk.
Mary and Brian will do a review of it, and find the issues that need to be fixed.

Because of the semester, a list of options for resolving this issue has not been created yet.
The reason developers don't like to use button tags is that all ASCII characters are being used as submit inputs.
Developers would be asked to redo all the functionality.
With jsf-basd tools it would get really complex.
Real estate is really precious. That's why there are symbols instead of words.
Ther would be less translation issues as well.
In asking for changing input submit to buttons, we are asking a lot of people to do a lot of work
This is why another way needs to be found..

This Jira is still out there.
They do come up but if you focus on those, you have to know that they popped up.
The location of where that text appears changes from being a hidden div element to something that becomes a visible position on the page.
There is nothing to notify the screen reader user so it can't be announced if it does not receive focus.
It's all the way at the bottom of the page, so the screen reader user will probably not notice it.
They are the tools that reveal information when hovered over or tabbed to.
There are some that try to show more information/give context using the title element.
These should all be in the same category.

Sakai branch changes a lot.
Scott Williams and Lucy Greco have both done testing in the past.
If Brian could write something up specifying what would be entailed, maybe we could have more testers.
It would be nice to have some sort of recruiting strategy.
Steve Githens has asked Mary and Brian to test Assignments2. That will be part of the 2.8 review.
The WG also will picking up tools we haven't done last time such as the podcast tool.
The WG should update documentation and create Sakai 2.7 current accessibility documentation as well.
The other option is to make sure all existing documentation is all applicable and up to date.

There is a page for Sakai 3 Q and A testing.
videos have been created that present a walkthrough how the tool should behave and what you should be able to do with that tool.
Brian could write walkthrough scrips based on these videos.
Goals for next meeting: To address jira tickets where patches need need to be applied, finish patches removing blur for onchange events, a couple other jira items where there is simple work to apply a patch, and write the walkthrough scripts based on the Sakai 3 videos.