Checker Tests

These are the tests currently carried out by the Checker. All results are preliminary and are provided for informational use only. If you discover a bug, or have questions or suggestions for improvement, please send us your feedback.

The Checker covers 9 of the 38 success criteria of WCAG 2.0 Level AA. Even if a page passes all tests, this does not guarantee its accessibility for users with disabilities.

Click on the test name to view the detailed test information including a description of the test, the relationship to WCAG 2.0, and instructions how to repair the problem. You can also view the possible results of the test.

List of Tests

Check to view tests

Applied Tests grouped by Success Criterion

  • Success Criterion 2.4.2: Page Titled
    Short info on "Success Criterion 2.4.2"
    Web pages have titles that describe topic or purpose. [Level A]

    Titles identify the current location without requiring users to read or interpret page content. When titles appear in site maps or lists of search results, users can more quickly identify the content they need. User agents make the title of the page easily available to the user for identifying the page. For instance, a user agent may display the page title in the window title bar or as the name of the tab containing the page.

    Understanding: Success Criterion 2.4.2
  • Success Criterion 2.4.4: Link Purpose (In Context)
    Short info on "Success Criterion 2.4.4"
    The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context , except where the purpose of the link would be ambiguous to users in general . [Level A]

    Whenever possible, provide link text that identifies the purpose of the link without needing additional context. ... Meaningful links help users choose which links to follow without requiring complicated strategies to understand the page. In some situations, authors may want to provide part of the description of the link in logically related text that provides the context for the link. In this case the user should be able to identify the purpose of the link without moving focus from the link. In other words, they can arrive on a link and find out more about it without losing their place.

    Understanding: Success Criterion 2.4.4
  • Success Criterion 2.4.6: Headings and Labels
    Short info on "Success Criterion 2.4.6"
    Headings and labels describe topic or purpose. [Level AA]

    When headings are clear and descriptive, users can find the information they seek more easily, and they can understand the relationships between different parts of the content more easily. Descriptive labels help users identify specific components within the content.

    Understanding: Success Criterion 2.4.6
  • Success Criterion 3.1.1: Language of Page
    Short info on "Success Criterion 3.1.1"
    The default human language of each Web page can be programmatically determined . [Level A]

    The intent of this Success Criterion is to ensure that content developers provide information in the Web page that user agents need to present text and other linguistic content correctly. Both assistive technologies and conventional user agents can render text more accurately when the language of the Web page is identified. Screen readers can load the correct pronunciation rules. Visual browsers can display characters and scripts correctly. Media players can show captions correctly.

    Understanding: Success Criterion 3.1.1
  • Success Criterion 3.1.2: Language of Parts
    Short info on "Success Criterion 3.1.2"
    The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text. [Level AA]

    The intent of this Success Criterion is to ensure that user agents can correctly present content written in multiple languages. This makes it possible for user agents and assistive technologies to present content according to the presentation and pronunciation rules for that language. This applies to graphical browsers as well as screen readers, braille displays, and other voice browsers.

    Understanding: Success Criterion 3.1.2
  • Success Criterion 3.2.2: On Input
    Short info on "Success Criterion 3.2.2"
    Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. [Level A]

    The intent of this Success Criterion is to ensure that entering data or selecting a form element has predictable effects. Changing the setting of any user interface component is changing some state in the control that will persist when the user is no longer interacting with it. So checking a checkbox or entering text into a text field changes its setting, but activating a link or a button does not. Changes in context can confuse users who do not easily perceive the change or are easily distracted by changes. Changes of context are appropriate only when it is clear that such a change will happen in response to the user's action.

    Understanding: Success Criterion 3.2.2
  • Success Criterion 3.3.2: Labels or Instructions
    Short info on "Success Criterion 3.3.2"
    Labels or instructions are provided when content requires user input. [Level A]

    To help avoid mistakes it is good user interface design to provide simple instructions and cues for entering information. Some users with disabilities may be more likely to make mistakes than users without disabilities or recovery from mistakes may be more difficult, making mistake avoidance an important strategy for users with disabilities. People with disabilities rely on well documented forms and procedures to interact with a page. Blind users need to know exactly what information should be entered into form fields and what the available choices are. Simple instructions visually connected to form elements can assist users with cognitive disabilities or those accessing a page using a screen magnifier.

    Understanding: Success Criterion 3.3.2
  • Success Criterion 4.1.1: Parsing
    Short info on "Success Criterion 4.1.1"
    In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete. [Level A]

    The intent of this Success Criterion is to ensure that user agents, including assistive technologies, can accurately interpret and parse content. If the content cannot be parsed into a data structure, then different user agents may present it differently or be completely unable to parse it. Some user agents use "repair techniques" to render poorly coded content. Since repair techniques vary among user agents, authors cannot assume that content will be accurately parsed into a data structure or that it will be rendered correctly, … unless the content is created according to the rules defined in the formal grammar.

    Understanding: Success Criterion 4.1.1
  • Success Criterion 4.1.2: Name, Role, Value
    Short info on "Success Criterion 4.1.2"
    For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined ; states, properties, and values that can be set by the user can be programmatically set ; and notification of changes to these items is available to user agents , including assistive technologies . Note: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification. [Level A]

    The intent of this Success Criterion is to ensure that Assistive Technologies (AT) can gather information about, activate(or set) and keep up to date on the status of user interface controls in the content. When standard controls from accessible technologies are used, this process is straightforward. If the user interface elements are used according to specification the conditions of this provision will be met. ... Examples of user interface control state are whether or not a checkbox or radio button has been selected, or whether or not a collapsible tree or list node is expanded or collapsed. Providing role, state, and value information on all user interface components enables compatibility with assistive technology, such as screen readers, screen magnifiers, and speech recognition software, used by people with disabilities.

    Understanding: Success Criterion 4.1.2

Select a test to display the details

