Info and Relationships

The Info and Relationships rule emphasizes the importance of presenting content in a way that is understandable and accessible to all users, including those who rely on assistive technologies. This ensures that information conveyed through relationships between elements, such as form labels, headings, and data tables, is clear and perceivable. By maintaining proper structural and semantic relationships, you can create more inclusive and navigable web content.

Interactive element accessibility label

Interactive element accessibility labels ensure all UI elements or custom views in an application have a descriptive label. These labels are essential for screen readers to interpret the element’s name, value, and purpose, facilitating accessibility for users with disabilities.

Testing for Interactive element accessibility labels is necessary as it ensures that all users, regardless of their abilities, can navigate and interact with the application effectively.

Success criteria

The rule checks for the following potential violations:

• All interactive UI elements must have a non-null, descriptive accessibility label.
• Custom views used as interactive elements must also have a descriptive accessibility label.
• The labels must be clear and convey the element’s purpose effectively.

How to fix?

To fix violations related to interactive element accessibility labels, follow these steps:

Android
Ensure the contentDescription property is defined for the element. This label is used by assistive technologies, such as screen readers to announce and trigger actions for interactable elements.

iOS
Ensure the accessibilityLabel property is defined for the element. This label is used by assistive technologies such as screen readers to announce and trigger actions for interactable elements.

Example

The following example scan report shows an Interactive element accessibility label violation in the app’s interface. The issue is identified for two buttons that lack proper accessibility labels.

Violation

• Button 1:
  The first button, located at the bottom of the screen, currently does not have an accessibility label. This means that a screen reader cannot convey any information about this button to users who rely on assistive technologies. As a result, users with visual impairments won’t know the purpose of this button.
• Button 2:
  Similar to the first button, the second button also lacks an accessibility label. This omission means that the button is effectively invisible to screen readers, and users who depend on such tools will not be able to interact with or understand its function.

Fix

To fix these violations, ensure that each button has a clear and descriptive accessibility label. This can be done by assigning a meaningful label that conveys the button’s purpose to assistive technologies.

• Button 1:
  Assign an accessibility label that describes the button’s action, such as “Support in 30 seconds.” This label will inform the screen reader to announce that this button provides support in 30 seconds when activated.

• Button 2:
  Assign an accessibility label that describes the button’s action, such as “Discount flights.” This label will enable the screen reader to announce that this button offers a discount on flights when activated.

Switch element accessibility label

The Switch element accessibility label ensures that switch controls in an app have both their name and value available to screen readers. This ensures that switch controls are fully accessible, allowing their label and state (on/off) to be accurately communicated to users who rely on screen readers. Proper labeling of switch elements helps in providing an inclusive experience for all users, including those with visual impairments.

App accessibility can automatically check for violations related to switch element labels. It analyzes the app’s interface to ensure that each switch control has a proper name and value that can be read by screen readers, highlighting any areas that need improvement.

Success Criteria

The rule checks for the following potential violations:

• Missing name
  The switch control does not have a descriptive name that can be read by a screen reader.
• Missing value
  State information should be provided in accessibility labels. Including values directly can cause confusion.
• Incorrect labeling
  The switch control is not associated correctly with its label, making it difficult for screen readers to convey the correct information to users.

How to Fix?

To ensure switch elements are accessible, follow these steps:

• Provide descriptive labels
  Ensure that each switch control has a descriptive label using the contentDescription property for Android or the accessibilityLabel property for iOS. This helps screen readers to convey the purpose of the switch to users.
• Convey the state
  Modern screen readers automatically detect the state (on/off) of the switch. Therefore, developers do not need to explicitly include the state in the hint property for Android or the accessibilityLabel for iOS. Including the state in the accessibilityLabel is redundant and may confuse users.
• Associate with label
  Use properties like labelFor in Android or ensure the control is correctly associated with its label in iOS. Proper association ensures that screen readers can link the switch control with its descriptive text.

Example

The following example scan report highlights that the switch element is missing proper descriptive content. This label does not describe the function of the switch, and the element is not correctly associated with a descriptive text label, so screen readers cannot accurately convey its purpose to users.

Fix

• Provide a meaningful label
  Change the label to something more descriptive, such as Enable notifications. This can be done by setting the contentDescription property for Android or the accessibilityLabel property for iOS. This ensures that screen readers can accurately convey the switch’s purpose to users.

