Building a Show More Accessible Disclosure Widget

Disclosure widgets like “Show More” or “Read More” help manage content density by revealing information progressively, keeping interfaces clean and user-friendly. While they enhance visual design and usability, making them accessible requires thoughtful implementation.

This article explores the principles, design considerations, and implementation techniques for building an accessible disclosure widget in compliance with the Web Content Accessibility Guidelines (WCAG).

What is a Disclosure Widget?

A disclosure widget is an interactive element that lets users expand or collapse sections of content. It typically starts with content hidden or minimized, accompanied by a control that allows users to reveal the full information when needed.

Common examples include:

• “Show More” buttons that reveal additional text in articles or product descriptions
• FAQ accordions that expand to show answers when questions are clicked
• “See More Comments” buttons on social media platforms
• Navigation menus that expand to reveal additional options on mobile devices

The primary purpose of disclosure widgets is to manage information density, allowing users to focus on essential content first while providing access to supplementary information on demand. When implemented correctly, these components improve user experience by reducing cognitive load and visual clutter without removing access to content.

Challenges for Disabled Users with Inaccessible Disclosure Widgets

When disclosure widgets are not built with accessibility in mind, they can present significant challenges for users with disabilities:

For screen reader users:

• Undiscoverable controls that aren’t properly announced as expandable
• No programmatic indication of the expanded/collapsed state
• No notification when content appears or disappears
• Hidden content that remains inaccessible even after activation

For keyboard-only users:

• Controls that can’t be accessed via keyboard navigation
• No visible focus indicators showing which element is currently selected
• Inability to activate controls using standard keyboard commands

For users with cognitive disabilities:

• Confusing or inconsistent labeling that doesn’t clearly indicate the purpose
• No visual cues about which elements are interactive
• Complicated interaction patterns that aren’t intuitive

For users with low vision:

• Poor contrast between the control and its background
• Tiny tap targets that are difficult to interact with
• Animations that can trigger vestibular disorders

These challenges not only frustrate users but can completely prevent access to important information. Creating accessible disclosure widgets ensures all users can access website content conveniently. Platforms like BrowserStack Accessibility help teams identify and resolve such issues early, making it easier to build inclusive, WCAG-compliant digital experiences.

WCAG Guidelines for Disclosure Widgets

The Web Content Accessibility Guidelines (WCAG) provide several requirements relevant to disclosure widgets:

1. Perceivable

• Info and Relationships (Level A): The state of disclosure widgets (expanded/collapsed) must be programmatically determined.
• Contrast (Level AA): Text and images containing text should have a minimum contrast ratio of 4.5 to 1.
• Non-text Contrast (Level AA): Visual elements like buttons and focus indicators require a contrast ratio of at least 3:1.

2. Operable

• Keyboard (Level A): All functionality must be operable through a keyboard interface.
• Focus Order (Level A): Focus must move in a meaningful sequence, particularly when content appears or disappears.
• Focus Visible (Level AA): Any keyboard operable user interface must have a visible focus indicator.
• Target Size (Level AAA): Interactive elements should be at least 44×44 pixels.

3. Understandable

• Consistent Identification (Level AA): Components with the same functionality should be identified consistently.
• Labels or Instructions (Level A): When user input is needed, clear labels or guidance should be provided to ensure users understand what is expected.

4. Robust

• Name, Role, Value (Level A): For all user interface components, the name, role, and state must be programmatically determinable.

Building an Accessible “Show More” Disclosure Widget

Here’s an example to build a fully accessible “Show More” disclosure widget that aligns with WCAG standards.

The component will display a truncated paragraph by default, along with a button that reveals the full content when activated. The process is outlined in the steps below

Step 1: Create a named HTML file (index.html) and write the following code in it:

```<!DOCTYPE html>

<html lang="en">

    <head>

        <meta charset="UTF-8">

        <meta name="viewport" content="width=device-width, initial-scale=1.0">

        <title>Disclosure Widget</title>

        <link rel="stylesheet" href="styles.css">

    </head>

    <body>

        <div class="disclosure-widget">

                <div class="disclosure-content" id="content-1">

                    <p class="content-visible">

                    This is the initially visible content that appears on page load.

                    It provides enough context for users to decide if they want to see more.

                    </p>

                    

                    <div class="content-hidden" id="hidden-content-1" aria-hidden="true" hidden>

                    <p>

                        This is the hidden content that will be revealed when the user activates 

                        the disclosure button. It could contain additional details, examples, or 

                        extended information that might not be necessary for all users.

                    </p>

                </div>

            </div>

        

            <button 

                class="disclosure-button" 

                aria-expanded="false" 

                aria-controls="hidden-content-1"

                id="disclosure-button-1">

                <span class="button-text">Show more</span>

                <svg class="button-icon" aria-hidden="true" width="24" height="24" viewBox="0 0 24 24">

                <path d="M7 10l5 5 5-5H7z"></path>

                </svg>

            </button>

        </div>

        <script src="index.js"></script>

    </body>

</html>

```

