Accessibility Design Guidelines:

Purchase Forms

Why is this Important?

Forms can be one of the most challenging aspects of navigating a website and considered a common barrier for people with disabilities. Forms are an essential aspect of accomplishing a user's end goal on a webpage and for this reason designers must make forms accessible for all users. When designing forms, following the WCAG accessibility Success Criteria is crucial, regardless of what the purpose of the form is (e.g., log in/sign up, search, contact).

Users that rely on only a keyboard must be able to tab through fields in a sequential order to enter information and submit data. People with cognitive or visual impairments will benefit when the form provides meaning instructions in regards to the form's purpose before the form begins. Read more about how this relates to Success Criterion 3.3.2

In addition, form fields must be clearly marked with meaningful and relevant labels in order to associate the form field with the label. Read more about how this relates to Success Criterion 1.3.1 and Success Criterion 2.4.6

                    <label for="firstname">First Name</label>
                    <input type="text" name="firstname" id="firstname" />

Figure A: Label is associated with a specific form control through the use of the <for> attribute.

Source: Photo by Jon Tyson on Unsplash

"The objective of this technique is to use the label element to explicitly associate a form control with a label. A label is attached to a specific form control through the use of the for attribute. The value of the for attribute must be the same as the value of the id attribute of the form control." See Figure A

WAI, WCAG Read more about this Success Criteria.

Best Practices

By following best practices, we can make forms easier to understand, complete, and submit for people with disabilities.

Use colour and text to indicate required fields.
Provide short and descriptive labels that are associated with its corresponding input field.
Group related form elements and use whitespace and headings to separate groups from one another.
Errors or success should be indicated by both color and text.
Ensure Forms are Keyboard Accessible for those using assitive devices.
Use accessible colour and contrast ratios in text elements.
Use a semantic <button> that includes a <type="submit"> instead of a <div> or <span>. This makes it visible by screenreaders.
Do not set a time limit to complete a form. Allow users to complete at their own pace
Ensure inputs and labels have large clickable areas for users with impaired motor control.

"The label element is not used for the following because labels for these elements are provided via the value attribute (for Submit and Reset buttons), the alt attribute (for image buttons), or element content itself <button>."
See Figure B

WAI, WCAG Read more about this Success Criteria.

                        <button type="submit">SUBMIT</button>

Figure B: Include <type="submit"> within a button element, visible by screenreaders.

EXAMPLES

Click on the icons below to reveal the corresponding WCAG Success Criteria

Form Example (Below)

Product Purchase and Checkout Process

In this example, a Product Purchase and Checkout Process is used to demonstrate the implementation of various WCAG Success Criteria seen in common elements that make up a <form>, such as <input>, <label>, <textarea>, and <button>.

"These techniques provide important cues and instructions that will benefit people with disabilities. Too much information or instruction can be just as harmful as too little. The goal is to make certain that enough information is provided for the user to accomplish the task without undue confusion or navigation."

WAI, WCAG Read more about this Success Criteria.

Step 1: Product Description

One of the first steps in purchasing a product online involves multiple features that if not accessible, prevent some users from reaching their goal. Images, headings, descriptive text, legible buttons and tabbed keyboard navigation, must be considered when designing cards that are AODA compliant.

NOTE: To make a website even more accessible, designers can refer to the Success Criterions related to appearance (UI) to help users with vision and cognitive impairments visually comprehend form information.

"Applying role="heading" to an element causes an AT (like a screen reader) to treat it as though it were a heading. If there is more than one heading on the page and the heading hierarchy is defined through the visual presentation, the aria-level attribute should be used to indicate the hierarchical level of the heading."

                    <h3 role="heading" aria-level="3">Pink Roses</h3>

Pink Roses Bouquet

$59.00 SALE

Enjoy floral bouquets with our unique collection of florals. Pink Roses Bouquet is a beautiful carefully curated selection of pink roses that comes with 12 stems.

Quantity ADD TO CART

Photo by Irina Zhuravleva on Unsplash

Step 2: Checkout Process

NOTE: Always use use semantic HTML form controls like button, input, select, and textarea rather than a div or a span element to be recognizable to screen readers. If you use a div or span, then include a role attibute such as: role="form" See Figure D

"The WCAG Success Criterion 4.1.2: Name, Role, Value is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification."

WAI, WCAG

"Use an HTML <form> element to contain your form controls, rather than the ARIA form role, unless you have a very good reason. The HTML <form> element is sufficient to tell assistive technologies that there is a form. Use an aria-label on the form to provide an accesible name." - MDN Mozilla

                    <divrole="form"aria-label="Payment"></div>
                    
                    <formaria-label="Payment"></form>

Figure D: Use an HTML <form> element to contain your form controls.

NOTE: The examples below integrate numerous WCAG Success Criteria that relate to forms and their content.

Shopping Cart

Please enter the quantity of items that you wish to purchase.

Product	Details	Remove	Quantity	Total
	Pink Roses 1 Dozen	Remove Item Remove from cart	Quantity	$50.00

To add a shipping address, please fill out the form below.
Required fields are marked with a ^*

Name:

First name ^*

Last name ^*

Looks good.

Email ^*

Phone ^*

Please enter a valid phone number.

Address:

Country ^*

Looks good.

Province ^*

Looks good.

City ^*

Please provide a valid city.

Postal Code ^*

Please provide a valid postal code.

Choose Your Delivery Method

Carrier	Method	Information	Price
truck icon	UPS	7 - 10 Business Days	$7.55

Payment Method

Please fill in your Credit Card information.

Credit Card Number ^*

Expiry Date^*

Security Code ^*

Please enter your security code.

Total

Discount

Subtotal	$50.00
Shipping	$5.32
-$0
Total	$55.32
Enter Coupon Code

The Success Criteria for Forms

Who Does This Benefit?

user IconUsing Keyboards for Navigation

vision IconVisual Impairments

computer IconPerson with a Motor Impairment

brain IconCognitive and Learning Disabilities

book IconReading Disabilities

The Related WCAG Success Criteria

1.1.1 Text Alternative

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.
(Level A)

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.4.1 Use of Color

Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
(Level A)

2.1.1 Keyboard

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
(Level A)

2.1.2 No Keyboard Traps

If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.
(Level A)

2.4.6 Headings and Labels

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.
(Level A)

2.4.7 Focus Visible

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
(Level AA)

3.2.1 On Focus

When any component receives focus, it does not initiate a change of context.
(Level AA)

3.2.2 On Input

Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.
(Level A)

3.3.2 Labels or Instructions

Labels or instructions are provided when content requires user input.
(Level A)

4.1.2 Name, Role, 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)