Test Detail: Providing descriptive titles for web pages

(Test for Success Criterion 2.4.2: Page Titled)

Results

Failed The title of the page is missing

There is no title element in the head element.

Failed The title of the page is empty

The title element is empty.

Failed The title of the page seems to be suspicious

The title seems to be a default or placeholder text instead of a proper description of the content.

Verification required Please check the title of the page

Human input is necessary to verify, that the title describes the content of the page.

Passed The title of the page seems to be descriptive

The title of the web page seems to describe the content.

About this Test

Checked Elements: title element

This test checks, whether the title of the web page identifies the contents or purpose of the page.

Short Description

It is important to provide a descriptive title for your web page.
Titles should identify the content of the web page without requiring users to read or interpret the page. They are used in a variety of places like search results, bookmarks, title bar and tabs of user agent, or the browser history to identify the page.

Understanding Success Criterion 2.4.2: Page Titled

How to Repair

Provide a descriptive title using the title element in the head of the page.

The title should always enable the user to distinguish different pages and identify their content.

  • Keep your titles simple, short and precise and
  • put the most specific information at the front (as the title might be cut off).
  • Don't use same titles for more than one page and and avoid unclear titles.

Writing Better Web Page Titles

WCAG 2.0

Principle 2: Operable
User interface components and navigation must be operable. WCAG 2.0: Principle 2
Guideline 2.4: Navigable
Provide ways to help users navigate, find content, and determine where they are. Understanding Guideline 2.4
Success Criterion 2.4.2: Page Titled (Level A)
Web pages have titles that describe topic or purpose. Understanding: Success Criterion 2.4.2
Techniques

Test Detail: Providing text alternatives in image maps

(Test for Success Criterion 2.4.4: Link Purpose (In Context))

Results

Failed The area has no alternative text

There is no alternative text for the area of the image map that could serve the same purpose as the selectable area of the image.

Failed The link text of the area seems to be suspicious

The alternative text of the area in the image map seems to be a default or placeholder text instead of a proper description of the selectable area.

Failed The link text of the area is ambiguous

The alternative text of the area in the image map is a duplicate of another alternative text in the same image map.

Verification required Please check the link text of the area

Human input is necessary to verify, that the alternative text of the area serves the same purpose as the selectable area of the image.

About this Test

Checked Elements: area element

This test checks, if the area elements in image maps have an alternative text that describes the target of the link.

Short Description

An image map is an image divided into selectable regions defined by area elements (each area is a link).
It is important to provide an alternative text in the area element, that serves the same purpose as the selectable area of the image. Specifying alternate text assists users without graphic display terminals, users whose browsers don't support forms, visually impaired users, those who use speech synthesizers, those who have configured their graphical user agents not to display images, etc.

Understanding Success Criterion 2.4.4: Link Purpose (In Context)

How to Repair

Provide a text in the alt attribute of the area element that serves the same purpose as the selectable area of the image.

WCAG 2.0

Principle 2: Operable
User interface components and navigation must be operable. WCAG 2.0: Principle 2
Guideline 2.4: Navigable
Provide ways to help users navigate, find content, and determine where they are. Understanding Guideline 2.4
Success Criterion 2.4.4: Link Purpose (In Context) (Level A)
The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context , except where the purpose of the link would be ambiguous to users in general . Understanding: Success Criterion 2.4.4
Technique

Test Detail: Providing descriptive headings

(Test for Success Criterion 2.4.6: Headings and Labels)

Results

Failed The heading is empty

There is no content in the heading.

Failed There is no text in the heading

The heading element contains only non-text content.

Verification required Please check the heading

Human input is necessary to verify, that the heading describes the section it belongs to.

Passed The heading seems to be descriptive

The heading seems to describe the section it belongs to.

About this Test

Checked Elements: h1-h6

This test checks, whether the headings identify their section of the content.

Short Description

It is important to provide a descriptive headings in your web page.
Descriptive headings give users an overview of the content and its organization, and help users find specific content and orient themselves within the web page. They identify sections of the content in relation both to the web page as a whole and to other sections of the same web page.

Understanding Success Criterion 2.4.6: Headings and Labels

How to Repair

Provide text in the headings, that describes the section. If you need to use images as headings, provide an alternative text with the content of the heading in the alt attribute of the image.

Keep your headings short and succinct and try to putting the most important information at the beginning of each heading. This helps users “skim" the headings to locate the specific content they need, and is especially helpful when browsers or assistive technology allow navigation from heading to heading.

Quick tips for accessible headings

WCAG 2.0

Principle 2: Operable
User interface components and navigation must be operable. WCAG 2.0: Principle 2
Guideline 2.4: Navigable
Provide ways to help users navigate, find content, and determine where they are. Understanding Guideline 2.4
Success Criterion 2.4.6: Headings and Labels (Level AA)
Headings and labels describe topic or purpose. Understanding: Success Criterion 2.4.6
Technique

Test Detail: Providing descriptive labels

(Test for Success Criterion 2.4.6: Headings and Labels)

Results

Failed The label is missing

There is no associated label for the form control.

Failed The label is empty

There is no content in the label.

Failed There is no text in the label

The label element contains only non-text content.

Failed The label is ambiguous

The text of the label is a duplicate of another label that occurs before this one in the same fieldset or form.

Verification required Please check the label

Human input is necessary to verify, that the label describes the purpose of the form control.

About this Test

Checked Elements: form elements

This test checks, whether the form control has an associated label that could be descriptive.

Short Description

It is important, that the label for any form control makes the control's purpose clear. Using the label element for associating labels with form control allows assistive technology to recognize the label and present it to the user.

Understanding Success Criterion 2.4.6: Headings and Labels

How to Repair

Provide a label element with a descriptive text for the form control. Associate the label with the form control, by using the id of the control as the value for the for attribute of the label.

Accessible HTML/XHTML Forms: Intermediate Level

