[WG: Accessibility] Sakai3 - getting the basics right

Thu Jan 14 16:57:27 PST 2010

Christian, great to know that you were on the call today. Please feel free to join in the conversation and to ask questions. As you heard today, Sakai 3 is one of our main topics of interest. 

I'm going to cc. the UX List with this conversation since these are great questions (and interesting answers) and I hope that everyone will benefit from them.

ALso, let me add on to some of Brian comments.

1. Captcha, specifically reCaptcha. reCaptcha is considered quite good and it does provide an audible challenge as well as a visual one. I'd love to hear how actual screen reader users feel about reCaptcha. I tried the audible challenge today and was surprised that I was presented with a 10 word phrase with one of the words unintelligible. 10 words seems like a lot to ask a person to type, although it appears that you don't have to get them all correct to pass. 

2. Semantic Markup. When I first started to design for disabled users, I assumed that screen reader users simply read through pages from top to bottom. When observing actual screen reader users I was very surprised that they interact with the page in much the same way that I do -- skimming the page to find the relevant bits. Where I used visual clues, the screen reader user relies on page semantics to provide context, structure and landmarks. 

3. Title Attribute. My understanding is that although screen readers can be configured to read the title attribute, most screen reader users don't use that feature. The text contained within the <a></a> tags is the thing that most screen readers key off of.

I'm sure that Brian will respond to your other questions. Let me say that all your efforts so far are great. 

One of my goals for Sakai 3 design and development is that accessibility be "baked-into" all our patterns from the start. 

The Accessibility WG can be a resource for examples, checklists, etc. Some of this already exists, but much of it needs to be developed or pulled together from other sources. 

Thanks,
Eli 

On Jan 14, 2010, at 3:51 PM, Richwine, Brian L wrote:

> Hello Christian. Welcome! Thanks for attending our teleconference. 
> 
> I'm going to make an attempt to answer a few of your questions before I have to run home for the night.
> 
> 1. Mary Stores, who you heard on the conference call said that she has successfully used CAPTCHA systems on Facebook, PayPal, and Last.FM among others. You could ask her what worked best about them. There were a few other issues on that page, but the CAPTCHA was the only blocking issue. Mary is preparing a report that will summarize her findings. I haven't looked at reCAPTHA. Perhaps someone else has and can comment on it, if not, or no one comments, we are happy to look at it for you.
> 
> 2. We have just started looking at the Sakai 3 development, but we did notice that Headings hierarchy was broken. This was observed on the Home page, right after logging in the first time as a newly registered user. What is meant here, is that there are not any level 1 headings. The first heading level found are the level 2 headings. This is important because screen readers frequently use the headings for discovering the page content and for navigating. With a screen reader, they can make a list of headings sorted by heading level, order of appearance (in the code), alphabetical, etc. Screen reader users can also navigate between headings of a specific level simply by pressing the appropriate number key (1, 2, 3). We will have a detailed report of findings on the first pages ready soon, which will include the other page structure / markup issues we have found.
> 
> 3. The slash between purpose and destination was as an "or" and was included because some links (like a more traditional link) have a destination (another page URL) while other links trigger scripts and have a function. Here we don't mean the href attribute, but the title attribute and the link text. What is important is to consider that a screen reader user can make a list of all the links on a page, and they should make sense in a list context (much like a list of bookmarks). Screen readers also make lists of the headings, form elements, aria landmarks, etc. The links lists and other list dialogs are useful to the screen reader user, because they help them quickly navigate the active parts of a page. Depending on how keyboard accessible an element is, it also may be the only way a screen reader user can activate or select a given element.
> 
> The classic problem that is most frustrating and illustrates the intent here, are pages where many of the links have link text of "Click Here" and when pulled into a list give no indication as to what happens when they are activated. An example of this on the Sakai 3 "My Sakai" page is the presence of multiple "Settings" links that don't distinguish between the different widgets they apply to. 
> 
> By default, screen readers will not announce the href attribute only if no link text or title attribute text is present. For instance, on the Sakai 3 "My Sakai" page, there are several links that read "javascript:;" and are listed as such in the link lists. An example is the link on the profile_chat_status_dropdown. The link is available to the screen reader user, but all they hear is "link javascript".
> 
> I have to go home now. More later!
> 
> Thanks again,
>  -Brian
> 
> 
> 
> 
> -----Original Message-----
> From: accessibility-bounces at collab.sakaiproject.org [mailto:accessibility-bounces at collab.sakaiproject.org] On Behalf Of Christian Vuerings
> Sent: Thursday, January 14, 2010 4:57 PM
> To: accessibility at collab.sakaiproject.org
> Subject: [WG: Accessibility] Sakai3 - getting the basics right
> 
> 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
> _______________________________________________
> accessibility mailing list
> accessibility at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/accessibility
> 
> TO UNSUBSCRIBE: send email to accessibility-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> _______________________________________________
> accessibility mailing list
> accessibility at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/accessibility
> 
> TO UNSUBSCRIBE: send email to accessibility-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"

. . . . . . . . . . .  .  .   .    .      .         .              .                     .

Eli Cochran
user interaction developer
ETS, UC Berkeley