An Official Website Of The United States Government
This site is currently in beta

Accessibility Guidance

Home » FAQ » Accessibility Guidance

Below you will find some helpful tips to help guide you towards getting a better score on Accessibility Module for your website or agency. For any further questions, please visit our frequently asked questions.

What websites are measured?

Accessibility Module scans for certain common accessibility issues on publicly accessible .gov websites in the federal government's executive branch. Websites which simply redirect to other websites are not measured.

Accessibility Module scans second-level federal .gov websites (e.g., agency.gov), checking the official .gov website list. Note that third-level federal websites (e.g., program.agency.gov), .mil, .edu, .us, and state, local, and Native Sovereign Nation (NSN) websites are NOT currently scanned by Accessibility Module.

Accessibility Module Spot Checks

The Accessibility Module  performs the following spot checks, informed by the current Section 508 standards. The checks use the WCAG 2.0 success criteria associated with each standard to inform the testing approach.

WCAG 2.0, Section 508 Content Type and Test Rule Mapping

WCAG Success Criteria

Content Type

Test Rule

Summary

Success Criteria Guidelines and Techniques

1.1.1 Non-text Content

Images

image-alt (axe-core 3.5)

Accessibility Module is checking to determine if images and other non-text content, including user interface elements, contain a text description. This requires manual inspection and therefore cannot be tested by Accessibility Module.

https://dequeuniversity.com/rules/axe/3.5/role-img-alt

1.1.1 Non-text Content

Images

role-img-alt (axe-core 3.5)

Accessibility Module is checking to determine if images and other non-text content, including user interface elements, contain a text description. This requires manual inspection and therefore cannot be tested by Accessibility Module.

https://dequeuniversity.com/rules/axe/3.5/role-img-alt

1.3.1 Info and Relationships

Forms

aria-hidden-focus (axe-core 3.5)

Accessibility Module is checking to ensure every ARIA input field has an accessible name. Accessible names must exist for the following input field roles: combobox, listbox, searchbox, slider ,spinbutton, textbox.

https://dequeuniversity.com/rules/axe/3.5/aria-input-field-name

1.3.1 Info and Relationships

Forms

aria-input-field-name (axe-core 3.5)

Accessibility Module is checking to ensure every element with a semantic role also has an accessible name. Semantic roles include: checkbox, menu, menuitemcheckbox, menuitemradio, radio, radiogroup, switch.

https://dequeuniversity.com/rules/axe/3.5/aria-toggle-field-name

1.3.1 Info and Relationships

Forms

aria-toggle-field-name (axe-core 3.5)

Accessibility module is checking to ensure that headings contain content and that this content is accessible by a screen reader. Screen readers alert users to the presence of a heading tag. If the heading is empty or the text cannot be accessed, this could either confuse users or even prevent them from accessing information on the page's structure.

https://dequeuniversity.com/rules/axe/3.5/empty-heading

1.3.1 Info and Relationships

Content Structure

empty-heading (axe-core 3.5)

Accessibility module is checking the form field does not have multiple labels. Assigning multiple labels to the same form field can cause problems for some combinations of screen readers and browsers, and the results are inconsistent from one combination to the next.

https://dequeuniversity.com/rules/axe/3.5/form-field-multiple-labels

1.3.1 Info and Relationships

Forms

form-field-multiple-labels (axe-core 3.5)

Accessibility module is checking that every form element has a programmatically associated label. Screen readers cannot programmatically determine information about input objects without an established label relationship

https://dequeuniversity.com/rules/axe/3.5/label

1.3.1 Info and Relationships

Forms

label (axe-core 3.5)

Accessibility module is checking that all list item 'li' elements are wrapped inside of 'ul' or 'ol' parent elements. For a list to be valid, it must have both parent and child elements.

https://dequeuniversity.com/rules/axe/3.5/listitem

1.3.1 Info and Relationships

Content Structure

listitem (axe-core 3.5)

Accessibility Module is checking whether the value for a role is valid. If aria role value is invalid there is no way to communicate the element's features, properties, and methods to assistive technologies.

https://dequeuniversity.com/rules/axe/3.5/aria-allowed-role

1.3.1 Info and Relationships

Tables

scope-attr-valid (axe-core 3.5)

