[WG: Accessibility] Sakai OAE, accessible validation and Gritter

[Eli Cochran]

Chris,
I didn't write them up because, as I said below, I didn't actually verify the problems through testing. I just projected based on my own knowledge. Ideally a screenreader user would review the implementation using JAWs, and then write up a detailed bug from their perspective. 
And, ideally, a screenreader user would then review the fix. 

But perhaps we shouldn't wait for that and I should just go ahead and log the JIRAs.

What do you (and anyone else) think?

- Eli 

 
On May 25, 2011, at 4:19 PM, Chris Roby wrote:

> Eli,
> 
> Thanks for all the work here, this is really important. Would you mind creating JIRAs in Sprint 110 for us to address these issues specifically, or is there another step we should take before we do that?
> 
> -- 
> Chris Roby
> 
> On May 25, 2011, at 12:42 PM, Eli Cochran wrote:
> 
>> I'll preface this by saying that I haven't actually tested the implementation with a screen reader, I just noticed the following areas of concern by looking at the rendered DOM. 
>> 
>> One of my designers was asking about the accessibility of the validation she was designing, so I started looking at the validation in OAE. 
>> 
>> Gritter 
>> It would appear from a cursory look that the Gritter (Growl-like) messages are pretty inaccessible. They could be made more accessible by adding role="alert". (role=alert automatically gets the region read by the screen reader.)
>> 
>> Form Validation
>> So there are number of validation models in the OAE right now (I'm working on a JIRA for this). I took a quick look at the validation which add <labels> for remediation of the form elements. (Pretty sure that this uses the jquery validate plugin). This is great... almost there. The <label> tag associates the validation text with the form element. However, it then should also have an aria-invalid=true attribute attached to the element and a role="alert" attribute set on the label. 
>> 
>> Example:
>> <input type="text" class="profilesection_generalinfo_content required error" value="" id="profilesection_generalinfo_publications_elements_751260285_placeofpublication" name="Place of publication" title="Place of publication" aria-invalid="true" >
>> <label for="profilesection_generalinfo_publications_elements_751260285_placeofpublication" generated="true" class="error" style="display: block; " role="alert">This field is required.</label> 
>> 
>> There's a nice little blog entry on the technique here: http://www.punkchip.com/2010/12/aria-enhance-form-validation/
>> A little more discussion of aria-invalid and aria-required here: http://www.w3.org/TR/wai-aria-practices/#ariaform
>> 
>> Probably could add this programmatically via the validate plugin. 
>> 
>> In general these are the kinds of things that we need to validate in the accessibility review. 
>> 
>> Thanks,
>> Eli 
>> 
>> . . . . . . . . . . .  .  .   .    .      .         .              .                     .
>> 
>> Eli Cochran
>> manager of user experience
>> user interaction developer
>> ETS, UC Berkeley
>> 
>> _______________________________________________
>> sakai-ui-dev mailing list
>> sakai-ui-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ui-dev
> 
> _______________________________________________
> sakai-ui-dev mailing list
> sakai-ui-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ui-dev

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

Eli Cochran
project manager, myBerkeley project
manager of user experience design
Educational Technology Services, U.C. Berkeley

"Do not solve the problem that’s asked of you. It’s almost always the wrong problem."
    - Don Norman




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/accessibility/attachments/20110525/542a3044/attachment-0001.html