Maybe we should make a protocol more friendly to the avrage Sakai developer, one that is immediately useable to folks who aren't developers at all.
Brian wants to make a five-step testing protocol that developers can perform for their own tools, and then make videos to demonstrate the steps.
People following the protocol would test for page titles, headings, frame titles, link text and form labels and keyboard-only operability.
Brian will write one up tonight to see if anything more needs done.
Scott Williams has slides that he uses for his "train the trainer" sessions when people test at his university.
Testing for color contrast issues is not necessary in this protocol, because they are minor. Also, most schools skin it and change it.
The WG would have to discuss how to test for text magnification.
Forms with onfocus or onchange input would be easy to test and should be included in the protocol.
One step in the 5-step protocol would be to look at the page title, frame title(s) and headings for each tool.
Think of it as categories or areas to check.
Gonzalo has volunteered to help give feedback about the protocol.
With some experience, you could do the protocols very fast, especially if you already have an awareness.
There is a heading on a form for the Site Browser tool that should really be a fieldset, so that would be a good example of a heading structure to demo in a video that needs improvement.
Developing a New checklist for Developers
Mike Elledge wrote a development check list (Microsoft Word 97-2003) (https://confluence.sakaiproject.org/display/2ACC/Sakai+Accessibility+WG's+Developer's+Guidelines+Development) that was a page and a half, which has received more visibility lately.
Brian is hoping to make this new checklist shorter than the check list.
There is also an -draft accessibility style guide from 2004 (Word doc on same page)https://confluence.sakaiproject.org/display/2ACC/Sakai+Accessibility+WG's+Developer's+Guidelines+Development that talks about how Sakai should be accessible.
The accesibility check list will be drafted after review.
Creating a Walkthrough Script for the Admin User Tool
Brian was wondering what is the best list to send question on how to use the Admin User tool,
Scott's Accessibility Evaluation of the Preferences Tool
Scott found it difficult to move items in the list to a different place using JAWS.
The top item in the active sites cannot be moved to the left. you can move it to the archives, but can't move it to the favorites.
If you make the page really small, then it will work right, but it is a bug with the tool.
it may be that ARIA roles should be set.
Better descriptions for the items are needed.
There is a time limit status not announced to screen reader users.
Global accessibility Issues Found
Scott says it would be good to have the skip nav links visible on focus, b/c it would help mobility impairments.
Brian has worked on a patch for it, but he is not sure what the status of that jira is.
The trick would be whether the institution wants this option.
Expand/contract navigation Sidebar
On the notifications page, there are headings to expand or contract radio buttons that are not true headings.
Scott was unable to receive keyboard focus at least on the Mac side, but true for PC side.
Brian wrote a patch for the Samigo Tests and quizzes tool in order to make those accessible.
The expand/contract navigation image for the sidebar menu does not have visible keyboard focus.
The focus disappears while you go through the ten items on the navigation bar.
Scott was using Firefox on the windows side.
Keyboard focus was there using Firefox 7 for Brian, but did not work in 6 for Scott.
Brian saw standard dotted outline used to indicate keyboard focus.
Some links disappear when you contract the sidebar.
It can cause a lot of confusion for people with cognitive disabilities, as well as screen-reader users, because for screen reader users, they do not know whether the sidebar is expanded or contracted by default.
They should go out of tabindex when contracted, so that they
will still show up in the links list for screen reader users.
The navigation could be expands when tabbed to.
Profile2
The Profilew tool has a lot more features now compared to the when the original walkthrough scrip was createdt.
For instance, there is now a privacy section.
Generally, this tool still seems not keyboard accessible.
Brian has started looking at it, but Scott will look as well.
Brian has noticed a major accessibility issue with this tool.
All the edit buttons appear to have contextual text with it, but they don't appear to have the right text.
When style sheets are disabled, staff info, contact info, etc. line up.
they are probably labeled in the wrong order.
Sakai 3 Update
At last Wednesday's teleconference, Joe discussed with everyone how accessibility tickest should be addressed.
The biggest accessibility improvement is that there was work done to make form validation accessible in one instance.
Chris Roby turned it into the framewowrk so it can be used for all production instances.
He demoed it yesterday.
Teleconference participants have requested a screen reader demonstration of the accessibility of certain components.
Mary and Joe will be doing the demonstration on November 2.