Accessible Form Elements |

ACCESSIBLE SEARCH: Using aria-label to Identify Site Search for Screen Reader Users

Posted on October 12, 2019October 13, 2019 by Mary Gillen

As website designers and developers, we should always plan on using the native HTML methods of labeling items on a page.

Consider the humble website search form, seen on so many websites:

It is easy for sighted users to understand that they can use the form to conduct a site search.

But what about visually-impaired folks who use screen readers to navigate a website? We have to provide them with a recognizable label for the search field that can be announced by a screen reader since the user cannot see the interface.

Issue

What if the designer doesn’t wants to place a visual label in the search form area in order to save space, yet still inform the screen reader users about the functionality of the search function?

Enter the aria-label.

ARIA (Accessible Rich Internet Applications), is a specification from the W3C and created to improve accessibility of applications by providing extra information to assistive technologies, such as screen readers, via attributes which could be added to HTML. [SOURCE]

Solution

Here’s how to add an aria-label as an explicit invisible label to the search form code that can accommodate screen reader users:

===

One-on-One Online Training: Learn How to Test Websites and Online Content for Accessibility: Are you a web developer, designer or content creator who needs to get up and running quickly on the basic rules of website accessibility and how it all relates to your website and its content?

Or maybe you already know the web design accessibility basics, but are stumped on how to fix your website and content so all is compliant.

Wouldn’t it be more practical if you could “learn by doing”…as in figuring out what needs to be fixed on your own website/content while you learn the WCAG 2.1 A, AA & AAA Guidelines?

Now you can through one-on-one online training with Mary Gillen.

Find out more about Mary Gillen’s “Learn How to Test Websites and Online Content for Accessibility” online training.

===

ACCESSIBLE FORMS: Phone Number Fields and Text Labels

Posted on July 14, 2019July 14, 2019 by Mary Gillen

Black Labrador Retriever Looking Up at Telephone Receiver

Many people with visual or cognitive disabilities can recognize phone number fields in HTML forms and usually understand what info needs to be provided to fill in the fields.

Phone numbers are frequently formatted in fixed, distinctive ways, and Web developers may feel that just providing visual formatting of the fields will be sufficient to identify them.

Not so fast

Even if all the fields have programmatically determined names, a text label must also identify the set of fields as a phone number. The label alerts screen reader users about the content necessary to complete the form field correctly.

Best Practice in HTML5

In its most basic form, a telephone form input and text label can be implemented like this:

<label for=”telNo”>Phone number:</label>
<input id=”telNo” name=”telNo” type=”tel”>

===

WEBSITE ACCESSIBILITY TESTING & REMEDIATION SERVICES: Mary Gillen is an experienced Website Accessibility Compliance Auditor and Remediator. She can test your website to determine if it meets accessibility standards:

WCAG 2.1: 312 checkpoints covering A, AA and AAA W3 accessibility guidelines
Section 508: 15 US federal guidelines covered by 59 accessibility checkpoints

Find out more about Mary Gillen’s Accessibility Testing & Remediation Services: Websites, PDFs, Office Docs & Videos

===

ACCESSIBLE FORMS: A Select “Jump Menu” Tip

Posted on May 24, 2019May 24, 2019 by Mary Gillen

“Jump menus” are select drop down menus that automatically submit once an option is selected. This occurs due to use of the JavaScript onchange event handler.

Problem is these types of select lists cannot be operated from the keyboard if they have an onchange handler that performs navigation. Why? Because the handler fires as the user moves the selection up and down using the keyboard. Moving through list items using the arrow keys will jump to another page or website location unexpectedly. This does not comply with WCAG 2.1 Guideline 3.2.2 – On Input (Level A).

SOLUTION: To make the select menu keyboard accessible, allow the user to trigger the navigation via a Submit button. This way the user has access to all the options in the menu using the up/down arrow keys, and, when ready, can press the Go (Submit) button that will trigger a processing script for successful navigation.

