Sakai 2.0+ Accessibility Discussion

Accessibility (even beyond Section 508's requirements) is certainly
something that Sakai is committed to. To that end, accessibility
standards were adopted early on that exceeded 508, and met WCAG 1.0
priority one, two, and, in some cases, three guidelines. The current
style guide was developed based on those standards, and wireframes in the style guide contain accessibility tags and elements. That said,
accessibility has been playing catch-up to Sakai's overall development.
The overall priority has been to make Sakai work, rather than make it
compliant.

In general, I don't think we are that far away from being compliant.
The refactored tools were based on the style guide and, though not
perfect, work pretty well with JAWS. The big challenge will be to make
changes to the wrapper and the way it interacts with the tools so that
the whole experience becomes seamless and navigable with a screen
reader. From a practical standpoint, it really doesn't matter if the
tools are compliant, if the path there isn't.

I will be meeting early this week with team members to talk about
the technical issues we face in making the outside of Sakai compliant
and supportive of the inner tool experience. We've also discussed
accessibility this last week during the tools team meeting and I will
be putting together a plan for testing the refactored tools, while we
address the wrapper issues.

So, I guess in summation, I would say we're not there yet, but we're on
the case.

Recent (May 17) email about the Indiana AT testing on March 7, 2004...

Their usability test is interesting since it provides the perspective of a screen reader user. it points out that the need to make some additions to the style guide and changes to the application. For example, although the icons (with alt tags) can be helpful in the schedule, the legend itself is probably unnecessary and confusing for a screen reader user (doh). There also needs to be feedback to the user that input has been received and accepted (in the style guide...not sure).

Other things we've discussed are worth repeating: Labels need to be better differentiated (probably through titles) and more consistent. Frames should have meaningful titles. Forms and tables should be properly tagged. Popups should be avoided. Accessibility information from a screen reader's perspective needs to be included, including suggestions for AT settings. Refresh and turning off refresh is a problem. Input buttons (like checkboxes) shouldn't be in tables. Subcategories can be confusing (like in Help) due to a lack of heading and subheading tags.

I think we've covered everything in the last paragraph in the style guide, but I'll look it over to be sure. I know you and the tools team have been trying to get as much accessibility as possible in reach release, but I'm not sure what's gotten in, so let's get together when you have a minute so I can know for sure what we've been able to include in 1.5.1 and 2.x. That way I can put together some documentation on accessibility for 1.5.1 and 2.0, and we can start plotting how to get the rest in 3.x.

I have added a draft timeline for evaluation and revision of 2.0 tools to be 508 compliant by Fall 2005. See attachment above.