1 Definition and purpose

An accessible name is the programmatically determined text used by assistive technologies to identify an interface element. It may describe a button, link, image, form control, or other component in a way that can be spoken or presented to users. The concept is central to digital accessibility because it gives nonvisual users a reliable way to understand what an element is and how it functions.

1.1 Core concept

The accessible name is not simply a visible caption. It is the official label exposed to accessibility APIs, which screen readers and similar tools rely on when interpreting content. A single element may have one computed name derived from text, attributes, or references, depending on the rules of the platform or standard in use.

1.2 Role in accessibility

Accessible names support navigation, orientation, and interaction. They help users distinguish one control from another, such as identifying multiple buttons on a page or selecting the correct item in a list. Without meaningful names, interface elements may be announced generically or left ambiguous, making tasks slower and more error-prone.

1.3 Distinction from visible text

Visible text and accessible names often match, but they are not identical concepts. A visible label may be hidden from assistive technology, while an accessible name may come from an attribute or reference that is not visually displayed. This distinction allows designers to provide names for icons, controls, and other elements that lack clear on-screen text.

2 Calculation and naming sources

Accessible names are assembled from one or more sources defined by accessibility specifications. The exact source depends on the element type and the authoring method used. Common naming sources include text content, associated labels, alternative text, and various attributes that provide explicit naming instructions.

2.1 Native text content

For many elements, the simplest naming source is their own text content. A link labeled “Read more” or a button labeled “Submit” usually exposes that text directly as its name. This approach is preferred when the visible text already describes the purpose clearly.

2.2 Associated labels

Some elements receive their names from another element that is explicitly associated with them. This relationship is common for form controls and custom components that need a separate labeling mechanism. Associated labels can improve clarity and ensure that the control is announced correctly.

2.2.1 Form labels

Form labels provide a direct description of an input’s purpose, such as “Email address” or “Postal code.” They are often connected to the control through structural markup or another platform-specific association. A well-linked label makes it easier for users to understand both what the field is for and which control it refers to.

2.2.2 ARIA labeling attributes

ARIA labeling attributes allow authors to assign or override a control’s accessible name. These attributes are especially useful for custom widgets, icon-only buttons, and components that do not have sufficient native text. They should be used carefully, because an incorrect attribute can hide better native naming information or create confusion.

2.3 Alternative text

Alternative text is a naming source for non-text content, especially when an image conveys information or performs a function. In accessibility APIs, alt text may serve as the accessible name or contribute to it. Its purpose is to provide a concise textual equivalent for content that cannot be directly read by a screen reader.

2.3.1 Images and icons

Images that communicate meaning often require short, descriptive names. An icon used as a button may need a label such as “Search” or “Close” if the graphic itself is not self-explanatory. Decorative images, by contrast, are usually excluded from naming so that they do not add noise to the reading experience.

2.3.2 Decorative content

Decorative content is intended to support visual design rather than convey meaning. Such material is generally hidden from assistive technology and does not contribute to the accessible name. This prevents unnecessary announcements and helps users focus on information that matters.

2.4 Attribute-based naming

Some accessible names come from attributes that were created specifically for naming or from references to other elements. These methods are useful when visible text is unavailable or when a component needs an explicit label source. Attribute-based naming is common in complex interfaces and reusable widgets.

2.4.1 Title attributes

Title attributes can sometimes provide a name or supplementary text, depending on the platform and element type. They are not always dependable as the sole naming source, because support may vary and visible tooltips are not a substitute for proper labeling. In practice, they are usually treated as a fallback rather than a primary strategy.

2.4.2 Element references

Element references allow one element to derive its name from another element already present in the document. This approach can be useful for keeping labels consistent across related controls or for naming items with long or shared descriptions. The referenced content must be available in a way that accessibility tools can access.

3 Naming rules and precedence

Accessible names are not arbitrary; they are computed according to a defined set of rules. These rules determine which naming source is used first and how conflicting information is resolved. The goal is to produce a single, stable name that reflects author intent and user needs.

3.1 Accessible name computation

Accessible name computation is the process used to determine the final name exposed to assistive technologies. It considers native semantics, labels, attributes, and references in a structured order. This process helps ensure that similar elements are announced consistently across browsers, operating systems, and assistive tools.

3.2 Source precedence order

When multiple potential name sources exist, some are prioritized over others. For example, a direct author-specified label may take precedence over content that is merely descriptive. Precedence rules reduce ambiguity and prevent an element from being named in contradictory ways.