===

WCAG 2.1: 312 checkpoints covering A, AA and AAA W3 accessibility guidelines
Section 508: 15 US federal guidelines covered by 59 accessibility checkpoints

Find out more about Mary Gillen’s Accessibility Testing & Remediation Services: Websites, PDFs, Office Docs & Videos

===

ACCESSIBLE BUTTONS: 4 Built-in Benefits

Posted on May 3, 2019May 3, 2019 by Mary Gillen

Ditch the <div> when creating accessible controls. The <button> element is a developer’s friend. Check out these four built-in benefits of using the <button> element:

Native keyboard focus.
Native role of button, which help AT users understand it’s an interactive element.
It can be triggered with Enter or Space without adding any extra JavaScript.
It can use the disabled attribute, for when the button shouldn’t be interactive anymore.

RESOURCE: Check out Rob Dodson’s just use buttons video as he demonstrates a few handy button features you might not have seen before.

[SOURCE]

===

WCAG 2.1: 312 checkpoints covering A, AA and AAA W3 accessibility guidelines
Section 508: 15 US federal guidelines covered by 59 accessibility checkpoints

Find out more about Mary Gillen’s Accessibility Testing & Remediation Services: Websites, PDFs, Office Docs & Videos

===

ACCESSIBLE FORMS: Avoid the Automatic Submit

Posted on April 3, 2019April 3, 2019 by Mary Gillen

Cartoon Illustration of HTML Forms

Forms are frequently designed so that they submit automatically when the user has filled in all the fields, or when focus leaves the last field.

From an accessibility standpoint, this causes two problems:

1) A disabled user who needs more context may move focus away from the field to the directions on how to fill in the form, or to other text, accidentally submitting the form.

2) With some form elements (such as a select menu), the value of the field changes as each item is navigated with the keyboard, again accidentally submitting the form.

Best Practice

Better to rely on the standard form behavior of the submit button and enter key.

Form Submit Code That Is Not Accessible

Form Select Menu Code That Is Not Accessible

<form method=”get” id=”form2″>
<input type=”text” name=”text1″>
<select name=”select1″ onchange=”form2.submit();”>
<option>one</option>
<option>two</option>
<option>three</option>
<option>four</option>
</select>
</form>

[SOURCE]

===

Read More Accessible Website Design Advice: Accessible Best Practice: Don’t Use Color As Part of Your Instructional Content

===

WCAG 2.1: 312 checkpoints covering A, AA and AAA W3 accessibility guidelines
Section 508: 15 US federal guidelines covered by 59 accessibility checkpoints

Find out more about Mary Gillen’s Accessibility Testing & Remediation Services: Websites, PDFs, Office Docs & Videos

===

ACCESSIBLE FORMS: Get a Head Start with Boilerform

Posted on March 26, 2019March 26, 2019 by Mary Gillen

Cartoon Illustration of HTML Forms

Boilerform is a little HTML and CSS boilerplate to give you a head start when creating accessible HTML forms.

By providing baseline BEM structured CSS and appropriate attributes on elements, Boilerform takes some of the pain away when building forms in the best possible way with a view to being dropped into most projects.

Take Boilerform for a test drive here.

===

WCAG 2.1: 312 checkpoints covering A, AA and AAA W3 accessibility guidelines
Section 508: 15 US federal guidelines covered by 59 accessibility checkpoints

Find out more about Mary Gillen’s Accessibility Testing & Remediation Services: Websites, PDFs, Office Docs & Videos

===

ACCESSIBLE FORMS: Calling All Radio Buttons

Posted on January 23, 2019February 5, 2019 by Mary Gillen

To be recognized by screen readers, radio button groups need: 1) a fieldset, 2) a legend, and 3) labels.

Legend text is announced along with the label text for radio buttons inside a fieldset, which makes it easier for a screen reader user to understand each radio button choice.

CODE EXAMPLE:

<form>

<fieldset>
<legend>Choose the sandwich you want to order:</legend>