The structure of the Show More disclosure widget is created in the file above. The next step is to style it.

Step 2: Create a name CSS file (styles.css) and write the following code in it:

```.disclosure-widget {

  max-width: 600px;

  margin: 20px 0;

  font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif;

  line-height: 1.5;

}




.content-hidden {

  margin-top: 8px;

}




/* Hide content when the hidden attribute is applied */

[hidden] {

  display: none;

}




.disclosure-button {

  display: flex;

  align-items: center;

  background-color: #0056b3;

  color: white;

  border: none;

  border-radius: 4px;

  padding: 8px 16px;

  font-size: 16px;

  margin-top: 16px;

  cursor: pointer;

  transition: background-color 0.2s;

}




/* High contrast for accessibility */

.disclosure-button:hover {

  background-color: #003d82;

}




/* Visible focus indicator */

.disclosure-button:focus {

  outline: 3px solid #005fcc;

  outline-offset: 2px;

}




/* Focus indicator for high contrast mode */

@media screen and (-ms-high-contrast: active) {

  .disclosure-button:focus {

    outline: 2px solid currentColor;

  }

}




.button-text {

  margin-right: 8px;

}




.button-icon {

  transition: transform 0.2s ease;

}




/* Rotate icon when expanded */

.disclosure-button[aria-expanded="true"] .button-icon {

  transform: rotate(180deg);

} 

```

Now that you have the structure and styling for the Show More widget, the next step is to add interactivity to the Show More widget. This will be implemented using JavaScript.

Step 3: Create a named JavaScript file (index.js) and write the following code in it:

```

document.addEventListener('DOMContentLoaded', function() {

  const disclosureButtons = document.querySelectorAll('.disclosure-button');

    disclosureButtons.forEach(button => {

    button.addEventListener('click', toggleDisclosure);

  });  

  function toggleDisclosure() {

    // Get the current expanded state

    const isExpanded = this.getAttribute('aria-expanded') === 'true';

        // Get the controlled element ID

    const controlledId = this.getAttribute('aria-controls');

    const controlledElement = document.getElementById(controlledId);

    

    if (!controlledElement) return;

        // Toggle expanded state

    this.setAttribute('aria-expanded', !isExpanded);

        // Update button text

    const buttonText = this.querySelector('.button-text');

    buttonText.textContent = isExpanded ? 'Show more' : 'Show less';

    

    // Toggle visibility of content

    if (isExpanded) {

      controlledElement.setAttribute('aria-hidden', 'true');

      controlledElement.hidden = true;

    } else {

      controlledElement.removeAttribute('aria-hidden');

      controlledElement.removeAttribute('hidden');

            // Optional: Announce to screen readers that content has expanded

      announceContentExpanded(controlledId);

    }

  }  

  function announceContentExpanded(contentId) {

    // Create a live region to announce the change

    const liveRegion = document.createElement('div');

    liveRegion.setAttribute('aria-live', 'polite');

    liveRegion.setAttribute('aria-atomic', 'true');

    liveRegion.classList.add('sr-only');

    document.body.appendChild(liveRegion);

    // Announce the change after a small delay to ensure screen readers catch it

    setTimeout(function() {

      liveRegion.textContent = 'Content expanded';

      

      // Remove the announcement after it's been read

      setTimeout(function() {

        document.body.removeChild(liveRegion);

      }, 1000);

    }, 100);

  }

});

// Helper CSS for screen reader only content

const style = document.createElement('style');

style.textContent = `

  .sr-only {

    position: absolute;

    width: 1px;

    height: 1px;

    padding: 0;

    margin: -1px;

    overflow: hidden;

    clip: rect(0, 0, 0, 0);

    white-space: nowrap;

    border: 0;

  }`

document.head.appendChild(style);

Step 4: Save and execute the code.

WCAG Disclosure Button Best Practices

Beyond the basic implementation, here are additional best practices to build an accessible disclosure button:

1. Clear and Consistent Labeling

Always provide clear, descriptive labels that indicate:

• What action the button performs (“Show more”)
• What content will be revealed (“Show more product details”)
• The current state (switching between “Show more” and “Show less”)

2. Provide Multiple Cues

Don’t rely on a single indicator to communicate interactivity:

• Use conventional button styling
• Include icons alongside text
• Apply subtle hover effects
• Ensure adequate color contrast

3. Manage Focus Appropriately

When new content appears:

• For critical information, move focus to the newly revealed content
• For supplementary information, maintain focus on the button
• Always ensure users can easily navigate to the new content

4. Handle Resizing and Zooming

Disclosure widgets should adapt easily when users:

• Resize browser window
• Zoom in (up to 200%)
• Use text-only zoom
• View content on various screen sizes

5. Support Alternative Input Methods

Ensure your disclosure widget works with:

• Touch interfaces (with adequate tap target size)
• Voice control software (with clear button names)
• Switch devices (with logical tab order)
• Mouse alternatives (with precise focus control)

6. Color Contrast

Ensure sufficient contrast between the text on the button and its background. According to WCAG guidelines, normal text should have a minimum contrast ratio of 4.5 to 1, while large text should meet a lower threshold of 3 to 1 to remain accessible.

Implementing Keyboard Navigation and Focus Management

Implementing keyboard navigation and focus management ensures websites and applications are accessible to everyone, including those who rely on keyboard navigation.

This involves making all interactive elements focusable, maintaining a logical tab order, providing visible focus indicators, and managing focus within dynamic content and focus traps. Proper keyboard accessibility requires attention to navigation patterns and focus management:

Tab Order

• Ensure disclosure buttons are in the natural tab order
• Make sure the tab order follows a logical sequence when content expands
• Don’t trap keyboard focus within expanded content

Keyboard Activation

• Buttons should be activatable with both the Enter and Space keys
• Arrow keys should not be required to operate basic disclosure functionality
• If using arrow keys for related disclosure sets (like accordions), document this pattern

Focus Management Strategies

Different disclosure widget types require different focus management:

1. For informational disclosures (like “Show more” text):

• Keep focus on the button after activation
• User can then continue reading or tab to the next control

2. For functional disclosures (like dropdown menus):

• Move focus to the first interactive element in the disclosed content
• Provide a clear way to return focus to the trigger

3. For modal disclosures (like dialogs triggered by disclosure):

• Move the focus into the modal
• Trap focus until the modal is closed
• Return focus to the trigger when closed

Designing for Accessibility

To design for accessibility, it is important to focus on ensuring color contrast is sufficient, font sizes are appropriate, and elements are visually distinguishable. This means using a minimum contrast ratio of 4.5:1 for small text and 3:1 for large text.

Fonts should be large enough for easy readability, with 12pt (16px) for regular text and 18pt (24px) for large text being good starting points. Elements should be designed so they are clearly identifiable and not rely solely on color for conveying information.

Accessible design goes beyond technical implementation to ensure disclosure widgets are visually accessible:

1. Color Contrast Requirements

• Button text: Minimum 4.5:1 contrast ratio against background
• Button borders: Minimum 3:1 contrast ratio against adjacent colors
• Icons: Minimum 3:1 contrast ratio against background
• Focus indicators: Minimum 3:1 contrast ratio against adjacent colors

2. Visual Distinction

Make sure disclosed content is visually distinct through:

• Indentation or padding
• Background color changes
• Borders or dividers
• Typography variations
• Animation (with care for users with motion sensitivity)

3. Inclusive Touch Targets

• Minimum touch target size: 44×44 pixels
• Adequate spacing between interactive elements (at least 8px)
• Extended touch area beyond visual boundaries when needed

4. Respecting User Preferences

• Respect reduced motion settings with prefers-reduced-motion media query
• Support dark mode with prefers-color-scheme media query
• Ensure functionality at increased text sizes and zoom levels

Testing for Accessibility Compliance using BrowserStack

Accessibility testing helps ensure that websites and applications are usable by everyone, including people with disabilities. It evaluates how easily users can navigate, read, and interact with content using assistive technologies. This process supports compliance with accessibility standards and promotes inclusive digital experiences.

BrowserStack Accessibility Testing offers a unified, web-based solution for identifying and monitoring accessibility issues across your site or web application. It enables teams to stay confident about accessibility compliance and audit readiness at all times. The platform combines three key testing approaches:

• Automated testing for detecting static issues using the Workflow Analyzer
• Assisted testing for identifying more advanced issues through guided checks
• Manual testing for uncovering usability concerns using screen readers

Getting Started with BrowserStack Accessibility Toolkit

1. Open the webpage you want to test in your browser
2. Launch DevTools (right-click on the page and select Inspect)
3. Navigate to the Accessibility Toolkit tab
4. Select a testing method: Workflow Analyzer, AI-Assisted Testing, or Screen Reader Testing

This toolkit makes it easy to identify accessibility gaps early, streamline fixes, and deliver a user experience that works for everyone.

Talk to an Expert

Conclusion

An accessible disclosure widget ensures that all users, regardless of ability, can access hidden content seamlessly. Building accessible disclosure widgets requires attention to details, interactive behavior, visual design, and functionality across platforms.

By following WCAG guidelines and implementing proper keyboard navigation, ARIA attributes, and focus management, a proper “Show More” component can be created for all users, regardless of their abilities or assistive technologies.