Site icon IT & Life Hacks Blog｜Ideas for learning and practicing

Why Forms Become Difficult to Use｜Input Assistance and Error Design Basics in WCAG 2.2

greeden
monitor displaying error text

Photo by Pixabay on Pexels.com

Why Forms Become Difficult to Use｜Input Assistance and Error Design Basics in WCAG 2.2

When people talk about web accessibility, attention often goes to alternative text for images or color contrast. However, in practical work, the area where differences often become especially significant is actually forms. Contact forms, document requests, member registration, job applications, seminar sign-ups, payments, and various applications—on websites, forms are important entry points where users move from simply viewing information to taking action. Yet in reality, forms are also places where users often abandon the process because they are “hard to fill in,” “errors are difficult to understand,” or “it is unclear what needs to be fixed.” In this third article, we will organize why forms become difficult to use and, in line with WCAG 2.2, examine the basics of input assistance and error design from a practical perspective.

What You Will Learn in This Article

  • Why users often abandon or get confused by forms
  • Key WCAG 2.2 success criteria related to forms
  • How to think about labels, instructions, required-field indicators, and error messages
  • Common “almost good” design issues in practice and how to improve them
  • The role-sharing between UUU Web Accessibility Service and form improvement

Forms do not become difficult to use simply because they have many input fields. Users often get stuck because of problems in how information is presented and how actions are guided, such as “it is unclear what to enter,” “they cannot notice input mistakes,” “they do not know how to fix them,” or “redoing the process is burdensome.” For example, labels may be vague and make it hard to judge what to enter; required fields may be indicated only by color; input examples may rely only on placeholders and disappear as soon as typing begins; errors may be listed only at the top of the screen, making it hard to match them with the relevant fields; or entered content may disappear when returning from a confirmation screen. Designs like these burden many users, not only people with disabilities. In other words, improving forms is both an accessibility measure and a UI improvement that contributes to results.

In WCAG 2.2, input assistance is very important for forms. The criteria to pay particular attention to are 3.3.1 “Error Identification,” 3.3.2 “Labels or Instructions,” 3.3.3 “Error Suggestion,” 3.3.4 “Error Prevention (Legal, Financial, Data),” 3.3.7 “Redundant Entry,” and 3.3.8 “Accessible Authentication (Minimum).” These require helping users enter information correctly, making it clear what happened and how to fix it when an error occurs, avoiding repeated entry of the same information, and not placing excessive burdens on users during authentication. They may look a little difficult at first, but in essence they all come down to the idea of “creating forms that do not impose unnecessary confusion or burden on users.”

The first thing to review is how labels are written. A form label is not sufficient just because an item name is visually placed nearby. It must clearly communicate to everyone what the input field is for. For example, “Name” can be ambiguous: does it mean full name, surname only, or is a nickname acceptable? “Company name” may also cause hesitation depending on whether it means only the legal entity name or includes the department name. For “Phone number,” if users do not know whether hyphens are allowed or whether landline and mobile numbers are both acceptable, they may stop and think. W3C’s forms tutorial also states that labels should describe the purpose of form controls and be properly associated with them. It is important not to rely only on visual proximity, but to correctly associate labels and input fields in HTML as well.

A very common practical issue is using placeholders as substitutes for labels. For example, an input field may show “Email address” in faint text inside the field, with no separate label. This may look clean, but once the user starts typing, the text disappears, making it harder to know what field they were filling in. Placeholders often have low contrast and can be difficult to read, and they also require care in relation to assistive technologies. Placeholders are useful when used as supplementary examples, but they do not replace labels themselves. The desire to keep forms visually simple is understandable, but reducing information too much ultimately makes forms harder to complete.

Next, the way instructions are presented is important. WCAG 2.2’s “Labels or Instructions” requires that, when input is needed, users can understand what and how to enter. The important point here is not to add excessive explanations, but to provide necessary information in the necessary place. For example, for a password field, show the requirement in advance, such as “at least 8 half-width alphanumeric characters.” For a phone number field, explain the format beforehand, such as “enter without hyphens.” If there is a function that automatically fills in the address from the postal code, explain how to use it nearby. Sometimes it is too late to provide instructions only after an error occurs. Showing points that users are likely to wonder about before they enter information helps reduce errors.

How required fields are communicated is also very important. A common pattern in many forms is to indicate required fields only in red. However, information may not be sufficiently conveyed through color differences alone. In WCAG, not relying on color alone to communicate information or instructions is a basic principle. Therefore, it is necessary to clearly write “Required” as text, provide a legend, and implement the indication so it is conveyed to screen readers as well. In addition, when required and optional fields are mixed, it is important to use rules that users can understand at a glance. For example, you might add “Required” and “Optional” to every field, or omit optional labels and mark only required fields. Unifying the notation policy across the site reduces confusion.

The difficulty of forms becomes most visible when errors occur. W3C’s explanations state that simply redisplaying the form after submission fails is not enough; users need to be able to recognize where the problem is and what was wrong. This is completely true in practice. A common poor example is showing only “Please check your input.” With this message alone, users cannot tell which field is wrong, whether something is missing, or whether the format is incorrect. A good error message has at least three elements. First, users can identify the field where the error occurred. Second, the problem is specific. Third, it explains how to fix the issue.