Accessibility module is checking that buttons have discernible text that clearly describes the destination, purpose, function, or action for screen reader users. The input-button-name rule separates functionality from the button-name rule to ensure that input buttons have discernible text; advise relevant to input button names was incorrect for button elements.

https://dequeuniversity.com/rules/axe/3.5/button-name

1.3.1 Info and Relationships

Tables

td-headers-attr (axe-core 3.5)

Accessibility Module is checking to ensure there is enough contrast between text and its background so that it can be read by people with moderately low vision, at least 4.5:1 for small text or 3:1 for large text.

https://dequeuniversity.com/rules/axe/3.5/color-contrast

1.3.1 Info and Relationships

Forms

WCAG2AA.Principle1.Guideline1_3.1_3_1.F68 (htmlcs 2.5.1)

Accessibility module is checking to ensure that each HTML document contains a title. The title is the first thing that screen reader users hear when they arrive at a page. If there is no title or if the title is not descriptive and unique, screen reader users must read through the page to determine its contents and purpose.

https://dequeuniversity.com/rules/axe/3.5/document-title

1.3.1 Info and Relationships

Tables

WCAG2AA.Principle1.Guideline1_3.1_3_1.H39.3.LayoutTable (htmlcs 2.5.1)

Accessibility module is checking to ensures that each element on the page with an id attribute has a unique id attribute value. The ID attribute uniquely identifies elements on a page, so one element id should not be used to identify another element.

https://dequeuniversity.com/rules/axe/3.5/duplicate-id

1.3.1 Info and Relationships

Content Structure

WCAG2AA.Principle1.Guideline1_3.1_3_1.H42.2 (htmlcs 2.5.1)

Accessibility module is checking that all frame and iframe elements have valid title attribute values. Screen reader users rely on a frame title to describe the contents of the frame.

https://dequeuniversity.com/rules/axe/3.5/frame-title

1.3.1 Info and Relationships

Tables

WCAG2AA.Principle1.Guideline1_3.1_3_1.H43,H63 (htmlcs 2.5.1)

Accessibility module is checking that all frame and iframe elements have titles that are not repeated. If no title is listed, screen readers will instead give information like “frame,” “javascript,” the filename, or the URL. In most cases, this information won’t be very helpful.

https://dequeuniversity.com/rules/axe/3.5/frame-title-unique

1.3.1 Info and Relationships

Tables

WCAG2AA.Principle1.Guideline1_3.1_3_1.H43.HeadersRequired (htmlcs 2.5.1)

Accessibility module is checking that every HTML document has a lang attribute. Screen readers use different sound libraries for each language, based on the pronunciation and characteristics of that language. Screen readers can switch between these language libraries easily, but only if the documents specify which language(s) to read and when.

https://dequeuniversity.com/rules/axe/3.5/html-has-lang

1.3.1 Info and Relationships

Tables

WCAG2AA.Principle1.Guideline1_3.1_3_1.H43.IncorrectAttr (htmlcs 2.5.1)

Accessibility module is checking that every HTML document has a lang or xml:lang attribute and that the attribute's value is valid value. Language settings are an issue for users who speak multiple languages and access website in more than one language. It is essential to specify a language and ensure that it is valid so website text is pronounced correctly.

https://dequeuniversity.com/rules/axe/3.5/html-lang-valid

1.3.1 Info and Relationships

Tables

WCAG2AA.Principle1.Guideline1_3.1_3_1.H43.MissingHeaderIds (htmlcs 2.5.1)

Accessibility module is checking that the headers attribute of a data cell contains the id attribute of all headers associated with the data cell.

https://www.w3.org/WAI/WCAG21/Techniques/html/H43.html

1.3.1 Info and Relationships

Tables

WCAG2AA.Principle1.Guideline1_3.1_3_1.H43.MissingHeadersAttrs (htmlcs 2.5.1)

Accessibility module is checking that Input Buttons must have discernible text. Screen reader users are not able to discern the purpose of an input type="button" without an accessible name.

https://dequeuniversity.com/rules/axe/3.5/input-button-name

1.3.1 Info and Relationships

Forms

WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.InputCheckbox.Name (htmlcs 2.5.1)

Accessibility module is checking that the checkbox input element does has a name available to an accessibility API. Valid names are: label element, title attribute.

https://www.w3.org/WAI/WCAG21/Techniques/html/H91.html

