Skip to Content


This page defines common terms relating to accessibility and ANDI terminology.

Basic Terms


Web content should be accessible to everyone including individuals with disabilities. Web accessibility encompasses all disabilities that affect access to the Web, including visual, auditory, physical, speech, cognitive, and neurological disabilities.


Often used interchangeably with the term "accessibility", 508 refers to Amendment Section 508 of the Rehabilitation Act (29 U.S.C. 794d) which mandates that all electronic and information technology developed, procured, maintained, or used by the federal government be accessible to people with disabilities.

Screen Reader

Screen readers are software programs that allow blind or visually impaired users to read text that is displayed on a computer screen. For web content, screen readers analyze the HTML markup, compute the text to be read using programmed algorithms and incorporate speech synthesizers to audibly read the text.

Popular screen readers are JAWS by Freedom Scientific, NVDA by NV Access, and VoiceOver by Apple.

Keyboard-Only User

Many users with motor disabilities rely on a keyboard for navigation. Since these users do not use a mouse, care must be taken to design web content so that all functionality can be accessed and interacted with using only a keyboard.


An element is an HTML object or tag, which is part of the structural markup of a web page. There are many different types of elements: images, links, lists, text containers, headings, forms, buttons, etc. Elements can contain many attributes and properties that further define the purpose of the element.


Keyboard focus is the location where keyboard actions will be interpreted by the application. An element is considered "focusable" if focus can be rested at the element, whether by using a keyboard or being programmatically shifted to the element. These focusable elements are typically part of the user interface where actions and events occur.

If an element is not "natively" focusable, a tabindex attribute can be added to the element to add focusability.


Keyboard focus is the location where keyboard actions will be interpreted by the application. An element is considered "tabbable" if focus can be rested at the element by using the tab key. These tabbable elements are typically part of the user interface where actions and events occur.

If an element is not "natively" tabbable, a tabindex attribute with zero or a positive value can be added to the element to make it tabbable. NOTE: Not everything that is focusable is tabbable, but anything tabbable is focusable.

Accessible Name

The accessible name is the name of a user interface element. The accessible name of an element is derived from the HTML markup on the page relevant to the element.

Accessible Description

An accessible description provides additional information related to an interface element that complements the accessible name. The accessible description may or may not be visually perceivable.

Acronyms Relating to Accessibility

W3C - World Wide Web Consortium

The World Wide Web Consortium (W3C) is an international community that develops open standards to ensure the long-term growth of the Web. For more information visit

ARIA - Accessible Rich Internet Applications

The Web Accessibility Initiative - Accessible Rich Internet Applications (WAI-ARIA) is a technical specification published by the W3C that specifies how to increase the accessibility of web pages. In particular, it focuses on dynamic content and user interface components.

WCAG - Web Content Accessibility Guidelines

Web Content Accessibility Guidelines (WCAG) is a set of guidelines which create standards for web content accessibility. For more information visit WCAG.

DOM - Document Object Model

The Document Object Model (DOM) defines the logical structure of web content. The HTML DOM is constructed as a tree of Objects. Each Object is an HTML element.

ANDI Terms

Namers & Describers

The W3C ARIA Text Alternative Computation specification (4.3) describes how elements are to be named and described. However, for justifiable reasons, screen reader vendors are hesitant to negatively impact their users; instead of adopting, they adapted the specification. Therefore, a common set of behaviors and best practices is emerging.

To break this real-world vs specification impasse, ANDI simplifies the naming and describing of elements by establishing articulate rules, long term supported practices, and eliminating unsupported or unpredictable methods. This is accomplished through exhaustive analysis of the Text Alternative Computation, real-world screen reader behavior, and HTML 5 specification.

To simplify development and testing, ANDI breaks down accessibility information into two types:

  1. Namers
  2. Describers

ANDI defines the following components as Namers:
  • aria-labelledby
  • aria-label
  • label (form elements)
  • alt (images)
  • value (input buttons)
  • figcaption (figure)
  • caption (table)
  • innerText (container elements)
ANDI defines the following components as Describers:
  • aria-describedby
  • legend (form elements & only with label)
  • title

For more info about Namers and Describers, see the Developer Guide.

ANDI Methodology

ANDI suggests using one Namer and one Describer per element. The benefit of this simplified nomenclature is the elimination of unpredictable and inconsistent screen reader behavior. Because this approach consolidates multiple specifications and real world behaviors, developer and tester accessibility training is greatly simplified.

Active Element

The Active Element in ANDI is the last element in the test page to receive focus or mouseover.


The ANDI Output displays what a screen reader should present to users. The Output calculation is based primarily on W3C specifications, and where specifications are not specific, thorough analysis of screen reader functionality.

Add-On Properties

Under the term "Add-On Properties", ANDI groups together additional roles and states of the element designated by certain attributes. Screen readers may insert their own phrasing to signify the presence of Add-On Properties.

Add-On Properties Are
  • tabindex
  • accesskey
  • role
  • aria-controls
  • aria-disabled
  • aria-expanded
  • aria-haspopup
  • aria-invalid
  • aria-pressed
  • aria-sort
  • aria-readonly
  • readonly
  • aria-required
  • required


When ANDI is launched, it scans every HTML element on the page and automatically analyzes each element for conditions that commonly cause accessibility issues. When it finds such a condition, ANDI generates an Alert which helps a user pinpoint potential accessibility issues.

Accessibility Components

Accessibility Components are HTML tags and attributes that influence the accessibility of elements on the page.

ANDI recognizes the following components:

  • aria-labelledby
  • aria-label
  • aria-describedby
  • alt
  • value
  • title
  • <label>
  • <legend>
  • <figcaption>
  • <caption>
  • innerText
  • child element
  • tabindex
  • accesskey
  • add-on properties

child element

This is part of the innerHTML. Most HTML elements can contain other html elements called "child elements".

The most popular form of nested structure relevant to accessibility is an image within a link.

Screen Reader Usage

Screen readers may not recursively search deep into the tree, but they do use some of the components of child elements to derive the accessible name and description. The current version of ANDI will only return the components of an image child to optimize performance and limit the recursion necessary to traverse every tree in the DOM.


This is part of the innerHTML. The innerText is the text contents of both the element and all of its child nodes.