WCAG 2.0

Principle 2: Operable
User interface components and navigation must be operable. WCAG 2.0: Principle 2
Guideline 2.4: Navigable
Provide ways to help users navigate, find content, and determine where they are. Understanding Guideline 2.4
Success Criterion 2.4.6: Headings and Labels (Level AA)
Headings and labels describe topic or purpose. Understanding: Success Criterion 2.4.6
Technique

Test Detail: Setting the main language of the page

(Test for Success Criterion 3.1.1: Language of Page)

Results

Failed No main language specified for the page

The language attributes are missing on the html element.

Failed The specification of the language of the page is incomplete

A language attribute is missing on the head element.

Failed The specification of the main language of the page is ambiguous

There are 2 conflicting language codes specified for the main language of the page.

Failed The main language of the page is not specified correctly

The language code is not in accordance with BCP 47.

Failed The main language specified for the page seems to be incorrect

Most of the page seems to be in a different language than the specified main language.

Verification required Please check the main language of the page

Human input is necessary to verify, that the main language specified for the page corresponds to the mainly used language.

Passed The language specified as the main language of the page seems to be correct

The specified language of the page seems to correlate with the mainly used language.

About this Test

Checked Elements: html element

This test checks, if the default language of a document is specified correctly by providing the lang and/or xml:lang attribute on the html element.

Short Description

It is necessary to mark the main language of a web page. This makes it possible for user agents and assistive technologies to present content correctly.
Screen readers can use the pronunciation rules of the language of the text. Visual browsers can display characters and scripts in appropriate ways. Furthermore automatic processing of the content like automatic translation or providing additional informations using a dictionary are made possible.

Understanding Success Criterion 3.1.1: Language of Page

How to Repair

Use the lang and xml:lang attributes on the html element to specify the main language used in the web page.

  • For HTML the lang attribute is required,
  • XHTML 1.1. requires the xml:lang attribute,
  • and for XHTML 1.0 you need to use both.

If you use both attributes, their values have to be the same.

The value of the language attribute is composed from a sequence of one or more "subtags" divided by "-", each of which refines or narrows the range of language. It has to conform to BCP 47.

Examples of valid language tags are

  • nb – for Norwegian Bokmal
  • nn – for Norwegian Nynorsk
  • en – for English
  • en-US – for English as used in the USA

Further Information:

WCAG 2.0

Principle 3: Understandable

Information and the operation of user interface must be understandable.

WCAG 2.0: Principle 3
Guideline 3.1: Readable
Make text content readable and understandable. Understanding Guideline 3.1
Success Criterion 3.1.1: Language of Page (Level A)
The default human language of each Web page can be programmatically determined . Understanding: Success Criterion 3.1.1
Technique

Test Detail: Using language specifications within the content

(Test for Success Criterion 3.1.2: Language of Parts)

Results

Failed The specification of the language is incomplete

A language attribute is missing.

Failed The language specification is ambiguous

There are 2 conflicting language codes specified for some part of the content.

Failed The language is not specified correctly

The specified language code for some part of the content is not in accordance with BCP 47.

About this Test

Checked Elements: All elements in (and including) the body

This test checks, if language specifications provided by the lang and/or xml:lang attributes within the content are valid.

Short Description

If you specify languages for elements within the content of web pages, do this according to specifications. This is necessary, so that user agents can interpret the definitions correctly.

Understanding Success Criterion 3.1.2: Language of Parts

How to Repair

The language of an element can be specified by its lang and/or xml:lang attributes.

  • For HTML you need to use the lang attribute,
  • for XHTML 1.1. you will need the xml:lang attribute,
  • and for XHTML 1.0 pages you need to use both.

If you use both attributes, their values have to be the same.

The value of the language attribute is composed from a sequence of one or more "subtags" divided by "-", each of which refines or narrows the range of language. It has to conform to BCP 47.
Examples of valid language tags are

  • nb – for Norwegian Bokmal
  • nn – for Norwegian Nynorsk
  • en – for English
  • en-US – for English as used in the USA

Further Information
Declaring Language in XHTML and HTML
Internationalization Best Practices: Specifying Language in XHTML & HTML Content
Language Subtag Registry
BCP 47, Tags for the Identification of Languages & Matching of Language Tags

WCAG 2.0

Principle 3: Understandable

Information and the operation of user interface must be understandable.

WCAG 2.0: Principle 3
Guideline 3.1: Readable
Make text content readable and understandable. Understanding Guideline 3.1
Success Criterion 3.1.2: Language of Parts (Level AA)
The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text. Understanding: Success Criterion 3.1.2
Technique

Test Detail: Specifying language changes in the content

(Test for Success Criterion 3.1.2: Language of Parts)

Results

Failed The language specification seems to be incorrect

The specified language of some part of the content seems to differ from the used language.

Verification required Please check the language

Human input is necessary to verify, that the specified language correlates with the used language.

Passed The specified language seems to be correct

The specified language seems to correlate with the used language.

About this Test

Checked Elements: Continuous run of text

This test checks passages of text on the web page to see if the language used matches the specified language.

Short Description

It is necessary to mark language changes in the content. This makes it possible for user agents and assistive technologies to present the entire content correctly.

Screen readers can use the pronunciation rules of the language of the text. Visual browsers can display characters and scripts in appropriate ways. Furthermore automatic processing of the content like automatic translation or providing additional informations using a dictionary are made possible.

Understanding Success Criterion 3.1.2: Language of Parts

How to Repair

Add markup around the text which is in another language and use the lang and xml:lang attributes to specify the correct language.

Further Information

WCAG 2.0

Principle 3: Understandable

Information and the operation of user interface must be understandable.

WCAG 2.0: Principle 3
Guideline 3.1: Readable
Make text content readable and understandable. Understanding Guideline 3.1
Success Criterion 3.1.2: Language of Parts (Level AA)
The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text. Understanding: Success Criterion 3.1.2
Technique

