WCAG 2.4.6 Headings and Labels — Testing Guide for Mobile & Web Apps

WCAG 2.4.6, "Headings and Labels," mandates that content is structured and identified in a way that makes it easy for users to understand the purpose of different sections and input fields. In simpler

Ensuring Clear Navigation: A Practical Guide to WCAG 2.4.6 Headings and Labels

WCAG 2.4.6, "Headings and Labels," mandates that content is structured and identified in a way that makes it easy for users to understand the purpose of different sections and input fields. In simpler terms, headings should clearly indicate what follows, and labels should unambiguously describe the purpose of form controls. This criterion is essential for both programmatic understanding and human comprehension.

Why WCAG 2.4.6 Matters: Impact on Real Users

Clear headings and labels are fundamental to usability and accessibility.

• Screen Reader Users: Individuals using screen readers rely heavily on headings to quickly navigate and understand the structure of a page or app screen. Without proper headings, they are forced to linearly read through content, making it inefficient and frustrating to find specific information. Similarly, descriptive labels are crucial for understanding the function of form elements.
• Cognitive Disabilities: Users with cognitive disabilities, including learning disabilities or ADHD, benefit immensely from clear, concise labeling and hierarchical structure. Well-defined headings break down complex information into manageable chunks, improving comprehension and reducing cognitive load.
• Mobile Users: On smaller screens, space is at a premium. Users often scan content quickly. Clear headings and labels facilitate this scanning, allowing them to locate desired sections or controls without extensive scrolling or guesswork.
• Users with Low Vision: While not directly a visual contrast issue, clear headings and labels help users with low vision orient themselves and understand the layout, reducing the effort required to find information.
• Search Engine Optimization (SEO): Properly structured headings are also a significant factor in how search engines understand and rank your content, indirectly benefiting all users by improving discoverability.

Compliance with WCAG 2.4.6 is also a legal requirement in many jurisdictions, including adherence to the European Accessibility Act (EAA) and the Americans with Disabilities Act (ADA) in the United States.

Common Violations and Examples

Violations of WCAG 2.4.6 often stem from a lack of semantic structure or insufficient descriptive text.

#### Mobile App Examples (Android/iOS)

1. Missing or Generic Headings:

• Violation: A mobile app screen displays a list of user settings, but there are no clear headings to delineate sections like "Account," "Notifications," or "Privacy." All items are presented in a single, undifferentiated list.
• Impact: A screen reader user attempting to find their notification settings would have to listen to every single setting item until they stumble upon the correct one.

1. Ambiguous Button Labels:

• Violation: A screen has multiple "Edit" buttons, but without any context. A user might see "Edit Profile," "Edit Address," and "Edit Payment Method." If the buttons are only labeled "Edit," users won't know which profile information they are modifying.
• Impact: Users might accidentally edit the wrong information, leading to frustration and potential data errors. Screen readers would announce "Button, Edit" repeatedly, providing no distinction.

1. Unlabeled Input Fields:

• Violation: A registration form has fields for "First Name," "Last Name," and "Email," but these are only indicated by placeholder text that disappears when the user starts typing. There are no associated elements or contentDescription attributes.
• Impact: Screen readers will announce the input field as "Edit box" or similar, leaving the user unaware of what information is expected. This is a significant barrier for users relying on assistive technologies.

#### Web App Examples

1. Overuse of Paragraphs for Headings:

• Violation: A webpage uses

  tags with bold styling and a larger font size to simulate headings for different sections of an article.

• Impact: Screen readers and assistive technologies do not recognize these as structural headings. Navigation by heading becomes impossible, and the content structure is lost programmatically.

1. Generic Search Button Labels:

• Violation: A website has multiple search functionalities (e.g., product search, site search, help center search). All search buttons are simply labeled "Search."
• Impact: Users are unsure which search function they are activating, leading to confusion and potentially irrelevant search results.

1. Form Controls Without Explicit Labels:

