惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

大猫的无限游戏
大猫的无限游戏
K
Kaspersky official blog
Apple Machine Learning Research
Apple Machine Learning Research
B
Blog
aimingoo的专栏
aimingoo的专栏
M
MIT News - Artificial intelligence
小众软件
小众软件
云风的 BLOG
云风的 BLOG
腾讯CDC
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
Hugging Face - Blog
Hugging Face - Blog
S
SegmentFault 最新的问题
Stack Overflow Blog
Stack Overflow Blog
量子位
S
Secure Thoughts
G
GRAHAM CLULEY
C
CXSECURITY Database RSS Feed - CXSecurity.com
人人都是产品经理
人人都是产品经理
雷峰网
雷峰网
T
Threat Research - Cisco Blogs
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
Cisco Talos Blog
Cisco Talos Blog
G
Google Developers Blog
爱范儿
爱范儿
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
有赞技术团队
有赞技术团队
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Martin Fowler
Martin Fowler
The GitHub Blog
The GitHub Blog
Google DeepMind News
Google DeepMind News
C
Cisco Blogs
D
Darknet – Hacking Tools, Hacker News & Cyber Security
博客园 - 聂微东
宝玉的分享
宝玉的分享
H
Hackread – Cybersecurity News, Data Breaches, AI and More
N
Netflix TechBlog - Medium
Forbes - Security
Forbes - Security
Engineering at Meta
Engineering at Meta
S
Security Affairs
Help Net Security
Help Net Security
博客园 - 三生石上(FineUI控件)
AWS News Blog
AWS News Blog
博客园 - 叶小钗
Recent Commits to openclaw:main
Recent Commits to openclaw:main
V2EX - 技术
V2EX - 技术
Hacker News: Ask HN
Hacker News: Ask HN
Project Zero
Project Zero
H
Heimdal Security Blog
W
WeLiveSecurity
C
Check Point Blog

TetraLogical Blog

Designing for people with reading disabilities - TetraLogical Designing for people who are D/deaf - TetraLogical Designing accessible documents - TetraLogical Introduction to creating accessible documents - TetraLogical Inclusive user research: vulnerable people - TetraLogical Designing for people who are blind - TetraLogical Designing for people with low vision - TetraLogical Meet the team: Niamh Madden - TetraLogical Designing for people with anxiety - TetraLogical Designing for people with disabilities - TetraLogical Accessible building blocks for the web videos - TetraLogical Common accessibility misconceptions - TetraLogical Common misconceptions about testing accessibility - TetraLogical Common misconceptions about implementing accessibility - TetraLogical Common misconceptions about WCAG - TetraLogical Common misconceptions about disability - TetraLogical Meet the team: Grace Snow - TetraLogical Sustainable accessibility in complex organisations: strategic foundations - TetraLogical Sustainable accessibility in complex organisations: organisational realities - TetraLogical Sustainable accessibility in complex organisations: external factors - TetraLogical Common misconceptions about screen readers - TetraLogical Guide to the Inclusive Design Principles - TetraLogical Meet the team: Ian Lloyd - TetraLogical Annotating designs using common language - TetraLogical Meet the team: Catriona Morrison - TetraLogical Championing inclusive language - TetraLogical Press release: TetraLogical launches accessible self-led training courses to help digital teams build confidence in accessibility - TetraLogical Why inclusive products are green products - TetraLogical Accessible Recruitment - TetraLogical Accessibility and the agentic web - TetraLogical Meet the team: Craig Abbott - TetraLogical Foundations: types of assistive technology and adaptive strategies - TetraLogical European Accessibility Act (EAA) FAQ - TetraLogical Screen reader HTML support tables - TetraLogical Interview with Lola Odelola - TetraLogical Understanding EN 17161 Design for All - TetraLogical Inclusive user research: building rapport - TetraLogical Foundations: Keyboard accessibility - TetraLogical Can generative AI write contextual text descriptions? - TetraLogical Understanding the European Accessibility Act (EAA) - TetraLogical Meet Josh: a sportsman who has spinal muscular atrophy - TetraLogical Meet Jonathan: a photographer who has ADHD - TetraLogical Foundations: grouping forms with `<fieldset>` and `<legend>` - TetraLogical XR Accessibility: for people with moving disabilities - TetraLogical Meet Andre: a music producer and blind screen reader user - TetraLogical Foundations: types of disability - TetraLogical Meet Lauren: a film editor who has ADHD - TetraLogical Meet Steve: a photographer who is deaf and low vision - TetraLogical Foundations: form validation and error messages - TetraLogical Meet Hasmukh: a blind cricketer and screen reader user - TetraLogical XR Accessibility: for people with hearing disabilities - TetraLogical XR Accessibility: for people with thinking disabilities - TetraLogical XR Accessibility: for people with seeing disabilities - TetraLogical Introduction to XR Accessibility - TetraLogical Design patterns and WCAG - TetraLogical Does WCAG 2.2 apply to native apps - TetraLogical Why are my live regions not working? - TetraLogical Building a culture of accessibility - TetraLogical When to use tabindex= Accessibility foundations - TetraLogical Meet the team: Demelza Feltham - TetraLogical Can generative AI help write accessible code? - TetraLogical Meet the team: Steve Faulkner - TetraLogical Meet the team: Gez Lemon - TetraLogical Keyboard accessibility myths and WCAG - TetraLogical Amendment to the Public Sector Accessibility Regulations - TetraLogical What Considerations for TV user interface accessibility - TetraLogical Meet the team: Alistair Duggin - TetraLogical Sticky content: focus in view - TetraLogical The only accessibility specialist in the room - TetraLogical Meet the team: Ian Pouncey - TetraLogical Meet the team: Dean Holden - TetraLogical Meeting WCAG Level AAA - TetraLogical Foundations: accessible names and descriptions - TetraLogical Inclusive XR: accessible augmented reality experiences - TetraLogical Foundations: pointer gestures - TetraLogical Meet the team: Graeme Coleman - TetraLogical Adding sign language to videos - TetraLogical Foundations: introduction to WAI-ARIA - TetraLogical Meet the team: Joe Lamyman - TetraLogical Inclusive XR: accessible 3D experiences - TetraLogical Foundations: visible focus styles - TetraLogical Foundations: target sizes - TetraLogical Meet the team: Henny Swan - TetraLogical Meet the team: Ela Gorla - TetraLogical Foundations: native versus custom components - TetraLogical Foundations: HTML semantics - TetraLogical Accessibility and supporting Internet Explorer - TetraLogical Meet the team: Felicity Miners-Jones - TetraLogical Accessibility and QR codes - TetraLogical Inclusive user research: recruiting participants - TetraLogical Research insight: accessibility of images - TetraLogical Meet the team: Léonie Watson - TetraLogical Android accessibility: roles and TalkBack - TetraLogical Accessible design systems - TetraLogical Meet the team: Patrick H. Lauke - TetraLogical Inclusive user research: analysing findings - TetraLogical How to write user stories for accessibility - TetraLogical Triaging WCAG 2.1 Level AAA - TetraLogical
Foundations: labelling text fields with input and label - TetraLogical
2024-08-21 · via TetraLogical Blog

Posted on by Demelza Feltham in Design and development

Tags: Assistive Technology, Foundations, Code, WCAG

In this post about forms, we explore how to effectively label text fields using <input> and <label> elements to create form inputs that are both accessible and user-friendly.

Forms play a key role in making the web interactive. They enable people to enter and submit data for various purposes such as logging into accounts, making purchases, filling out surveys and so on. There are many ways to make forms more accessible, including grouping forms with the <fieldset> and <legend> elements, implementing form validation and error messages effectively, as well as ensuring that every form field has a clear and accessible label.

This benefits everyone, but in particular:

  • People browsing with screen a reader and braille displays who cannot see content and rely on the properly coded form labels to understand the input requirements
  • People browsing with screen magnification or browser zoom who rely on visible labels adjacent to fields to understand the input requirements
  • People browsing with speech recognition who rely on visible labels in order to interact with form inputs
  • People with cognitive disabilities who rely on clearly visible labels, so they understand input requirements
  • People with reduced focus or short attention spans who rely on persistent labels, and not placeholder text, so they understand input requirements