Checkbox element accessibility label

A Checkbox Element Accessibility Label ensures that checkbox elements within your app are properly labeled and fully accessible to users relying on assistive technologies like screen readers. Proper labeling of checkboxes means that both the name and the value of the checkbox are communicated to screen readers, allowing users to understand and interact with these elements effectively.

Success criteria

The rule checks for the following potential violations:

• Checkbox elements without an associated label.
• Labels that are not properly linked to their corresponding checkbox elements.
• Labels that are not descriptive enough to provide context about the checkbox option.

How to fix?

To fix violations related to checkbox element accessibility labels, follow these steps:

• Associate labels with checkboxes:
  • Use contentDescription to provide the accessibility label to the checkbox.
• Provide descriptive labels:
  • Ensure that the label text clearly describes the purpose of the checkbox.
  • Avoid using ambiguous or single-word labels.

Example

The following example scan report highlights that the checkbox element lacks an associated label, making it inaccessible to users relying on screen readers.

Fix
To correct this violation, associate a label with the checkbox element through the labelFor attribute or provide a meaningful contentDescription or hint for a clear description of it’s purpose.

Editable element accessibility label

Editable elements such as EditTexts or TextViews should have both name and value available to screen readers. This ensures editable elements are fully accessible, allowing their purpose (name) and current value to be accurately communicated to users relying on screen readers.

App Accessibility can automatically check for violations related to editable element accessibility labels. These tools ensure that all editable fields are appropriately labeled and can be read by screen readers, identifying any missing or incorrect labels.

Success Criteria

The rule checks for the following potential violations:

• Missing Labels
  Editable elements must have a descriptive label.
• Label-Value Association
  The label should be associated with the corresponding editable element, ensuring screen readers convey both the label and the current value.
• Consistency
  Labels should be consistent across different parts of the application.

How to fix?

To ensure the accessibility label is defined for an editable element, follow these steps:

Android

• Provide a hint
   Use the hint attribute for EditText or editable TextView elements to provide a label. Screen readers read this hint as the name of the field.
• Use labelFor
   Associate a TextView with an EditText using the labelFor attribute to define a relationship between the label and the editable element.

iOS

• Set accessibility label
   Use the accessibilityLabel property to provide a descriptive label for UITextField or UITextView elements.

Example

The following example scan report highlights the editable element with the ID com.bsstag.espressotesting:id/url lacks an accessibility label. This violation prevents screen readers from providing the necessary information to users.

Fix

• For Android
   Add a hint attribute to the EditText element to provide a label. This ensures the screen reader can convey the purpose of the field.
• For iOS
   Set the accessibilityLabel property for UITextField or UITextView elements to provide a descriptive label.

View State in element accessibility label

App Accessibility checks if the view state information is included in the accessible name of elements. Screen readers automatically announce an element’s type and state, so including this information can be redundant or even cause conflicts with the view’s current state. Ensuring that accessibility labels do not contain view state information is important for creating a fully accessible and user-friendly app.

Success Criteria

The rule checks for the following potential violations:

• Inclusion of State Information
  Accessibility labels should not include information about the element’s state, such as “ON” or “OFF”.
• Redundant Information
  Accessibility labels should not repeat information that screen readers automatically announce.

How to Fix?

To fix violations related to view state information in element accessibility labels, follow these steps:

• Remove state information
  Ensure that the accessibility labels defined in the contentDescription property (Android) or accessibilityLabel property (iOS) do not contain information about the state of a view.
• Rely on assistive technologies
  Depend on assistive technologies to automatically convey the element’s type and current state alongside its accessible name. This approach avoids redundancy and ensures that the information presented is always up-to-date and accurate.

Example

In the following example scan report, the alarm element’s accessibility label includes view state information. The alarm set for 06:00 AM includes the state information "tap" in its content description. When a screen reader announces this element, it reads the entire label, including the "tap" state. This is redundant because the screen reader will automatically announce the state of the element.

Fix

• Remove "tap" from the content description.
• Ensure the screen reader is allowed to announce the element’s state automatically.

References

Learn more about Resize Text WCAG: 2.1 - 1.3.1 (Level A) guideline