1.3.1 Info and Relationships

Forms

WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.InputFile.Name (htmlcs 2.5.1)

Accessibility module is checking that the file input element has a name available to an accessibility API. Valid names are: alt undefined, title undefined, aria-label undefined, aria-labelledby undefined.

https://www.w3.org/WAI/WCAG21/Techniques/html/H91.html

1.3.1 Info and Relationships

Forms

WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.InputPassword.Name (htmlcs 2.5.1)

Accessibility module is checking that the the password input element does has a name available to an accessibility API. Valid names are: label element, title attribute.

https://www.w3.org/WAI/WCAG21/Techniques/html/H91.html

1.3.1 Info and Relationships

Forms

WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.InputRadio.Name (htmlcs 2.5.1)

Accessibility module is checking that the radio input element has a name available to an accessibility API. Valid names are: title attribute, element content, aria-label attribute, aria-labelledby attribute.

https://www.w3.org/WAI/WCAG21/Techniques/html/H91.html

1.3.1 Info and Relationships

Forms

WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.InputText.Name (htmlcs 2.5.1)

Accessibility module is checking that the text input element has a name available to an accessibility API. Valid names are: label element, title undefined, aria-label undefined, aria-labelledby undefined.

https://www.w3.org/WAI/WCAG21/Techniques/html/H91.html

1.3.1 Info and Relationships

Forms

WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.Select.Name (htmlcs 2.5.1)

Accessibility module is checking that the select element has a name available to an accessibility API.

https://www.w3.org/WAI/WCAG21/Techniques/html/H91.html

1.3.1 Info and Relationships

Forms

WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.Textarea.Name (htmlcs 2.5.1)

Accessibility module is checking that the editible text area element has a name available to an accessibility API.

https://www.w3.org/WAI/WCAG21/Techniques/html/H91.html

1.4.3 Contrast (Minimum)

Contrast

color-contrast (axe-core 3.5)

Accessibility Module is checking to ensure there is enough contrast between text and its background so that it can be read by people with moderately low vision, at least 4.5:1 for small text or 3:1 for large text.

https://dequeuniversity.com/rules/axe/3.5/color-contrast

1.4.3 Contrast (Minimum)

Contrast

WCAG2AA.Principle1.Guideline1_4.1_4_3.G145 (htmlcs 2.5.1)

Accessibility module is checking that a contrast ratio of at least 3:1 exists between text (and images of text) and background behind the text.

https://www.w3.org/WAI/WCAG21/Techniques/general/G145.html

1.4.3 Contrast (Minimum)

Contrast

WCAG2AA.Principle1.Guideline1_4.1_4_3.G18 (htmlcs 2.5.1)

Accessibility module is checking that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text.

https://www.w3.org/WAI/WCAG21/Techniques/general/G18.html

1.3.1 Info and Relationships

Tables

WCAG2AA.Principle1.Guideline1_3.1_3_1.H43,H63 (htmlcs 2.5.1)

Accessibility module is checking to associate each data cell (in a data table) with the appropriate headers. This technique adds a headers attribute to each data cell (td element). It also adds an id attribute to any cell used as a header for other cells. The headers attribute of a cell contains a list of the id attributes of the associated header cells. If there is more than one id, they are separated by spaces.

https://www.w3.org/WAI/WCAG21/Techniques/html/H43.html, https://www.w3.org/WAI/WCAG21/Techniques/html/H63.html

1.3.1 Info and Relationships

Tables

WCAG2AA.Principle1.Guideline1_3.1_3_1.H43.HeadersRequired (htmlcs 2.5.1)

Accessibility module is checking for layout tables: determine whether the content has a relationship with other content in both its column and its row. If “no," the table is a layout table. If “yes," the table is a data table. If table is a data table then headers or id attributes are required.

https://www.w3.org/WAI/WCAG21/Techniques/html/H43.html

1.3.1 Info and Relationships

Tables

WCAG2AA.Principle1.Guideline1_3.1_3_1.H43.IncorrectAttr (htmlcs 2.5.1)

Accessibility module is checking whether an correct headers attribute is applied on this td element. Expected '<expected headers>' but found '<actual headers>'.

https://www.w3.org/WAI/WCAG21/Techniques/html/H43.html