Test Detail: Providing a submit button to initiate a change of context

(Test for Success Criterion 3.2.2: On Input)

Results

Verification required Please check that implicit changes of context are described

Human input is necessary to verify, that the submit button is the only way to initiate a change of context with the form or that there is a description of the change before the initiating form control.

About this Test

Checked Elements: form elements

This test checks, if data in a form can be submitted explicitly by using submit buttons (input type="submit", input type="image", or button type="submit").

Short Description

Major changes in the content of the Web page can disorient users who are not able to view the entire page simultaneously, if they are made without user awareness. Using a button to submit data in a form explicitly is an appropriate control to use for causing a change of context.

Further Information: Changes of context

Understanding Success Criterion 3.2.2: On Input

How to Repair

WCAG 2.0

Principle 3: Understandable

Information and the operation of user interface must be understandable.

WCAG 2.0: Principle 3
Guideline 3.2: Predictable
Make Web pages appear and operate in predictable ways. Understanding Guideline 3.2
Success Criterion 3.2.2: On Input (Level A)
Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. Understanding: Success Criterion 3.2.2
Technique

Test Detail: Submitting forms without submit buttons

(Test for Success Criterion 3.2.2: On Input)

Results

Failed The form can not be submitted accessibly

A submit button is missing.

About this Test

Checked Elements: forms without submit buttons

This test checks, if the submission of forms without submit buttons is accessible and predictable.

Short Description

It is necessary to provide a submit button for forms with multiple controls or forms containing other controls than radio buttons, checkboxes or select boxes. If such forms don't have a submit button, changes to controls may lead to unintended submissions and it is difficult to impossible for people using assistive technologies to submit the form.

Understanding Success Criterion 3.2.2: On Input

How to Repair

Add a submit button (input type="submit", input type="image", or button type="submit") to the form.

Make sure that the action specified for the form performs the desired action. Also make sure, that any changes to form elements within the form do not cause a change of context or that any such changes are described before the initiating control.

WCAG 2.0

Principle 3: Understandable

Information and the operation of user interface must be understandable.

WCAG 2.0: Principle 3
Guideline 3.2: Predictable
Make Web pages appear and operate in predictable ways. Understanding Guideline 3.2
Success Criterion 3.2.2: On Input (Level A)
Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. Understanding: Success Criterion 3.2.2
Techniques

Test Detail: Informing about changes of context caused by changes to a form control

(Test for Success Criterion 3.2.2: On Input)

Results

Verification required Please check that a change of context, initiated within or by the form, is described

Human input is necessary to verify, that the change of context is described prior to the form or initiating form control.

Verification required Please check that a change of context is described

Human input is necessary to verify, that a change of context is described prior to the initiating form control.

About this Test

Checked Elements: form elements without submit buttons

This test checks, if changes of context caused by changes to form controls are accessible and predictable.

Short Description

Because changing the value of a form control does not typically result in a change of context, it is important that authors provide instructions that make the user aware of the behavior in advance.

Further Information: Changes of context

Understanding Success Criterion 3.2.2: On Input

How to Repair

WCAG 2.0

Principle 3: Understandable

Information and the operation of user interface must be understandable.

WCAG 2.0: Principle 3
Guideline 3.2: Predictable
Make Web pages appear and operate in predictable ways. Understanding Guideline 3.2
Success Criterion 3.2.2: On Input (Level A)
Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. Understanding: Success Criterion 3.2.2
Technique

Test Detail: Using a label to identify the purpose of a form control

(Test for Success Criterion 3.3.2: Labels or Instructions)

Results

Failed There is no label to identify the purpose of the form control (simple form)

There is no associated label for the form control that could identify its purpose and the alternatively usable title or adjacent button are also missing.

Failed There is no label to identify the purpose of the form control

There is no label for the form control that could identify its purpose and the alternatively usable title is also missing.

Failed The purpose of the form control is not stated (simple form)

The label identifying the purpose of the form control is empty and the alternatively usable title attribute of the control or adjacent button are also missing.

Failed The purpose of the form control is not stated

The label identifying the purpose of the form control is empty and the alternatively usable title attribute of the control is also missing.

Failed There is no text in the label

The label element contains only non-text content.

Failed The label is ambiguous

The text of the label is a duplicate of another label that occurs before this one in the same fieldset or form.

Failed The label is at the wrong position

The label element is located at a position it is not expected to be.

Verification required Please check the label

Human input is necessary to verify, that the label describes the purpose of the form control.

About this Test

Checked Elements: form controls

This test checks, if the purpose of a form control is identified by an associated label element.

Short Description

It is important, that the label for any form control makes the control's purpose clear.

The preferred way of associating a label with a form control is to use an associated label element.
For radio buttons and checkboxes the label should be placed after the form control, for all other form controls it should be placed before.

Understanding Success Criterion 3.3.2: Labels or Instructions

How to Repair

Add a label element and associate it with the form control by referencing the id of the control as the value of the for attribute of the label. The text of the label should describe the purpose of the control unambiguously.
For radio buttons and checkboxes place the label after the form control, for all other elements place it before.

Further information: Accessible HTML/XHTML Forms: Intermediate Level

Note: It is also possible to label a form control with its title or an adjacent button, but those practices are not recommended and should only be applied if there is no room for a label element in the layout.

WCAG 2.0

Principle 3: Understandable

Information and the operation of user interface must be understandable.

WCAG 2.0: Principle 3
Guideline 3.3: Input Assistance
Help users avoid and correct mistakes. Understanding Guideline 3.3
Success Criterion 3.3.2: Labels or Instructions (Level A)
Labels or instructions are provided when content requires user input. Understanding: Success Criterion 3.3.2
Techniques

Test Detail: Using the title attribute to identify the purpose of a form control

(Test for Success Criterion 3.3.2: Labels or Instructions)

