Accessibility WG Teleconference Minutes 04-21-2011

Owned by Former user (Deleted)
Last updated: May 06, 2011Version comment
6 min read

Attendees

  • Mike Elledge - Michigan State University
  • Scott Williams - Michigan State University
  • Brian Richwine - Indiana University Bloomington
  • Mary Stores - Indiana University Bloomington
  • Gonzalo Silverio

ARIA markup and Voiceover Concerns

  • In the previous meeting notes the WG discussed an accessibility concern where users of Voiceover, the screen-reader for Mac, could not access certain tools marked up with the ARIA role of menu.
  • Brian took one of the tools that has the ARIA role of menu and saved it as a static web page.
  • The owns state did not get fixed.
  • In the toolbar or menu roles, according to the ARIA best practices document, ARIA expects the application to handle all the keystrokes and deal with setting focus.
  • This is the reason Voiceover users can't access the items in the menu role: because VO might be expecting Sakai to use event handlers to put focus on keystrokes.
  • It may not be easy to resolve this accessibility issue for VO users because of the way the action bars were written by so many different people.
  • It may be that the ARIA roles might have to be removed. That may be an easier fix than trying to support it.
  • Perhaps another navigation landmark instead of menu could be used.
  • The menu role typically has submenus (typical to the Windows OS with file, edit, help) where there are dropdown menus. The toolbar role matches a little better the semantics. So this is not a bug with Voiceover.

Third Party Accessibility Certification

  • Brian and Gonzalo have been working on a list of tools that could be recommended for testing as part of the certification process.
  • Gonzalo created a list of tools. However, there is no discussion on what they thought of the tools.
  • The main question to consider in creating the list is where to draw the line. Perhaps the administrative tools would not be used by most users, so accessibility may not be so much of a concern.
  • There were at least 22 tools that seemed heavily used. that's a fair number.
  • The sub-pages of each tool would also need to be tested for accessibility.
  • The Tests and Quizzes tool has a lot of possible sub-pages and different features that would need to be tested for accessibility: short answer, multiple choice, matching.
  • If you looked at the student and instructor views for Tests and Quizzes, more than five sub-pages would have to be tested.
  • The lowest cost level for certification from the NFB is 100 pages. The next cost level is 100 pages plus PDFs. The platinum level NFB certification is the highest cost, but includes everything in the certification process.
  • There was a Blackboard PowerPoint presentation concerning their NFB certification process.
  • Before Blackboard could become NFB certified, they went through a certification preparation process.
  • Blackboard worked with Deque and came up with 23 use cases.
  • There were no specifics on whether the use cases applied to specific tools.
  • IU has been using the free version of FireEyes , plus a screen reader user, to evaluate web sites.
  • The professional version is much like the Jira system where you can comment, track issues, assign different priorities, etc.
  • Otherwise, FireEyes can run and store scripts and do evaluations. The user just doesn't have the ability to generate reports or assign and comment on those issues.
  • If you had a client concerned about privacy, the information from the web site evaluation goes to Deque's servers. So if someone had proprietary information or intellectual property, the privacy issue would be a concern.
  • The professional version comes with a server, but Deque still reserves the right to logon and do maintenance and inspect it.
    *Here is the FireEyes link
  • Blackboard went to Deque, Deque worked with them, developers developed the use cases, Deque did testing, then there was dialog between the two so that the issues could be fixed.
  • Once Blackboard achieved a certain level of accessibility with Deque, then they went to NFB.
  • The $30-50,000 would do the pre-testing that was done for Blackboard before Blackboard went to the NFB for certification.
  • The Accessibility WG could conceivably do the pre-testing, but the risk would be not being able to interpret it the way NFB would evaluate it.
  • If you go to NFB for certification, is it a one-shot deal? Do you have to pay again to get retested?
  • The risk of not passing would be higher, though it still may be cheaper if it's only $9,000.
  • you could evaluate Sakai for accessibility five times with the NFB before it would cost $50,000.
  • Deque envisions two staff members taking several months of time; that is why it costs so much.
  • As far as the Sakai board's concern, Alan Berg took the comments from a couple meetings ago and took it to Ian Dolphin. Then Rutgers had some dialog and some of the issues from Rutgars got fixed.
  • There was definitely commitment towards accessibility, even if it cost $50,000 and some side discussion of how to obtain the money.
  • The person from Rutgers said they were assuming Sakai sites were accessible and the WG were addressing any accessibility concerns that might come up.
  • Brian's response was that the WG is a limited resource. The WG can only test a limited number of tools.
  • Example: If there are 30 tools listed, the WG would not be able to evaluate all 30 tools before the deadline.
  • The WG has to assign priorities and look at certain things.
  • So there is a risk, especially in OSP, Module and Portfolio type tools, that accessibility issues could be missed.*
  • So as far as recommending tools for certification, if the WG cannot provide that information, someone will have to be paid to determine that.
  • There's the thought this could be done internally, or the Sakai board could get a third party to do it because maybe the third party company would have a different view. maybe
  • Once modules and tools and number of sub-pages are determined, you could get comparison quotes.
  • Perhaps folks at Rutgers and people throughout the community could be involved in testing and repairs of accessibility issues.
  • Mike says that at MSU when looking at the new business enterprise system, they used QA scripts. They then tested the system using just the keyboard and JAWS.
  • Often the QA scripts for Sakai are very technical, so Brian has been trying to make the script so you could tell someone to perform a task and they could carry it out.
  • In the walkthrough scripts, the Accessibility WG goes through all the issues.
  • The WG could hand a walkthrough script to Deque and see then if anything was missed.
  • Since the Accessibility WG has done all this work up front, it might be a lot cheaper.
  • The WG isn't asking them to fix the problems, just to identify holes that may have been missed.
  • Deque has a service for prep for NFB. so the WG would make a list of prioritized tools with a cutoff level, then upper management could see if that made sense to them.
  • The Accessibility WG could also supply ratings of accessibility for the tools that have been tested.
  • The Mail tool probably has been deprecated.

Tests and Quizzes Tool Accessibility

  • The tests and quizzes tool has also been updated.
  • Mary and Brian set up a meeting with Megan May to meet with 2 web developers who are working on the user interface side of tests and quizzes.
  • On initial evaluation, Brian could see that there are mostly unlabeled form elements.
  • The action of matching in the tests and quizzes tool is a more complicated accessibility issue. Screen reader users will have to remember which term goes with which number and try to match that way. A lot of memorization is involved for those who are blind.
  • IU is putting a new beta of tests and quizzes out for summer 1.
  • Brian suggests maybe a series of simple patches of form controls would address 99% of the accessibility issues for tests and quizzes.

Sakai Accessibility Statements

  • Brian had an e-mail conversation with Sean Keesler, who is responsible for sakaiproject.org.
  • he is the first person who reads e-mail that comes to the site.
  • He often is the person who receives questions regarding how accessible is Sakai.
  • There is some talk of hosting accessibility documentation on the Sakai Project web site and getting official approval of the accessibility statements.
  • Brian has not heard yet from Sean, but there is some chance of having accessibility documentation on the main Sakaiproject.org site.
  • Brian is going to go ahead and write up documentation for 2.8.0 release and post it on the WG page.
  • Mike has volunteered to write some copy.
  • Once Brian has finished writing the copy and posting it to the WG site, he will send a note to Mike.

JAWS and ARIA Support