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

[Richwine, Brian L]

Eli,

Some of the information presented below is incorrect. For instance, the example of using the label element for indicating the remediation message for the form input elements. The label element is used to link text that describes the purpose and function of a form control to the form control. If as in the example given, the label element was used to present the message "This field is required" then that will be the only label screen-reading software will announce and the control will be listed as "This field is required Edit" in a screen-reading software's Form Controls List Dialog. The title attribute on form controls is only announced in absence of a series of other labels, almost as a last resort. Especially since the text "This field" in the example's label doesn't do anything to describe the field or its function, users would be clueless as to what is required and how to fix it (is the field asking for an email address, a phone number, etc.).

The relationship between a label created by the label element and a form control is a 1 to 1 relationship. Only one label element can be associated to a given form control and a label element can only be associated to one form control. When multiple label elements are tied to a form control, only one will be exposed to the accessibility API layer by the user agent and it is undefined which label would be announced.

There are a series of ARIA properties that can be used to tie other elements containing child text to a form control (see aria-label, aria-labeledby, and aria-describedby attributes).

In this case, what is really desired is the ability to have both a label for the control, and extra descriptive text to help the user remediate the error. The proper technique is to use the label element to explicitly tie text for the label to the form input element if that label text is being displayed, or don't use the label element at all and rely on the title attribute to label the form input element if the label isn't presented visually. The error message should be tied to the form control using the aria-describedby attribute. The aria-described by attribute will provide supplemental information and won't override the form control label, thus the screen-reader user will still know what the form control is for and get supplemental info.

Also, the example presented in your email suggests in its error message that the form field is required but the field was left empty. An effort should be made to assist users wherever possible to prevent errors from happening. One way is to indicate to the user that the form field is required. For assistive users, one way to do this is to add the aria-required attribute and set it to true.

Best case examples (assuming required text field that was submitted empty and generated a validation error):
  If not using visible label:

<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" aria-describedby="desc1" aria-required="true">
<p id="desc1" role="alert" class="error">Please enter a valid place of publication code.</p>

If using visible label:

<label for="profilesection_generalinfo_publications_elements_751260285_placeofpublication">Place of publication: </label>
<input type="text" class="profilesection_generalinfo_content required error" value="" id="profilesection_generalinfo_publications_elements_751260285_placeofpublication" name="Place of publication"
aria-invalid="true" aria-describedby="desc1">
<p id="desc1" role="alert" class="error"> Please enter a valid place of publication code.</p>

For either of the examples above, when the input element gets focus, JAWS announces:
"Place of publication Edit Required Invalid Entry. Please enter a valid place of publication code. Type of text."
For either of the examples above, when viewed in the Forms List dialog in JAWS (a finder tool in JAWS that presents a list of all of the form controls in a browser window), the control is listed as:
"Place of publication Edit"

For comparison, when a completely unlabeled input element (<input type="text" value="" name="notLabeled">) gets focus, JAWS announces:
"Edit. Type of text."
In the Forms List dialog in JAWS, the control is listed as:
"Edit"

Using either of the above techniques allows the assistive technology user to understand the purpose of the input field, that it is a text box they can enter text in ("Edit", "Type of Text"), the state (it is required, it is invalid), and get helpful information on how to remediate the error ("Please enter a valid place of publication code").

The behavior of screen-reading software like JAWS is to follow a hierarchy of checking for the presence of a features that can be used as a label, and to announce the first one it finds, and then to stop checking for further labels. After deciding on a label an announcing it, then it proceeds to describe any important semantic info (is it an edit field and what type, or a submit button, etc.), state information (is it disabled, is it invalid, is it required, etc.), and extra descriptive info (child text of elements indicated in the aria-describedby attribute).

Important Note: Relying on title attributes to communicate important, necessary to know information is definitely not recommended. The text value of the title attribute is not accessible to sighted keyboard only (non-mouse) users. Also, if the JAWS screen reading software chooses another feature to announce as the label for an element, then the title attribute is generally unavailable to the screen-reader user. For instance, using the title attribute to describe the format for entering information (date format, phone number format, etc.) is not recommended - place the text on the screen where all can see it and tie it to the control using the aria-describedby attribute so it does not override the element's label. The aria-describedby attribute can hold multiple ID values and will concatenate text from all of the indicated elements so error messages can be added to the model input information if desired.

For instance, the default settings of JAWS 12 for configuring the method for choosing text to announce when describing an element are:

For an Image choose the first from:
Alt attribute, title attribute, src attribute

For an unlabeled image link (where the image has no alt attribute or title and the link has no text, title attribute, or alt attribute):
Speak Image's src attribute instead of the link's href value

For a link, chose the first from:
Child text including alt attributes on images, title attribute, alt attribute, href attribute

For a button (the label element does not apply to buttons):
Child text including alt attributes on images, title attribute, alt attribute, value attribute

For a form input element, select element, etc. (not buttons):
Associated Label element's child text including alt attribute on images, form field element's title attribute, form field element's alt attribute
Note: JAWS can alternatively be set to read both label and title if different or both the label and alt if different, but neither of these is the default and these two options are exclusive of each other.




From: sakai-ui-dev-bounces at collab.sakaiproject.org [mailto:sakai-ui-dev-bounces at collab.sakaiproject.org] On Behalf Of Eli Cochran
Sent: Wednesday, May 25, 2011 3:42 PM
To: Sakai UI Development; accessibility at collab.sakaiproject.org WG
Subject: Sakai OAE, accessible validation and Gritter

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

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