kelliedesigner
commented
6 years ago Key findings from gov.uk on form elements:
Keep forms as simple as possible - only ask what’s needed to run your service.
Optional/mandatory fields
- only ask for the information you absolutely need
- if you do ask for optional information, mark the labels of optional fields with ‘(optional)’
- don’t mark mandatory fields with asterisks
Label vs input relationship
- all form fields should be given labels
- don’t hide labels, unless the surrounding context makes them unnecessary
- labels should be aligned above their fields
- label text should be short, direct and in sentence case
- avoid colons at the end of labels
- labels should be associated with form fields using the for attribute
Size of input
- Make field widths proportional to the input they take.
- Ensure that users can enter the information they need at smaller screen sizes.
- Snap form fields to 100% width at smaller screen sizes.
Hint text
- don’t use placeholder text in form fields, as this will disappear once content is entered into the form field
- use hint text for supporting contextual help, this will always be shown
- hint text should sit above a form field
- ensure hint text can be read correctly by screen readers
Textarea
- Make the height of a textarea proportional to the amount of text to be entered.
Key findings from gov.uk on error messaging
Ask one question per page
- Recovering from errors can be hard for users, especially if a page contains multiple errors.
- Simplify forms by rewriting and where possible, splitting long forms across multiple pages - with each page asking a single question.
Summarise errors at the top of the page You must:
- show an error summary at the top of the page. The error summary must appear at the top of the page, so it is visible when the page is refreshed and is immediately read out by assistive technology.
- include a heading to alert the user to the error
- link to each of the problematic questions
Additionally, you should reflect that there's been an error in the
by prefixing the existing title with "Error: ". That will make sure screen readers are alerted to there being an error as soon as possible.</p> <p>Highlight errors in forms</p> <p>For each error:</p> <ul> <li>write a message that helps the user to understand why the error occurred and what to do about it</li> <li>put the message in the <label> or <legend> for the question, after the question text, in red</li> <li>use a red border to visually connect the message and the question it belongs to</li> <li>if the error relates to specific text fields within the question, give these a red border as well</li> </ul> </blockquote> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/jeddy3"><img src="https://avatars.githubusercontent.com/u/808227?v=4" />jeddy3</a> commented <strong> 6 years ago</strong> </div> <div class="markdown-body"> <p><a href="https://www.nngroup.com/articles/web-form-design/">NN Group findings</a>:</p> <blockquote> <ul> <li>Keep it short - eliminate unnecessary fields</li> <li>Visually group related labels and fields</li> <li>Present fields in a single column layout. </li> <li>Use logical sequencing.</li> <li><a href="https://www.nngroup.com/articles/form-design-placeholders/">Avoid placeholder text</a>.</li> <li>Match fields to the type and size of the input. </li> <li>Distinguish optional and required fields</li> <li>Explain any input or formatting requirements.</li> <li>Avoid Reset and Clear buttons. </li> <li>Provide highly visible and specific error messages.</li> </ul> </blockquote> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/jeddy3"><img src="https://avatars.githubusercontent.com/u/808227?v=4" />jeddy3</a> commented <strong> 6 years ago</strong> </div> <div class="markdown-body"> <p>On naming... the <a href="https://www.w3.org/WAI/tutorials/forms/grouping/">W3C Web Accessibility uses the term "control"</a> to group labels, inputs and associated meta:</p> <blockquote> <p>Grouping related form controls makes forms more understandable for all users, as related controls are easier to identify. It also makes it easier for people to focus on smaller and more manageable groups rather than try to grasp the entire form at once.</p> <p>Grouping needs to be carried out visually and in the code, for example, by using the <code><fieldset></code> and <code><legend></code> elements to associate related form controls. </p> </blockquote> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/kelliedesigner"><img src="https://avatars.githubusercontent.com/u/6122118?v=4" />kelliedesigner</a> commented <strong> 6 years ago</strong> </div> <div class="markdown-body"> <p>Key findings from <a href="http://coop-design-manual.herokuapp.com/styles/forms/index.html">Co-op Design System</a></p> <blockquote> <ul> <li> <p>know why you’re asking each question and what it’s needed for</p> </li> <li> <p>tell users why we’re asking</p> </li> <li> <p>explain it in plain English</p> </li> <li> <p>allow users to click on the question or label to let them start answering (doing this takes the cursor to the text entry field)</p> </li> <li> <p>do not use placeholder text (text that sits within the text entry field) — if a question needs extra clarification, use hint text instead (static text that sits outside of the text entry field)</p> </li> <li> <p>make the length of the text input box appropriate for the amount of information needed: do not make it frustratingly short or intimidatingly long.</p> </li> <li> <p>The format of people’s names can vary. Some do not fit into conventional UK formats. It can be unnecessary and uncomfortable for users to define themselves using a title, or a separate first name — surname format</p> </li> <li> <p>Never gather a title to assume gender</p> </li> <li> <p>[Progress trackers can] get in the way and confuse users.</p> </li> <li> <p>Only use a progress tracker if you have thorough research to support the decision. </p> </li> </ul> </blockquote> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/kelliedesigner"><img src="https://avatars.githubusercontent.com/u/6122118?v=4" />kelliedesigner</a> commented <strong> 6 years ago</strong> </div> <div class="markdown-body"> <p><strong>Key findings relating to marking fields as optional as opposed to mandatory</strong></p> <p><a href="http://uxmovement.com/forms/why-users-fill-out-less-if-you-mark-required-fields/">UX Movement </a> Why Users Fill Out Less If You Mark Required Fields</p> <blockquote> <ul> <li>Marking optional fields won't inhibit user's voluntary over-disclosure</li> </ul> </blockquote> <p><a href="https://blog.optimalworkshop.com/designing-form-fields-optional-versus-required">Optimal Workshop</a> Designing form fields: Optional versus required</p> <blockquote> <ul> <li>Including the phrase ‘optional’ after a label is much clearer than any visual symbol you could use to mean the same thing. </li> <li>Using language like “Optional” is letting users know they have a choice, which is inline with the Norman Nielsen Group usability principle of user control and freedom.</li> <li>The asterisk is a design element that is cluttering up a form. It’s taking away from the goal of filling out the form. Chances are the majority of your form fields will be required so only needing to mark the optional ones takes up less real estate.</li> <li>It’s expected that fields are required.</li> <li>Only ask what is necessary</li> </ul> </blockquote> <p><a href="https://www.fusionbox.com/blog/detail/rethinking-the-red-required-asterisk-for-better-form-ux/599/">Fusion Box </a> Rethinking The Red "Required" Asterisk For Better Form UX</p> <blockquote> <ul> <li>While the asterisk symbol is a long-held convention, it remains a potentially ambiguous icon without a clear semantic meaning.</li> <li>This clutter also affects visually impaired users and those relying on assistive technologies such as screen readers. Depending on the software package and user settings asterisks are either ignored or read out loud as "star". Appropriate ARIA properties will ensure that required fields are clearly delineated, but adding these labels will not guarantee that the asterisk will be skipped over.</li> <li>When approaching forms in which a majority of the fields are mandatory it is often best to mark only the optional fields and allow users to infer that unmarked fields are required.</li> </ul> </blockquote> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/kelliedesigner"><img src="https://avatars.githubusercontent.com/u/6122118?v=4" />kelliedesigner</a> commented <strong> 5 years ago</strong> </div> <div class="markdown-body"> <p><a href="https://uxdesign.cc/design-better-forms-96fadca0f49c"><strong>Design Better Forms</strong></a> Common mistakes designers make and how to fix them</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/kelliedesigner"><img src="https://avatars.githubusercontent.com/u/6122118?v=4" />kelliedesigner</a> commented <strong> 5 years ago</strong> </div> <div class="markdown-body"> <p><a href="https://www.nngroup.com/articles/form-design-placeholders/">Placeholders in Form Fields Are Harmful </a></p> </div> </div> <div class="page-bar-simple"> </div> <div class="footer"> <ul class="body"> <li>© <script> document.write(new Date().getFullYear()) </script> Githubissues.</li> <li>Githubissues is a development platform for aggregating issues.</li> </ul> </div> <script src="https://cdn.jsdelivr.net/npm/jquery@3.5.1/dist/jquery.min.js"></script> <script src="/githubissues/assets/js.js"></script> <script src="/githubissues/assets/markdown.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/highlight.min.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/languages/go.min.js"></script> <script> hljs.highlightAll(); </script> </body> </html>
As a user of the design system I want to know how to add a single text input component to my project So that there is a consistent experience across services
Description
Submitting data is a fundamental aspect of interfaces. The most common form of data is freeform text. There are a number of problems surrounding input:
Links and resources
Website:
Content form:
Acceptance Criteria
Document solutions to following concerns:
Then: