[WG: Accessibility] Sakai3 - getting the basics right

[Christian Vuerings]

First of all I should introduce myself, I am Christian Vuerings, one of the Sakai3 front-end developers and I am currently working at Caret (University of Cambridge).
The main subjects I've worked on so far for Sakai3 are the Sakai 2+3 hybrid mode, the new prototypes for Sakai 3 and the chat widget.

I've been following the accessibility list and I listened to the latest teleconference.
During that call I heard some very interesting stories about Sakai3 and some of the current issues with it:

1) The Captcha system we have at the moment doesn't meet the needs for blind users since it doesn't provide any alternatives such as having an audio file next to it.
This is definitely right but I don't know which Captha system would be the best to implement.
Recently I heard about reCAPTHA which should be more accessible to blind users and it also helps organisations to digitise books.
Is this something that would look good to you? Does anyone has experience with it or knows about any better examples?

2) The basic structure is not right.
With this I assume you mean the sequence of the h1 till h6 tags? Using divs when we need to use p tags? Are there any other things we should change?
A list of what needs to be changed on which pages would be very handy.

Apart from what I heard on that call I also saw some things that captured my attention in the document called "Accessibility Improvements that Could Be Seen in Sakai 3 over Sakai 2.x":

3) Make all link text/titles to unique destinations distinct. Make sure the purpose/destination of each link is clear.
Should I interprete the slash between purpose and destination as an OR or as an AND?
And what do you mean with the destination of a link?
Do you mean the href attribute in an anchor tag or does the title attribute suffice to explain where the user will go to?
In Sakai 3 we currently have a lot of <a href="javascript:;">link</a> tags, it would be fairly easy to add a title attribute to those but changing the href attribute will be much harder.

4) Don't use frames/iFrames. If frames are necessary, make sure they have descriptive names that provide necessary contextual information.
I am also a big opponent of using frames/iframes myself but as far as I am aware of we had to use iframes in two places:
a) Widgets that use any API from Google such as the google maps widget. The reason for this is because the JavaScript from google conflicts with ours.
b) The Sakai 2+3 Hybrid mode. Since Sakai 2 is completely iframe based it is nearly impossible to have a hybrid mode that isn't. I had to make the tools as iFrames but I managed to keep the titles of the tools and the menu which list the tools as native Sakai3 code.

5) Allow users to specify their default WYSIWYG editor preference.
Since the current Sakai3 uses a completely modified version of the tinyMCE editor it will be very hard to implement this request.
The reason some people modified this component is to have the ability to insert widgets into pages, have the editor always on the top of the screen and to fit it in with the current design.
Would it be alright to say that we'll try to make the tinyMCE editor that we are using now as accessible as possible and ignore others for now?


As you can see from the list above I think we, the front-end developers, just need some concrete steps/tasks that we could complete in order to make Sakai3 more accessible.
The system we are currently using to track our bugs/issues and tasks is Sakai Jira.
Does it sounds fine to you to use this system for tracking things for accessibility as well?

The main Sakai3 JIRA project which is called Sakai 3 - core already has the following components:
 - Groups
 - UI Development
 - UX Design

What I would suggest to do is to add a group called e.g. "Accessibility" where you would be able to add the bugs you encounter (e.g. providing a screen-readable captha) and the tasks that need to be done (e.g. check if the login page conforms with the current accessibility guidelines).

To end this mail I would just want to give a list of things I've done over the last few weeks to improve the accessibility:
 - Put the CSS outline back on links so the users have visual feedback of where their tab focus is. [2]
 - Changed the absolute positioned divs that showed the font/font-size to select boxes for TinyMCE. This is part of their accessibility example ( http://tinymce.moxiecode.com/examples/example_17.php )
 - Added several labels to textfields + supplied the for attribute on them (for instance on the log-in page)
 - Putting some of the input and label elements in forms.


Regards,
Christian

PS: Just before sending this mail I saw that Eli posted the captha problem to Jira: http://jira.sakaiproject.org/browse/SAKIII-131

[1] http://jira.sakaiproject.org/browse/SAKIII
[2] http://jira.sakaiproject.org/browse/SAKIII-83