Results

Failed The labelling title is ambiguous

The title used for labeling the form control is a duplicate of another title of a form control that occurs before this one in the same fieldset or form.

Verification required Please check the labelling title

Human input is necessary to verify, that the title describes the purpose of the form control.

About this Test

Checked Elements: form controls

This test checks, if the purpose a form element is identified by its title attribute.

Short Description

It is important, that the label for any form element makes the control's purpose clear.
The preferred way of associating a label with a form control is to use an associated label element, but it is also possible to use the title attribute of the control if there is no room for the label in the design.

Understanding Success Criterion 3.3.2: Labels or Instructions

How to Repair

Use a title, which describes the purpose of the control unambiguously.

WCAG 2.0

Principle 3: Understandable

Information and the operation of user interface must be understandable.

WCAG 2.0: Principle 3
Guideline 3.3: Input Assistance
Help users avoid and correct mistakes. Understanding Guideline 3.3
Success Criterion 3.3.2: Labels or Instructions (Level A)
Labels or instructions are provided when content requires user input. Understanding: Success Criterion 3.3.2
Technique

Test Detail: Using a button to identify the purpose of a form control

(Test for Success Criterion 3.3.2: Labels or Instructions)

Results

Failed The labelling adjacent button has no text

The button used for labeling the form control has no text value, which could be used to identify its purpose.

Failed The text of the labelling adjacent button is to general

The button used for labeling a form control has a text value, which can not be used to identify the purpose of the form control.

Verification required Please check the labelling button

Human input is necessary to verify, that the text value of the button describes the purpose of the form control.

About this Test

Checked Elements: form controls

This test checks, if the purpose a form control is identified by an adjacent button.

Short Description

It is important, that the label for any form control makes the control's purpose clear.
The preferred way of associating a label with a form control is to use an associated label element, but it is also possible to use an adjacent button if there is no room for the label in the design.

Understanding Success Criterion 3.3.2: Labels or Instructions

How to Repair

Add a text value to the button, that makes the purpose of the form control clear.
For instance for a search field, add the word "search" to the button.

WCAG 2.0

Principle 3: Understandable

Information and the operation of user interface must be understandable.

WCAG 2.0: Principle 3
Guideline 3.3: Input Assistance
Help users avoid and correct mistakes. Understanding Guideline 3.3
Success Criterion 3.3.2: Labels or Instructions (Level A)
Labels or instructions are provided when content requires user input. Understanding: Success Criterion 3.3.2
Technique

Test Detail: Structuring forms

(Test for Success Criterion 3.3.2: Labels or Instructions)

Results

Failed The form seems to need structuring

The amount of form controls within the form usually needs grouping by fieldsets.

Passed The form seems to be structured correctly

There are no more than 8 form controls not grouped by fieldsets.

About this Test

Checked Elements: form elements

This test checks, if there are not more than 8 controls in a form, not grouped by fieldsets.

Short Description

It is necessary to provide a semantic grouping for related form controls. This allows users to understand the relationship of the controls and interact with the form more quickly and effectively.

Form controls that are logically related (like address fields) should be grouped by enclosing them with a fieldset element. All controls within a given fieldset are then related.

Understanding Success Criterion 3.3.2: Labels or Instructions

How to Repair

Add a fieldset element around every related group of form controls. Provide a descriptive legend element as the first element of the fieldset that states the meaning of, or instructions for the enclosed elements.

WCAG 2.0

Principle 3: Understandable

Information and the operation of user interface must be understandable.

WCAG 2.0: Principle 3
Guideline 3.3: Input Assistance
Help users avoid and correct mistakes. Understanding Guideline 3.3
Success Criterion 3.3.2: Labels or Instructions (Level A)
Labels or instructions are provided when content requires user input. Understanding: Success Criterion 3.3.2
Technique

Test Detail: Labelling groups of form elements

(Test for Success Criterion 3.3.2: Labels or Instructions)

Results

Failed The legend is missing

There is no legend labeling the fieldset.

Failed The legend is empty

There is no content in the legend.

Failed There is no text in the legend

The legend element contains only non-text content.

Failed The legend is ambiguous

The text of the legend element is a duplicate of another legend that occurs before this one in the same form.

Verification required Please check the legend

Human input is necessary to verify, that the legend describes the group formed by the fieldset.

About this Test

Checked Elements: fieldset element

This test checks, if the fieldset has a descriptive label provided by the legend element.

Short Description

The first element inside every fieldset should be a legend element, which provides a label or instructions for the group. Often, user agents will present the value of the legend before the label of each control, to remind users that they are part of the same group.

Understanding Success Criterion 3.3.2: Labels or Instructions

How to Repair

Provide a descriptive legend element as the first element of the fieldset.

Further information: Accessible Forms using WCAG 2.0

WCAG 2.0

Principle 3: Understandable

Information and the operation of user interface must be understandable.

WCAG 2.0: Principle 3
Guideline 3.3: Input Assistance
Help users avoid and correct mistakes. Understanding Guideline 3.3
Success Criterion 3.3.2: Labels or Instructions (Level A)
Labels or instructions are provided when content requires user input. Understanding: Success Criterion 3.3.2
Technique

Test Detail: Defining ids

(Test for Success Criterion 4.1.1: Parsing)

Results

Failed The id is incorrect

The syntax of the id value is not correct.

Failed The id is not unique

The id value of the element is a duplicate of an id that occurs before this element.

Passed The ID is valid

The value of the id attribute is unique and syntactically correct.

About this Test

Checked Elements: Elements with a defined id attribute

This test checks, if the values of the id attributes are syntactically correct and unique.

Short Description

IDs have to be unique and their syntax has to be correct.

When id attribute values are not unique, they are particularly problematic when referenced by labels, headers in data tables, or used as fragment identifiers, as user agents do not have enough information to determine essential relationships (i.e., to determine which label goes with which item).

