ANDI

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

This help page explains the conditions that cause Alerts to appear, the reason why they appear, and how to fix or further investigate the issue.

No, not always. It's up to a human to evaluate ANDI's results and make the final decision on whether or not there is an accessibility issue. ANDI is merely an inspection tool used for this purpose.

• Form Element has no accessible name, associated label, or title.

Why did ANDI alert this?

This form element has no HTML markup that would provide an accessible name for the element.

Why is this an accessibility concern?

A screen reader would either read nothing for this form element or may make a guess. A user with a vision disability will not know what information to enter into this form field.

What should be done?

Add HTML markup that will provide an accessible name for the form element.

After making coding changes to provide a name for the form element, test the changes by launching ANDI and reading the updated ANDI Output.

• Element has no accessible name.

Why did ANDI alert this?

This element has no HTML markup that would provide an accessible name for the element.

Why is this an accessibility concern?

A screen reader would either read nothing for this element or may make a guess. A user with a vision disability will not hear the information about this element.

What should be done?

Add HTML markup that will provide an accessible name for the element.

After making coding changes to provide an accessible name for the element, test the changes by launching ANDI and reading the updated ANDI Output.

• Image has no accessible name, alt, or title.

Why did ANDI alert this?

This image element has no HTML markup that would provide an accessible name for the element.

Why is this an accessibility concern?

A screen reader would either read nothing for this element or may make a guess. A user with a vision disability will not know if the image is meaningful.

What should be done?

Determine if the image is meaningful or decorative.

If the image is meaningful, add HTML markup that will provide an accessible name (alternative text) for the image.

If the image is decorative, add HTML markup that will communicate to a screen reader that the image is not meaningful and can be ignored.

After making coding changes to provide an accessible name for the element, test the changes by launching ANDI and reading the updated ANDI Output.

• Table has no accessible name, caption, or title.

Why did ANDI alert this?

This table element has no HTML markup that would provide an accessible name for the table.

Why is this an accessibility concern?

A screen reader user often has the capability to preview a list of data tables on the page. If data tables aren't named, then the user is forced to spend more time determining the meaning of each table. This greatly decreases efficiency for users with vision disabilities when multiple tables exist on the page.

What should be done?

Determine if the table is a true data table or if the html table structure is being used for layout and alignment purposes.

If it is a data table, add HTML markup that will provide an accessible name that summarizes the data table.

If it is not a data table, add HTML markup that will communicate to a screen reader that the html table markup should be ignored and considered to be non-semantic containers used for layout purposes.

After making the appropriate coding changes test the changes by relaunching ANDI.

• Figure has no accessible name, figcaption, or title.

Why did ANDI alert this?

This <figure> element has no HTML markup that would provide an accessible name for the element.

Why is this an accessibility concern?

A screen reader would either read nothing for this element or may make a guess. A user with a vision disability will not know the meaning of the figure.

What should be done?

Add HTML markup that will provide an accessible name (alternative text) for the figure.

After making coding changes to provide an accessible name for the figure, test the changes by launching ANDI and reading the updated ANDI Output.

• Iframe has no accessible name or [title].

Why did ANDI alert this?

This iframe element has no HTML markup that would provide an accessible name for the element.

Why is this an accessibility concern?

A screen reader user often has the capability to preview a list of iframes on the page. If the iframes aren't named, then the user must find another way to determine which iframe is which. This greatly decreases efficiency for users with vision disabilities when multiple iframes exist on the page.

What should be done?

Add HTML markup to provide an accessible name for any iframe that contains content presented to the user.

After making coding changes to provide an accessible name for the iframe, test the changes by launching ANDI and reading the updated ANDI Output.

• [%%%] is referencing a duplicate id [id=%%%]; Element ids should be unique.
• Element has a duplicate id and is referenced by a <label[for]>; Element ids should be unique.

Why did ANDI alert this?

This element has an accessibility component that is referencing a duplicate id.

Why is this an accessibility concern?

It is an HTML requirement that element id values must be unique. Some accessibility components reference other elements by their id. If ids are the same (duplicated) among several elements, an element may be referencing the wrong element, and the screen reader output may not be correct.

Accessibility Components that use id references are: aria-labelledby, aria-describedby, table cell headers, the for attribute of a <label>, and many other aria-* attributes.

In addition to accessibility concerns, when ids are not unique there may be JavaScript event issues if the duplicate ids are referenced by the beloved JavaScript method getElementById.

What causes this?

Often, this is the result of a developer copying and pasting an element and forgetting to change the id. It's possible that a developer may not know that ids must be unique according to W3C standards.

What should be done?

The value of each id on the page should be made unique.

• More than one <label[for=%%%]> associates with this element [id=%%%].

Why did ANDI alert this?

This element is associated with a <label> whose for attribute value matches the value of another label's for attribute. i.e. a "duplicate for".

Why is this an accessibility concern?

When a screen reader is trying to make an associate between a form element and a label, if there are multiple label's with the same for value, a screen reader might read the label that was not intended to be associated with the element. W3C specifications do not explicitly state that duplicate for attributes should not be used, however screen readers do not support such usage.

What causes this?

Often, this is the result of a developer copying and pasting a label and forgetting to change the value of the for attribute on the pasted label.

What should be done?

Ensure that the for attributes are unique, and correctly pointing to the id of the associating form element.

If the concatenation of the text of multiple labels is the intention, then use the aria-labelledby attribute whose value is a space delimited list of ids which point to the ids of the labels.

• [aria-describedby] should be used in combination with a component that provides an accessible name.

Why did ANDI alert this?

The only HTML markup found on the element that provides accessibility information is the aria-describedby attribute.

Why is this an accessibility concern?

Screen readers expect an accessible name to be provided when aria-describedby is used. If there is no name, a screen reader might fail and read irrelevant text or make a guess.

What should be done?

One option is to simply use aria-labelledby instead of aria-describedby. Another option is to provide an accessible name along with the aria-describedby by adding an aria-labelledby, aria-label, or other element-specific "Namer".

• <legend> should be used in combination with a component that provides an accessible name.

Why did ANDI alert this?

This type of element, can make use of the <legend> tag, however <legend> should not be used as the only means of which to name or describe an element.

Why is this an accessibility concern?

For all elements except a fieldset, legend does not technically provide a name. When used alone, screen readers may not read correctly or may double speak.

What should be done?

If a <legend> tag is being used to describe a group of form elements, the best practice to name each individual form element is to add a <label> tag associated with the form element (<label for="id">) or contain the form element within a label.

• [aria-labeledby] is misspelled, use [aria-labelledby].

Why did ANDI alert this?

The element contains a typo or misspelling of an ARIA attribute.

Why is this an accessibility concern?

Most screen readers do not check for attribute misspellings or attempt to interpret syntax errors. Therefore, the misspelled ARIA attributes will not provide the intended accessibility information.

What should be done?

The misspelling should be corrected since a developer explicitly attempted to add additional accessibility information.

ANDI checks for the following misspellings:

• [aria-role] not a valid attribute, use [role] instead.

Why did ANDI alert this?

The element contains an attribute that does not exist: aria-role.

Why is this an accessibility concern?

Most screen readers do not check for attribute misspellings or attempt to interpret syntax errors. Therefore, aria-role will not provide the intended accessibility information.

What should be done?

Most likely, the attribute role was intended to be used on this element.

• [role=image] is invalid; Use [role=img].

Why did ANDI alert this?

This element has a role attribute with a value of "image".

Why is this an accessibility concern?

"image" is not a valid value for role. A screen reader will not recognize this element as an image.

What should be done?

Change the value to "img", as in role="img" so that the screen reader will recognize the element as an image.

• '%%%' is an unsupported value for [role].

Why did ANDI alert this?

This element's role attribute contains a value that is not present in the Core Accessibility API Role Mapping Table.

Why is this an accessibility concern?

Assistive Technology will not be able to communicate the semantics of the element because the role value is, essentially, not supported.

What should be done?

Change the role value to one in the Core Accessibility API Role Mapping Table.

• Element has multiple roles. Determine if sequence is acceptable.

Why did ANDI alert this?

This element's role attribute contains more than one value. For example, role="link presentation"

Why is this an accessibility concern?

Assistive Technology will attempt to use the first value in the sequence. If it doesn't recognize or support the first value, it will attempt to use the next value in the sequence. And so on.

What should be done?

Ensure that the values provided in the list of values are acceptible for the application, and that the sequence is intentional. As a best practice, and for the broadest support, the role attribute should contain a single value, not a list.

• Scope attribute value [scope=%%%] is invalid.

Why did ANDI alert this?

ANDI's Table Analysis Mode is set to "scope" and this element has a scope attribute but the value is invalid.

If scope associations are not appropriate for this table's design, change the Table Analysis Mode to "headers".
How to choose the right Table Analysis Mode

Why is this an accessibility concern?

A screen reader will not make the correct cell associations if the value is invalid.

What should be done?

Change the value of the scope attribute to col, row, colgroup, or rowgroup.

• [headers] attribute only valid on <th> or <td>.

Why did ANDI alert this?

ANDI's Table Analysis Mode is set to "headers" and this element has a headers attribute but is not a <td> or <th>

If headers associations are not appropriate for this table's design, change the Table Analysis Mode to "scope".
How to choose the right Table Analysis Mode

Why is this an accessibility concern?

A screen reader will not make the intended cell associations.

What should be done?

Move the headers attribute to a table cell such as a <td> or <th> and ensure that the reference id is pointing to the correct <th>.

• Table has no <th> cells.

Why did ANDI alert this?

This table doesn't have any <th> cells.

Why is this an accessibility concern?

A data table should have <th> cells so that a screen reader can associate header cells with the data cells.

What should be done?

If the table is a "presentation" table used for layout instead of data, then role="presentation" should be added to the <table> and no <th> tags should be used.

Otherwise, if the table is intended to provide data, use <th> cells to make the header associations. In addition, for accessibility, table headers must have additional markup to make the associations: scope or headers/id. More information here: How to make data table cell associations.

• Table using both [scope] and [headers], may cause screen reader issues.

Why did ANDI alert this?

This table has cells using both scope attributes and headers/id.

Why is this an accessibility concern?

A screen reader may not correctly associate the cells since it has to account for both scope and headers/id. If modifications are made to this table in the future, the associations may become broken and its accessibility would suffer.

What should be done?

As a best practice, choose one cell association method appropriate for the table design: either scope or headers/id. More information here: How to make data table cell associations.

• Table has no [headers/id] associations.

Why did ANDI alert this?

ANDI's Table Analysis Mode is set to "headers" and This table has no headers/id associations.

If headers associations are not appropriate for this table's design, change the Table Analysis Mode to "scope".
How to choose the right Table Analysis Mode

Why is this an accessibility concern?

A screen reader may not correctly associate header cells to the data cells.

What should be done?

Tables must make header cell associations using either headers/id or scope. If applicable for this table, add id attributes to the <th> cells and headers attributes to the <td> cells which point at the id of their associated <th>. More information here: How to make data table cell associations.

• Table has no [scope] but does have [headers], switch to 'headers/id mode'.
• Table has no [headers/id] but does have [scope], switch to 'scope mode'.

Why did ANDI alert this?

ANDI is suggesting that the user test the table in the other Table Analysis Mode because it has detected accessibility markup for the other mode.

What should be done?

Change the Table Analysis Mode and determine if the table is accessible. How to choose the right Table Analysis Mode

• Scope association needed at intersection of <th>.

Why did ANDI alert this?

This table contains column or row headers (<th>) that intersect. One or more <th> at the "intersection" positions are missing a required scope attribute.

Why is this an accessibility concern?

When a <th> cell is positioned at an "intersection" of table headers a screen reader may not be able to correctly assume the direction in which the <th> points.

What should be done?

To all <th> cells at table header intersections, add a scope attribute with a value that indicates the direction in which the cell points. (scope="col" or scope="row").

• ARIA table has no [role=cell] cells.
• ARIA grid has no [role=gridcell] cells.
• ARIA table/grid has no [role=columnheader] or [role=rowheader] cells.
• ARIA table/grid has no [role=row] rows.

Why did ANDI alert this?

This page has a tabular structure built using an ARIA table or ARIA grid design pattern, but there is an issue with the structure.

Why is this an accessibility concern?

A user who is visually impaired and relying on a screen reader will not be able to fully navigate the ARIA table or ARIA grid when the proper structure is not in place.

What should be done?

Correct the structure to abide by the standards for an ARIA table, or ARIA grid.

• Table has no <th> or <td> cells.

Why did ANDI alert this?

This table has no <th> cells or <td> cells.

Why is this an accessibility concern?

If this table has no cells, is it really a data table? Users with a vision disability who use a screen reader may not understand how to navigate this table.

What should be done?

If the <table> element is a data table, it should contain <th> and <td> element. If the <table> element does not contain tabular data and is instead used for structural layout, it should have role="presentation". If the <table> element is a placeholder container for dynamically propagating table data (using JavaScript to dynamically inject the data), then ignore this alert.

• Table has more than %%% levels of [scope=%%%].

Why did ANDI alert this?

ANDI's Table Analysis Mode is set to "scope" and this table has cells using the scope attribute but there are more than two "levels".

If scope associations are not appropriate for this table's design, change the Table Analysis Mode to "headers".
How to choose the right Table Analysis Mode

Why is this an accessibility concern?

A screen reader may not associate all header cells intended.

What should be done?

There are several remediation options:

More information here: How to make data table cell associations

• Presentation table has data table markup (%%%); Is this a data table?

Why did ANDI alert this?

This layout table, marked with role="presentation", has HTML markup reserved for data tables.

Why is this an accessibility concern?

A screen reader may see the data table markup, and make cell associations or add verbosity to the elements within the presentation table.

What should be done?

For this presentation table, remove HTML markup intended for data tables.

• <table> with [role=%%%] is not recognized as a data table.

Why did ANDI alert this?

This table has a role with a value that is not presentation, none, table, grid, or treegrid.

Why is this an accessibility concern?

An element's role overrides the semantics of the tagname. This means a screen reader only considers the role value and does not recognize that the element's tagname is <table>.

What should be done?

If this <table> element looks like a data table (contains cells with organized data), then it should have either no role or a role that signifies a data table such as role="table".

If the table is primarily used for presentation/layout, then the role should be role="presentation".

Otherwise, test the element according to the role.

• <table[role=%%%]> has <th> cells missing columnheader or rowheader role.

Why did ANDI alert this?

This <table> has an ARIA role of table|grid|treegrid and contains <th> cells that don't have the role of columnheader or rowheader.

Why is this an accessibility concern?

A screen reader may not make the correct cell to header associations when native html is mixed with ARIA.

What should be done?

Within an ARIA table, the role of each header cell should be explicitly defined. Ensure that each header cell has a role attribute with the value of columnheader or rowheader.

Furthermore, each data cell should have a role attribute with the value of cell or gridcell.

• <table[role=%%%]> has cells not contained by [role=row].

Why did ANDI alert this?

This [role=table] or [role=grid] element has [role=cell] or [role=gridcell] cells that are not contained by an element with [role=row].

Why is this an accessibility concern?

A screen reader user may skip these cells while navigating this table/grid since they are not programmatically part of the table.

What should be done?

Adjust the structure of this table or grid so that each cell is contained by a row (an element with [role=row]).

Example:
<div role="table" aria-label="Fruit Inventory">
 <div role="row">
  <div role="cell"> Apples </div>
  <div role="cell"> Oranges </div>
 </div>
...
</div>

• Table has no [scope] associations.

Why did ANDI alert this?

ANDI's Table Analysis Mode is set to "scope" and this table has no scope attributes.

If scope associations are not appropriate for this table's design, change the Table Analysis Mode to "headers".
How to choose the right Table Analysis Mode

Why is this an accessibility concern?

A screen reader may not correctly associate header cells to the data cells.

What should be done?

Tables must make header cell associations using additional markup. If applicable for this table design, add scope attributes to the <th> cells using the appropriate values: col, row, colgroup, or rowgroup. More information here: How to make data table cell associations.

• [accessKey] value "%%%" has more than one character.

Why did ANDI alert this?

An accesskey with more than one character as its value was found on this element.

Why is this an accessibility concern?

Multi-character accesskeys do not work in any browser. Some browsers support space delimited values, but such use is not a recommended practice.

What should be done?

Set the accesskey value to use only one character.

• Duplicate [accessKey=%%%] found on button.
• Duplicate [accessKey=%%%] found on link.

• Duplicate [accessKey=%%%] found.

Why did ANDI alert this?

This element has an accesskey attribute that matched another element's accesskey.

Why is this an accessibility concern?

The accesskey functionality may not work as intended. Accesskeys on buttons and links must be unique. Some browsers allow for a "focus jump" functionality when duplicate accesskeys are placed on elements that aren't links and buttons. However, when a shared accesskey is placed on links or buttons, usually only the first button or link will be selected.

What should be done?

As a best practice, make each accesskey unique. If multiple buttons or links share the same function, put the accesskey on only one.

• Element referenced by [%%%] with [id=%%%] not found.

Why did ANDI alert this?

This element has an aria-labelledby or aria-describedby that points to an id that cannot be found on the page.

Why is this an accessibility concern?

Important accessibility information might be missing. Screen readers will not notify a user that the id could not be found.

What causes this?

This may be due to one of these reasons:

What should be done?

Deeper investigation of the code is needed.

Attributes aria-labelledby and aria-describedby should only contain id references, not text directly inserted into the attribute's value. Example:

When multiple ids are used, they should be space delimited, not comma delimited. Example:

• Improper use of [aria-labelledby] possible: Referenced ids "%%%" not found.
• Improper use of [aria-describedby] possible: Referenced ids "%%%" not found.
• Improper use of [headers] possible: Referenced ids "%%%" not found.

Why did ANDI alert this?

More than one id referenced by an aria-labelledby, aria-describedby, or cell headers cannot be found on the page. ANDI suggests that the attribute is not being used properly.

Why is this an accessibility concern?

Important accessibility information might be missing. Screen readers will not notify a user when the id references cannot be found.

What causes this?

This is typically caused by the developer not understanding that aria-labelledby, aria-describedby, headers values are meant to contain id references and literal text was mistakenly added directly into the attribute's value. Another possibility is that a developer may have intended to reference elements that were later removed or the id values were changed.

What should be done?

Ensure that the attribute is being used properly: A list of id references only and not literal text.

• Element referenced by [headers] attribute with [id=%%%] is not a <th>.

Why did ANDI alert this?

ANDI's Table Analysis Mode is set to "headers" and this cell is referencing an element that is not a <th>.

If headers associations are not appropriate for this table's design, change the Table Analysis Mode to "scope".
How to choose the right Table Analysis Mode

Why is this an accessibility concern?

A screen reader will not make the intended cell association.

What should be done?

The headers attribute should reference the id of a <th>.

• <img> referenced by image map %%% not found.

Why did ANDI alert this?

ANDI found an image map (<map>) that references an (<img>) that does not exist on the page.

Why is this an accessibility concern?

The image map will not work for all users.

What should be done?

Ensure that the name attribute of the <map> points to an <img> that has a matching usemap.

• [%%%] is referencing a legend which may cause speech verbosity.

Why did ANDI alert this?

This element has an aria-labelledby or aria-describedby attribute that is referencing a <legend> element.

Why is this an accessibility concern?

This arrangement may cause speech verbosity; the text within the <legend> may be read more than once by a screen reader.

What should be done?

Either remove the reference to the <legend> from the aria-labelledby/aria-describedby or change the <legend> to a generic tag that carries no semantics such as <strong>.

• [%%%] reference contains another [%%%] reference which won't be used for this Output.

Why did ANDI alert this?

This element has an aria-labelledby|aria-describedby that is referencing an element that has an aria-labelledby|aria-describedby or contains an element that has an aria-labelledby|aria-describedby.

Why is this an accessibility concern?

While this arrangement should not directly cause an accessibility issue, the output may not be as expected. When traversing an aria-labelledby|aria-describedby reference, subsequent aria-labelledby|aria-describedby references will not be followed to prevent the possibility of causing an infinite loop while trying to calculate the accessible name/description.

What should be done?

Ensure that this element's output is as expected.

• [%%%] is directly referencing [id=%%%] multiple times which may cause speech verbosity.

Why did ANDI alert this?

This element has an aria-labelledby or aria-describedby that is referencing the same element more than once.

Why is this an accessibility concern?

This will directly cause speech verbosity because the referenced element will be read each time it is referenced.

What should be done?

It's rare that listing the same id multiple times in an ARIA reference is intentional. Most likely it is a copy/paste coding error. Ensure that the output is as expected, and remove any unintended duplicated id references in the element's aria-labelledby or aria-describedby attributes.

• [%%%] is directly and indirectly referencing [id=%%%] which may cause speech verbosity.

Why did ANDI alert this?

This element has an aria-labelledby or aria-describedby that is referencing an element both directly and indirectly. Directly because the referenced element's id is in the id reference list. Indirectly because the element is contained by an element that is being directly referenced.

Why is this an accessibility concern?

This may cause speech verbosity because the referenced element may be read more than once.

What should be done?

Ensure that any referenced elements that are not contained by other referenced elements.

• Element's [headers] references provide no association text.

Why did ANDI alert this?

ANDI's Table Analysis Mode is set to "headers" and this cell is using a headers attribute but the elements it references do not provide header cell association text.

If headers associations are not appropriate for this table's design, change the Table Analysis Mode to "scope".
How to choose the right Table Analysis Mode

Why is this an accessibility concern?

A screen reader will not communicate the intended header cell associations.

What causes this?

The referenced cell has no HTML markup that would provide text such as innerHTML.

What should be done?

Either modify the referenced elements by adding text contents, or point the headers at the id of a different element that does provide text.

• In-page anchor target with [id=%%%] not found.

Why did ANDI alert this?

This link's href points to the id of an element on the page that cannot be found. NOTE: ANDI should not throw this alert if a JavaScript "click event handler" is attached to this link.

Why is this an accessibility concern?

If this link is intended to be used as an in-page jump, or skip to content link, it may not function as intended.

What should be done?

Testers should click on the link to discover if the link is functional as an in-page jump/bookmark. If the link has no function, add the element with the id to the page or remove the link. Further evaluation or a discussion with the web author may be needed to determine the purpose of this link.

• [headers] attribute is referencing a <td> with [id=%%%].

Why did ANDI alert this?

ANDI's Table Analysis Mode is set to "headers" and this cell is referencing an element that is a <td>.

If headers associations are not appropriate for this table's design, change the Table Analysis Mode to "scope".
How to choose the right Table Analysis Mode

Why is this an accessibility concern?

A screen reader may not make the intended cell association.

What should be done?

The headers attribute should reference the id of a <th>. The web author may be able to simply convert the <td> into a <th>

• [headers] attribute is referencing an element [id=%%%] external to its own table.

Why did ANDI alert this?

This table cell has a headers attribute which is referencing the id of an element that is not in the same table.

Why is this an accessibility concern?

A screen reader most likely will not make this header association because a headers attribute should only reference <th> cells in the same table.

What should be done?

Ensure that all headers attributes are referencing <th> cells in the same table.

• Element nested in <label> but label[for=%%%] does not match element [id=%%%].

Why did ANDI alert this?

This element is nested within a <label> that has a for attribute that does not match the element's id.

Why is this an accessibility concern?

A screen reader may not announce the correct label for this element or another element, which may cause a user with a vision disability to enter information in the wrong place.

What should be done?

A form element should be associated with its <label> explicitly (for/id match) and/or implicitly (nesting the element inside the label). In this instance, the element is nested inside its <label> which establishes a programmatic association, however, the label's for attribute does not match the id of the form element. This mismatch may break the programmatic association, or cause an incorrect association with a different element.

Ensure that the label's for attribute matches the id of the form element.

• Page <title> cannot be empty.

Why did ANDI alert this?

A <title> tag was found in the page's <head> but the contents were empty.

Why is this an accessibility concern?

A screen reader would not read a concise, logical title for the page, and would instead read the url.

What should be done?

Add text contents to the <title> tag in the page's <head>.

• Page has no <title>.

Why did ANDI alert this?

A <title> tag could not be found in the page's <head> or the document.title was not set.

Why is this an accessibility concern?

A screen reader would not read a concise, logical title for the page, and would instead read the url.

What should be done?

Add a <title> tag in the page's <head>.

• Page has more than one <title> tag.

Why did ANDI alert this?

More than one <title> tag was found in the page's <head>.

Why is this an accessibility concern?

A screen reader will not read both <title> tags. Therefore, if any important information is in another <title>, that information may not be spoken.

What should be done?

To prevent any likelihood of an accessibility issue, ensure that there is only one <title> and that title is in the <head>. Use ANDI (Structures), "page title" to view the actual page title; determine if the title is sufficient.

• There are more legends (%%%) than fieldsets (%%%).

Why did ANDI alert this?

More <legend> tags were found on the page than <fieldset> tags.

What causes this?

A <legend> could have been placed on the page without being contained in a <fieldset>. Another possibility is that more than one <legend> could have been placed in a <fieldset>.

Why is this an accessibility concern?

<legend> tags serve no semantic purpose outside of a <fieldset>. Moreover, each <fieldset> should contain only one <legend>. Either of these scenarios could signify that a developer did not add proper markup to the page, and therefore the accessible name and descriptions of the form elements could be semantically incorrect.

What should be done?

Ensure that this page's <legend> tags are contained within a <fieldset> and are at a 1:1 ratio. Remember that a <legend> only describes a group of form elements; each form element must have an explicit label to provide an accessible name.

• There are more figcaptions (%%%) than figures (%%%).

Why did ANDI alert this?

More <figcaption> tags were found on the page than <figure> tags.

What causes this?

A <figcaption> could have been placed on the page without being contained in a <figure>. Another possibility is that more than one <figcaption> could have been placed in a <figure>.

Why is this an accessibility concern?

<figcaption> tags serve no semantic purpose outside of a <figure>. Moreover, each <figure> should contain only one <figcaption>. Either of these scenarios could signify that a developer did not add proper markup to the page, and therefore the accessible name and description of elements could be semantically incorrect.

What should be done?

Ensure that each of this page's <figcaption> tags are contained within a <figure> and are at a 1:1 ratio. Remember that a <figcaption> names a <figure> and by default does not name or describe other elements contained within the figure. If an element within the figure should be named or described by the <figcaption>, point an aria-labelledby or aria-describedby at the <figcaption>.

• There are more captions (%%%) than tables (%%%).

Why did ANDI alert this?

More <caption> tags were found on the page than <table> tags.

What causes this?

A <caption> could have been placed on the page without being contained in a <table>. Another possibility is that more than one <caption> could have been placed in a <table>.

Why is this an accessibility concern?

<caption> tags serve no semantic purpose outside of a <table>. Moreover, each <table> should contain only one <caption>. Either of these scenarios could signify that a developer did not add proper markup to the page, and therefore the accessible name and description of elements could be semantically incorrect.

What should be done?

Ensure that each of this page's <caption> tags are contained within a <table> and are at a 1:1 ratio.

• Tabindex value "%%%" is not a number.

Why did ANDI alert this?

An element was found on the page with a non-numeric value for the tabindex attribute.

Why is this an accessibility concern?

Browser behavior is inconsistent in this scenario. Some browsers will replace the value with a negative tabindex, others will not change the value. Regardless, a keyboard user will not be able to place focus on such an element.

What should be done?

Ensure that the value of the tabindex attribute is a numeric, positive or negative integer. Remember that only positive values allow for keyboard focus using the tab key. Negative values are meant for programmatically controlling focus with JavaScript.

• List item <li> is not contained by a list container <ol> or <ul>.

Why did ANDI alert this?

This list item (<li>) is not contained by a list container tag (<ol> or <ul>).

Why is this an accessibility concern?

Since the list item tag carries a semantic meaning, it should be contained within a list container.

What should be done?

If the list item (<li>) is meant to be part of a list, contain it within a list container tag (<ol> or <ul>). Otherwise, use a different tag for the item such as <strong>, <em>, or <span>.

• Description list item is not contained by a description list container <dl>.

Why did ANDI alert this?

This description list item (<dd> or <dt>) is not contained by a description list container tag (<dl>).

Why is this an accessibility concern?

Since the description list item tags carry semantic meaning, they should be contained within a description list container.

What should be done?

If the description list item (<dd> or <dt>) is meant to be part of a description list, contain it within a description list container tag (<dl>). Otherwise, use a different tag for the item such as <strong>, <em>, or <span>.

• Using HTML5, found deprecated {attribute/tag}

Why did ANDI alert this?

ANDI detected an HTML5 doctype and the presence of a deprecated attribute or tag. A deprecated attribute or tag means it’s being phased out and there are better, more flexible alternatives.

ANDI will throw this Alert when it finds:

Why is this an accessibility concern?

Screen readers may not support deprecated HTML.

What should be done?

Abide by the specifications of the doctype being used.

With HTML5,

• [scope=%%%] value is invalid; acceptable values are col, row, colgroup, or rowgroup.

Why did ANDI alert this?

This element has a scope attribute with a value that is invalid.

Why is this an accessibility concern?

A screen reader may not make the correct header to cell associations within this data table.

What should be done?

Ensure that all scope attributes have valid values. Valid values for the scope attribute are:

Note that scope="column" is invalid. The scope attribute should be used with <th> elements only.

• This <a> element has [name=%%%] which is a deprecated way of making an anchor target; use [id].

Why did ANDI alert this?

This <a> element is the anchor target of an in-page link. It is using the name attribute, which is deprecated, instead of the id attribute.

Why is this an accessibility concern?

Since the name attribute has been deprecated for <a> elements, future browsers may not support this as a valid technique. Therefore, this page's accessibility could be impacted in the future if the in-page link targeting this anchor doesn't function as expected.

What should be done?

Replace the name attribute on the anchor target with an id attribute.

• [alt] attribute is meant for <img> elements.

Why did ANDI alert this?

This element has an alt attribute and is not an image: <img>, <input[type=image]>, or <area>.

Why is this an accessibility concern?

Not all screen readers will announce the alt attribute for non-image elements. Therefore, some accessibility information that was intentionally added in the alt value may not be spoken.

What should be done?

Do not use the alt attribute for non-images. Instead use the global attribute aria-label to provide an accessible name or title to provide an accessible description.

• Explicit <label[for]> only works with form elements.

Why did ANDI alert this?

The for attribute of a <label> is pointing to the id of this element which is not a form element. A form label must be associated with a control.

Why is this an accessibility concern?

Some screen readers will not announce an explicit label on non-form elements. Therefore, the associating <label> may not be read as part of the accessible name of this element.

What should be done?

This element does not derive its accessible name from <label>. Consider using aria-label or aria-labelledby on the element.

• Combining %%% may produce inconsistent screen reader results.

Why did ANDI alert this?

This element contains multiple accessibility components which ANDI's "One Namer, One Describer" methodology discourages.

Why is this an accessibility concern?

When elements have multiple Namers or multiple Describers, screen reader precedence differs wildly. To minimize these differences and ensure consistent screen reader output, follow ANDI's methodology.

What should be done?

Only one Namer should be used at a time. Only one Describer should be used at a time.

ANDI defines the following components as Namers. Choose one:

ANDI defines the following components as Describers. Choose one:

• JavaScript event %%% may cause keyboard accessibility issues; investigate.

Why did ANDI alert this?

This element has a JavaScript event. Events ANDI scans for: onBlur, onChange, onDblClick

Why is this an accessibility concern?

The presence of JavaScript events does not mean there is a definite accessibility issue. However, depending on what the JavaScript event was programmed to do, an accessibility issue could exist. Examples:

What should be done?

Test the element to ensure that the JavaScript events do not cause accessibility issues such as focus loss or confusion, keyboard traps, or dynamic screen changes without notification.

• Image defined as decorative is in the keyboard tab order.

Why did ANDI alert this?

This image contains a programmatic contradiction: it was defined as decorative using role="presentation" or alt="", but it has a non-negative tabindex which places it in the keyboard tab order.

Why is this an accessibility concern?

When tabbing to this decorative image, a screen reader may read nothing or may read incorrectly.

What should be done?

Decorative Images should not be in the tab order, therefore, remove the tabindex. If the image is not decorative, include a text description of the image using the alt attribute. In general, images do not have to be in the keyboard tab order.

• Element with [role=%%%] not in the keyboard tab order.

Why did ANDI alert this?

This element has a role attribute with a value that tells a screen reader that the element is interactive (example: role="link", role="button") but it cannot be navigated to using the keyboard tab key.

Why is this an accessibility concern?

An individual that does not use a mouse (whether by necessity or choice) uses the tab key as the primary means of navigating a page. Keyboard-only users expect most interactive elements (links, buttons, form elements) to be in the tab order since that is the standard behavior for these types of elements. When an HTML element is defined as an interactive element using the role attribute, additional handling often needs to be added to ensure that the interactive element is accessible to keyboard users.

What should be done?

If this element should be in the tab order, add tabindex="0" to the element. Otherwise, if navigation to the element is handled by other means (such as arrow keys), test to ensure that the element can be accessed using only a keyboard. In addition, links and buttons should be able to be activated using only a keyboard (enter key for links), (spacebar and enter key for buttons).

Alternatively, use semantic HTML tags (<a>,<button>) instead of generic tags with a role attribute (<div role="link">,<div role="button">) and the browser will automatically handle most keyboard accessibility requirements.

• Focusable element is not in keyboard tab order; should it be tabbable?

Why did ANDI alert this?

This element has a tabindex value that is negative. A negative tabindex is not always an accessibility issue, but you'll need to do some manual inspection of this element.

Why is this an accessibility concern?

Elements with negative tabindex values cannot receive focus using the keyboard's tab key. Users who cannot use a mouse due to a disability and users who prefer a keyboard use the tab key as a primary means of navigation. Keyboard users may not be able to access elements which are not in the tab order.

What should be done?

Some manual inspection of the element is needed. Test for keyboard operability. Ensure that the functionality of this element is not restricted to mouse users only. If the element should be in the tab order, an easy way to do so is to change the tabindex value to zero (tabindex="0").

• Focusable element is not in keyboard tab order and has no accessible name; should it be tabbable?

Why did ANDI alert this?

This element has a tabindex value that is negative and it has no accessible name.

Why is this an accessibility concern?

Elements with negative tabindex values cannot achieve focus using the keyboard's tab key. However, focus can be placed on such elements programmatically using JavaScript. Also, elements must have an accessible name.

What should be done?

Ensure that not being able to tab to the element is acceptable and related functionality is not restricted to mouse use only. Also ensure that when focus is shifted to the element, a proper accessible name is provided.

• Iframe contents are not in keyboard tab order because iframe has negative tabindex.

Why did ANDI alert this?

This iframe element has a tabindex value that is negative (such as tabindex="-1") and it contains focusable elements.

Why is this an accessibility concern?

Because this iframe has a negative tabindex, the contents of the iframe cannot be accessed (tabbed to) using a keyboard. This means that users who cannot use a mouse and rely on a keyboard for navigation will not be able to interact with elements inside this iframe.

What should be done?

Remove the tabindex attribute from the iframe, or set the tabindex to zero (tabindex="0").

• If <canvas> element is interactive with mouse, it's not keyboard accessible because there is no focusable fallback content.

Why did ANDI alert this?

A <canvas> element was found that has no focusable elements within the fallback content.

Why is this an accessibility concern?

A <canvas> by default is not keyboard accessible. When a <canvas> element is interactive, JavaScript is used to control mouse click and hover events. Users who primarily rely on a keyboard for navigation cannot interact with a <canvas> element unless keyboard accessible elements and event handling are provided.

What should be done?

Making a <canvas> fully accessible requires a high degree of JavaScript skill.

If the <canvas> is interactive using a mouse, then the <canvas> should include keyboard-focusable (tabbable) elements within the "fallback" content which will provide keyboard users with functionality that is equivalent to what is available to mouse users.

For example, if the <canvas> has several "hit regions" or "clickable areas", buttons could be provided within the canvas fallback content that will perform a similar function as the hit regions. (As always any such controls should be properly named and described).

To provide visual indication of focus when a fallback control receives focus, a focus event should be added to the fallback control which highlights the hit region with which it associates.

It is acceptable if the keyboard functionality that mimics mouse functionality exists outside of the <canvas> element or even exists outside this page. However, users should be informed about any alternatives.

• <canvas> element has focusable fallback content; Test for keyboard equivalency to mouse functionality.

Why did ANDI alert this?

A <canvas> element was found that has focusable elements within the fallback content. Some additional, manual testing is needed.

Why is this an accessibility concern?

A <canvas> by default is not keyboard accessible. When a <canvas> element is interactive, JavaScript is used to control mouse click and hover events. Users who primarily rely on a keyboard for navigation cannot interact with a <canvas> element unless keyboard accessible elements and event handling are provided.

What should be done?

This particular canvas has some focusable fallback content, which is good. However, some manual testing needs to be done to determine if any important mouse accessible functionality has a keyboard accessible alternative.

If the <canvas> is interactive using a mouse, then the <canvas> should include keyboard-focusable (tabbable) elements within the "fallback" content which will provide keyboard users with functionality that is equivalent to what is available to mouse users.

For example, if the <canvas> has several "hit regions" or "clickable areas", buttons could be provided within the canvas fallback content that will perform a similar function as the hit regions. (As always any such controls should be properly named and described).

To provide visual indication of focus when a fallback control receives focus, a focus event should be added to the fallback control which highlights the hit region with which it associates.

It is acceptable if the keyboard functionality that mimics mouse functionality exists outside of the <canvas> element or even exists outside this page. However, users should be informed about any alternatives.

• <a> element has no [href], [id], or [tabindex]; This might be a link that only works with a mouse.

• <a> element has no [href], or [tabindex]; This might be a link that only works with a mouse.

Why did ANDI alert this?

This element is not in the tab order (no href or tabindex) yet the <a> tag was used. This is an indication that it might function as a link that may only be available to mouse users.

Why is this an accessibility concern?

This element might be missing some important components which would allow it to be accessible to users who use the keyboard to navigate.

What should be done?

Some manual testing and investigating is needed.

The most common (classic) way to create a link is to use the <a> tag and include an href that points to the link's destination page. Sometimes developers will make a conscious choice to use the <a> tag but prefer not to use an href to handle the link's activation logic and instead use JavaScript to do some processing before redirecting the user. When an href is not present on an <a> element but the <a> element does function like a link, role="link" should be applied so that a screen reader knows that the element is, indeed, a link. Or, if the element behaves more like a button (performing actions), rather than a link (redirecting), role="button" can be a better idea. Or better still, just use <button>.

Furthermore, to ensure that the link is in the tab order, an href or tabindex="0" should be applied. If the link has a negative tabindex, then some manual testing is necessary to ensure that the link is keyboard accessible.

Finally, once the link is recognized by the screen reader as a link, and can be navigated to, ensure that the link can be operated using the keyboard by pressing the "enter" key.

• This <a> element is the target of another link; When link is followed, target may not receive visual indication of focus.

Why did ANDI alert this?

This <a> element is the target of another link's href. The element does not have a tabindex.

Why is this an accessibility concern?

Because this <a> element does not have a tabindex it is not focusable, therefore, there will be no visual indication of focus when the link is followed. After following the link, sighted users may not be able to track where focus has been placed.

What should be done?

To ensure that the anchor target displays a visual indication of focus when it receives focus add a tabindex attribute to the <a> target element. In addition, ensure that the browser's default focus ring or enhanced focus styling is in place for the element.

• Empty header cell.

Why did ANDI alert this?

This cell is a <th> and it is empty (has no Namer).

Why is this an accessibility concern?

A screen reader will not read anything for this header since it is empty.

What should be done?

Add text to categorize the purpose of the column or row. Table header cells should not be empty.

Exclusions

With some table designs it is acceptable for a header cell to be empty. For example, when it is at the intersection of a row of headers and a column of headers. This alert will not be thrown for header cells at the upper left position of a table.

• Live region has no innerText content.

Why did ANDI alert this?

This element has been designated as a live region, but its contents are empty (no innerHTML).

Why is this an accessibility concern?

Because screen readers only monitor a live region's contents for changes, a screen reader will not presently announce anything for this live region.

What should be done?

This may not be an issue if the live region is supposed to be empty at a given moment. When the live region is dynamically updated with content changes, refresh ANDI and check the output. If the output still has this alert, it is likely that the live region is not being used properly. Screen readers do not monitor a live region's HTML attributes for changes. For example, if the live region's aria-label value is dynamically changing, a screen reader automatically speak the changes. Ensure that dynamic content changes to the live region are occurring within the innerHTML of the live region.

• Image is presentational; its [alt] will not be used in output.

Why did ANDI alert this?

This image has been declared presentational/decorative using role=presentation or role=none but it has a non-empty alt attribute.

Why is this an accessibility concern?

A screen reader will not speak the alt text since it sees the image as presentational or decorative.

What should be done?

If the image is truly decorative (non-meaningful) ensure that the output relating to this image is as expected.

• [%%%] attribute length exceeds 250 characters; consider condensing.

Why did ANDI alert this?

This element's title, alt, or aria-label attribute value has a length that exceeds 250 characters.

Why is this an accessibility concern?

An accessible name should be a concise identifier of an element. A screen reader has no way of skipping through sections of long accessible names. Shortening the accessible name will help with efficient page navigation using a screen reader.

What should be done?

If a long amount of text is needed, shorten the accessible name and use the aria-describedby attribute. The aria-describedby provides a screen reader user a way to make a selection to hear more information about an element.

• Ambiguous Link: same name/description as another link but different href.

Why did ANDI alert this?

This link shares an identical accessible name and accessible description as another link on the page, but the hrefs are different. Essentially, the links do not have descriptive text.

Why is this an accessibility concern?

Ambiguous links are a potential problem for all users, not just users of assistive technologies (screen readers). Because of this ambiguity (the name/description of the links are the same, but the destinations are different) a user may navigate to an unintended location.

Moreover, screen reader users have the capability to bring up a list of links by which they can efficiently navigate. If the links in such a list are not unique and "self-defining", then the accessibility of the page is affected.

What should be done?

If the hrefs are different, the accessible name and accessible description of each link should be uniquely identified. Note that, if the hrefs are identical, the link names/descriptions can be the same or different.

• Link text is vague and does not identify its purpose.

Why did ANDI alert this?

The accessible name and description of this link is vague and does not provide a meaningful context.

Why is this an accessibility concern?

A person who is visually impaired may not be able to determine the full purpose of this link without seeking out its context in relation to nearby elements on the page.

What should be done?

Provide a meaningful accessible name/description for this link.

• Link has click event but not keyboard accessible.

Why did ANDI alert this?

This link does not have an href or tabindex and a JavaScript click event was detected.

Why is this an accessibility concern?

This link performs some function but is not in the tab order. It may not be accessible to users who navigate using a keyboard.

What should be done?

Ensure that the ANDI Output is appropriate.

Close ANDI and test whether the link can be accessed using the tab key, shift+tab keys, arrow keys or other documented keys.

For a link to be in the keyboard tab order add an href="#", or href="javascript:void(0)", or tabindex="0".

If an href is not being used it may be necessary to add role="link" to the <a> element so that a screen reader will recognize the element as a link and include it in its Links List functionality.

• <a> without [href] may not be recognized as a link; add [role=link] or [href].

Why did ANDI alert this?

This <a> element has a tabindex but it does not have an href.

Why is this an accessibility concern?

A screen reader may not identify this element as a link and the user may not know that the element is actionable.

What should be done?

Does this element function like a link? Click on it using a mouse. Navigate to it using the keyboard and press the enter key.

If the element performs a function, add role="link" to the element or add an href. Doing so will ensure that the screen reader will identify the element as a link.

NOTE: If the element appears and operates like a button, add role="button" and ensure that the element can be pressed using the space bar key.

If this element does not perform a function when clicked, this element might be an anchor target, in which case, disregard this alert.

• <marquee> element found, do not use.

Why did ANDI alert this?

This element is a <marquee>.

Why is this an accessibility concern?

A marquee, depending on its design, can cause flashing which can trigger seizures in some individuals. In addition, the constantly moving text within a marquee can be difficult to read for people with low vision or who have cognition disorders like dyslexia.

What should be done?

It is best to not use the <marquee> tag and to not allow any text to constantly move or scroll on the page.

• <blink> element found, do not use.

Why did ANDI alert this?

This element is a <blink>.

Why is this an accessibility concern?

This element can trigger seizures in some individuals when the content is large. In addition, the blinking/flashing text within a <blink> element can be difficult to read for people with low vision or who have cognition disorders like dyslexia.

What should be done?

Do not use the <blink> tag and do not allow any text to repeatedly blink or flash on the page.

• Server side image map found.

Why did ANDI alert this?

This element contains a sever side image map.

Why is this an accessibility concern?

Server side image maps cannot be navigated by screen reader users and users who do not use a mouse.

What should be done?

Do not use server side image maps. Client side image maps are acceptable but must be made accessible by adding alt attributes to the <area> tags.

• Image [alt] text is not descriptive.

Why did ANDI alert this?

This image has alt text that does not provide an equivalent text description conveying the purpose and/or function of the image.

Why is this an accessibility concern?

If the image does not have a text alternative description that contains a meaningful representation of the image, then the image is not accessible to a person who is blind or visually impaired and uses a screen reader.

What should be done?

The image alt text or other Namer/Describer should provide a text alternative or brief description of the image.

Alternatively, if the image is purely decorative and does not require an explanation, add role=presentation to the image or set the alt value to an empty string alt="". Doing so will ensure that the screen reader does not try to describe the image.

• <area> not contained in <map>.

Why did ANDI alert this?

ANDI has found an image map element, (<area>), that is not contained within a <map> element.

What should be done?

To create a proper client-side image map, <area> elements must be within a <map> element.

• Image [alt] text contains file name.

Why did ANDI alert this?

The image alt text contains a file name such as ".jpg", ".gif", ".png".

Why is this an accessibility concern?

If the image does not have a text alternative description that contains a meaningful representation of the image, then the image is not accessible to a person who is blind or visually impaired and uses a screen reader.

What should be done?

The image alt text or other Namer/Describer should provide a text alternative or brief description of the image.

Alternatively, if the image is purely decorative and does not require an explanation, add role=presentation to the image or set the alt value to an empty string alt="". Doing so will ensure that the screen reader does not try to describe the image.

• Redundant phrase in image [alt] text.

Why did ANDI alert this?

The image alt contains a redundant phrase such as "image of ...", "photo of ...".

Why is this an accessibility concern?

A screen reader will automatically announce the word "graphic" when an <img> tag is being used, therefore, including the redundant phrase in the alt text increases verbosity.

What should be done?

Remove the redundant phrase from the alt value.

• Ensure that background images are decorative.

Why did ANDI alert this?

ANDI has found an element styled as a background-image using CSS. A manual evaluation of all background images is needed.

Why is this an accessibility concern?

When images contain important information, a person who is visually impaired will miss the important information if the image does not have a text description or text equivalent somewhere on the page.

Screen readers consider all background images to be decorative and therefore visually impaired users are not told about the presence of background images. Note: This is only an accessibility issue when background images contain important information.

What should be done?

Ensure that any background images that are meaningful have a text alternative somewhere on the page. Graphics/Images ANDI has two helpful features to locate background images: The Hide Background and Find Background buttons.

If meaningful background images are found with no text alternatives, consider these solutions:

• Live Region contains a form element.

Why did ANDI alert this?

There is a "live region" on this page (aria-live) that contains a form element.

Why is this an accessibility concern?

Screen readers monitor live regions and will speak changes whenever the content of the live region changes.

If a form element is contained within the live region, the screen reader will be reading out the live region contents when the form element changes causing confusion and verbosity for screen reader users.

What should be done?

Remove form elements from the live region or move the aria-live to another element.

• A live region can only be a container element.

Why did ANDI alert this?

This element is not a container element (cannot contain text or other elements) and it is designated as a "live region" (aria-live).

Why is this an accessibility concern?

Screen readers monitor live regions and will speak changes whenever the content of the live region changes. Since this element is not a container element and therefore has no contents, the design will not work as expected. i.e. screen readers will not recognize changes to this live region.

What should be done?

Only container elements (such as a <div>) can be designated as live regions. Changes to the contents (innerText) of the live region will trigger the screen reader to speak the changed content.

• List item's container is not recognized as a list because it has [role=%%%].

Why did ANDI alert this?

This list element <li> is contained by a list container element <ol> or <ul> but the list container has a role that changes its semantics to something that is not a list container.

Why is this an accessibility concern?

A screen reader will not recognize this as a list because the semantics of the list container have been overridden with a role attribute.

What should be done?

Remove the role from the list container, or if it is necessary, move it to another containing element.

• [aria-level] is not a greater-than-zero integer; level 2 will be assumed.

Why did ANDI alert this?

The aria-level attribute is not greater than zero and/or is not an integer.

Why is this an accessibility concern?

When the aria-level on a role="heading" element is not a greater than zero integer, a screen reader will default the heading level to level 2.

What should be done?

Ensure that the aria-level value is valid and is an appropriate level for its location on the page.

• Non-unique button: same name/description as another button.

Why did ANDI alert this?

This button has the same accessible name and description as another button.

Why is this an accessibility concern?

If these buttons perform different functions or use a different set of data, then they each need to be uniquely identified. A person who is visually impaired may not be aware of the button's context (its location on the page). If two or more buttons have the same accessible name and description, then functionality should also be the same no matter which buttons is pressed.

For example, consider a data table with buttons labeled "Delete" on every row. An identifying description about what is going to be deleted must be programmatically associated with the button, otherwise a user may delete the wrong item.

What should be done?

If the buttons perform a different function or use a different set of data, either rename the buttons or attach a unique description to the button using the aria-describedby or title attributes. Otherwise, if the buttons are truly identical and perform the same function using the same data, no change is required.

• Element visually conveys heading meaning but not using semantic heading markup.

Why did ANDI alert this?

This element appears to be a false heading.

Why is this an accessibility concern?

Headings (text that is concise, has a large font size or bold font weight) provide a way to visually organize and categorize sections of a page. Users of assistive technology are able to quickly navigate web pages when headings exist on a page. However, headings must be coded properly using semantic heading tags (<h1> through <h6>) in order for users of AT to navigate.

What should be done?

Convert this false heading, and any others on the page, into one of the semantic heading tags: <h1>, <h2>, <h3>, <h4>, <h5>, <h6>.

• Heading element level <h#> conflicts with [aria-level=%%%].

Why did ANDI alert this?

This heading element's heading level implied by its tag name, (<h1> - <h6>) does not match the numeric aria-level value.

Why is this an accessibility concern?

The intended heading level may not be communicated to users of assistive technology.

What should be done?

Always ensure that the heading level used is the proper heading level in relation to the content and other headings on the page. When role="heading" is used, the aria-level will supersede the heading level from the tag name. Therefore, either:

As a best practice, stick with native semantics instead of ARIA whenever possible.

• [role=heading] used without [aria-level]; level 2 will be assumed.

Why did ANDI alert this?

This element was defined as a heading using role="heading" but it was not given a heading level using aria-level.

Why is this an accessibility concern?

A screen reader will assume the heading level to be level 2 since 2 is the default aria-level.

What should be done?

Use semantic HTML headings (<h1>, <h2>, <h3>, <h4>, <h5>, <h6>) instead of role="heading" or add the aria-level attribute to the element and assign it a positive numeric value.

• An associated <label> would increase the clickable area of this element.

Why did ANDI alert this?

This radio button or checkbox does not have an associated <label> and the size of the radio button or checkbox is less than 21px by 21px.

Why is this an accessibility concern?

People with motor disabilities who can used a mouse may have trouble clicking on a small target less than 21px by 21px. Note: This size limit (21px by 21px) is arbitrarily determined and not an official WCAG requirement.

What should be done?

Adding an associated <label> to a radio button or checkbox allows a mouse user to click on the label to select the radio button or checkbox. This increases the size of the clickable area. An associated <label> is also a standard way of providing an accessible name for a radio button or checkbox.

• Content has been injected using CSS pseudo-elements ::before or ::after.

Why did ANDI alert this?

This page has content injected using the CSS pseudo-elements ::before or ::after.

Why is this an accessibility concern?

Depending on the browser being used, Content injected using this technique may not recognized by screen readers, therefore, the text may not be communicated to individuals using assistive technologies. Specifically, in Internet Explorer screen readers will not detect recognize CSS pseudo-element content.

What should be done?

If the content is meaningful or important, it should be made apparent to a blind individual using a screen reader.

If the meaning of the injected content is available elsewhere on the page, no change is needed. Otherwise, remediation options are as follows:

• Element has background-image; Perform a manual contrast test.

Why did ANDI alert this?

This element is "on top of" a background-image, therefore, the contrast ratio cannot be automatically determined. The element background color could not be determined due to a background image.

Why is this an accessibility concern?

Informational text should have a contrast ratio that allows the text to be readable by people with moderately low vision.

What should be done?

Perform a manual contrast ratio test by selecting the primary color of the background image and the primary foreground color of the text using a color selector tool (Colour Contrast Analyser Installation).

The WCAG AA Contrast Ratio requirement is as follows:

• Page has images; If images contain meaningful text; Perform a manual contrast test.

Why did ANDI alert this?

The page contains inline images (<img>, <input[type='image']>, or <svg>).

Why is this an accessibility concern?

If an image contains informational text, that text should have a contrast ratio that allows the text to be readable by people with moderately low vision.

What should be done?

If the images on this page contain informational text, perform a manual contrast ratio test by selecting the primary background color and the primary foreground color of the text using a color selector tool (Colour Contrast Analyser Installation).

The WCAG AA Contrast Ratio requirement is as follows:

• Opacity less than 100%; Perform manual contrast test.

Why did ANDI alert this?

This element has a CSS property opacity with a value that is less than 1, thus making it semi-transparent.

Why is this an accessibility concern?

By reducing the opacity value to less than one, the element's foreground color and background color is affected and will lower the contrast ratio. Informational text should have a contrast ratio that allows the text to be readable by people with moderately low vision.

Is this really an issue? (disabled elements)

Sometimes developers use CSS opacity to make an element appear disabled. Disabled elements do not need to be included in a contrast test, but it is up to the tester to determine if the element is in a disabled state. Moreover, to communicate to a screen reader user that an element is disabled, the element should have aria-disabled="true".

What should be done?

If the text is not in a disabled state, perform a manual contrast ratio test by selecting the primary color of the background image and the primary foreground color of the text using a color selector tool (Colour Contrast Analyser Installation).

The WCAG AA Contrast Ratio requirement is as follows:

• [role=grid] found; test navigation of design pattern.

Why did ANDI alert this?

An element with role="grid" was detected on the page.

Why is this an accessibility concern?

When the grid receives focus, a screen reader will announce specific navigation instructions. Therefore, users have certain expectations on how a grid should operate.

What should be done?

Developers should follow W3C WAI-ARIA Authoring Practices for Grids.

The developer must manage focus within the grid using JavaScript and a tester should ensure that proper navigation has been implemented. It is advisable to close ANDI while testing the navigation of the Grid, however, ANDI can be used to test the naming and describing (ANDI Output) of the elements within the grid.

Summary of grid operation expectations:

A properly implemented grid is an excellent, usable, accessible interface. A developer should have advanced knowledge of accessibility requirements and must implement the grid to the specifications of the WAI ARIA Authoring Practices. In many instances, native HTML data table markup using <table> structure or ARIA role="table" structure should sufficiently meet the needs of the user.

• Text does not meet minimum AA contrast ratio (4.5:1).
• Text does not meet large text minimum AA contrast ratio (3:1).

Why did ANDI alert this?

This element has very low contrast between foreground and background colors. In other words, the background and foreground colors do not have a sufficient contrast ratio based on minimum requirements.

Why is this an accessibility concern?

Informational text should have a contrast ratio that allows the text to be readable by individuals with moderately low vision.

What should be done?

Adjust the text color and/or the background color of this element so that the contrast ratio is at or above the minimum required contrast ratio.

The WCAG AA Contrast Ratio requirement is as follows:

• Page has %%% disabled elements; Disabled elements are not in the keyboard tab order.
• Page has %%% disabled buttons; Disabled elements are not in the keyboard tab order.
• Page has %%% disabled links; Disabled elements are not in the keyboard tab order.

Why did ANDI alert this?

Disabled elements (disabled="disabled") were found on the page.

Why is this an accessibility concern?

Elements disabled using the disabled attribute are not in the tab order by default and cannot be placed in the tab order. Therefore, a person who is visually impaired and using a keyboard to tab through the page may not know that the field is disabled (or even exists on the page).

What should be done?

Some would argue that disabling elements is a bad design practice in general. Users may become confused or frustrated if they don't know why an element is disabled or how they can make it become enabled.

The disabling of an element does not always equate to an accessibility issue. However, an argument can be made that disabled elements violate some of the Four Principles of Accessibility. Namely, is the content Perceivable? Is it Operable? Is it Understandable?

There may be an opportunity to improve upon the design to make it more accessible and usable by everyone. Here are a few things to consider:

• Page has %%% disabled elements; Disabled elements do not require sufficient contrast.

Why did ANDI alert this?

Disabled elements (disabled="disabled") were found on the page. Disabled elements are inactive user interface components and do not have color contrast requirements according to the WCAG AA Contrast Ratio requirement.

• Element is hidden from screen reader using [aria-hidden=true] resulting in no output.

• Element is hidden from screen reader using [aria-hidden=true] resulting in no output.

Why did ANDI alert this?

This element has been hidden from a screen reader using aria-hidden="true". Note: The element may be contained by (an ancestor of) an element with aria-hidden="true".

Why is this an accessibility concern?

If the element is interactive or the sole source of meaningful information, it should be recognized by a screen reader so that a user with a vision disability can interact with the element or access its meaning.

When an element is denoted as aria-hidden="true" the screen reader will entirely ignore the element.

What should be done?

aria-hidden="true" is meant to be used in specific situations. It's okay to use aria-hidden="true" when:

It is rare that focusable elements should have aria-hidden="true". Most likely, if an element is focusable it should not have aria-hidden="true" and should not have an ancestor element with aria-hidden="true".

If the element should not be used by all users, hide the element using css display:none which will remove the element from the screen and will hide the element from screen reader users.

One example where aria-hidden="true" usage is acceptable and common is in the case of modal dialogs. When the modal is open, the "grayed-out background" should not be accessible to any user. This inaccessible content may have aria-hidden="true" to complement the "grayed out" visual cue.