For example, “Please enter your phone number” clearly indicates that the field is empty, while “The email address format is incorrect. Example: sample@example.jp” also explains how to correct it. By contrast, abstract phrases such as “Invalid value” or “Input error” force users to keep guessing. W3C’s guidance on form notifications also recommends that error summaries refer to the corresponding labels, provide concise and easy-to-understand explanations, explain how to fix the problem, and make it easy to move to the relevant field. In other words, error messages should not be designed as “scolding messages,” but as “guidance that helps users resume.”

A common practical question is “how much real-time validation should be added?” Showing errors immediately during input may look convenient, but if the timing is wrong, red warning text may continue appearing even while the user is still typing, which can make them anxious. Especially for fields such as email addresses and phone numbers, where the format is only complete after all characters are entered, warning users after every keystroke is not always helpful. Therefore, it is necessary to design validation according to the nature of each field: judge after input is complete, notify when focus leaves the field, or show errors clearly upon submission. What matters is not showing errors as early as possible, but helping users correct them without interrupting their thinking.

Confirmation screens and re-entry handling are also deeply related to form accessibility. WCAG 2.2 added 3.3.7 “Redundant Entry,” which requires that information already entered within the same process should generally not need to be entered again. For example, making users re-enter all their address or name information at the confirmation stage or in another step of an application form places a large burden on them. It also increases input errors and cognitive load. In practice, it is important to review whether entered content is carried over, whether autocomplete is available, whether users can easily return from the confirmation screen, and whether corrections are easy. The purpose of a form is not to “make users enter information carefully,” but to “enable users to correctly complete the necessary information.”

For forms involving authentication, the perspective of 3.3.8 “Accessible Authentication (Minimum)” is also essential. In login or member registration contexts, designs that demand excessive memory or cognitive effort from users become major barriers. Examples include prohibiting copy and paste, interfering with password managers, making difficult image-based authentication mandatory, or relying on complex puzzle-style CAPTCHA. Security is, of course, important, but unusable authentication ends up excluding many users. Reviewing authentication methods and how assistive functions are handled, while balancing safety and usability, is increasingly important in form design.

To make this easier for practitioners to understand, let us organize common examples of “almost good” forms. First, forms that look polished but have vague labels. Second, forms with insufficient explanations for required fields or format conditions. Third, forms with abstract error messages that make it difficult to identify what needs fixing. Fourth, forms where entered content disappears after a submission error. Fifth, forms that are difficult to tap on smartphones, with checkboxes or small buttons that are hard to operate. Sixth, forms that make users enter the same information repeatedly across confirmation screens or multiple steps. All of these are problems that can easily occur even without advanced systems, and many can be improved by slightly reviewing the design.

For example, in a document request form, the form before improvement might simply list “Name,” “Email,” “Company,” and “Inquiry details,” use only red marks for required fields, provide no format explanation for the email field, and show only “There is an error” after submission. After improvement, the roles become clear, such as “Full name (Required),” “Email address (Required),” and “Company name (Optional).” The email address field includes an input example. If it is empty, the message says “Please enter your email address.” If the format is wrong, it says “The email address format is incorrect. Example: sample@example.jp.” The error summary allows users to move to the relevant field. Entered content is preserved even when returning from the confirmation screen, and buttons and options are large enough to use easily on smartphones. Each individual difference may look small, but together they have a major impact on completion rates and user confidence.

So how should we think about compatibility with UUU Web Accessibility Service? Services like UUU, which provide reading support functions such as text resizing, contrast adjustment, line spacing and letter spacing adjustment, read-aloud, translation, and furigana display, are valuable for supporting the understandability and visibility of areas around forms. For example, they can make explanatory text and notes easier to read, improve visibility, and make it easier for users to choose a viewing environment that suits them.

On the other hand, the accessibility of the form itself cannot be fully ensured through viewing support alone. Elements such as proper association of labels, specificity of error wording, methods for indicating required fields, error notifications after submission, reduction of re-entry, and authentication design require reviewing the original HTML, system, and UI design. In other words, services like UUU are highly compatible as “support for making content easier to see and use,” but the quality of the form design itself must still be carefully prepared by the creators. Understanding this role-sharing makes it easier to have appropriate expectations for tool adoption while also focusing on essential improvements.

Form improvement is not only the job of specialists. Public relations staff can make guidance and explanatory text easier to understand. Web managers can unify rules for required fields and error wording. Directors can include perspectives such as “Is entered content preserved?”, “Are errors specific?”, and “Is it easy to tap on smartphones?” during requirements definition. Engineers can support implementation aspects such as label association, notification methods, focus movement, and authentication handling. In other words, form accessibility is not something that one specialist checks at the end. It is a theme connected to planning, wording, UI design, implementation, and operation.

Here is the summary of the third article. The causes of difficult-to-use forms are not only the number of fields, but also a lack of small considerations: vague labels, insufficient instructions, unhelpful required-field indicators, weak error design, too much re-entry, and burdens during authentication. WCAG 2.2 provides ways of thinking that help users through labels and instructions, error identification, error suggestions, reduced re-entry, and easier authentication. Because forms are important contact points directly connected to a site’s results, it is essential to design them not only for appearance, but also for ease of completion. Next time, we will look specifically at keyboard operation and focus indicators, and how to reduce usability issues that are not immediately visible.

Reference Links

Exit mobile version