Accessible Name

key: accessible-name

The programmatically determined name of a user interface element that is included in the accessibility tree.

The accessible name is calculated using the accessible name and description computation.

For native markup languages, such as HTML and SVG, additional information on how to calculate the accessible name can be found in HTML Accessibility API Mappings 1.0, Accessible Name and Description Computation (working draft) and SVG Accessibility API Mappings, Name and Description (working draft).

Note: As per the accessible name and description computation, each element always has an accessible name. When no accessible name is provided, the element will nonetheless be assigned an empty ("") one.

Note: As per the accessible name and description computation, accessible names are flat string trimmed of leading and trailing whitespace. Notably, it is not possible for a non-empty accessible name to be composed only of whitespace since these must be trimmed.

Accessibility Support

  • Because the accessible name and description computation is not clear about which whitespace are considered, browsers behave differently when trimming and flattening the accessible name. For example, some browsers completely trim non-breaking spaces while some keep them in the accessible name.
  • There exists a popular browser which does not perform the same trimming and flattening depending whether the accessible name comes from content, an aria-label attribute, or an alt attribute.
  • There exists a popular browser which assign no accessible name (null) when none is provided, instead of assigned an empty accessible name ("").


Note: The examples presented here are non-normative and not testable. They serve to illustrate some common pitfalls about the definition and to help implementers of ACT rules understand it.

The input elements have an accessible name of, respectively, "Billing Name" and "Billing Address". These accessible names are given by the aria-labelledby attributes and associated elements.

<div id="myBillingId">Billing</div>

	<div id="myNameId">Name</div>
	<input type="text" aria-labelledby="myBillingId myNameId" />
	<div id="myAddressId">Address</div>
	<input type="text" aria-labelledby="myBillingId myAddressId" />

This button element has an accessible name of "Share ACT rules" given by its aria-label attribute.

<button aria-label="Share ACT rules">Share</button>

This img element has an accessible name of "ACT rules" given by its alt attribute.

<img src="#" alt="ACT rules" />

The button element has an accessible name of "Share ACT rules" given by the enclosing label element (implicit label)

<label>Share ACT rules<button>Share</button></label>

The button element has an accessible name of "Share ACT rules" given by the associated label element (explicit label)

<label for="act-rules">Share ACT rules</label><button id="act-rules"></button>

This a element has an accessible name of "ACT rules" given from its content. Note that not all semantic roles allow name from content.

<a href="">ACT rules</a>

This span element has an empty accessible name ("") because span does not allow name from content.

<span>ACT rules</span>

This span element has an empty accessible name ("") because span is not a labelable element.

<label>ACT rules<span></span></label>

Note: When the same element can have an accessible name from several sources, the order of precedence is: aria-labelledby, aria-label, own attributes, label element, name from content. The examples here are listed in the same order.

Note: For more examples of accessible name computation, including many tricky cases, check the Accessible Name Testable Statements.


key: decorative

Serving only an aesthetic purpose, providing no information, and having no functionality.

Note: Authors can mark an img element as decorative to indicate that it should be ignored by assistive technology by using either role="presentation", role="none", or alt="". An element should only be marked as decorative if removing the element does not cause a loss of information to the user.

Accessibility Support

There are several popular browsers that do not treat images with empty alt attribute as having a role of presentation but instead add the img element to the accessibility tree with a role of either img or graphic.

Equivalent resource

key: equivalent-resource

Non-identical resources can still be equivalent by equally complying to the expectation formed by the user when navigating to them, thus serving an equivalent purpose. This would usually involve that the advertised key content is the same.

Web pages and documents (e.g. PDFs, office formats etc.) may be equivalent resources, even if the resources:

  • are located on different URLs, including different domains
  • present different navigation options, e.g. through bread crumbs or local sub menus
  • contain different amounts of information and/or differently worded information
  • use different layouts.

If all resources cover the user's expectations equally well, the resources are considered to be equivalent.

Note: The user's expectations for the resource can be formed by different things, e.g. the name of the link leading to the resource, with or without the context around the link. This depends on the accessibility requirement that is tested.

Note: If the same content is presented in different formats or languages, the format or language itself is often part of the purpose of the content, e.g. an article as both HTML and PDF, an image in different sizes, or an article in two different languages. If getting the same content in different formats or languages is the purpose of having separate links, the resources are not equivalent.

Explicit Semantic Role

key: explicit-role

The explicit semantic role is the semantic role of an element set by its role attribute.

The role attribute takes a list of tokens. The explicit semantic role is the first valid role in this list. If none of the tokens are valid, the implicit semantic role will be used instead. The valid roles are all non-abstract roles from WAI-ARIA Specifications.

Other roles may be added as they become available. Not all roles will be supported in all assistive technologies. Testers are encouraged to adjust which roles are allowed according to the accessibility support base line. For the purposes of executing test cases in all rules, it should be assumed that all roles are supported by assistive technologies so that none of the roles fail due to lack of accessibility support.

Accessibility Support

Some browsers and assistive technologies treat the tokens of the role attribute as case-sensitive. Unless lowercase letters are used for the value of the role attribute, not all user agents will be able to interpret the tokens correctly. ARIA in HTML (working draft) also specifies that authors must use lowercase letters for the role and aria-* attributes.


key: filename

A filename is a text string that identifies an electronically stored file. In a URL it is located at the end of the path, after the last slash and before any query strings. For example the src attribute specifies a URL path of src="/foo/bar.jpg?baz " which contains the filename bar.jpg.

Generic placeholder text

key: generic-placeholder-text

Generic placeholder text is text content that is ambiguous in its meaning and does therefore not provide any useful information in the context in which the text is used.

Typically, generic placeholder text is inserted by authoring tools to populate content attributes that have not been specified by content authors. The text will likely be specific to the authoring tool and system language settings.

In the English language, examples of generic placeholder text used to populate the alt attribute of HTML img elements include, but is not limited to:

  • "image"
  • "spacer"
  • "picture"
  • "default"

Used In Rules (0):

No Data

Implicit Semantic Role

key: implicit-role

The Implicit Semantic Role is the semantic role of each element that is used when no valid explicit semantic role is specified. Elements with no role attribute, or with a role attribute containing no valid token, are mapped to their implicit role.

Implicit roles for HTML and SVG, are documented in the HTML accessibility API mappings (working draft), the ARIA in HTML (working draft) documentation, and the SVG accessibility API mappings (working draft).

Included in the accessibility tree

key: included-in-the-accessibility-tree

Elements included in the accessibility tree of platform specific accessibility APIs. Elements in the accessibility tree are exposed to assistive technologies, allowing users to interact with the elements in a way that meet the requirements of the individual user.

The general rules for when elements are included in the accessibility tree are defined in the core accessibility API mappings. For native markup languages, such as HTML and SVG, additional rules for when elements are included in the accessibility tree can be found in the HTML accessibility API mappings (working draft) and the SVG accessibility API mappings (working draft).

Note: Users of assistive technologies might still be able to interact with elements that are not included in the accessibility tree. An example of this is a focusable element with an aria-hidden attribute with a value of true. Such an element could still be interacted with using sequential keyboard navigation regardless of the assistive technologies used, even though the element would not be included in the accessibility tree.


Note: The examples presented here are non-normative and not testable. They serve to illustrate some common pitfalls about the definition and to help implementers of ACT rules understand it.

This span element is included in the accessibility tree (by default, elements are included in the accessibility tree).

<span>ACT rules</span>

This span element is not included in the accessibility tree because it is hidden to everybody by the CSS property.

<span style="display:none">ACT rules</span>

This span element is not included in the accessibility tree because it is explicitly removed by the aria-hidden attribute.

<span aria-hidden="true">ACT rules</span>

This span element is positioned off screen, hence is not visible, but is nonetheless included in the accessibility tree.

<span style="position: absolute; top:-9999em">ACT rules</span>

Although the span element with an id of "label" is not itself included in the accessibility tree, it still provides an accessible name to the other span, via the aria-labelledby attribute. Thus, it is still indirectly exposed to users of assistive technologies. Removing an element from the accessibility tree is not enough to remove all accessibility concerns from it since it can still be indirectly exposed.

<span id="label" style="display:none">ACT rules</span>
<span aria-labelledby="label">Accessibility Conformance Testing rules</span>

Although this input element is not included in the accessibility tree, it is still focusable, hence users of assistive technologies can still interact with it by sequential keyboard navigation. This may result in confusing situations for such users (and is in direct violation of the fourth rule of ARIA (working draft)).

<input type="text" aria-hidden="true" name="fname" />

Matching characters

key: matching-characters

A sequence of characters is considered to match another if, after removing leading and trailing space characters and replacing remaining occurrences of one or more space characters with a single space, the two sequences of characters are equal character-by-character, ignoring any differences in letter casing.

Non-streaming media element

key: non-streaming-media-element

An HTML Media Element for which the duration property is not 0.


key: outcome

A conclusion that comes from evaluating an ACT Rule on a test subject or one of its constituent test target. An outcome can be one of the three following types:

  • Inapplicable: No part of the test subject matches the applicability
  • Passed: A test target meets all expectations
  • Failed: A test target does not meet all expectations

Note: A rule has one passed or failed outcome for every test target. When there are no test targets the rule has one inapplicable outcome. This means that each test subject will have one or more outcomes.

Note: Implementations using the EARL10-Schema can express the outcome with the outcome property. In addition to passed, failed and inapplicable, EARL 1.0 also defined an incomplete outcome. While this cannot be the outcome of an ACT Rule when applied in its entirety, it often happens that rules are only partially evaluated. For example, when applicability was automated, but the expectations have to be evaluated manually. Such "interim" results can be expressed with the incomplete outcome.

Owned by

key: owned-by

An element A is owned by element B if element A is a child of element B in the accessibility tree.

Note: This definition is different from the definition of "owned element" in WAI-ARIA. Because browsers have different accessibility trees, which element owns which other elements can vary between browsers. Until there is a standard accessibility tree, testing with multiple accessibility trees may be necessary.

Used In Rules (1):

Rendered text

key: rendered-text

An element is considered to have "rendered text" when it contains text nodes that do not inherit from an element that is styled with display:none or visibility:hidden. The rendered text is a string of the concatenated text of all these text nodes.

Same resource

key: same-resource

Two or more resources can be the same resource even though the URLs for them are different. This can be due to URL parsing, server settings, redirects and DNS aliasing.

If the parsed URLs for two resources are identical, the resources are the same resource.

Depending on the server, URLs can either be case-sensitive or case-insensitive, meaning that <a href="page1.html"> and <a href="Page1.html"> lead to either the same or two different pages.

Fully parsed URLs can be different, but still lead to the same resource after making the HTTP request, due to redirects and DNS aliasing. For example, these URLs are all fully normalized:,, The server can however be configured to serve the same site for http and https, and the same site for and This is common, but not guaranteed.

Some types of redirects are also caused by user agents, e.g. ensuring that and resolve to the same resource.

On the other hand, identical relative URLs do not necessarily resolve to the same resource, even if they are in the same web page (HTML). This happen because external content can be included through iframe and URLs in or out of it will resolve relatively to different base URLs.

Section of content

key: section-of-content

A distinct part or subdivision of a document.

A section of content may consist of one or more paragraphs and include graphics, tables, lists and sub-sections that together serve a purpose.

A section of the content may be defined in different ways, and combinations of these, such as:

  • HTML markup, using WAI-ARIA landmarks or HTML5 sectioning elements.
  • A heading that marks the beginning of the section of content.

Used In Rules (1):

Semantic Role

key: semantic-role

A semantic role is a semantic association that indicates an object's type. This allows tools to present and support interaction with the object in a manner that is consistent with user expectations about other objects of that type.

The semantic role of an element is its explicit semantic role if it has any, otherwise, the implicit semantic role is used.

Standard keyboard navigation

key: standard-keyboard-navigation

Standard keyboard navigation entails using one or more of the following:

  • Tab key
  • Shift+Tab
  • Arrow keys
  • Esc key
  • Enter key
  • Space key

Expected behavior of standard keyboard navigation keys:

  • Tab key: Skipping forward between focusable elements
  • Shift+Tab: Skipping backwards between focusable elements
  • Arrow keys: Navigate input elements, e.g. up/down drop down, between radio buttons etc.
  • Esc key: Close or cancel, e.g close a modal
  • Enter key: Select or activate the element in focus (same as clicking with mouse)
  • Space key: Select input elements, e.g. drop downs, radio buttons etc.

Text content

key: text-content

The textual content is a concatenated string of all text nodes within an element and all textual alternatives within an element. This includes all the rendered text as well as the text alternative returned by the Text Alternative Computation of all img elements that are not set to role=presentation. The strings are to be concatenated in the order in which they appear in the DOM tree.

Used In Rules (0):

No Data


key: visible

Content perceivable through sight.

Content is considered visible if making it fully transparent would result in a difference in the pixels rendered for any part of the document that is currently within the viewport or can be brought into the viewport via scrolling.

Content is defined in WCAG.


Note: The examples presented here are non-normative and not testable. They serve to illustrate some common pitfalls about the definition and to help the implementers of ACT rules understand it.

This span element is visible (by default, elements are visible).

<span>Now you can see me!</span>

This span element is not visible because of the CSS visibility property.

<span style="visibility: hidden">I'm the invisible man</span>

This span element is not visible because of the CSS display property.

<span style="display: none">I'm the invisible man</span>

This span element is not visible because it is positioned off-screen

<span style="position: absolute; top: -9999px; left: -9999px;">Incredible how you can</span>

This span element is not visible because it contains only whitespace and line breaks.

	<br />

This span element is not visible because it has the exact same color as its background.

<span style="color: #00F; background: #00F;">See right through me</span>

Visual Output

key: visual-output

This test aspect includes all visual data output from the web page onto a graphic display.

Used In Rules (0):

No Data

WAI-ARIA specifications

key: wai-aria-specifications

The WAI ARIA Specifications group both the WAI ARIA W3C Recommendation and ARIA modules, namely:

Note: depending on the type of content being evaluated, part of the specifications might be irrelevant and should be ignored.

Web page (HTML)

key: web-page-html

An HTML web page is the set of all fully active documents which share the same top-level browsing context.

Note: Nesting of browsing context mostly happens with iframe and object. Thus a web page will most of the time be a "top-level" document and all its iframe and object (recursively).

Note: Web pages as defined by WCAG are not restricted to the HTML technology but can also include, e.g., PDF or DOCX documents.

Note: Although web pages as defined here are sets of documents (and do not contain other kind of nodes), one can abusively write that any node is "in a web page" if it is a shadow-including descendant of a document that is part of that web page.


key: whitespace

Characters that have the Unicode "White_Space" property in the Unicode properties list.

This includes:

  • all characters in the Unicode Separator categories, and
  • the following characters in the Other, Control category:

    • Character tabulation (U+0009)
    • Line Feed (LF) (U+000A)
    • Line Tabulation (U+000B)
    • Form Feed (FF) (U+000C)
    • Carriage Return (CR) (U+000D)
    • Next Line (NEL) (U+0085)