3.3 Empty and hidden content

Empty or hidden content typically does not contribute to the accessible name. If a label contains no readable text, it may leave the element unnamed unless another source is available. Content that is visually or semantically hidden may also be excluded, depending on how it is implemented and whether it remains exposed to accessibility APIs.

4 Element-specific behavior

Different interface elements use accessible names in different ways. Some elements have built-in naming behavior, while others rely heavily on explicit authoring. Understanding these differences is important when designing interfaces that are both usable and consistent.

Buttons and links often use their visible text as the accessible name. If they contain only an icon, they typically need an explicit label so the action is announced clearly. For interactive elements, the name should describe the action or destination rather than the visual appearance.

4.2 Form controls

Form controls depend heavily on accurate naming because users must understand what data is expected. Labels should identify the field unambiguously and, where possible, match the terminology used in the surrounding interface. Clear names are especially important for error prevention and efficient form completion.

4.2.1 Text inputs

Text inputs usually require a direct label that explains what the user should enter. Examples include fields for names, addresses, passwords, or search terms. Placeholder text may appear helpful, but it should not be treated as a replacement for a persistent accessible name.

4.2.2 Checkboxes and radio buttons

Checkboxes and radio buttons need names that indicate the option being selected. In grouped controls, the label should work together with the group context so the choice is understood in relation to the available alternatives. Clear naming helps users compare options without confusion.

4.2.3 Select elements

Select elements should have names that describe the category or property being chosen. Because the visible control may display only a current value, the accessible name must make the purpose of the menu obvious. This is especially important when several dropdowns appear close together on the same page.

4.3 Images and graphics

Images and graphics may be named when they carry informational or functional meaning. Charts, diagrams, logos, and illustrative visuals can require a concise textual equivalent. If a graphic is purely decorative, however, it is usually better for it to remain unnamed.

4.4 Headings and landmarks

Headings and landmarks are often identified through their semantic role, but they may also require names in certain cases. A landmark such as a navigation region may need a label to distinguish it from another region of the same type. Similarly, headings associated with complex sections can benefit from clear, concise wording.

5 Authoring practices

Good naming practices make content easier to understand and maintain. Authors should aim for labels that are brief, descriptive, and aligned with the purpose of the control or object. Consistency across a site or application also improves the user’s ability to predict how interfaces will behave.

5.1 Writing meaningful labels

A meaningful label tells users what an element does or what information is required. It should avoid vague wording such as “Click here” or “Item 1” when a more specific description is possible. In many cases, the best label matches the user’s task language rather than the developer’s internal terminology.

5.2 Avoiding redundant names

Redundant naming can create clutter for assistive technology users. If the visible text already states the purpose of a control, additional labels should not repeat the same wording unnecessarily. Efficient naming keeps announcements concise while still preserving essential detail.

5.3 Maintaining consistency

Consistent naming patterns help users recognize similar actions across different parts of an interface. Terms such as “Save,” “Submit,” and “Apply” should be used deliberately, since each may suggest a slightly different outcome. Stable terminology also supports learning and reduces cognitive load.

5.4 Testing with assistive technology

Testing with assistive technology helps confirm that names are exposed as intended. Developers and content authors can verify whether controls are announced correctly, whether custom widgets are labeled properly, and whether decorative items remain silent. Such testing is an important part of quality assurance because visual inspection alone may not reveal accessibility issues.

Accessible names are part of a broader model used to describe interface elements. They work together with other properties that define what an element is, what it says, and how it can be used. Understanding these related concepts helps distinguish naming from other forms of accessibility metadata.

6.1 Accessible description

An accessible description provides supplemental information beyond the name. It may offer instructions, explanations, or clarifications that are useful but not essential for identification. Unlike the name, the description is usually treated as supporting content rather than the primary label.

6.2 Accessible role

Accessible role identifies the function or type of an element, such as button, link, checkbox, or heading. The role tells assistive technology how the element behaves, while the name tells it what the element is called. Together, these two pieces of information make an object understandable.

6.3 Accessible properties and states

Accessible properties and states describe characteristics such as whether a control is selected, expanded, disabled, or required. These details change the user’s interpretation of the element but do not replace its name. They are typically announced alongside the name and role to form a complete picture.

6.4 Name, role, and value model

The name, role, and value model is a common framework for describing interactive elements in accessibility. The name identifies the element, the role explains its purpose, and the value conveys its current setting or status when applicable. This model underpins much of how assistive technologies present interface information to users.