1.3.1 Info and Relationships

Tables

WCAG2AA.Principle1.Guideline1_3.1_3_1.H43.MissingHeaderIds (htmlcs 2.5.1)

Accessibility module is checking that the headers attribute of a data cell contains the id attribute of all headers associated with the data cell.

https://www.w3.org/WAI/WCAG21/Techniques/html/H43.html

1.3.1 Info and Relationships

Tables

WCAG2AA.Principle1.Guideline1_3.1_3_1.H43.MissingHeadersAttrs (htmlcs 2.5.1)

Accessibility module is checking that the each data cell in a data table is associated with the appropriate header attributes.

https://www.w3.org/WAI/WCAG21/Techniques/html/H43.html

1.3.1 Info and Relationships

Forms

WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.InputCheckbox.Name (htmlcs 2.5.1)

Accessibility module is checking that the checkbox input element does has a name available to an accessibility API. Valid names are: label element, title attribute.

https://www.w3.org/WAI/WCAG21/Techniques/html/H91.html

1.3.1 Info and Relationships

Forms

WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.InputFile.Name (htmlcs 2.5.1)

Accessibility module is checking that the file input element has a name available to an accessibility API. Valid names are: alt undefined, title undefined, aria-label undefined, aria-labelledby undefined.

https://www.w3.org/WAI/WCAG21/Techniques/html/H91.html

1.3.1 Info and Relationships

Forms

WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.InputPassword.Name (htmlcs 2.5.1)

Accessibility module is checking that the the password input element does has a name available to an accessibility API. Valid names are: label element, title attribute.

https://www.w3.org/WAI/WCAG21/Techniques/html/H91.html

1.3.1 Info and Relationships

Forms

WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.InputRadio.Name (htmlcs 2.5.1)

Accessibility module is checking that the radio input element has a name available to an accessibility API. Valid names are: title attribute, element content, aria-label attribute, aria-labelledby attribute.

https://www.w3.org/WAI/WCAG21/Techniques/html/H91.html

1.3.1 Info and Relationships

Forms

WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.InputText.Name (htmlcs 2.5.1)

Accessibility module is checking that the text input element has a name available to an accessibility API. Valid names are: label element, title undefined, aria-label undefined, aria-labelledby undefined.

https://www.w3.org/WAI/WCAG21/Techniques/html/H91.html

1.3.1 Info and Relationships

Forms

WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.Select.Name (htmlcs 2.5.1)

Accessibility module is checking that the select element has a name available to an accessibility API.

https://www.w3.org/WAI/WCAG21/Techniques/html/H91.html

1.3.1 Info and Relationships

Forms

WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.Textarea.Name (htmlcs 2.5.1)

Accessibility module is checking that the editible text area element has a name available to an accessibility API.

https://www.w3.org/WAI/WCAG21/Techniques/html/H91.html

1.4.3 Contrast (Minimum)

Contrast

WCAG2AA.Principle1.Guideline1_4.1_4_3.G145 (htmlcs 2.5.1)

Accessibility module is checking that a contrast ratio of at least 3:1 exists between text (and images of text) and background behind the text.

https://www.w3.org/WAI/WCAG21/Techniques/general/G145.html

1.4.3 Contrast (Minimum)

Contrast

WCAG2AA.Principle1.Guideline1_4.1_4_3.G18 (htmlcs 2.5.1)

Accessibility module is checking that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text.

https://www.w3.org/WAI/WCAG21/Techniques/general/G18.html

2.1.1 Keyboard

Keyboard Access 

scrollable-region-focusable (axe-core 3.5)

Accessibility module is checking that scrollable content for focusable elements enable keyboard navigation. Keyboard navigation should not fail when focus moves to an element within a scrollable region.

https://dequeuniversity.com/rules/axe/3.5/scrollable-region-focusable

2.4.2 Page Titled

Page Titles

document-title (axe-core 3.5)

Accessibility module is checking to ensure that each HTML document contains a title. The title is the first thing that screen reader users hear when they arrive at a page. If there is no title or if the title is not descriptive and unique, screen reader users must read through the page to determine its contents and purpose.

https://dequeuniversity.com/rules/axe/3.5/document-title

2.4.2 Page Titled

Page Titles

WCAG2AA.Principle2.Guideline2_4.2_4_2.H25.1.EmptyTitle (htmlcs 2.5.1)