ID tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").

Understanding Success Criterion 4.1.1: Parsing

How to Repair

IDs are assigned to an element with the id attribute. If an ID is invalid, assign a new, unique ID, having the following syntax:
ID tokens

  • must begin with a letter ([A-Za-z]) and
  • may be followed by
    • any number of letters,
    • digits ([0-9]),
    • hyphens ("-"),
    • underscores ("_"),
    • colons (":"), and
    • periods (".").

Take care, to also update all references to the old ID.

WCAG 2.0

Principle 4: Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. WCAG 2.0: Principle 4
Guideline 4.1: Compatible
Maximize compatibility with current and future user agents, including assistive technologies. Understanding Guideline 4.1
Success Criterion 4.1.1: Parsing (Level A)
In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete. Understanding: Success Criterion 4.1.1
Techniques

Test Detail: Using accesskeys

(Test for Success Criterion 4.1.1: Parsing)

Results

Failed The accesskey is not unique

The accesskey value of the element is a duplicate of an accesskey that occurs before this element.

Passed The accesskey is unique

There is no element with the same accesskey before the inspected element.

About this Test

Checked Elements: Elements for which the accesskey attribute is allowed and defined

This test checks, if the defined accesskey values are unique.

Short Description

Accesskeys are used to access an element with the keyboard directly. If their values are not unique, the result of pressing the key is not uniquely resolvable.

In HTML4.01 and XHTML, accesskeys are allowed for the following elements: a, area, button, input, label, legend, textarea. HTML5 allows the accesskey attribute on all elements.

Understanding Success Criterion 4.1.1: Parsing

How to Repair

Assign a new, unique, one character long accesskey to the element.

WCAG 2.0

Principle 4: Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. WCAG 2.0: Principle 4
Guideline 4.1: Compatible
Maximize compatibility with current and future user agents, including assistive technologies. Understanding Guideline 4.1
Success Criterion 4.1.1: Parsing (Level A)
In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete. Understanding: Success Criterion 4.1.1
Technique

Test Detail: Referencing form controls

(Test for Success Criterion 4.1.1: Parsing)

Results

Failed The reference to a form control is invalid

The structure of the id, referenced by the for attribute of the label, is not valid.

Failed The label does not reference a form control

The id referenced by the for attribute is not defined on a fitting form control.

Passed The label has a corresponding form control

The id referenced by the for attribute is defined on an appropriate form control.

About this Test

Checked Elements: label elements with the for attribute

This test checks, if the id referenced by the for attribute of the label element is valid and has a corresponding element.

Short Description

The for attribute of the label element references a form control by its id. This ID has to be valid and has to be defined on a form control within the same form element (or web page if the label is not contained in a form).

Understanding Success Criterion 4.1.1: Parsing

How to Repair

Associate the label with its form control, by using the value of the id attribute of the control as the value of the for attribute of the label.

If the form control has no or an invalid ID, assign a valid ID to it. ID tokens

  • must begin with a letter ([A-Za-z]) and
  • may be followed by
    • any number of letters,
    • digits ([0-9]),
    • hyphens ("-"),
    • underscores ("_"),
    • colons (":"), and
    • periods (".").

WCAG 2.0

Principle 4: Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. WCAG 2.0: Principle 4
Guideline 4.1: Compatible
Maximize compatibility with current and future user agents, including assistive technologies. Understanding Guideline 4.1
Success Criterion 4.1.1: Parsing (Level A)
In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete. Understanding: Success Criterion 4.1.1
Technique

Test Detail: Referencing table cells as headers

(Test for Success Criterion 4.1.1: Parsing)

Results

Failed A reference to a header cell is invalid

The id referenced by the headers attribute is invalid.

Failed The headers attribute does not reference a table cell

The id referenced by the headers attribute is not defined on an appropriate table cell.

Passed All headers of the table cell exist

The ids referenced by the headers attribute are defined on adequate table cells.

About this Test

Checked Elements: th and td elements with the headers attribute

This test checks, if the ids, referenced by the headers attribute of the th or td element, are valid and have a corresponding id value.

Short Description

The headers attribute of the th and td element specifies the table cells related to the cell as being a header. The header table cells are referenced by their id, split by whitespace. This ID has to be valid and must be defined on a cell within the same table.

Understanding Success Criterion 4.1.1: Parsing

How to Repair

Check, that the IDs referenced by the headers attribute are split by whitespace and that all IDs are valid. ID tokens

  • must begin with a letter ([A-Za-z]) and
  • may be followed by
    • any number of letters,
    • digits ([0-9]),
    • hyphens ("-"),
    • underscores ("_"),
    • colons (":"), and
    • periods (".").

If the IDs are valid and split correctly, add a unique and valid id to the table cell used as a header and exchange the unmatched reference in the headers attribute by the newly assigned ID.

WCAG 2.0

Principle 4: Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. WCAG 2.0: Principle 4
Guideline 4.1: Compatible
Maximize compatibility with current and future user agents, including assistive technologies. Understanding Guideline 4.1
Success Criterion 4.1.1: Parsing (Level A)
In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete. Understanding: Success Criterion 4.1.1
Technique

Test Detail: Referencing image maps

(Test for Success Criterion 4.1.1: Parsing)

Results

Failed The reference to an image map is invalid

The id or name referenced by the usemap attribute is invalid.

Failed The usemap attribute does not reference an image map

The id or name referenced by the usemap attribute is not defined on an appropriate map.

Passed The element uses an image map

The usemap attribute of the element references a corresponding map element.

About this Test

Checked Elements: img, input and object elements with a usemap attribute

This test checks, if the id or name, used by the usemap attribute of the element, is valid and references a corresponding map element.

Short Description

The usemap attribute references an image map.
For HTML 4.01 a map element with a corresponding name attibute has to exist, for XHTML 1.1 a map with the corresponding id is required, and for XHTML 1.0 usemap can reference the map either by its name or id. Name and id have to be valid.

