WCAG 3.3.2 Labels or Instructions — Testing Guide for Mobile & Web Apps

WCAG 2.1 Level A criterion 3.3.2, "Labels or Instructions," mandates that forms and interactive controls provide clear, understandable labels or instructions. This ensures users can accurately input i

Ensuring Clarity: A Practical Guide to WCAG 3.3.2 Labels or Instructions

WCAG 2.1 Level A criterion 3.3.2, "Labels or Instructions," mandates that forms and interactive controls provide clear, understandable labels or instructions. This ensures users can accurately input information and understand what is expected of them.

What WCAG 3.3.2 Requires

At its core, this criterion demands that any input field or interactive element that requires user input or action must have a corresponding label or instruction. This label or instruction should clearly identify the purpose of the input field or the action required. It needs to be visible and associated with the element it describes.

Why WCAG 3.3.2 Matters

This criterion directly impacts users who rely on clear guidance for interaction. This includes:

• Novice users: Those unfamiliar with complex interfaces or specific jargon.
• Users with cognitive disabilities: Individuals who may have difficulty processing complex instructions or remembering context.
• Elderly users: Who may experience declining vision or cognitive abilities, making clear instructions essential.
• Non-native speakers: Who may struggle with nuanced language or idiomatic expressions.
• Anyone under pressure: In a time-sensitive situation, clear instructions prevent errors and frustration.

For instance, a missing label on a form field for "Date of Birth" can lead to incorrect data entry, potentially causing account creation failures or incorrect profile information. In web applications, unclear instructions for a multi-step checkout process can cause users to abandon their carts. This directly affects conversion rates and user satisfaction. Compliance with this criterion is also a legal requirement in many jurisdictions, including under the EU's European Accessibility Act (EAA) and the Americans with Disabilities Act (ADA) in the United States.

Common Violations with Examples

Violations of WCAG 3.3.2 often stem from a lack of explicit labeling or the use of ambiguous instructions.

#### Mobile App Examples

1. Missing Input Labels:

• Scenario: A registration form with fields for "Name," "Email," and "Password." The "Email" field has no visible label, only a placeholder text "your.email@example.com."
• Violation: Placeholder text is not a sufficient label. If the user clears the placeholder, the purpose of the field is lost. Screen readers may not announce placeholder text as a label, leaving visually impaired users confused.

1. Ambiguous Button Labels:

• Scenario: A screen with a "Submit" button and a "Cancel" button. The "Submit" button is labeled "Go."
• Violation: "Go" is not specific enough. Users might not understand what action "Go" initiates, especially if there are multiple potential actions.

#### Web App Examples

1. Implicit Instructions for Complex Forms:

• Scenario: A credit card payment form requires a "CVV" number. The input field is simply labeled "CVV."
• Violation: While "CVV" is a common term for credit card security codes, some users may not know what it stands for or where to find it on their card. Instructions like "Enter the 3-digit security code on the back of your card" are necessary.

1. Context-Dependent Actions Without Clear Labels:

• Scenario: A product listing page has a button next to each item that simply says "Add."
• Violation: "Add" is ambiguous. Does it add to a wishlist, a shopping cart, or something else? The context might imply "add to cart," but explicit labeling is safer.

How to Test for Compliance

Ensuring compliance with WCAG 3.3.2 requires a multi-faceted approach.

#### Manual Testing Steps

1. Review all form fields and interactive elements: For every input field (text, dropdown, radio buttons, checkboxes, etc.) and actionable element (buttons, links that perform actions), verify that there is a clear, descriptive label or instruction.
2. Check for placeholder text as the sole label: Ensure that placeholder text is only used as a hint and not as the primary label. If placeholder text is cleared, the field's purpose must still be obvious.
3. Test with screen readers: Use a screen reader (e.g., NVDA, JAWS, VoiceOver) to navigate through forms and interactive elements. Confirm that labels are announced correctly and comprehensibly when the element receives focus.
4. Evaluate instruction clarity: For complex inputs or actions, assess whether the provided instructions are easy to understand for a diverse audience. Avoid jargon and assume minimal prior knowledge.
5. Focus on dynamic content: Test forms or interactive elements that appear or change based on user input. Ensure that new labels or instructions are provided when needed.

