Skip to main content

Tagged as

forms

Creating Accessible Forms

Overview

This has been presented as 4th 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:

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.

Common mistakes of that a web developers make

Most developers feel making a website accessible require an additional effort, time consuming and needs to write a lot of additional code; which is actually not very true. But yes, there are certain additional things to be done, but they are most times enhancements. Having said that, most of the efforts that require to make a website accessible are the best practices of HTML. Here, I will endeavor to illustrate some of the common mistakes that a web developer commits.

  • Provide inappropriate page titles or provide a common title for all the pages across the website something like the name of the organization without the respective page title
  • Do not declare doctype External Website of the document
  • Do not define language of the document
  • Do not provide text alternative to non text elements such as images, CAPTCHA, audio etc.
  • Do not markup the headings in the documents
  • Use table attributes for the layout purpose
  • Do not mark up table summary, table headers
  • Do not mark up associated labels for form fields using “for” and “id” attributes
  • Do not provide site map to the website
  • Do not use accessibility techniques while using Java script, Flash etc.

Best reading…

Writing accessible HTML forms

We fill a lot of forms on the web on daily basis – may it be for a bank transaction, booking of travel, shopping etc. Often we see forms looks very beautiful but in reality, most of them are not beautiful due to lack of associated labels. Oh! wait, we know, you are about to shown on us and say that you have never seen a form just with input elements and without text labels, you are right, but did you ever see a form with a text browser or with a screen reader. Here is an exercise for you before reading this article:

  1. Download NVDA External link Screen reader and install on your Microsoft Windows machine
  2. Open your web browser perhaps Mozilla Firefox and visit the APSRTC‘s New Registration Form External Website and you should see a beautiful form like below.

    APSRTC New Registration form

  3. Press “F” key on your keyboard to reach to the first form field and then navigate the form using “tab” key; ideally you should hear something like “Username:edit, Password: password edit, Confirm password: password edit, Personal information, Firstname:edit” and so on. But you will hear something like “Table with 16 rows and 2 columns, row two, column two edit” and so on… and here is how this form looks on a text browser:
    Text version of APSRTC Registration form

Now, let’s see what are the issues with above form. Firstly, screen reader is reading number of rows and columns, since the APSRT did not use CSS to control the layout of the form but have used <table> attributes to control the layout. Well, screen readers has the capability to turn off reading the layout tables but some users may not be aware of this option. Also, it is not recommended to use the table attributes to control the layout.

Second problem is that screen reader is unable to read the labels of the form since associated label “for” and “id” attributes are missing. Besides screen readers and text browsers, even search engines treat those form fields with no labels. Here are some ground rules to make accessible forms.

  • Provide necessary instructions before the form states
  • Do not indicate mandatory fields in form of color alone
  • If a form field is a required field, inform the same to the user along with form label
  • Provide associate labels to the form fields
  • Use appropriate “fieldset” and “legend” attributes for check boxes and radio buttons
  • If you opt to use image button, remember to provide alternate text
  • If the form is dynamic, use ARIA labels, roles and states as appropriate

Related links: