An accessible name is a textual identifier assigned to an interactive or static element within a digital interface. It is essential for ensuring that users who rely on assistive technologies, such as screen readers, can understand and interact with web content effectively. Accessible names provide meaningful information that can be spoken aloud or displayed as text to users, enhancing their ability to navigate and comprehend web pages.

Accessible names are crucial because they bridge the communication gap between digital content and users with disabilities. They ensure that everyone, regardless of their abilities, can interact with and understand web elements. Without accessible names, users relying on assistive technologies may miss out on essential information or functionality, leading to a frustrating and exclusionary experience. Properly implemented accessible names contribute to a more inclusive and user-friendly digital environment, aligning with WCAG 2.2 level AA standards.

What to Include:

1. Descriptive Text: Use clear, concise language that accurately describes the function of the element. For instance, a button leading to a contact form should have an accessible name like "Contact Us."
2. Visible Text First: Ensure any visual text of the element is included in the accessible name and is the first part of the accessible name. For example, if a button says "Submit," the accessible name should start with "Submit" followed by any additional information as necessary.
3. Describe the Function: Linked images or image/icon buttons should describe the destination or function, such as “Company Home” for a linked logo or “Search” for an eyeglass icon search button.

What to Avoid:

1. Redundant Words: Avoid unnecessary repetition of words or phrases. For example, instead of "Click here to submit," use "Submit."
2. Non-Descriptive Labels: Avoid vague labels like "Click here" or "More." These do not provide sufficient information about the element's purpose. If this is the visible text for the control, make sure to provide the relevant contextual information in the accessible name. For example, instead of “Learn More”, the accessible name should be “Learn more about [SUBJECT]”.

What to Include:

1. Meaningful Labels: Ensure that landmarks have names that reflect their content or purpose, such as "Main" or "Secondary." Do not include the role information such as “Footer” or “Navigation”. This will be provided by the element’s role.
2. Descriptive Alt Text: For images, provide descriptive alt text that conveys the image’s content or function, such as "Company Logo."

What to Avoid:

1. Placeholder Text: Avoid using generic placeholder text like "Image" or “Graphic”. This will be provided by the element’s role.
2. Irrelevant Information: Do not include irrelevant details that do not contribute to understanding the element.

Do’s:

1. Do use specific, descriptive language.
2. Do ensure that alt text for images conveys meaningful information.
3. Do use logical naming conventions for landmarks and headings.
4. Do describe the function or destination for interactive elements.
5. Do include the visible text or label for the element.

Don’ts:

1. Don’t use vague or non-descriptive labels.
2. Don’t include state information for interactive elements (“Toggle”, “Open”, “Close”).
3. Don’t include role information for interactive elements (“Button”, “Link”, “Tab”).
4. Don’t repeat redundant information.
5. Don’t include irrelevant or extraneous details.
6. Don’t use placeholder text that does not describe the content or function.

Accessible name computation is the process by which browsers and assistive technologies determine the accessible name for an element. This computation follows a specific order of operations to ensure that the most relevant and useful information is provided to users. Understanding how accessible name computation works is crucial for developers to create accessible web content effectively.

1. aria-labelledby Attribute: If an element has an aria-labelledby attribute, the value of this attribute will be used as the accessible name. This attribute references other elements on the page whose text content (including alt text for images) will be concatenated to form the accessible name.
2. aria-label Attribute: If the aria-labelledby attribute is not present, the aria-label attribute will be used next. This attribute provides a string that labels the element directly.
3. Native HTML Element Labeling: For elements with inherent labeling mechanisms (like <input> elements with associated <label> elements), the accessible name will be derived from the associated labels.
4. Text Content: If none of the above attributes are present, the accessible name will be taken from the element's text content. This includes any text nodes directly within the element.
5. title Attribute: If the element does not have any of the above attributes or text content, the title attribute will be used to provide the accessible name.
6. Role-Specific Mechanisms: Some ARIA roles have specific properties that provide accessible names. For example, the alt attribute of an <img> element will be used as its accessible name.