#### Automated Tools

While manual testing is crucial, automated tools can efficiently scan for common violations.

• Browser Developer Tools: Most modern browsers offer accessibility inspection tools that can identify missing aria-label attributes or associated elements.
• Dedicated Accessibility Checkers: Tools like axe-core (which powers many browser extensions and CI/CD integrations) can detect missing labels and other common WCAG violations.
• SUSA (SUSATest) Autonomous Exploration: As detailed below, SUSA can autonomously identify these issues.

#### Mobile-Specific Considerations (Android/iOS)

• Android:
• contentDescription: For ImageView or Button elements without visible text, ensure contentDescription is set to provide a descriptive label for screen readers.
• hint vs. labelFor: Use android:hint for placeholder text, but ensure a proper android:labelFor attribute links a TextView label to its corresponding EditText input field.
• iOS:
• UIAccessibilityLabel: Set this property for UI elements to provide a descriptive label for VoiceOver.
• UIAccessibilityHint: Use this for additional guidance beyond the label.
• isAccessibilityElement: Ensure interactive elements are marked as accessibility elements.

How to Fix Violations

The primary fix is to associate a clear, descriptive label with each form control.

#### Code Examples

HTML (Web):

• Using : This is the most semantic and accessible method.

    <label for="email">Email Address:</label>
    <input type="email" id="email" name="email">

• Using aria-label: Useful when a visible label is not feasible.

    <input type="password" aria-label="Password (at least 8 characters)">

Android (Kotlin):

• Linking TextView label to EditText:

    <LinearLayout>
        <TextView
            android:id="@+id/label_username"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="Username" />

        <EditText
            android:id="@+id/edit_username"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:labelFor="@id/label_username" />
    </LinearLayout>

• Using contentDescription for an icon button:

    <ImageButton
        android:id="@+id/button_save"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:src="@drawable/ic_save"
        android:contentDescription="Save current item" />

iOS (Swift):

• Setting UIAccessibilityLabel for a UITextField:

    usernameTextField.accessibilityLabel = "Username"

• Setting UIAccessibilityHint for additional guidance:

    passwordTextField.accessibilityLabel = "Password"
    passwordTextField.accessibilityHint = "Must be at least 8 characters long and include a number."

How SUSA Checks This Criterion

SUSA leverages its autonomous exploration capabilities and specialized user personas to meticulously check for WCAG 3.3.2 compliance.

1. Autonomous Exploration: Upon uploading an APK or web URL, SUSA navigates through the application, interacting with all visible form fields and interactive elements. It systematically attempts to identify and engage with every input mechanism.
2. Persona-Based Testing: SUSA employs its suite of 10 user personas, including novice, elderly, and accessibility personas. These personas simulate users with varying levels of technical proficiency and cognitive abilities, specifically looking for clarity and ease of understanding in labels and instructions.
3. Identification of Missing/Ambiguous Labels: During exploration, SUSA analyzes the UI for elements that require input or action. It checks for:

• Input fields lacking associated visual or programmatic labels.
• Placeholder text used as the sole identifier for an input field.
• Buttons or links with vague or contextually unclear labels.

1. Accessibility Violation Detection: SUSA's built-in WCAG 2.1 AA testing engine specifically flags instances where labels or instructions are missing or insufficient, directly identifying violations of criterion 3.3.2.
2. Cross-Session Learning: With each subsequent run, SUSA learns more about the application's structure and common interaction patterns, improving its ability to detect subtle labeling issues and ensuring consistent compliance checks over time.
3. Auto-Generated Regression Scripts: Crucially, SUSA not only finds these issues but also auto-generates Appium (for Android) and Playwright (for Web) regression test scripts. This means that once a fix is implemented, SUSA can automatically verify that the violation of WCAG 3.3.2 remains resolved in future builds, preventing regressions.

By integrating SUSA into your QA process, you can ensure that your applications provide clear, understandable labels and instructions, making them accessible and user-friendly for everyone.