UI Development

Accessible Form

This blog is to  understand the step by step procedure to develop an accessible form. There are two ways to develop form

1) Using native HTML form elements and

2) Custom controls

Native Elements:

For the native elements when the user navigates through assistive technology it accurately announces the type and state of the form elements.
Ex: A radio button gets announced radio button not checked and check box gets announced checkbox not checked. In case of custom control it will neither announce the type nor the state unless the author makes the required coding.

When a native form button is developed provide a value attribute that describes the action associated within it.

For the user to identify the action associated with it or to enter some information,  accessible label is required. The label should be provided for form element using the label tag. Except for  button all other form elements support label tag.

Custom Elements:

Custom controls uses aria-labelledby WCAG 2.0 Check-point. Will use role, aria-label for custom controls

When a visible label cannot be provided for a form element a “title” attribute or aria-label can serve the purpose of label.

Providing additional instructions for form elements

Keyboard accessibility for form elements

All the form elements should be navigable and actionable using a keyboard. If a login button can only be activated by a mouse, screen reader and keyboard only users never can log into the portal.

Keyboard focus visibility

Check that the keyboard indicator is visible on the form fields when they are focused. This will enable the low vision users to keep track of the elements they are navigating.
Don’t remove the default outline css property for input and anchor elements

Grouping of form elements with field set or aria role= “group” for check box and “radiogroup” for radio buttons

Checkbox grouping

Error identification

The first change that happens when the form is submitted is the validation. Once the validation
is done user should be intimated with a success or failure message. This message in most cases will not be exposed to assistive technologies like screen readers. This behavior will be frustrating in case of form submission failure scenarios. The user focus remains on the submit button, a message will be displayed somewhere else on the screen.
Screen readers users will not understand if the form is submitted or not. In some cases the message will be displayed for a few seconds and disappears.

Error Suggestion

Once the user is aware that the form submission is unsuccessful with appropriate error message, it is important to intimate which all fields caused the problem.
The errors could be because of the following reasons in general.
1) Information that is required are omitted by the user
2) Information that is provided by the user but fails in format

There are many ways of displaying the errors.
1. On form submission all the error messages are displayed in a list on top of the form providing each error message as a link, allowing the user to jump directly to the error field from error message.

2.  For screen reader users who navigate with tab key of keyboard the error message should be read along with the field,
so bind the field with the error message using aria-describedby(passes the id of error message). On clicking submit button the focus should jump  to the first field in the list of elements having error messages for screen reader user.

In addition to the error messages, aria-invalid(state) is used for intimating the user that the input provided falls outside the accepted values. aria-required helps to prevent the users from ignoring the mandatory fields.

For an e-mail id field, a generic error message can be “Incorrect format”. A better suggestion could be “Provide the email in a correct format Ex:smith@yahoo.com”. Date of journey could not be before the current date”, “Enter the date of journey in mm/dd/yyyy format” etc.

 

About The Author

Leave a Reply

*