Accessibility module is checking to ensure the title is not empty.

https://www.w3.org/WAI/WCAG21/Techniques/html/H25.html

2.4.2 Page Titled

Page Titles

WCAG2AA.Principle2.Guideline2_4.2_4_2.H25.1.NoTitleEl (htmlcs 2.5.1)

Accessibility module is checking the source code of the HTML or XHTML document and ensures that a non-empty title element appears in the head section.

https://www.w3.org/WAI/WCAG21/Techniques/html/H25.html

2.4.4 Link Purpose (In Context)

Links and Buttons

aria-allowed-role (axe-core 3.5)

Accessibility Module is checking whether the value for a role is valid. If aria role value is invalid there is no way to communicate the element's features, properties, and methods to assistive technologies.

https://dequeuniversity.com/rules/axe/3.5/aria-allowed-role

2.4.4 Link Purpose (In Context)

Links and Buttons

button-name (axe-core 3.5)

Accessibility module is checking that buttons have discernible text that clearly describes the destination, purpose, function, or action for screen reader users. The input-button-name rule separates functionality from the button-name rule to ensure that input buttons have discernible text; advise relevant to input button names was incorrect for button elements.

https://dequeuniversity.com/rules/axe/3.5/button-name

2.4.4 Link Purpose (In Context)

Links and Buttons

input-button-name (axe-core 3.5)

Accessibility module is checking that Input Buttons must have discernible text. Screen reader users are not able to discern the purpose of an input type="button" without an accessible name.

https://dequeuniversity.com/rules/axe/3.5/input-button-name

2.4.4 Link Purpose (In Context)

Links and Buttons

input-image-alt (axe-core 3.5)

Accessibility module is checking that the <input type="image"> has a non-empty alt, aria-label or aria-labelledby attribute, otherwise screen reader users will not know the button's purpose.

https://dequeuniversity.com/rules/axe/3.5/input-image-alt

2.4.4 Link Purpose (In Context)

Links and Buttons

link-name (axe-core 3.5)

Accessibility module is checking for link text and alternate text for images, when used as links, must be discernible by a screen reader, must not have a duplicate label, and must be focusable.

https://dequeuniversity.com/rules/axe/3.5/link-name

2.4.4 Link Purpose (In Context)

Links and Buttons

list (axe-core 3.5)

Accessibility module is checking that all ordered and unordered lists (defined by ul or ol elements) contain only li content elements. This feature makes lists clearer to understand, but will only work if lists are properly structured.

https://dequeuniversity.com/rules/axe/3.5/list

2.4.4 Link Purpose (In Context)

Links and Buttons

WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.A.EmptyNoId (htmlcs 2.5.1)

Accessibility module is checking that anchor elements are not empty. Error occurs when no text, no href or no ID is found.

https://www.w3.org/WAI/WCAG21/Techniques/html/H91.html

2.4.4 Link Purpose (In Context)

Links and Buttons

WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.A.NoContent (htmlcs 2.5.1)

Accessibility module is checking that link has a href attribute, but without link text. This means it does not have an accessibility API "name".

https://www.w3.org/WAI/WCAG21/Techniques/html/H91.html

2.4.4 Link Purpose (In Context)

Links and Buttons

WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.Button.Name (htmlcs 2.5.1)

Accessibility module is checking that button has a name.

https://www.w3.org/WAI/WCAG21/Techniques/html/H91.html

2.4.4 Link Purpose (In Context)

Links and Buttons

WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.InputButton.Name (htmlcs 2.5.1)

Accessibility module is checking that the button element has a name available to an accessibility API. Valid names are: title attribute, element content, aria-label attribute, aria-labelledby attribute.

https://www.w3.org/WAI/WCAG21/Techniques/html/H91.html

2.4.4 Link Purpose (In Context)

Links and Buttons

WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.InputImage.Name (htmlcs 2.5.1)

Accessibility module is checking that the image input element has a name available to an accessibility API. Valid names are: alt undefined, title undefined, aria-label undefined, aria-labelledby undefined.

https://www.w3.org/WAI/WCAG21/Techniques/html/H91.html

2.4.4 Link Purpose (In Context)

Links and Buttons

WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.Li.Name (htmlcs 2.5.1)

