At this weeks Sakai release meeting, multiple features were discussed for inclusion in the next release. The accessibility of these features was not discussed.
There will be a beta 7 release on Monday or Tuesday of next week. There will also be at least 1 to 2 more beta releases before the final 2.9 release.
Because the test server was updated this past week and the next beta release is imminent, Joe recommends further accessibility testing should be put off until after the beta 7 release. This will give Brian time to update the server.
There won’t be any other beta releases for two to three weeks after beta 7, so it will be an ideal time for testing.
Gonzalo worked on two different Jiras marked for merger in the b07 release. Those should be reviewed by the end of this week/early next week.
Gonzalo asked that the neo portal be retested because he removed all ARIA live areas.
Many Jira tickets marked for 2.9 seem to be getting fixed by various members of the Sakai community, so the group will need to devote some time before the 2.9 release to verify patches.
Jira filter for tickets which need to be verified by AWG:
Final accessibility testing for 2.9 should finish up by the middle of September. This will allow time for filing Jiras, creating patches, and verifying those patches.
Server Upgrade
Brian updated the test server to beta 6.
Unfortunately, there was no advance notice sent to the working group because Java needed updated for security reasons.
Brian decided to update the server from beta 5 to beta 6 because the JAVA update required him to reset the server.
2.9 Accessibility Review
2.9 Testing Problems or Concerns
Content used to facilitate accessibility testing will be reloaded after the beta 7 is released and the server is updated next week.
Scott conducted the comprehensive review protocol for the account tool.
He discovered that during validation if you have an incorrect entry, an error message is displayed at the top of the page. Unfortunately, the cursor remains at bottom of the frame when using JAWS so the user has no idea that the error message is being displayed and the information that the user filled out was not submitted. The virtual cursor remains at the Create Account button.
A general rule should be drafted so that the same accessibility fix for this issue, which has been implemented in the Gradebook tool, would be patched in each tool which displays error messages after submission.
It would be good to look at all tools that have validation or error messages and see how they are formed.
Then a convention could be made to explain how the validations/errors occur.
Joe will try before Tuesday to create the Jira ticket for this issue. He will set the first child task in the ticket so this issue is addressed in the accounts tool, including Scott's review comments, so Gonzalo can start working on it.
The other issue Scott discovered relates to required fields in the account tool.
There’s an asterisk but no explanation statement. The asterisk is part of the label.
There should be a statement at top of form saying required fields marked with *
There was some discussion as to whether ARIA should be used to indicate required fields, or whether it is just another way to make Sakai more robust in terms of finding out this information.
Collaborative Testing
At the previous teleconference a discussion was started about setting up collaborative accessibility testing. The discussion was tabled until this teleconference so all members had time to think about the topic.
In the past the group tested the Portal Chat and Forums tools collaboratively.
It was decided that the group will retest the Portal Chat collaboratively.
Joe will send a Doodle poll with dates and times by Monday.
The dates will be next week, or after Labor Day due to the b beginning of the semester.
The Resources menu has been worked on to be more accessible with screen reading software.
Joe was doing comprehensive keyboard/technical testing on this tool and noticed an issue.
There are two links that work with the Add and Actions menus.
Joe wondered if both links are needed because visual indication of focus is not present when navigating these links.
Gonzalo pointed out these links are not part of the patched Add and action menus and probably needs to be retested.
The WG should consider the accessibility perspective from screen reading and keyboard users and test the patched Resources tool collaboratively as well. This will be an agenda item at the next teleconference.
Gonzalo reminds us that 90% of Sakai usage is centered on the Resources tool, so it’s important.
Any Other Business
Future Implementations to Sakai that the Working Group Should Discuss and Think About
Gonzalo suggested that accessibility preference settings should be added in the future so that people can, for instance, choose whether or not they want ARIA updates to be announced.
He would like this topic to be included on the agenda of future teleconferences.
Nominally these preference settings would be included in the 2.10 release, but Gonzalo feels that it should be implemented into a 2.9.x updated by the end of spring semester if the group can decided on which settings should be included as preferences.
The group needs to consider that in 2.10 there will be a lot of asynchronous updates to the DOM in Chat and Portal. All the ARIA live updates were stripped from Portal, so a possible setting might be if an asynchronous update isn’t critical for my operation, it can be turned off globally.
These preferences haven’t been very well thought out yet. However, we should keep in mind that some things would work much better if the user had control over them, such as a high contrast mode.
Sakai will still be built accessibly, but maybe certain preferences might need to be controlled by the user.