Form inputs with inaccessible labels result in increased errors and barriers to completing tasks. This wastes time and may discourage people from returning to the form all together. One way to prevent this issue is by providing form labels using the <input> and <label> elements.

A black and white photo of Hasmukh, an older man of South Asian heritage. He is wearing his cricket whites smiling as he stands ready to bat.
Hasmukh, a blind cricketer and screen reader user, sometimes can't use forms because there are no labels on form inputs. He has to ask for help which is frustrating.

The <input> element

The <input> element defines where people can input data and what type of data they should enter. It serves as a visual cue by clearly indicating the expected data and programmatic cue for assistive technology users.

A collection of different input types, including password, date of birth date picker and a select element for country selection.
Form fields with text labels of "Password", "Date of Birth", and "Country".

The type attribute in HTML is used to specify the type of form input being used within an <input>. These are defined in the markup using the type attribute on each <input> element.

Common input types include:

  • password
  • date
  • checkbox
  • radio buttons

It is important to decide what type of data the form input is collecting, as this will inform the value of the type attribute for each input. For example, a login would need a field for the email, and a field for the password. The advantage of including the type attribute, is that when the form is submitted, it automatically validates the format, email or password.

<input type="email">
<input type="password">

Below is a list of some additional attributes that can be used:

  • required communicates that the field must be populated prior to form submission
  • maxlength determines the maximum number of characters that can populate the field
  • minlength determines the minimum number of characters that can populate the field
  • placeholder determines the contents of the field prior to it being populated. It will act as hint text

The <label> element

The <input> element describes the required data visually and programmatically, helping people to understand what is needed. A clear and descriptive <label> makes form inputs clear, especially when multiple form inputs of the same type are present in the same form.

For example, when purchasing a gift card for someone, one email field will collect the email address of whoever is purchasing the gift card.

Email input field labelled with your email.
A text field labelled as Your email

And one email field will collect the recipient's email address.

Recipients email input field.
A text field labelled as Recipients email

Clear labelling is crucial here to explain the different purposes of the field, as the <input> type does not change.

A note on placeholder text

Although this article does not aim to be exhaustive, it’s important to note that using placeholder text as a substitute for a label is inadequate from both usability and accessibility standpoints.

Placeholder text disappears when people begin entering information or change the field selection. This can create challenges for people with cognitive impairments, who may not remember what the form input is for, and make it harder for them to complete the form confidently.

Text field input with password as placeholder text
A text field clearly labelled by the placeholder text, “Password”.
Text field input with no visible label and no placeholder text.
The same text field once a user has started to enter text, appearing with no visible label.

For people that can see, the placement of a <label> near an <input> field helps them understand the connection. For example, if a text field is placed next to "Name" they recognise they are linked. However, to make this relationship accessible to people with visual impairments, it must be explicitly defined in the HTML markup. Without this, individuals with visual impairments may struggle to understand which labels correspond to which form inputs, much like how a sighted person would if the labels and fields were not clearly connected.

Two text fields and a checkbox with no visible labels.
A form field with two text field inputs with no visible label, and a checkbox with no visible label

Connecting a <label> and <input> with for and id

Just as people that can see would intuitively associate a <label> with an <input> field based on their visual proximity, correct use of the for and id attributes ensures that when the <input> field receives focus, the <label> becomes part of the form field’s accessible name. This improves the accessibility for people who rely on screen readers and other assistive technologies.

Add an id to the <input> element to uniquely identify the field:

<input id="email_login" type="email">

Set the for attribute on the <label> to match the id of the <input>:

<label for="email_login">Email:</label>

When screen reader focus is on the email <input> field, it will be announced as “Email edit blank”, blank due to their being no content within the field.

Tips

  • Select the correct <input> field type using the type attribute
  • Write clear and descriptive labels for each form field
  • Don’t rely on placeholder text as the only <label> for <input> fields
  • Ensure labels and inputs are properly linked, one way this can be achieved is using for and id attributes
  • Use standard label positioning to make forms easier for everyone to navigate

Further reading

Next steps

Read more accessibility foundations posts or sign up for Accessibility Unlocked, our free six-day newsletter series designed to help you kick-start accessibility.