WCAG 1.3.5 Identify Input Purpose — Testing Guide for Mobile & Web Apps

WCAG 1.3.5, "Identify Input Purpose," is a crucial Level AA success criterion that ensures users, especially those using assistive technologies, can understand the purpose of form inputs. This means c

Ensuring Input Clarity: A Practical Guide to WCAG 1.3.5 (Identify Input Purpose)

WCAG 1.3.5, "Identify Input Purpose," is a crucial Level AA success criterion that ensures users, especially those using assistive technologies, can understand the purpose of form inputs. This means clearly labeling what information is expected in each field.

What WCAG 1.3.5 Requires

At its core, this criterion mandates that the purpose of each input field is programmatically identifiable. For web applications, this is typically achieved using the autocomplete attribute. For native mobile applications, platform-specific accessibility properties serve this function. The goal is to provide context so that user agents (like screen readers) can convey the input's purpose to the user effectively.

Why It Matters: User Impact and Broader Compliance

For Users:

• Assistive Technology Users: Screen reader users rely heavily on clear input purpose identification. Without it, they might not know whether a field requires a name, email address, phone number, or credit card number, leading to confusion and frustration.
• Cognitive Disabilities: Users with cognitive disabilities can benefit from clear, unambiguous labels that reduce mental load and improve comprehension.
• Low Vision Users: Some low vision users may use magnification or high contrast modes. Clear input labels, even when visually distinct, are essential for understanding.
• Users with Motor Impairments: For users who may have difficulty typing or remembering information, pre-filled forms or intelligent input suggestions can significantly improve efficiency.

Broader Compliance:

• EU EAA (European Accessibility Act): This directive mandates accessibility for a wide range of products and services, including websites and mobile apps. WCAG 1.3.5 is a foundational element for meeting these requirements.
• ADA (Americans with Disabilities Act): While not explicitly mentioning WCAG, the ADA's mandate for equal access to information and services is directly supported by implementing accessibility standards like WCAG 1.3.5.
• Improved User Experience for All: Clear labels benefit everyone, not just users with disabilities. They make forms easier to understand and complete for all users.

Common Violations and Examples

Violations of WCAG 1.3.5 often stem from missing or incorrect autocomplete attributes in web development, or missing accessibility labels in native mobile development.

#### Web Application Examples:

1. Missing autocomplete for Email:

• Violation: A registration form has an input field for email but lacks the autocomplete="email" attribute.
• Impact: A screen reader might announce "email edit text" without specifying it's an email address, forcing the user to guess or navigate to a separate label. Password managers may also fail to auto-fill.

1. Incorrect autocomplete for Phone Number:

• Violation: An input field for a phone number is labeled "Phone" but has autocomplete="tel-country-code".
• Impact: The browser or assistive technology might expect only the country code, leading to incorrect auto-filling or user confusion if a full number is expected.

1. Generic autocomplete for Sensitive Data:

• Violation: A credit card number input field uses autocomplete="off" or a generic autocomplete="cc-name" when autocomplete="cc-number" is appropriate.
• Impact: Prevents secure auto-filling of credit card details, increasing manual entry effort and potential for errors. This also impacts user trust regarding data security.

#### Mobile Application Examples (Android/iOS):

1. Missing Content Description for Phone Number Field:

• Violation: An Android input field for a phone number has no contentDescription attribute set.
• Impact: TalkBack (Android's screen reader) will announce the field's ID or a generic "edit text," not that it's for a phone number.

1. Generic Label for Name Field:

• Violation: An iOS text field for a user's full name has an accessibilityLabel set to "Name" instead of a more specific value like "Full Name" or "First Name" and "Last Name" if split.
• Impact: Users might not understand if it's for the first name, last name, or both, especially in international contexts where name structures vary.

How to Test for Compliance

Testing for WCAG 1.3.5 requires a combination of manual inspection and automated tools.

#### Manual Testing Steps:

1. Inspect Form Fields: Navigate through all form fields in your application.
2. Use Accessibility Inspector Tools:

• Web: Utilize browser developer tools (e.g., Chrome DevTools, Firefox Developer Tools) to inspect the HTML and check for the presence and correctness of autocomplete attributes.
• Mobile (Android): Use the Accessibility Scanner app or Android Studio's Layout Inspector to examine the contentDescription property of input fields.
• Mobile (iOS): Use Xcode's Accessibility Inspector to check the accessibilityLabel and accessibilityHint properties.

1. Simulate Assistive Technology:

• Web: Use a screen reader (e.g., NVDA on Windows, VoiceOver on macOS) to navigate forms and listen to how input fields are announced.
• Mobile: Enable TalkBack (Android) or VoiceOver (iOS) and interact with forms to understand the user experience.

1. Test Auto-Filling:

• Web: Attempt to use browser auto-fill features or password managers to see if they correctly populate fields.
• Mobile: Observe if the operating system's auto-fill suggestions appear correctly.

#### Automated Tools:

• Web:
• Axe DevTools: Browser extension that identifies WCAG violations, including missing or incorrect autocomplete attributes.
• Lighthouse (Chrome DevTools): Audits accessibility and provides reports that can highlight issues related to input identification.
• Pa11y: A command-line tool and Node.js module for automated accessibility testing.
• Mobile:
• Accessibility Scanner (Android): A Google app that scans your app and provides detailed reports on accessibility issues, including missing content descriptions.
• Xcode Accessibility Inspector (iOS): Built into Xcode, it allows real-time inspection of UI elements and their accessibility properties.

#### Mobile-Specific Considerations:

• Android: For input fields that have a clear visual label but no programmatic label, ensure the contentDescription is set to match the visual label. If the visual label is dynamic, the contentDescription should also be dynamic.
• iOS: Use accessibilityLabel for the primary identifier of the input field. If additional context is needed, use accessibilityHint. For grouped fields (like first and last name), ensure each has its own distinct label.

How to Fix Violations

#### Web Application Fixes:

• Add autocomplete Attributes:
• Email:
• Phone: (use more specific values like tel-national, tel-local if applicable)
• Name:
• Credit Card Number:
• Other common values: given-name, family-name, street-address, postal-code, country, organization, username, current-password, new-password. Refer to MDN documentation for a comprehensive list.

• Ensure Labels are Associated: Always use or associate labels programmatically using ARIA attributes if a visual label cannot be a element.

#### Mobile Application Fixes:

• Android:
• XML Layout:

        <EditText
            android:id="@+id/emailEditText"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:hint="@string/enter_email"
            android:inputType="textEmailAddress"
            android:importantForAutofill="yes"
            android:contentDescription="@string/email_address_input_description" />

• Programmatically (Kotlin):

        val editText = findViewById<EditText>(R.id.emailEditText)
        editText.contentDescription = getString(R.string.email_address_input_description)

• Ensure android:importantForAutofill="yes" is set for fields that should be auto-filled.

• iOS:
• Storyboard/XIB: In the Attributes Inspector, set the "Accessibility Label" for the UITextField or UITextView.
• Programmatically (Swift):

        let emailTextField: UITextField = {
            let textField = UITextField()
            textField.accessibilityLabel = "Email Address"
            return textField
        }()

How SUSA Checks This Criterion

SUSA Test automates the identification of WCAG 1.3.5 violations during its autonomous exploration.

• Web Exploration: When SUSA encounters a web form, it analyzes the autocomplete attributes of all input fields. It checks for the presence of appropriate values based on the input type and its context. If attributes are missing, incorrect, or set to off where they should be enabled, SUSA flags it as a violation.
• Mobile Exploration (Android/iOS): For native mobile applications, SUSA leverages platform-specific accessibility APIs. It inspects contentDescription (Android) and accessibilityLabel (iOS) for all input fields. SUSA verifies that these properties are present and descriptive, providing clear programmatic identification of the input's purpose.
• Persona-Based Testing: SUSA's diverse user personas, including those with accessibility needs, further enhance its testing. For instance, an "accessibility" persona will specifically focus on how screen readers interpret these fields, uncovering issues that standard automated checks might miss.
• Cross-Session Learning: With each run, SUSA learns more about your application's structure and common input patterns. This allows it to refine its checks for WCAG 1.3.5, becoming more effective at identifying subtle violations over time.
• Auto-Generated Scripts: Crucially, SUSA doesn't just find violations; it auto-generates regression test scripts (Appium for Android, Playwright for Web) that include checks for these input identification issues. This ensures that future development doesn'