Skip to end of metadata
Go to start of metadata
- Scott Williams
- Brian Richwine
- Mary Stores
- Joe Humbert
- Gonzalo Silverio
- Indiana University Student
Creating A testing Protocol
- A link to the Firefox comprehensive testing protocol was sent out to professionals of accessibility. Not much feedback was received.
- 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.
- Brian was wondering what is the best list to send question on how to use the Admin User 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.
- 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.
- 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.