Understanding Success Criterion 4.1.1: Parsing

How to Repair

For HTML 4.01:
Associate the element with a map element with the usemap attribute. The value of the usemap attribute is a '#' followed by the value of the name attribute of the map.
If the map has no or an invalid name value, assign a valid name to it.

For XHTML:
Associate the element with a map element with the usemap attribute. The value of the usemap attribute is a '#' followed by the value of the name attribute of the map.
If the map has no or an invalid name or id value, assign a valid name or id to it.

Name and id tokens

  • must begin with a letter ([A-Za-z]) and
  • may be followed by
    • any number of letters,
    • digits ([0-9]),
    • hyphens ("-"),
    • underscores ("_"),
    • colons (":"), and
    • periods (".").

If there is no map used, delete the usemap attribute.

WCAG 2.0

Principle 4: Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. WCAG 2.0: Principle 4
Guideline 4.1: Compatible
Maximize compatibility with current and future user agents, including assistive technologies. Understanding Guideline 4.1
Success Criterion 4.1.1: Parsing (Level A)
In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete. Understanding: Success Criterion 4.1.1
Technique

Test Detail: Writing correct code

(Test for Success Criterion 4.1.1: Parsing)

Results

Failed The (X)HTML code is not well-formed

There is an error in the structure of a tag or attribute.

Failed There is an error in the tag structure

Opening and closing tags that are not used according to specification.

Failed The element contains duplicate attributes

An attribute occurs more than once on an element.

Passed The web page can be parsed

The code is well-formed, opening and closing tags are used according to specification and attributes occur only once per element.

About this Test

Checked Elements: HTML code

This test checks, if the HTML code is well-formed (e.g. opening and closing angle brackets, (balanced) attribute quoting, whitespace between attributes), all opening and closing tags are used according to specification and attributes are specified only once per element.

Short Description

It is necessary to write correct code.

Markup errors in element tags and duplicate attributes could cause assistive technology to be unable to generate a satisfactory model of the page. Different user agents may implement different heuristics to recover from errors, resulting in inconsistent presentations of the page between user agents.

Understanding Success Criterion 4.1.1: Parsing

How to Repair

  • Add missing opening and closing angle brackets.
  • Enclose attribute values with quotes and ensure that the opening and closing quote is present.
  • Add whitespace between attributes.
  • Add closing tags for all elements with required closing tags.
  • Remove closing tags for all elements where closing tags are forbidden.
  • Nest opening and closing tags for all elements correctly.
  • Remove duplicate attributes.

WCAG 2.0

Principle 4: Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. WCAG 2.0: Principle 4
Guideline 4.1: Compatible
Maximize compatibility with current and future user agents, including assistive technologies. Understanding Guideline 4.1
Success Criterion 4.1.1: Parsing (Level A)
In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete. Understanding: Success Criterion 4.1.1
Techniques

Test Detail: Naming frames

(Test for Success Criterion 4.1.2: Name, Role, Value)

Results

Failed The name of the frame is missing

The name of the frame or iframe is not defined, because the title attribute is missing.

Failed The name of the frame is empty

The title attribute of the frame or iframe has no value.

Failed The name of the frame seems to be suspicious

The title of the frame or iframe seems to be a default or placeholder text instead of a proper description of its content.

Verification required Please check the name of the frame

Human input is necessary to verify, that the title of the frame or iframe describes its contents.

About this Test

Checked Elements: frame and iframe elements

This test checks, if the frame or iframe has a descriptive title.

Short Description

It is necessary to use of the title attribute of the frame or iframe element to describe the contents of each frame. This provides a name for the frame so users can determine which frame to enter and explore in detail.

The title attribute is not interchangeable with the name attribute. The title labels the frame for users; the name labels it for scripting and window targeting. The name is not presented to the user, only the title is.

Understanding Success Criterion 4.1.2: Name, Role, Value

How to Repair

Add a title attribute to the frame or iframe with a short title describing the contents of the frame.

WCAG 2.0

Principle 4: Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. WCAG 2.0: Principle 4
Guideline 4.1: Compatible
Maximize compatibility with current and future user agents, including assistive technologies. Understanding Guideline 4.1
Success Criterion 4.1.2: Name, Role, Value (Level A)
For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined ; states, properties, and values that can be set by the user can be programmatically set ; and notification of changes to these items is available to user agents , including assistive technologies . Note: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification. Understanding: Success Criterion 4.1.2
Technique

Test Detail: Naming button elements

(Test for Success Criterion 4.1.2: Name, Role, Value)

Results

Failed The button has no name

The button has no associated text which can be used as a name.

Passed The button has a name

The button element has an associated text.

About this Test

Checked Elements: button elements

This test checks, if a name for the button is provided by its title or content.

Short Description

The name of a button element is provided by the text associated with that element. This text provides a name for the button so users are able to understand its purpose and can decide whether they want to click it.

The text associatetd with a button is the value of the title attribute, the text within the button element and the alt attribute if the button contains an image.

Understanding Success Criterion 4.1.2: Name, Role, Value

How to Repair

  • Add text as content to the button, if you can.
  • If the button element contains an image, add a descriptive alternative text to the image with the alt attribute.
  • If the button element is empty or only contains non-text-content other than an image, add a descriptive title to the button.

WCAG 2.0

Principle 4: Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. WCAG 2.0: Principle 4
Guideline 4.1: Compatible
Maximize compatibility with current and future user agents, including assistive technologies. Understanding Guideline 4.1
Success Criterion 4.1.2: Name, Role, Value (Level A)
For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined ; states, properties, and values that can be set by the user can be programmatically set ; and notification of changes to these items is available to user agents , including assistive technologies . Note: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification. Understanding: Success Criterion 4.1.2
Technique