Accessibility module is checking that the list box element has a name available to an accessibility API.

https://www.w3.org/WAI/WCAG21/Techniques/html/H91.html

3.1.1 Language of Page

Language

html-has-lang (axe-core 3.5)

Accessibility module is checking that every HTML document has a lang attribute. Screen readers use different sound libraries for each language, based on the pronunciation and characteristics of that language. Screen readers can switch between these language libraries easily, but only if the documents specify which language(s) to read and when.

https://dequeuniversity.com/rules/axe/3.5/html-has-lang

3.1.1 Language of Page

Language

html-lang-valid (axe-core 3.5)

Accessibility module is checking that every HTML document has a lang or xml:lang attribute and that the attribute's value is valid value. Language settings are an issue for users who speak multiple languages and access website in more than one language. It is essential to specify a language and ensure that it is valid so website text is pronounced correctly.

https://dequeuniversity.com/rules/axe/3.5/html-lang-valid

3.1.1 Language of Page

Language

valid-lang (axe-core 3.5)

Accessibility module is checking that the language specified in the HTML document is one of the valid languages to ensure text is pronounced correctly for screen reader users (e.g. <html lang="en"> would set the language of the document to English).

https://dequeuniversity.com/rules/axe/3.5/valid-lang

3.1.1 Language of Page

Language

WCAG2AA.Principle3.Guideline3_1.3_1_1.H57.3.Lang (htmlcs 2.5.1)

Accessibility module is checking that the value of the lang attribute conforms to "BCP 47: Tags for the Identification of Languages" or its successor and reflects the primary language used by the Web page.

https://www.w3.org/WAI/WCAG21/Techniques/html/H57.html

3.1.1 Language of Page

Language

WCAG2AA.Principle3.Guideline3_1.3_1_2.H58.1.Lang (htmlcs 2.5.1)

Accessibility module is checking that the human language of the content of the element is the same as the inherited language for the element as specified in "HTML 4.01, Inheritance of language codes".

https://www.w3.org/WAI/WCAG21/Techniques/html/H58.html

4.1.1 Parsing

Parsing

duplicate-id (axe-core 3.5)

Accessibility module is checking to ensures that each element on the page with an id attribute has a unique id attribute value. The ID attribute uniquely identifies elements on a page, so one element id should not be used to identify another element.

https://dequeuniversity.com/rules/axe/3.5/duplicate-id

4.1.1 Parsing

Parsing

WCAG2AA.Principle4.Guideline4_1.4_1_1.F77 (htmlcs 2.5.1)

Accessibility module is checking that all values of type ID are unique in the Web page.

https://www.w3.org/WAI/WCAG21/Techniques/failures/F77.html

4.1.2 Name, Role, Value

Frames and iFrames

frame-title (axe-core 3.5)

Accessibility module is checking that all frame and iframe elements have valid title attribute values. Screen reader users rely on a frame title to describe the contents of the frame.

https://dequeuniversity.com/rules/axe/3.5/frame-title

4.1.2 Name, Role, Value

Frames and iFrames

frame-title-unique (axe-core 3.5)

Accessibility module is checking that all frame and iframe elements have titles that are not repeated. If no title is listed, screen readers will instead give information like “frame,” “javascript,” the filename, or the URL. In most cases, this information won’t be very helpful.

https://dequeuniversity.com/rules/axe/3.5/frame-title-unique

4.1.2 Name, Role, Value

Frames and iFrames

WCAG2AA.Principle2.Guideline2_4.2_4_1.H64.1 (htmlcs 2.5.1)

Accessibility module is checking that each frame and iframe element in the HTML or XHTML source code for the presence of a title attribute.

https://www.w3.org/WAI/WCAG21/Techniques/html/H64.html

Disclaimer

The Accessibility Module reports do not constitute a complete accessibility evaluation. Rather, they display the initial results of limited automated scans that address only a small portion of what’s required to make a website fully accessible. In addition, although significant effort has been taken to ensure accuracy, Accessibility Module may occasionally cite initial issues that, through additional manual testing, are found to be false positives. Due to limitations of automated testing, the Accessibility Module checks are not intended to be authoritative, and are not intended to convey a Section 508 conformance assessment.