<input type=”radio” name=”sandwich” value=”cheese” id=”sandwich_cheese”>
<label for=”sandwich_cheese”>Cheese</label>

</fieldset>

</form>

BROWSER VIEW

===

WCAG 2.1: 312 checkpoints covering A, AA and AAA W3 accessibility guidelines
Section 508: 15 US federal guidelines covered by 59 accessibility checkpoints

Find out more about Mary Gillen’s Accessibility Testing & Remediation Services: Websites, PDFs, Office Docs & Videos

===

ACCESSIBLE FORMS: Don’t Forget to Use Explicit Form Field Labels

Posted on January 9, 2019January 9, 2019 by Mary Gillen

Sample HTML form fields with labels

Did you know that most screen readers don’t recognize placeholder values in form fields?

Your website visitors who use screen readers navigate through your forms using the Tab key. The <label> elements are used by screen readers to announce/identify each form control and the type of info to be collected. Placeholder text is bypassed by the screen reader. Plus placeholders are usually more difficult to read by sighted visitors due to color contrast issues.

Example:

White email <label> vs. dark grey “enter your email address” placeholder:

Use Explicit Form Control Labels

An “explicit” label is created using the HTML label element with a “for” attribute that has the same value as the matching input “id” attribute.

Here is an example:

<label for=”firstname”>First Name: </label>
<input type=”text” name=”first_name” id=firstname”>

The label “for” and the input “id” attributes can be used with any of the form fields: text inputs, text area, select menus, check boxes and radio buttons.

IMPORTANT NOTE: The “id” attribute for each form element in a document must be unique.

[RESOURCE]

===

WCAG 2.1: 312 checkpoints covering A, AA and AAA W3 accessibility guidelines
Section 508: 15 US federal guidelines covered by 59 accessibility checkpoints

Find out more about Mary Gillen’s Accessibility Testing & Remediation Services: Websites, PDFs, Office Docs & Videos

===

FORMS: Accessible Select Menu – Get the Code

Posted on January 8, 2019 by Mary Gillen

Select menus with more than 11 options should be coded with option groups and labels in order to be accessible.

Here’s the code:

<form>
<label for=”favfood”>Choose your favorite food</label>
<select name=”favfood”>
<optgroup label=”Fruit”>
<option value=”1″>Apples</option>
<option value=”2″>Oranges</option>
<option value=”3″>Pears</option>
<option value=”4″>Bananas</option>
</optgroup>
<optgroup label=”Bread”>
<option value=”5″>Sourdough</option>
<option value=”6″>Wheat</option>
<option value=”7″>Rye</option>
<option value=”8″>White</option>
</optgroup>
<optgroup label=”Entree”>
<option value=”9″>Beef</option>
<option value=”10″>Chicken</option>
<option value=”11″>Fish</option>
</optgroup>
<optgroup label=”Cheese”>
<option value=”12″>American</option>
<option value=”13″>Swiss</option>
</optgroup>
</select>
</form>

===

WCAG 2.1: 312 checkpoints covering A, AA and AAA W3 accessibility guidelines
Section 508: 15 US federal guidelines covered by 59 accessibility checkpoints

Find out more about Mary Gillen’s Accessibility Testing & Remediation Services: Websites, PDFs, Office Docs & Videos

===

<accessible-website-services>

Category: Accessible Form Elements

ACCESSIBLE FORMS: Phone Number Fields and Text Labels

ACCESSIBLE FORMS: A Select “Jump Menu” Tip

ACCESSIBLE BUTTONS: 4 Built-in Benefits

ACCESSIBLE FORMS: Avoid the Automatic Submit

ACCESSIBLE FORMS: Get a Head Start with Boilerform

ACCESSIBLE FORMS: Calling All Radio Buttons

ACCESSIBLE FORMS: Don’t Forget to Use Explicit Form Field Labels

FORMS: Accessible Select Menu – Get the Code