It's official: Level Access and eSSENTIAL Accessibility are becoming one! Read the Press Release.
Webinar Icon

Last week’s presentation in our Accessibility Basics Webinar Series covered best practices for Accessible Forms. Senior Director of Client Services Mona Rekhi presented the webinar and has provided answers to the questions we received during Q&A – both those that were answered during the webinar and those we weren’t able to get to during the allotted time.

Forms Q&A

Is there a reason why the * is at the end of the label? If placed before the label we can identify the required fields faster when we navigate with a screen reader by form elements. 

//MR: The * can be placed before or after the label text. As long as it is within the <label> tag it will be rendered along with the label text. For example:

<label for=”uname”>*Username </label>

Does the label always have to be on the top of the field, or can it be to the left of it?

//MR: the label text should be displayed close to the form field. It can be placed closely above the form field. For radio buttons and checkboxes, it suggested that labels be displayed to the right of the form field.

Would the use of an asterisk to note required fields be necessary on paper forms?

//MR: Asterisk could be used to denote required form fields as long as, just as on a web page, a legend is associated to describe the asterisk. For example: * Required Fields

How would you code a date so that the screen reader understands it as a date?

//MR: You can use:

<label for="expire">Expiration date (MM/YYYY): </label> <input type="text" 
name="expire" id="expire">



  <label for="d1" Date: </label>

  <input aria-describedby="dformat" id="d1" type="text" name="sample_field">*
   <span id="dformat">MM/DD/YY</span>


Should web applications/web forms have implicit submission or do we need to disable the Enter = submit? 

//MR: I believe what you are asking is should enter, when pressed in an input field, trigger form submission. That is the default behavior of a form and is fine.  Some users rely on that, while others may accidentally press enter, but it is acceptable and allowed.  If you were using proper form markup and form buttons, enter on a button in the form that is not the submit button should not trigger the form.  So if developers create custom buttons they should make sure that enter on buttons does not submit.

Is the use of placeholder text not a good practice to make a compliant form?

//MR: SSB suggests avoiding using placeholder text as the only way to communicate the label for a form field. The disadvantages of using only the placeholder are outlined below:

  • Placeholder text does not have sufficient color contrast
  • Placeholder text disappears when a text box receives focus
  • Users may think that the text field is populated and may skip the text field

Always provide an explicitly associated text label for a text field.

Do you need special software to check 508 compliance in forms?

//MR: Testing for conformance to Section 508 standards or WCAG guidelines requires a combination of automated, manual testing and assistive technology validation.

Given the lack of support for the title attribute, is also adding aria-label suggested? Does doubling them cause them to both be read in some screen readers? Is this still preferred to provide the widest audience with a label however? (Assuming no actual label is in use)

//MR: SSB recommends using an explicit label for a form field as a preferred format. For example:

<label for="ship1">Ship To:</label>

<input id="ship1" type="text" name="shiptoaddr1" size="30">

ARIA -Label is also a compliant way to label a form field. For example:

<input aria-label="Search" type="text" id="search" />

<button id="b1"> Go </button>

So (* First Name) is not compliant and (First Name*) is compliant just because of the asterisk before and after?

//MR: Both are compliant as long as * is denoted by a legend . For example * – Required form fields AND are included in the <label> tag

For example:

<label for="ship1">*Ship To:</label>

<input id="ship1" type="text" name="shiptoaddr1" size="30">

If I have read-only fields how should assistive technology, especially JAWS, behave with them? Should JAWS have to read that field as read-only or can it simply skip read-only elements?

//MR: Read-only fields are rendered by the screen reader when the read-only attribute is included with the form field. Screen reader users are not able to enter content in a read-only form field.

For example:

<input type=”text” readonly >

Can I use <H> element instead of Legend elements?

//MR: When describing the required field indicator, we use the term legend for the text that describes the *asterisk for what it indicates. We are not discussing the <legend> tag.

Headings (H1 – H6) are used to define structure and hierarchy of content. A heading is used when defining a new section of content within the web page.

Can we use aria-labelledby and fieldset/legend together?

//MR: aria-labelledby can be used to group elements, and so can fieldset/legend. SSB recommends using native HTML elements such as fieldset/legend as a desired solution.

For text fields the label is usually on the left, but for checkboxes you said the label should be on right, but would the user get the checkbox before the label? And does it matter?

//MR: Labels for most fields are positioned immediately before the field, that is, for left-to-right languages, either to the left of the field or above it, and for right-to-left languages, to the right of the field or above it. Labels for radio buttons and checkboxes are positioned after the field. These positions are defined because that is the usual (and therefore most predictable) position for the label for fields, radio buttons and checkboxes. Checkboxes and radio buttons have a uniform width while their labels often do not. Therefore, having the radio button or checkbox first allows both the buttons and the labels to line up vertically. See this guidance from W3C:

Are screen readers able to read “title” attributes?

//MR: Yes; however, screen reader users have the ability to enable or disable the screen reader from rendering the title attribute.

Visual layout vs. tab order?

//MR: Tab order should follow the visual layout of the page. The tab order should tab through the interactive elements on the page based on the visual layout.

How would I fulfill this requirement: “Information revealed by mouseover (TITLE) is not available to keyboard-only users (i.e., there is no equivalent screen text or visual context)”?

//MR: Use redundant keyboard handlers. For example:

<a href="" onMouseOver="window.status='Go to the yahoo homepage':return true" onFocus="window.status='Go to the yahoohomepage':return true">

Yahoo Home Page


Is use of the placeholder attribute not a good practice to make a compliant form? I have a requirement where I need to design the page without labels on the text boxes. 

//MR: The placeholder attribute should be avoided. Some solutions include placing a visual label above the form field within the textbox as soon as focus is placed on the form field and the placeholder disappears. Another possible solution is to provide an icon which depicts the placeholder, again displayed within the textbox when the placeholder disappears.  Here is a good article on the topic: