Making an Accessible Form with ARIA, Part 1

Share on FacebookShare on LinkedInShare on Twitter

Aria-describedby, aria-required, and aria-label

This blog is part of my series on using ARIA. It will look at forms and some easy things you can do with ARIA states and properties to make forms accessible.

In my last post I explained how ARIA provides the information or semantics that are missing. For example, you can use ARIA to alert users to their properties and important relationships such as disabled, required, and other labels. In forms, relationships and properties are often clear to visual users because of the way the thing looks, but these same relationships are not clear from the code. You can use ARIA to clarify those important relationships between elements that the user really needs to know.

Using Aria-describedby

Take a look at the picture of a form below:

A form with a search field and instructions below the field that read: Notes: This form is a test for ARIA properties.  We want the error text to be read as soon as the form is submitted with empty text and we want the instructions below to be read with the label of the search form.  The Form itself does nothing.  This search is for the mysite.com (not the web)

 

The Problem

Our form has instructions and context information below the form that a screen reader user would not get to before they submit the form. This is a classic accessibility problem with forms.

For screen reader users (who cannot see the page) the screen reader default is to read the content from beginning to end sequentially. Often users will reach a control without having read all the descriptions and instructions because these institutions are actually AFTER the control itself. In our form the user would submit the page before reaching the text that this form does not search the web.

Aria-describedby saves the day

Use aria-describedby to solve this type of problem: when one element gives a description or instructions about another element. Using the aria-describedby attribute makes any descriptions or instructions read with the control itself. So when a screen reader user tabs to the element the screen reader will announce its description and instructions and the user will know how to use it. It does not matter where it appears on the screen or code.

To use aria-describedby just set the aria-describedby attribute to reference the id of the description or instructions.

In our example:

<input aria-describedby= "divinstruction"  aria-required="true" type="text" name="text1" id ="text1"/>

And make sure the value matches the ID :

<div id="divinstruction">

  This search is for the mysite.com (not the web)

  </div>

That is it. Problem solved.

Required elements

Aria-required indicates if a form field is required. Aria-required  = "true" means the field required, and aria-required ="false" means the field not required.

Example

<input aria-describedby= "divinstruction"   aria-required="true"  type="text" name="text1" id ="text1"/>

aria-label

Another useful attribute is aria-label. Usually you can use HTML labels to provide the label for a form element (or, if needed, you can use aria-labledby). But what if you do not have any  label text to put in a label tag? What if adding text will mess up the look? What if the look makes it clear what the thing is, but it won't make sense when read? What then?

Answer...  use aria-label. (OK the title gave it away...) Aria-label allows you to add a label string that will not be viewable  on the screen.

Example

<button aria-label="Close" onclick="myDialog.close()">X</button>

Another problem simply solved.

In the next blog post I will explain how aria helps make error messages accessible for  form  validation.

[hs_action id="6666"]

4 comments

Leave a Reply

You can use these HTML tags:

<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>