Creating Accessible Forms

Overview

This has been presented as 4^th Learning Session to the members and guests of W3C Accessibility in India Community Group. Objective of these learning sessions is to raise awareness about accessibility and enhance network of accessibility professionals.

Slides

Below are the slides presented in the session:

[slideshare id=57260792&doc=19a44141-2932-4348-a1b4-c07c1205eba1-160120053335]

Text Transcript

Hello everyone, Thank you for joining us. In this session, we will be talking about Creating Accessible forms. Agenda of this session will be:

Agenda

1. About Deque and Me
2. Setting the Context – Forms
3. Remembering Basics
   1. Associated Labels
   2. Group Level Form Controls
   3. Labels and Instructions
4. Making Dynamic and Complex Forms accessible
5. Error handling and prevention
6. WCAG 2.0 Success Criteria related to forms
7. Resources
8. Questions

About Deque

Deque is a global leader in the area of Accessibility serving Government, Corporate and other organizations for 15+ years. Digital Accessibility is both our mission and vision.

About Me

Am an accessibility evangelist with a decade+ of experience. Started my accessibility journey at BarrierBreak, then worked at several organizations including Yahoo!, PayPal, HCL Technologies and currently works at Deque. Accessibility is not just my profession but something very close to my heart. My hobbies include networking, swimming, playing Chess and Carrom. Currently I live in Hyderabad with my wife Hema and our cute daughter Khushi Varshini.

Setting the context – Forms

Today digital forms are playing a key role in people lives. They are everywhere from school admission to avail retirement benefits. It’s encouraging to see even Government is promoting use of digital services. Moving to digital would be an added benefit to people with disabilities and make them less dependent. They are also safe and secure way to store and easy to retrieve.

Basics – Associated Labels

It’s essential that all form controls are programmatically associated with their respective labels. This can be achieved by using <for> and <id> attributes, <aria-label> or <title> attribute.

View Form Label example

References for Associated Labels:

1. W3C – WAI’s tutorial on Form labels
2. Technique H44: Using Label elements to associate text labels with form controls
3. Technique G131: Providing Descriptive Labels

Basics: Group level form controls

When user has to select options that are provided in the form of radio buttons, checkboxes or when there are a group of form controls such as Date of birth, phone number; those controls usually have a common label. In such a situation, it’s essential to ensure that:

1. All form controls are programmatically associated with their labels
2. All form controls are programmatically associated with their common label

View Radio button example

References for Group level form controls

1. Technique H71: Providing a description for groups of form controls using fieldset and legend elements

Basics: Labels and instructions

It’s recommended that forms labels are visible. Now-a-days, placeholder text is used as form label; but this is not a good practice unless there is a mechanism to make label still visible even when user has inserted data into input field. Otherwise, it would be difficult for several users including those with cognitive disabilities to review the information before submitting.

It’s also important to provide instructions about required fields, if input field accepts data only in specific format or any other information that user should know while filling out the form.

Resources for Labels and instructions

1. Understanding SC 3.3.2: Labels and Instructions

Dealing with Dynamic and Complex Forms

I’m going to demonstrate you all 3 examples:

1. Creating Accessible Date Picker where the date picker is completely accessible using keyboard and not with mouse alone, all dates have descriptive labels for user to select
2. Now-a-days, e-Commerce is trending and often the challenge is to deal with Shopping cart. Shopping carts usually gets updated dynamically as user makes selection of a product. So it’s essential that user gets the updated information about pricing, quantity added, total number of products in the cart etc., So let’s look at an Example of Accessible Shopping Cart <aria-live> tribute plays a key role to make such applications accessible.
3. Another interesting widget would be Character count. We see several applications will have <texture> input field that allows only a limited number of characters can be inserted. In this case, user should be informed about permitted number of characters along with the <label> and alert user when nearing to end of allowed number of characters. It’ would be annoying to to expose character count right from first character. View Example of an Accessible Character Counter

Error handling and prevention

It’s important that there is a mechanism to identify mistakes that user has made on form submission. It’s also important error messages are conveyed via multiple clues including through text and styling input fields that requires correction.

It’s essential to enable users to prefer from making mistakes. To address this, user should be provided helpful information along with form label for potential fields that require user to input in specific format. For instance, Date of birth field accepts in a specific format or in a user registration form, password field may have some conditions. These need to be informed to user.

Resources for Error handling and prevention

1. Understanding SC 3.3.1: Error identification
2. Understanding SC 3.3.6 – Error prevention

WCAG 2.0 Success Criteria that are related to Forms

1. 1.3.1 Info and Relationships: Information, Structure and relationships conveyed through presentation can be programmatically determined or are available in text (Level A)
   1. Associate labels either explicitly or implicitly
   2. Ensure that group related form controls are marked up using <fieldset> and <legend>
2. 2.4.6 Headings and Labels: To describe topic / purpose (Level AA)
   1. Provide descriptive labels
   2. Provide visible labels
3. 3.3.2 Labels or instructions: Labels or instructions are provided when content requires user input (Level A)
   1. Identifying required field
   2. Error identification
   3. Providing instructions
4. 4.1.2 Name, Role and Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A)

Resources

I have put together some great resources including Code Examples from our Deque University, a nice tutorial from W3C, a couple of articles from WebAIM and my good friend Rakesh.

View Resources

Thanks everyone for attending and looking forward to see web more inclusive. Do feel free to reach out to me for any questions / comments.