Only a professional evaluator can perform a complete accessibility evaluation. Agencies should use both manual and automated tests to fully assess whether their website is accessible. For testing guidance, please refer to the Harmonized Testing Process for Section 508 Compliance: Baseline Tests for Software and Web Accessibility.

Section 508 Accessibility Standards

In 2000, Section 508 of the Rehabilitation Act of 1973 was amended to include technical requirements for all Federal government Electronic & Information Technology (EIT) to be made accessible to persons with disabilities. ‘Section 508’ has since become synonymous with technology accessibility standards in government jargon. Refer to the Section 508 standards for more information.

WCAG 2.0

Around the same time that the government was amending Section 508, the World Wide Web Consortium (W3C) was busy developing their own standards. The first official version, released in 1999, was call the Web Content Accessibility Guidelines (WCAG 1.0). To keep pace with the evolving online environment, the standards were updated in 2008 to their current version, WCAG 2.0. In the proposed Section 508 Standards refresh, the web content section formally incorporates the more detailed WCAG 2.0 Level AA standards. Refer to the WCAG 2.0 Guidelines for more informations.

Why is this important?

Citizens rely on their government for a range of essential services that impact their well-being, such as medicare/medicaid/social security support, assistance in finding low-income housing, travel information from the State Department, health information from the CDC, etc. Disabled veterans rely on the support of the Department of Veteran’s Affairs for a range of vital services. All citizens must file an annual tax return. Many small companies access government websites to bid on government contracts and grow their business.

When this information is presented in a way that is not accessible to people with disabilities, those people are shut out from essential services and opportunities that should be available to all Americans. Additionally, a large number of Americans with disabilities are employed by the federal government, and having accessible technology is essential for them to be able to perform their work effectively. Accessibility has long been a priority for the federal government, and a recent White House web standards memo further reinforced our commitment that all federal websites are accessible to all users.

Limitations

All issues which prevent full access to websites is not possible with the current state of automated testing tools. For instance, while we can automatically check if an image on a website has an alt text attribute, we cannot measure if that alt text is sufficiently descriptive; a picture of a dog with an alt text attribute that reads “cow” would pass the automatic check, but since the alt text is incorrect, the image is not accessible. While we can detect the background color and text color by reading a page’s Cascading Style Sheets (CSS), we may not be able to detect the color of an image; if text is overlayed on a background image, we would not be able to measure whether the level of contrast is sufficient. It is for these reasons that fully assessing a site’s accessibility still requires manual evaluation by an accessibility professional.

How common accessibility issues impact website visitors?

There are a wide range of requirements for accessible web content. Here are a few examples of common accessibility issues:

How we measure accessibility on Accessibility Module?

While we cannot fully measure accessibility with automated tools, we can measure for broader potential issues on websites, such as whether an image does or does not contain alt text, whether there is sufficient contrast between the text and background, whether a page is properly structured for someone using a screen reader to access the information, etc. To do this, we employ an open-source tool known as Pa11y. Pa11y uses another open-source tool, the HTML_Codesniffer, to identify accessibility issues.

Other measurement tools

While Pa11y is the tool we chose to measure accessibility on Accessibility Module, there are a range of other excellent proprietary and open-source tools available to assist web developers and IT managers in understanding how to build accessible technology.

The HTML_Codesniffer, the technology behind Pa11y, is a browser extension that can be used to automatically detect some accessibility issues on a webpage. The HTML_Codesniffer will point out the particular code snippet with the issue, the location of the issue on the page, and the principle violated by the issue.

To showcase another example, the University of Illinois has been working for several years to develop another free, open-source tool, the Functional Accessibility Evaluator (FAE). While the tool is still under development, the current version is an excellent way to evaluate a full website; in contrast to Pa11y, the FAE can crawl the subwebsites of a website, allowing a more comprehensive scan that can identify more potential accessibility issues.

How to correct accessibility issues?

The tools and Success Criteria Guidance provided in the table provide web developers and content managers with the information they need to pinpoint the issues on their pages. If you need help fixing issues identified in Accessibility Module, contact your agency’s 508 coordinator. Additionally, GSA’s Office of Governmentwide Policy (OGP) conducts training to help 508 coordinators and IT/content professionals better understand how to build accessible technology. To learn more about accessible technology, contact the Government-wide Section 508 Program at Section.508@gsa.gov or visit https://section508.gov/