Create usable forms and registration

Design the content and instructions

Start by listing the minimum information needed to register or complete the request. Use a visible label for every field and put the label above or beside its control. A placeholder is a hint, not a replacement for a label. Explain required fields, accepted formats, dates, character limits, and what happens after submission before the person starts. Group related choices with a clear question and keep the order predictable.

Keep registration steps short where possible. If a long process must be split into pages, name each step and show progress without making people guess what will happen next.

Tell people what information is optional and whether they can save and return later. Avoid asking them to repeat information that was already entered. If an upload is required, state the accepted file types and a size limit in advance, and provide a text alternative to any instruction shown in a sample image.

For recognized personal-data fields such as name, email, phone, or address, give the developer the field purpose so the rendered control can expose an appropriate autocomplete token. Within the same multi-step process, reuse information or let people select it instead of asking them to retype it, unless re-entry is essential, needed for security, or the information is no longer valid. For authentication, request that password managers and paste remain allowed. If spam protection uses CAPTCHA, ask the developer to review its alternative and test the complete path.

Plan validation and confirmation

Write error messages that identify the field and the correction, such as “Enter a date in MM/DD/YYYY format.” Keep the person’s valid entries when validation fails. Provide a summary for multiple errors and place it where keyboard and screen reader users can find it. After success, confirm what was submitted and what happens next. A change in the page, an error summary, or a success message must be announced or brought into the user’s path by the implemented form behavior.

If the site uses Gravity Forms, its official accessibility guidance recommends visible labels, meaningful custom validation messages, and the built-in error-summary approach. Review the form’s current settings and version rather than assuming a default makes the entire flow accessible. Never hide required information in color alone.

Hand off interaction and data behavior

Ask the developer to test the complete flow with keyboard only, zoom, and a screen reader. Verify label-to-control associations, focus order, visible focus, grouped choices, date pickers, upload controls, error focus, status announcements, and the success path. Controls should be comfortably sized. WCAG 2.2’s 2.5.8 minimum is 24 by 24 CSS pixels with exceptions for spacing, equivalent controls, inline targets, unchanged user-agent controls, and cases where a particular presentation makes that target size essential, such as a dense map or data visualization, or where a legal requirement constrains it. Aim for 44 by 44 CSS pixels for primary controls where practical.

Avoid time limits in registration when possible. If one applies, implement the WCAG adjustment or extension options, or document a valid criterion exception and how users can complete the task. Ask the process owner to review confirmation, retention, and privacy wording. Accessibility review does not approve collection of data or create a policy.