How to make improve your Online Booking Accessibility

Accessible Form

How to make improve your Online Booking Accessibility

Form Instructions

The screen reader may not notice anything other than the form labels, controls, and legends. Therefore, we must take care to present the instructions in a way that screen reader users will understand.

Assist users in completing the form and using each form control by providing instructions. Indicate any input that is necessary and optional, data formats, and other relevant information.

Code Snippet

<label id="bookLabel" for="bookdate">Booking date:</label>
<span>
	<input type="text" name="bookdate" id="bookdate" aria-labelledby="bookLabel" aria-describedby="bookDesc">
	<span id="bookDesc">MM/YYYY</span>
</span>

Form Controls and Labels

Online booking requires the use of numerous form fields, controls, and labels. We occasionally forget about the end users.

When practical, we should always use native form controls and labels. Use label elements to offer accessible names to native form controls where possible.

We must ensure that the visual label for a form control matches that control’s accessible name.

fieldset and legend

Groups of radio buttons must be wrapped in a <fieldset> with a <legend> that describes the purpose of the radio buttons.

Groups of checkboxes must also be wrapped in a <fieldset> with a legend unless the label for each checkbox is sufficient to describe the checkbox’s purpose completely.

Groups of associated form controls (e.g. a group of text boxes for first, middle, and last name) may also be wrapped in a <fieldset> with a <legend> describing their purpose.

Form Layout and Semantic Order

Form controls appear to screen reader users and keyboard-only users in the source order. Because of this, it’s crucial that the source order for form controls make sense. When form controls are shown in a single column, that is an easy task.

However, you should be careful to ensure that the source and tab order makes logical sense when form controls are shown in numerous columns or other complex layouts.

Required Fields

Although colour can be used to indicate which fields are needed, it cannot serve as the only cue.

Required form controls should use the required property if using HTML5. Required form controls should have the aria-required=”true” attribute for HTML versions older than 4.0.

Furthermore, developers might want to add the word “required” or an asterisk to the label itself (rather than using the CSS ::after selector).

Code Snippet

<label for="firstname">First Name (required): </label>
<input type="text" name="firstname" id="firstname" required aria-required="true">

Validating Form

A form field should have the aria-invalid=”true” property if the input is invalid. This enables screen reader users to be informed of the form fields that need to be filled out. It could be beneficial to include extra styling for invalid input, such a coloured backdrop. When providing such styling, provide high color contrast.

  • Error messages should likewise be as helpful as possible in prompting users how to resolve an invalid form submission.
  • Regardless of whether a form submission is successful, users should always receive feedback.

Code Snapshot

<div role="alert">
  <h4>There are 2 errors in this form</h4>
  <ul>
  	<li>
  		<a href="#firstname" id="firstname_error">
  		   The First name field is empty; it is a required field and must be filled in.
  		</a>
  	</li>
  	<li>
  		<a href="#birthdate" id="birthdate_error">
  		   The Date field is in the wrong format; it should be similar to 27/07/2022 (use a / to separate day, month, and year).
  		</a>
  	</li>
  </ul>
</div>

Enough Time

A process could take longer for users with disabilities to finish. If time is required, users should be offered at least one of the following options.

  • Turn off the time limit
  • Adjust the time limit to extend up to 10 times the default time limit
  • You will have 20 seconds to extend the time restriction before timing out, and you can do so up to 10 times.

Review Data before Submitting

Users should, in general, be given as many opportunities as possible to avoid or correct errors in their form inputs.

Users must exercise extra caution when submitting information that could result in a legal obligation, complete a transaction, or have other significant repercussions in the event of an error.

  • The form submission must be reversible
  • The form submission must be checked for errors and the user must be given an opportunity to resolve the errors
  • The user must be provided a process for reviewing, confirming, and correcting the information prior to submission.

WCAG 2.1

  • WCAG 2.2.1: Timing Adjustable .
  • WCAG 3.3.4: Error Prevention

How Enabled.in helps online Booking Websites

Enabled.in Accessibility services handles all kinds of compliance issues for you. From back-end to front-end, ensuring full ADA and WCAG compliance is our standard.

With Enabled.in accessibility testing framework, website owners can effortlessly reach compliance with WCAG 2.1, ADA, ATAG 2.0, EN 301-549 and Section 508 regulations, as required by any governmental and regulatory bodies.

We are committed to involving people with disabilities in the accessibility testing process. As a result, we can offer future-proof digital online booking accessibility solutions.

Contat info@enabled.in

Free Accessibility Testing

Related

elearning accessibility checklist 508 WCAG

e-Learning Accessibility Checklist

e-Learning

This Accessibility e-Learining checklist is a practical resource guide for experienced accessibility professionals and for those newer to the industry.

e-learning accessibility casestudies ADA 508 WCAG

e-Learning Accessibility Case Study

e-Learning

Our combined expertise has enabled the creation of accessible e-Learning which ensures equity of learning experience for Student with Disabilities.