Test Detail: Naming fieldset elements

(Test for Success Criterion 4.1.2: Name, Role, Value)

Results

Failed The fieldset has no naming legend

The fieldset has no legend which can be used to name it.

Failed The fieldset has no name

The legend of the fieldset has no associated text which can be used as a name.

Passed The fieldset has a name

The fieldset has a legend with an associated text.

About this Test

Checked Elements: fieldset elements

This test checks, if a name for the fieldset is provided by its legend element.

Short Description

The name of an fieldset element is provided by its legend element. The associated text of the legend element provides a name for the fieldset so users are able to understand the purpose of groups of form controls.

The text associatetd with a legend is the contained text and the alt attribute if the legend contains an image.

Understanding Success Criterion 4.1.2: Name, Role, Value

How to Repair

Provide a descriptive legend element as the first element of the fieldset. Add text as content to the legend, if you can. If the legend element contains an image, add a descriptive alternative text to the image with the alt attribute.

Further information: Accessible Forms using WCAG 2.0

WCAG 2.0

Principle 4: Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. WCAG 2.0: Principle 4
Guideline 4.1: Compatible
Maximize compatibility with current and future user agents, including assistive technologies. Understanding Guideline 4.1
Success Criterion 4.1.2: Name, Role, Value (Level A)
For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined ; states, properties, and values that can be set by the user can be programmatically set ; and notification of changes to these items is available to user agents , including assistive technologies . Note: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification. Understanding: Success Criterion 4.1.2
Technique

Test Detail: Naming input buttons

(Test for Success Criterion 4.1.2: Name, Role, Value)

Results

Failed The input button has no name

The input element of type button, submit or reset has no or an empty value attribute.

Passed The input button has a name

The input element of type button, submit or reset has a non-empty value attribute.

About this Test

Checked Elements: input[@type='button'], input[@type='submit'], or input[@type='reset'] elements

This test checks, if a name for the input[@type='button'], input[@type='submit'], or input[@type='reset'] is provided by its value attribute.

Short Description

The name of an input element of type button, submit or reset is provided by its value attribute. The text of this attribute provides a name for the form control so users are able to understand its purpose and can decide whether they want to click it.

Understanding Success Criterion 4.1.2: Name, Role, Value

How to Repair

Add a text, describing the function of the input element, using its value attribute.

WCAG 2.0

Principle 4: Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. WCAG 2.0: Principle 4
Guideline 4.1: Compatible
Maximize compatibility with current and future user agents, including assistive technologies. Understanding Guideline 4.1
Success Criterion 4.1.2: Name, Role, Value (Level A)
For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined ; states, properties, and values that can be set by the user can be programmatically set ; and notification of changes to these items is available to user agents , including assistive technologies . Note: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification. Understanding: Success Criterion 4.1.2
Technique

Test Detail: Naming input images

(Test for Success Criterion 4.1.2: Name, Role, Value)

Results

Failed The input image has no name

The input element of type image has no alt or title text.

Passed The input image has a name

The input element of type image has a non-empty title or alt attribute.

About this Test

Checked Elements: input[@type='image'] elements

This test checks, if a name for the input[@type='image'] element is provided by its title or alt attribute.

Short Description

The name of an input element of type image is provided by its title or alt attribute. The text of this attribute provides a name for the form control so users are able to understand its purpose and can decide whether they want to click it.

Understanding Success Criterion 4.1.2: Name, Role, Value

How to Repair

Add a text, describing the function of the input element, using its alt attribute.

WCAG 2.0

Principle 4: Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. WCAG 2.0: Principle 4
Guideline 4.1: Compatible
Maximize compatibility with current and future user agents, including assistive technologies. Understanding Guideline 4.1
Success Criterion 4.1.2: Name, Role, Value (Level A)
For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined ; states, properties, and values that can be set by the user can be programmatically set ; and notification of changes to these items is available to user agents , including assistive technologies . Note: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification. Understanding: Success Criterion 4.1.2
Technique

Test Detail: Naming form controls

(Test for Success Criterion 4.1.2: Name, Role, Value)

Results

Failed The form control has no name

The input element of type radio, checkbox, file, text or password, the select element or the textarea has no title and no associated label.

Failed The name of the form control is not set correctly

The label for the input element of type radio, checkbox, file, text or password, the select element or the textarea is at the wrong position.

Passed The form control has a name

The input element of type radio, checkbox, file, text or password, the select element or the textarea has a non-empty title or associated label.

About this Test

Checked Elements: input[@type='radio'], input[@type='checkbox'], input[@type='file'], input[@type='text'], input[@type='password'], select or textarea elements

This test checks, if a name for the form control is provided by an associated label or its title attribute.

Short Description

The name of an input element of type radio, checkbox, file, text or password, a select element or a textarea is provided by its associated label element or its title attribute. This text provides a name for the form control so users are able to understand its purpose and can decide what to insert or select.

Understanding Success Criterion 4.1.2: Name, Role, Value

How to Repair

Add a label element and associate it with the form control by referencing the id of the control as the value of the for attribute of the label.
The text of the label should describe the purpose of the contol unambiguously. For radio buttons and checkboxes place the label after the form control, for all others place the label before the form control.

Further information: Accessible HTML/XHTML Forms: Intermediate Level

Note: It is also possible to name form controls with their title attribute, but this practice is not recommended and should only be applied if there is no room for a label element in the layout.

WCAG 2.0

Principle 4: Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. WCAG 2.0: Principle 4
Guideline 4.1: Compatible
Maximize compatibility with current and future user agents, including assistive technologies. Understanding Guideline 4.1
Success Criterion 4.1.2: Name, Role, Value (Level A)
For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined ; states, properties, and values that can be set by the user can be programmatically set ; and notification of changes to these items is available to user agents , including assistive technologies . Note: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification. Understanding: Success Criterion 4.1.2
Techniques