Interaction Quality

Accessible Name

An accessible name is the programmatically determinable label or text alternative that assistive technologies use to identify a user interface element.

Concept facts

An accessible name is the programmatically determinable label or text alternative that assistive technologies use to identify a user interface element.

Also known as
Accessible label, programmatic label, name computation, accessibility name.
Used in
Web accessibility, screen-reader support, form design, button design, icon controls, ARIA implementation, design QA, and accessibility testing.
Interpret with
Assistive technology, screen reader testing, alternative text, focus order, keyboard accessibility, form usability, error message, and input validation.

Plain-language explanation

An accessible name tells assistive technology what an element is called. A sighted user may understand a button from visible text or surrounding layout, but a screen reader depends on the accessible name to announce what the control does.

For example, a button with only a search icon needs an accessible name such as “Search.” A form field needs a label that tells the user what information is required.

Accessible names are created through native HTML labels, visible text, alt text, ARIA attributes, and other markup relationships. The exact name depends on formal computation rules.

Why it matters

Without clear accessible names, users may hear vague or misleading announcements such as “button,” “link,” or “image” without knowing what action is available.

In high-stakes systems, this can prevent task completion. A user may not know which button submits an application, uploads a document, confirms consent, changes account details, or cancels a transaction.

Accessible names also support quality assurance. They make interface meaning testable and reduce the risk of hidden accessibility defects.

Use contexts

Accessible names are used when designing or reviewing:

  • forms and field labels
  • icon-only buttons
  • search controls
  • upload, submit, cancel, and confirmation actions
  • modal dialogs and disclosure controls
  • dashboards and filters
  • status controls and navigation landmarks
  • mobile and web interfaces with assistive-technology support

Application guidance

Prefer native HTML and visible labels where possible. A visible label usually supports more users than an invisible programmatic label alone.

Check that the accessible name matches the visible purpose of the control. Avoid names that are technically present but unclear, such as “click here,” “open,” or “button 1.”

For icon-only controls, provide a clear accessible name. For images that communicate meaning, provide useful alternative text. For decorative images, avoid unnecessary announcements.

Test with accessibility tools and, where appropriate, screen-reader review. Ensure that repeated controls have distinguishable names, such as “Edit applicant address” rather than several identical “Edit” buttons.

Practical example

A fintech KYC flow asks users to upload a national ID image, verify personal details, and submit the application. The visual interface shows three icon-only buttons: upload, retake, and submit. Screen-reader users hear only “button” for each control.

The accessible-name issue creates a verification risk. Users may submit the wrong document, fail to retake a poor image, or abandon the flow and contact support. The UX consequence is service-access failure, support burden, and possible compliance delay.

Interpretive boundaries

An accessible name is not the same as visible copy, although the two should usually align.

Having an accessible name does not automatically make a control usable. The name must be meaningful in context, and the surrounding interaction must still support keyboard use, focus order, validation, and error recovery.

Accessible-name work should not rely only on ARIA. Native HTML and clear visible labels are usually more robust.

Applied at Userhub

Userhub reviews accessible names when evaluating forms, dashboards, status controls, navigation, and high-friction service journeys.

In UX Lab work, accessible-name issues often reveal deeper problems in component design, content clarity, and accessibility QA.

See Userhub UX Lab for applied UX research and evaluation context.

Sources and references

World Wide Web Consortium. (2018). Accessible Name and Description Computation 1.1. W3C Recommendation. https://www.w3.org/TR/accname-1.1/

World Wide Web Consortium. (2026). Accessible Name and Description Computation 1.2. W3C Working Draft. https://www.w3.org/TR/accname-1.2/

World Wide Web Consortium. (n.d.). ARIA Authoring Practices Guide. https://www.w3.org/WAI/ARIA/apg/

World Wide Web Consortium. (2024). Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation. https://www.w3.org/TR/WCAG22/

Lazar, J., Allen, A., Kleinman, J., & Malarkey, C. (2007). What frustrates screen reader users on the web: A study of 100 blind users. International Journal of Human-Computer Interaction, 22(3), 247–269. https://doi.org/10.1080/10447310709336964

Cite this entry

APA

Userhub. (2026). Accessible Name. UX Reference. https://userhub.com.bd/reference/accessible-name/