Accessibility WG Teleconference Minutes 03-29-12

Attendees

  • Joe Humbert, IUPUI
  • Brian Richwine, Indiana University
  • Mary Stores, Indiana University

Agenda

  • Sakai OAE
    • OAE v1.1 review
      • Testing Updates
      • Issues/ concerns
      • Update on walkthrough scripts
    • Other OAE work
      • Auto complete
      • Headings
      • Non-unique links
      • Skip navigation
      • Auto suggest in search box
      • Read/unread messages
  • Sakai 2.9
    • Server upgrade to b03
    • Brian reviewing email tool
  • Any Other Business

Notes

OAE Review

Testing of Functional Areas

  • Joe received an e-mail from Scott, who is still testing functional areas.
  • Because Scott has been on vacation, testing won't get done until next week. He still intends to do more testing after he completes what he signed up for. Scott is the only one who has done any physical testing.
  • Joe plans on doing Firefox/WCAG2 testing. He may also attempt to test with Dragon Naturally speaking for one functional area.

Walkthrough Scripts

  • Joe finished modifying the walkthrough script drafts he received from Kent Fitzgerald.
  • He is going to try and create more for some of the other functional areas.

Jiras

  • Discussions have taken place regarding outstanding Jira tickets.
  • Gonzalo has been consulting with people regarding [the auto suggest issue|https://jira.sakaiproject.org/browse/SAKIII-4065]. He pulled suggestions from the ARIA specifications. Joe thinks there might still be an issue and will consult next week with Gonzalo after he returns from vacation.
  • [Lack of heading structure|https://jira.sakaiproject.org/browse/SAKIII-4706] will be worked on. Gonzalo has added at least one heading to every  page and more where he can. Most pages have only one heading.
  • The heading structure will be implemented in 1.3. once it has been resolved.
  • The {non-unique link text on the search feature|https://jira.sakaiproject.org/browse/SAKIII-4070] has been fixed. The Jira has been updated in terms of where there are numbers of content items, participants and comments. New Jiras will be filed.
  • Gonzalo has been working on the -skip navigation issue|https://jira.sakaiproject.org/browse/SAKIII-3729]
  • The skip navigation issue might be implemented in v1.3, although it has not yet been determined how many skip navigation links will be included.
  • Whether or not to have skip navigation links may be a user preference. Gonzalo suggested that because of pushback on issues that change design preference. A toggle could be implemented to preserve the original design of OAE.
  • The skip navigation preference would not be toggled on by default. He suggested an accesskey for toggling this preference.
  • Brian has suggested that skip navigation links could at least be evident to screen reader users, eliminating the need for these users to toggle this particular preference.
  • For keyboard only users the skip navigation preference could be set to be visible or invisible.

Impromptu OAE Accessibility Review

  • There was an impromptu accessibility review done by the University of California, which will be e-mailed to Joe at a later time.
  • Eli sat down with Lucy Greco to do a review of OAE, since the report sparked the interest of people higher up.
  • Joe and Eli will work together to make sure that the issues the Eli and Lucy found are not already Jiras.
  • Sakai 2 Updates
  • The server has been upgraded to b03.
  • There may be a beta 04 release in the next couple of weeks. However, a significant number of fixes need to be resolved before that release.

Improving Workflow Process for Open Jiras and the Build

  • In the CLE team release meeting, they have a Jira filter where it shows all the Jiras that have been resolved but not closed as merged in trunk in the next release.
  • There were quite a few accessibility Jiras the for including Nneoportal crashing JAWS.
  • Workflow has changed to indicate  an issue describing the problem, if someone assigns or closes it, and if assigned, that person has a chance to work on it and either fix it or declare it unfixed.
  • Then it gets resolved and not tested. A filter will be made to verify it, then someone can test it.
  • Then someone on the Release Team has a filter that shows the tickets that have been tested but not closed. they go through an mark those close Finally, someone can QA those closed tickets in trunk.
  • Brian will revisit those 7 accessibility Jiras this weekend to mmake sure those get into the next beta release.
  • When new Jiras are put in, they will go into a status where they will have to be approved.
  • Brian may have to call and talk to Sam Ottenhoff and Aaron Zeckoski. They are from two different organizations. They have picked up the ball in supporting 2.9. they are trying to make the build and Jira processes as clean as possible.
  • Brian will have to look for how that approve process works.
  • Jira tickets not touched in a certain amount of time may close automatically, so Jiras need to be kept track of.
  • There are 9000 Jiras in the system and only 6 or 7 active people.
  • If a Jira is not getting attention in a release and it's marked for a previous release, it might drop out of view.
  • Previously, issues have been put in and been constantly upgraded.
  • They are working on permissions on different steps of the workflow.
  • If the Accessibility WG feels like they should be able to speak authoratatively on a concern over a Jira, Arron or Sam should be contacted regarding permissions.
  • Brian hopes to put into Jiras tomorrow and try to make a list of ones to push. He will make sure the fixed version is up to date and then send an e-mail.

* If Brian sent a list of Jiras to say here's some that need attention, then an assigned person would be provided. Some have been worked on since Brian's absence and those need verification.

E-mail Tool

  • In the latest 2.9 CLE release, they replaced one of the previous messaging tools with a tool they call Mail-sender. It actually shows up in the tools list as e-mail. This tool has not been looked at by the Accessibility WG before.
  • At first glance it looks simple. When you go to the tool, there's a compose page that opens by default. there are standard e-mail things - the "to" field, the "subject" field, message body, the ability to add attachments, or submit or cancel the e-mail. You can also check a box to send it back to yourself.
  • All those controls are unlabeled except for the checkbox. It would be easy to label a lot of them.
  • However, in the "to" field, they use a complicated layout to convey the information structure. There's a series of check boxes, but they are links. links act like radio buttons. One might say "all", another "roles", and a third, "sections or groups". None of these are not in a list.
  • If you click on a link, a new series of check boxes pops up, so you can get different sections of the class, for example. since the links aren't associated with anything, it would be confusing for a non-visual user. It seems to Brian that these should be radio buttons, possibly with contextual information.
  • The new check boxes that pop up when a link is activated are nested. But it's all visual. A well thought out list of fieldsets, and legends and maybe focus management would be in order.
  • You have the ability to send e-mail to every student in the class. Screen reader users could use first letter navigation and the forms list to find the person. But it might be good to have the check boxes in a list and an easy way to skip past the list.
  • How would keyboard only user do this. If there were 200 students, would they tab 200 times? There is a field that says "send to other user". They would have to know the username. Otherwise, the keyboard only user would have to go through the entire list. Joe wonders if a tree view would work.
  • There are images that have redundant links.
  • They have a level 3 heading for compose, but they put visibility.hidden. The word "compose" is displayed in the action bar, but it is just text.
  • Content on the page seem to linearize well except for the "to" part which has random check boxes and links.
  • Page zoom seemed fine.
  • There is no title on the tool, and the primary language is not set to English.
  • This tool has no landmarks for easy navigation.
  • Color is not used to convey meaning. Brian has not checked color contrast ratios.

End of meeting