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

推荐订阅源

C
Check Point Blog
AI
AI
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
U
Unit 42
Vercel News
Vercel News
Stack Overflow Blog
Stack Overflow Blog
P
Proofpoint News Feed
Microsoft Security Blog
Microsoft Security Blog
The GitHub Blog
The GitHub Blog
WordPress大学
WordPress大学
Martin Fowler
Martin Fowler
博客园 - 【当耐特】
B
Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Apple Machine Learning Research
Apple Machine Learning Research
博客园_首页
F
Full Disclosure
Google DeepMind News
Google DeepMind News
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
H
Help Net Security
Recorded Future
Recorded Future
N
News and Events Feed by Topic
雷峰网
雷峰网
V
Vulnerabilities – Threatpost
Schneier on Security
Schneier on Security
aimingoo的专栏
aimingoo的专栏
S
Schneier on Security
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
O
OpenAI News
Project Zero
Project Zero
罗磊的独立博客
G
GRAHAM CLULEY
腾讯CDC
P
Privacy International News Feed
V
V2EX
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Hugging Face - Blog
Hugging Face - Blog
爱范儿
爱范儿
H
Heimdal Security Blog
L
LINUX DO - 热门话题
Forbes - Security
Forbes - Security
美团技术团队
MongoDB | Blog
MongoDB | Blog
Security Latest
Security Latest
M
MIT News - Artificial intelligence
T
Tor Project blog
Cisco Talos Blog
Cisco Talos Blog
宝玉的分享
宝玉的分享
T
Threat Research - Cisco Blogs
TaoSecurity Blog
TaoSecurity 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 Foundations: labelling text fields with input and label - 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 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: accessible names and descriptions - TetraLogical
2023-04-05 · via TetraLogical Blog

Posted on by Henny Swan in Design and development

Tags: Assistive Technology, Code, Foundations, WCAG

An element's name, or accessible name, is how it's identified. An accessible description provides additional information, about the element, that complements the accessible name.

In this post we explore assigning accessible names and descriptions using HTML and WAI-ARIA.

Why are accessible names important?

An accessible name is the information used by Assistive Technologies (AT) to identify an element such as an image, link, button, or form input. AT is software or hardware used by people with disabilities to help them do a number of things including navigating web content.

For example, people browsing with a desktop screen reader or browsing with a mobile screen reader rely on accessible names so they can understand content. Using a button as an example, if it has an accessible name of Search the screen reader will announce Search when it encounters it.

A visible search button with the Voiceover speech output b
When the Voiceover screen reader encounters a button with an accessible name of search, "Search" is announced as shown in the speech dialog box.

People browsing with speech input rely on accessible names, so they can interact with content using speech commands. Using the button example again, a person navigating using speech can say click Search to activate the search button.

HTML

Using HTML semantics, an accessible name can be created in a number of ways.

For links, the <a> element's content gives the link its accessible name of About us:

<a href="index.html">About us</a>

For images, an alt attribute gives an image an accessible name of TetraLogical Logo:

<img src="tetralogical_logo.png" alt="TetraLogical logo">

For form inputs, a <label> gives an input an accessible name of Terms and conditions when its for attribute has the same value as the id attribute on an <input>.

<input type="checkbox" id="terms">
<label for="terms">Terms and conditions</label>

For buttons, the <button> element's content gives a button an accessible name of Search:

<button>Search</button>

WAI-ARIA

WAI-ARIA (Web Accessibility Initiative Accessible Rich Internet Applications) complements HTML semantics by providing a set of attributes that allow you to enhance the native roles of HTML elements to build more accessible user experiences. You can read more about this in introduction to WAI-ARIA.

WAI-ARIA has two attributes that can provide, or alter, accessible names for elements: aria-label and aria-labelledby. Each have a slightly different use, but the thing to remember is that they will both override the native HTML accessible name.

Name

The aria-label attribute takes a piece of text as its value. This text becomes the element's label or accessible name. In the following example, the screen reader will announce Search button:

<button id="search" aria-label="Search"></button>

The aria-labelledby attribute uses text that exists elsewhere in the document as a label. It takes the value of the id attribute on the element it points to, so it becomes the label or accessible name for the element with aria-labelledby applied to it. In the following example, the screen reader will also announce Search button:

<h2 id="searchLabel">Search</h2>

<label for="search">Enter search term
  <input type="search" id="search">
</label>
<button aria-labelledby="searchLabel"></button>

Description

The aria-describedby attribute gives an element an accessible description. It also points to text elsewhere in the document taking its value from the id attribute on the element it points to. In the following example and demo, a screen reader will announce the accessible name Password, and the accessible description Must be at least 20 characters and contain upper and lowercase letters, numbers and other characters.

<label for="passwordLabel">Password</label> <input type="password" id="passwordLabel" name="password" aria-describedby="passwordDescription">
<p id="passwordDescription">Must be at least 20 characters and contain upper and lowercase letters, numbers and other characters</p>

Tips

  • Always use semantic HTML over WAI-ARIA when it is available
  • Do not change native semantics, unless you really have to
  • Use the ARIA Authoring Practices Guide (APG) as a reference for how to apply role, name, description, state and keyboard behaviour for accessible custom components

Summary

  • An accessible name is the information used by Assistive Technologies to identify an element such as an image, link, button or form input
  • Interactive elements can be assigned an accessible name using HTML or WAI-ARIA aria-label or aria-labelledby
  • Elements can be given an additional description using aria-describedby
  • Interactive elements must have an accessible name, an accessible description is optional
  • aria-label and aria-labelledby will override the native HTML accessible name
  • Success Criterion 4.1.2 Name, Role, Value (Level A)

More information

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.