• Violation: A contact form includes a "Submit" button. However, the button's purpose is only described by surrounding text or its visual appearance, not by an associated element or an aria-label attribute.
• Impact: For screen reader users, the button might be announced only as "Button," without conveying its specific action (e.g., "Submit Contact Form").

How to Test for WCAG 2.4.6 Compliance

Testing for this criterion involves a combination of manual inspection and automated tools.

#### Manual Testing Steps

1. Inspect Headings:

• Web: Use your browser's developer tools (e.g., Inspect Element in Chrome/Firefox) to examine the HTML structure. Look for semantic heading tags (

  through

  ). Ensure they are used hierarchically (e.g.,

  within an

  section, not skipping levels like

  to

  ).

• Mobile: For native apps, use accessibility inspectors (like Accessibility Scanner for Android or Accessibility Inspector in Xcode for iOS). Check that screen elements that function as section titles are properly identified as headings or have descriptive labels.

1. Examine Form Labels:

• Web: For every form input field (, </code>, <code><select></code>), verify that it has a programmatically associated <code><label></code> element. The <code>for</code> attribute of the <code><label></code> should match the <code>id</code> attribute of the input. Alternatively, check for <code>aria-label</code> or <code>aria-labelledby</code> attributes that provide a clear description.</li> <li> <strong>Mobile:</strong> Use accessibility inspectors to check <code>contentDescription</code> (Android) or <code>accessibilityLabel</code> (iOS) for input fields and buttons. Ensure these labels are descriptive and unambiguous.</li> </ul> <ol> <li><strong>Test with Assistive Technologies:</strong></li> </ol> <ul> <li> <strong>Screen Readers:</strong> Navigate your app or website using a screen reader (e.g., VoiceOver on iOS, TalkBack on Android, NVDA or JAWS on desktop). Try to understand the content and complete tasks using only the screen reader. Pay attention to how headings are announced and if labels are clear.</li> <li> <strong>Keyboard Navigation:</strong> Tab through all interactive elements. Verify that the focus order makes sense and that labels or headings clearly indicate the purpose of each element as it receives focus.</li> </ul> <p>#### Automated Tools for Checking</p> <ul> <li> <strong>Browser Extensions:</strong> Axe DevTools, WAVE (Web Accessibility Evaluation Tool) can identify missing labels and incorrect heading structures on web pages.</li> <li> <strong>Command-Line Tools:</strong> <code>eslint-plugin-jsx-a11y</code> (for React) and similar linters can catch common accessibility issues in code during development.</li> <li> <strong>Mobile Accessibility Scanners:</strong> Android's Accessibility Scanner and iOS's Accessibility Inspector can provide automated checks for many accessibility criteria, including missing labels.</li> <li> <strong>CI/CD Integrated Tools:</strong> Tools like Pa11y can be integrated into CI pipelines to automatically scan web applications for accessibility violations.</li> </ul> <p>#### Mobile-Specific Considerations</p> <ul> <li> <strong><code>contentDescription</code> (Android) / <code>accessibilityLabel</code> (iOS):</strong> This is the primary mechanism for providing descriptive text for UI elements that don't have inherent text labels (like icons, images acting as buttons, or input fields without visible labels). Ensure these are set and descriptive for all interactive elements.</li> <li> <strong>Layout Structure:</strong> Native mobile UI frameworks often have concepts of views and containers. Ensure that logical groupings of content are indicated through clear headings or descriptive labels for parent containers when appropriate.</li> <li> <strong>Placeholder Text:</strong> While placeholder text can be helpful visually, it should <strong>never</strong> be the sole indicator of an input field's purpose, as it disappears on focus and is not reliably announced by all screen readers.</li> </ul> <h3>How to Fix Violations</h3> <p>#### Fixing Web Accessibility Issues</p> <ul> <li> <strong>Headings:</strong> Use semantic HTML heading tags (<code><h1></code>-<code><h6></code>) correctly.</li> </ul> <pre><code class="lang-html"> <!-- Before: Using paragraphs for headings --> <p style="font-weight: bold; font-size: 1.5em;">Product Details</p> <!-- After: Using semantic headings --> <h2>Product Details</h2> </code></pre> <ul> <li> <strong>Form Labels:</strong> Associate <code><label></code> elements with their corresponding form controls using the <code>for</code> and <code>id</code> attributes.</li> </ul> <pre><code class="lang-html"> <!-- Before: No explicit label --> <input type="email" id="userEmail"> <!-- After: With explicit label --> <label for="userEmail">Email Address:</label> <input type="email" id="userEmail"> <!-- Alternative using aria-label --> <input type="email" id="userEmail" aria-label="Email Address"> </code></pre> <p>#### Fixing Mobile Accessibility Issues</p> <ul> <li> <strong>Android (XML Layouts):</strong> Use <code>android:contentDescription</code> for elements that need a descriptive label.</li> </ul> <pre><code class="lang-xml"> <!-- Before: Icon button without description --> <ImageButton android:id="@+id/settings_button" android:src="@drawable/ic_settings" /> <!-- After: With contentDescription --> <ImageButton android:id="@+id/settings_button" android:src="@drawable/ic_settings" android:contentDescription="@string/settings_button_description" /> </code></pre> <p>(Where <code>@string/settings_button_description</code> would be defined in <code>res/values/strings.xml</code> as "Settings")</p> <ul> <li> <strong>iOS (Swift/SwiftUI):</strong> Use <code>accessibilityLabel</code> for <code>UIView</code> or <code>View</code> elements.</li> </ul> <pre><code class="lang-swift"> // Before: Button without accessibility label let myButton = UIButton(type: .system) myButton.setTitle("Save", for: .normal) // After: With accessibility label let myButton = UIButton(type: .system) myButton.setTitle("Save", for: .normal) myButton.accessibilityLabel = "Save changes" </code></pre> <h3>How SUSA Checks for WCAG 2.4.6</h3> <p>SUSA autonomously explores your application, identifying and verifying headings and labels through its intelligent crawling and persona-based testing.</p> <ul> <li> <strong>Autonomous Exploration:</strong> SUSA navigates your APK or web URL without requiring pre-written scripts. During this exploration, it identifies all visible UI elements, including headings and form controls.</li> <li> <strong>Persona-Based Dynamic Testing:</strong> SUSA simulates 10 distinct user personas, including "Curious," "Impatient," and "Accessibility" users. The "Accessibility" persona specifically focuses on testing how well the application adheres to accessibility standards like WCAG 2.4.6.</li> <li> <strong>Detection of Violations:</strong></li> <li> <strong>Headings:</strong> SUSA analyzes the semantic structure of your web pages for</li> </ul> <div class="cta-box"> <h3>Test Your App Autonomously</h3> <p>Upload your APK or URL. SUSA explores like 10 real users — finds bugs, accessibility violations, and security issues. No scripts.</p> <a href="https://susatest.com/signup" class="cta-btn">Try SUSA Free</a> </div> <div class="related"> <h3>Related Articles</h3> <div class="related-grid"> <a href="/blog/wcag-131-info-and-relationships-testing-guide" class="related-card"> <h4>WCAG 1.3.1 Info and Relationships — Testing Guide for Mobile & Web Apps</h4> <p>Read more →</p> </a> <a href="/blog/wcag-123-audio-description-or-media-alternative-testing-guide" class="related-card"> <h4>WCAG 1.2.3 Audio Description or Media Alternative — Testing Guide for Mobile & Web Apps</h4> <p>Read more →</p> </a> <a href="/blog/wcag-111-non-text-content-testing-guide" class="related-card"> <h4>WCAG 1.1.1 Non-text Content — Testing Guide for Mobile & Web Apps</h4> <p>Read more →</p> </a> <a href="/blog/wcag-1413-content-on-hover-or-focus-testing-guide" class="related-card"> <h4>WCAG 1.4.13 Content on Hover or Focus — Testing Guide for Mobile & Web Apps</h4> <p>Read more →</p> </a> </div> </div> </article> <footer> © 2026 SUSATest. Autonomous QA that tests your app like thousands of real users before release. </footer> </body> </html>