5 Commandments sử dụng thường xuyên trong xây dựng form

We’ve already discussed why accessibility matters and whetted your appetite on accessibility by providing a few simple things you can do to make your site more accessible.  Now it’s time to look at accessibility in forms, a common component of just about every site. Inaccessible forms can affect a wide array of disabilities - screen reader users, keyboard-only users, cognitive disabilities, and mobility impaired - and create unnecessary barriers for what could be loyal website visitors and customers.  Here are 5 items to get you started:

1. Thou shalt use the <label> tag.

The label tag associates a single label tag to a single form element (text fields, radio buttons, checklists, etc.) and gets read by the screen reader when focus is placed on the form element so that a user knows what type of input is expected.  The “for” attribute is used to associate the label with the form element by matching the value of the “for” attribute to the value of the elements “id” attribute.  This association should be unique - one label per form element.  Using the id attribute fosters this since id’s should be unique on a page as well.  This also has the side effect of being able to select an option or put focus on an element by clicking on the label, which is great for someone who has difficulty being accurate with a mouse.  And remember, the placeholder attribute should not be used as a replacement for a label.

Example:

<label for=”myinput”>Label text</label>
<input id=”myinput” name=”textfield” type=”text”>

2. Thou shalt use fieldsets and legends for grouping.

Use fieldset and legend tags for grouping related input elements, particularly with sets of radio buttons and checkboxes.  Use the legend tag with fieldsets to associate a description with the group of elements.  The text of the legend element will be read by the screenreader when a person tabs to an input element in the group, whereas text placed outside of legend text would be completely skipped by screen readers when tabbing from form element to form element.

Example:

<fieldset>
    <legend>Choose your favorite sport:</legend>
    <input id="soccer" type="checkbox" name="sports" value="soccer">
    <label for="soccer">Soccer</label><br>
    <input id="basketball" type="checkbox" name="sports" value="basketball">
    <label for="basketball">Basketball</label><br>
    <input id="quidditch" type="checkbox" name="sports" value="quidditch">
    <label for="quidditch">Quidditch</label><br>
</fieldset>

3. Thou shalt clearly indicate required fields as part of the label text.  

Optimally, required fields would have “(required)” in the label text of each required field as not all screen readers read an asterisk by default.  Alternatively, if most fields are required, instead of polluting every label with “(required)”, non-required fields could have “(optional)” as part of the label. Either way, required fields should be clearly indicated.

Example:

<label for=”myinput”>Label text (required)</label>
<input id=”myinput” name=”textfield” type=”text”>

4. Thou shalt keep all form elements accessible by a keyboard and in logical tab order.  

Not everyone uses a mouse.  Some users navigate a form by tabbing from element to element. By default, form elements can receive focus by the keyboard but it is possible to break this behavior with javascript.  Be sure it stays intact.  In addition, the tab order of the form elements should be logical.  Bouncing from First Name to Address to Last Name is likely to cause a non-sighted user to question whether they’re missing something.  Generally, staying away from tables for form layout and allowing forms to keep their linear display is all that’s required since tab order is set according to the order of the form elements in the source code.  But there are times when tables are needed for forms and tab order needs to be addressed with the tabindex attribute. However, use the tabindex attribute with caution.    

5. Thou shalt clearly provide feedback to the user.

Whether it’s a validation error or successful form submission, users should be clearly notified.  Validation errors should include what field was rejected and why.  W3C provides an excellent overview of common approaches for placement of these success and error notifications.

For basic forms, following these commandments will create a form usable by a wider audience.  However, forms can get vastly more complicated.  Sometimes there IS a need to associate one label with multiple form elements.  Sometimes a label needs to be hidden.  Sometimes we need to use custom controls like star ratings and share buttons.  A couple great resources for more in-depth form accessibility are:

• W3C’s Form Concepts Tutorial
• Webaim’s Creating Accessible Forms

Go forth and accessify!