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

推荐订阅源

美团技术团队
T
The Exploit Database - CXSecurity.com
aimingoo的专栏
aimingoo的专栏
小众软件
小众软件
T
Tailwind CSS Blog
V
V2EX
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
WordPress大学
WordPress大学
Hugging Face - Blog
Hugging Face - Blog
IT之家
IT之家
PCI Perspectives
PCI Perspectives
腾讯CDC
酷 壳 – CoolShell
酷 壳 – CoolShell
Recent Commits to openclaw:main
Recent Commits to openclaw:main
大猫的无限游戏
大猫的无限游戏
The Cloudflare Blog
N
News and Events Feed by Topic
博客园 - 三生石上(FineUI控件)
Help Net Security
Help Net Security
雷峰网
雷峰网
有赞技术团队
有赞技术团队
Last Week in AI
Last Week in AI
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
量子位
GbyAI
GbyAI
O
OpenAI News
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
AI
AI
S
Security Affairs
F
Fortinet All Blogs
L
LINUX DO - 最新话题
博客园 - 【当耐特】
Webroot Blog
Webroot Blog
Schneier on Security
Schneier on Security
W
WeLiveSecurity
Security Latest
Security Latest
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
T
Tenable Blog
L
LINUX DO - 热门话题
Google DeepMind News
Google DeepMind News
Simon Willison's Weblog
Simon Willison's Weblog
Cyberwarzone
Cyberwarzone
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
C
CERT Recently Published Vulnerability Notes
Engineering at Meta
Engineering at Meta
P
Palo Alto Networks Blog
博客园 - 叶小钗
T
Threatpost
H
Heimdal Security Blog
Microsoft Security Blog
Microsoft Security 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.