[WG: Accessibility] Sakai3 - getting the basics right

[Mary Stores]

Hello,

I just took a look at recaptchas and this is exactly what I am talking 
about. You can find an example at this link 
http://recaptcha.net/learnmore.html . It works because there's a link 
that says, "get an audio challenge." An audio file is played telling 
the user to type the words they hear with spaces, and the words are 
played twice. It's usually a human person saying part of a phrase or 
sentence. There's an option to play the sound again or to download an 
mp3 file of it. The audio quality isn't too bad, either. As a matter of 
fact, according to the research I just did, this is exaclty what 
facebook uses.

Mary
Quoting "Richwine, Brian L" <brichwin at indiana.edu>:

> 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"
>