When multiple sources are available, the order of operations ensures that the most relevant and detailed information is used. For example, if an element has both an aria-labelledby and aria-label attribute, the aria-labelledby attribute will take precedence, and the aria-label will be ignored.

By understanding and correctly implementing the accessible name computation rules, developers can ensure that their web content is accessible and provides meaningful information to all users. This helps create a more inclusive web experience, improving usability for individuals relying on assistive technologies.

When implementing accessible names, it is crucial to choose the appropriate method based on the context and functionality of the web element. Accessible names can be assigned using various techniques, each with its own set of considerations. The primary methods include using aria-label, aria-labelledby, the content of the element, visually hidden screen reader-only text, the title attribute, placeholder text in inputs, and the <label> element. Understanding the strengths and limitations of each method is essential to ensure that accessible names are correctly conveyed to users relying on assistive technologies.

When implementing accessible names, it is crucial to choose the appropriate method based on the context and functionality of the web element. Accessible names can be assigned using various techniques, each with its own set of considerations. The primary methods include using aria-label, aria-labelledby, the content of the element, visually hidden screen reader-only text, the title attribute, placeholder text in inputs, and the <label> element. Understanding the strengths and limitations of each method is essential to ensure that accessible names are correctly conveyed to users relying on assistive technologies.

The aria-labelledby attribute is used to reference other elements on the page that serve as the label for the element in question. This method is beneficial when there are existing elements, such as headings or labels, that already provide a clear and descriptive name. By using aria-labelledby, the element can inherit the accessible name from one or more other elements, maintaining consistency and reducing redundancy. It is particularly effective for complex components where multiple parts need to be associated with to produce a single label.

Using the content of the element itself as the accessible name is a straightforward method and is often the most intuitive. For elements like buttons and links that have visible text, the content naturally serves as the accessible name. This approach ensures that the visible label is the same as the accessible name, providing a seamless experience for all users. Additionally, text alternatives (alt text) for images count as content and can serve as the accessible name, ensuring that the purpose or function of the image is communicated effectively. However, this method relies on the visible text or text alternative being sufficiently descriptive and may not be suitable for elements without visible content or when the content is CSS based.

Visually hidden screen reader-only text involves adding text that is hidden from visual users but can be read by screen readers. This technique is useful for providing additional context or descriptions without cluttering the visual interface. It is commonly implemented using CSS to hide the text visually while keeping it accessible to assistive technologies. This method is particularly effective for adding contextual information to elements that have insufficient visible labels.

The <label> element is one of the most fundamental and reliable methods for providing accessible names, particularly for form controls. Associating a <label> with an input element ensures that the accessible name is consistently conveyed to users by screen readers. This method is straightforward and highly effective, making it a best practice for form accessibility. The <label> element should contain clear, descriptive text that accurately describes the purpose of the input field, ensuring that users understand the required information or action.

The title attribute can provide a tooltip that appears when users hover over an element with their mouse. It can also serve as an accessible name for screen readers. However, relying solely on the title attribute is not recommended, as it may not be consistently supported by all screen readers and is not always the most robust method for providing accessible names. It should be used as a supplementary technique rather than the primary method.

Placeholder text in input fields can offer guidance on what users should enter into the field. While it can be read by screen readers, it is not a reliable method for providing accessible names, as it disappears once users start typing. Placeholder text should never replace the use of a proper <label> element, which provides a more stable and consistent accessible name for input fields. Proper labeling ensures that users understand the purpose of the input field at all times.

Each method for implementing accessible names has its own appropriate use cases, and understanding when to apply each technique is key to creating accessible and user-friendly web interfaces. In the following sections, we will delve into the specifics of each method to provide detailed guidance on their implementation.

Note: We will not be discussing placeholder text or the title attribute as methods in detail. Although these approaches may provide an accessible name, they are not considered best practices. Relying on placeholder text can lead to confusion as it disappears once users start typing, potentially leaving users without context. Similarly, the title attribute is not consistently supported by all screen readers, is not exposed to keyboard-only users and does not offer a robust solution for accessibility. Furthermore, depending on these methods often results in other defects being introduced. Therefore, we will focus on more reliable and effective methods to ensure accessible names are properly conveyed.

Using the visible content of the element itself as the accessible name is a straightforward and intuitive method. This approach ensures that the visible label is the same as the accessible name, providing a seamless experience for all users. For elements like buttons and links that have visible text, the content naturally serves as the accessible name. Additionally, text alternatives (alt text) for images count as content and can serve as the accessible name, ensuring that the purpose or function of the image is communicated effectively. When both text and images with text alternatives are used, the accessible name of the control will contain the content from both, enhancing the clarity and context for users relying on assistive technologies.

Decorative content can be excluded from the accessible name of a control using methods such as aria-hidden="true" for elements or setting alt="" for images. These techniques ensure that assistive technologies ignore these elements, preventing them from contributing to the accessible name. This helps maintain clarity and avoids redundancy in the accessible name.

By relying on the content of the element for the accessible name, developers ensure a robust and straightforward approach that accurately reflects the visible interface. This method provides a consistent and reliable user experience, as the accessible name directly corresponds to the element's visual and functional content. This method is appropriate when the visible text and image content of the control contains all the information needed for the accessible name and does not need to be supplemented with additional context.

<button>Search</button>

Accessible Name: "Search"

<button>Search <img src="icon.png" alt=""></button>

Accessible Name: "Search" (the image is decorative and does not contribute to the accessible name)

<button>Search <img src="books.png" alt="Books"></button>

Accessible Name: "Search Books" (the accessible name combines the text content and the alt text of the image)

<button>
  <svg width="24" height="24" role="img" aria-labelledby="svgTitle">
    <title id="svgTitle">Search</title>
    <use xlink:href="#search-icon"></use>
  </svg>
</button>

Accessible Name: "Search" (the title element within the SVG provides the accessible name via the aria-labelledby attribute)

In these examples, the accessible name is derived from the visible text content and any text alternatives provided for images. For the button with text "Search" and a blank alt attribute, the accessible name remains "Search" as the image is decorative and does not add to the accessible name. For the button with both text "Search" and an image with alt text "Books," the accessible name is "Search Books," combining both sources of content. In the case of the button with only an SVG containing a title, the accessible name is provided by the title element within the SVG, ensuring that screen readers can convey the function of the button to users.

Adding non-visible screen reader-only content to an element is the most robust method for providing any additional context needed beyond the visible content. This technique involves including text that is hidden from visual users but can be read by screen readers, ensuring that the accessible name contains all necessary information without altering the visual design.

When using this method, it is crucial that the additional content is appended to the visible text. The element's accessible name must start with the visible text, followed by any supplementary details. This ensures that the primary information is immediately conveyed, with extra context provided seamlessly for those using assistive technologies.

This approach is particularly appropriate for situations where an ambiguous link is used, or additional detail that would be helpful for non-visual users is necessary. For example, a link with visible text "Read more" might not provide sufficient context. By adding screen reader-only text, such as "Read more about our services," users can gain a clearer understanding of the link's purpose. Another common use case is indicating that a link opens in a new window, which is important for users to know to avoid confusion or unexpected behavior.

This method involves applying a set of CSS rules to an element to hide it visually but keep it accessible to screen readers. This approach is commonly referred to as the "sr-only" technique.

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  margin: -1px;
  padding: 0;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  border: 0;
}

<a href="services.html">Read more<span class="sr-only"> about our services</span></a>

This method achieves the same effect using slightly different CSS properties. It is another popular approach for hiding elements visually while keeping them accessible.

.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  margin: -1px;
  padding: 0;
  overflow: hidden;
  clip: rect(0 0 0 0);
  white-space: nowrap; /* Added to prevent text from wrapping */
  border: 0;
}

<a href="https://example.com" target="_blank">Learn more<span class="visually-hidden"> (opens in a new window)</span></a>

Both methods effectively remove the content from the visual flow of the page, ensuring it does not disrupt the layout or design, while keeping it available in the DOM for screen readers and other assistive technologies. These techniques are widely used to enhance web accessibility by providing additional context and information to users who rely on screen readers.

The <label> element is one of the most fundamental and reliable methods for providing accessible names, particularly for form controls. Associating a <label> with an input element ensures that the accessible name is consistently conveyed to users by screen readers and other assistive technologies. This method is straightforward and highly effective, making it a best practice for form accessibility.

Benefits of Using the <label> Element

1. Improved Usability: Labels provide clear and descriptive text that helps users understand the purpose of form controls.
2. Better Accessibility: Associating labels with form elements ensures that screen readers announce the label text when the form control receives focus.
3. Increased Click Area: Clicking on a label focuses the associated form control, enhancing the user experience, especially for users with motor impairments.

There are two main ways to associate a <label> with a form control: implicitly and explicitly.

An implicit association is made by placing the input element within the <label> tag. This method is simple, though it has inconsistent support across assistive technology, so it is not recommended.

<label>
  Email
  <input type="email" name="email"/>
</label>

Accessible Name: "Email"

An explicit association is made by using the for attribute on the <label> element and matching it with the id of the form control. This method is more flexible and is preferred for larger forms or when the label and input are not adjacent.

<label for="emailInput">Email:</label>
<input type="email" id="emailInput" name="email">

Accessible Name: "Email"

In some cases, it may be necessary to provide additional context beyond the basic label text. This can be achieved by using visually hidden screen reader-only text within the label. However, non-visible text with instructions should only be added to the <label> element if these instructions are also visible somewhere else on the screen. Instructions relevant to the form must be visually presented. This approach is necessary when instructions are presented in a location not directly adjacent to the field's visible label.

<label for="passwordInput">
  Password:
  <span class="sr-only"> (must be at least 8 characters long)</span>
</label>
<input type="password" id="passwordInput" name="password">

Accessible Name: "Password (must be at least 8 characters long)"

In this example, ensure that the instruction "must be at least 8 characters long" is visible somewhere else on the screen, such as in a help text area or next to the form field, but not within the <label> tag.

As discussed earlier, you can use CSS to visually hide the additional text while keeping it accessible:

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  margin: -1px;
  padding: 0;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  border: 0;
}

Using the <label> element appropriately ensures that all users, including those relying on assistive technologies, can understand and interact with form controls effectively. This practice not only complies with accessibility standards but also enhances the overall user experience.

The aria-labelledby attribute is a powerful method for creating accessible names by referencing other elements on the page. This method is beneficial for associating text (plain text or the accessible name of images and other content) with an element, even when that text is marked as display: none. One of the key advantages of using aria-labelledby over aria-label is that the text nodes used for the aria-labelledby content will automatically translate, making it an ideal choice for multilingual applications.

Benefits of Using aria-labelledby

1. Automatic Translation: The text nodes used in aria-labelledby will be automatically translated, ensuring accessibility across different languages.
2. Flexible Association: This method allows for associating text from multiple elements, including those not visually displayed, providing a comprehensive accessible name.
3. Consistency: It maintains consistency by reusing existing text content or labels, ensuring that the accessible name aligns with the visible content.

<svg width="24" height="24" role="img" aria-labelledby="svgTitle">
  <title id="svgTitle">Search</title>
  <use xlink:href="#search-icon"></use>
</svg>

Accessible Name: "Search"

<div role="region" aria-roledescription="slide" aria-labelledby="slide1Title">
  <div id="slide1Title" style="display: none;">Slide 1 of 5</div>
  <img src="slide1.jpg" alt="Beautiful landscape">
  <p>Description of the slide content.</p>
</div>

Accessible Name: "Slide 1 of 5"

<h2 id="sectionTitle">User Profile</h2>
<p id="sectionDescription">Details about the user.</p>
<div role="region" aria-labelledby="sectionTitle sectionDescription">
  <!-- Content of the user profile section -->
</div>

Accessible Name: "User Profile Details about the user."

In these examples, aria-labelledby is used to associate various elements to create comprehensive accessible names. The SVG example uses aria-labelledby to reference its <title> element, ensuring that the accessible name "Search" is read by screen readers. The carousel slide example uses hidden text with display: none; to provide important context ("Slide 1 of 5") as part of the accessible name. The third example shows how multiple existing text nodes can be combined to form a complete accessible name, enhancing clarity and context for users relying on assistive technologies.

The aria-label attribute is used to provide a string that labels an element. While it may seem like an easy option for creating accessible names, it comes with several limitations that developers must consider. The aria-label attribute can override any existing content within the element when a user is navigating using the tab key, but graphical content within the element must still be hidden from assistive technologies, as it can be exposed through browse/reading mode navigation. Additionally, aria-label does not automatically translate, which can be problematic for multilingual websites. Furthermore, aria-label cannot be used on elements without a role assigned, limiting its flexibility.

Limitations of aria-label

1. Lack of Automatic Translation: Unlike aria-labelledby, aria-label does not automatically translate, requiring manual updates for multilingual support.
2. Maintenance Issues: If the content of the element changes, the aria-label must be manually updated to stay accurate, increasing the risk of inconsistencies.
3. Overrides Content: While it overrides existing content during keyboard navigation, the graphical content must still be hidden from assistive technologies to prevent exposure through other navigation modes.
4. Role Requirement: aria-label cannot be used on elements that do not have an assigned role, limiting its applicability.

Despite these limitations, aria-label can still be useful in specific scenarios where other methods are not practical. Below are three examples of good usage:

<button aria-label="Search">
  <span aria-hidden="true" class="icon-search"></span>
</button>

Accessible Name: "Search"

.icon-search::before {
  content: url('search-icon.png'); /* Provide the graphic content */
  display: inline-block;
  width: 24px;
  height: 24px;
}

<div role="button" aria-label="Details" aria-expanded="false">
  <img src="expand-icon.png" alt="">
</div>

Accessible Name: "Details"

Note: The information about expanding/collapsing is provided by the aria-expanded attribute.

<a href="#menu" aria-label="Menu" aria-expanded="false">
  <svg width="24" height="24" role="img" aria-hidden="true">
    <use xlink:href="#menu-icon"></use>
  </svg>
</a>

Accessible Name: "Menu"

Note: The information about expanding/collapsing is provided by the aria-expanded attribute.

In these examples, aria-label is used effectively to provide accessible names for elements that do not have sufficient visible text content. The icon button without text example uses CSS pseudo-content to provide the graphic, with a span element marked as aria-hidden="true". This ensures that the button is labeled "Search," making its function clear to screen reader users. The complex interactive element example uses aria-label to describe the content, with the aria-expanded attribute indicating whether the content is expanded or collapsed. The navigation menu icon example uses aria-label to indicate that the element is a menu, with the aria-expanded attribute providing additional context. By understanding the limitations and appropriate use cases for aria-label, developers can ensure their web content remains accessible and user-friendly.

Creating accessible names is a critical aspect of web accessibility, ensuring that all users, including those relying on assistive technologies, can understand and interact with web content effectively. The methods for providing accessible names include using the content of the element, aria-labelledby, visually hidden screen reader-only text, and the <label> element for form controls. Each method has its specific use cases and advantages, contributing to a robust and user-friendly digital experience.

While the aria-label attribute can be useful in certain scenarios, it comes with limitations such as lack of automatic translation, maintenance issues, and the requirement for graphical content to be hidden from assistive technologies. Therefore, it should be avoided unless necessary. More reliable and flexible methods, such as aria-labelledby and using visible content, should be prioritized.

It is also essential to note that using the title attribute and placeholder text for accessible names is not recommended. These methods are not robust and do not provide a consistent user experience across different assistive technologies and contexts.

By following these best practices, developers can ensure their web content is accessible, providing a seamless and inclusive experience for all users. Prioritizing robust and flexible methods for creating accessible names not only aligns with accessibility standards but also enhances the overall usability and functionality of digital interfaces.