AEM User Story Example: Accordion Component

Being an AEM tech lead, I’ve sat through countless meetings about ticket creation. One thing that keeps popping up? The struggle to create that ‘perfect’ ticket. You know, the one where everything’s clear, and nobody has to ping you with a dozen follow-up questions.

So, I took a shot at crafting a solid example of a user story. For this one, I’m diving into making a new Accordion Component. It’s gotta be user-friendly, look good, be accessible to everyone, and make life easy for our content authors.

I tried to extend this User Story will a lot of extended requirements and details. It captures:

  1. Business Requirements
  2. Author Requirements
  3. Accessibility Requirements

Curious? Check out my take below. Maybe it’ll help you out the next time you’re scratching your head over a ticket!

Epic: Component Development

Story Title: Accordion Component

User Story:

As a content author,
I want to create an accordion component,
So that I can showcase content in an organized, collapsible format that’s inclusive to all users, including those with accessibility needs.


We’re gearing up to develop an accordion component that’s not just visually appealing and user-friendly but is also deeply rooted in accessibility principles. This isn’t just a collapsible tool for content, but a beacon of inclusivity, especially for users relying on assistive technologies.


[Figma Link or attach mock-ups or wireframes for the Accordion Component.]


  • Collaboration with the QA team is essential for extensive testing across browsers and in terms of accessibility.


  • The accordion component should support a hierarchy with headers and corresponding content sections.
  • Headers must be clickable, triggering the expansion or collapse of their related content.
  • The accordion should have a default style but should also be customizable to fit various website themes.
  • Animated transitions for expanding and collapsing sections would enhance the user experience.
  • Responsive behavior is essential; the accordion should adapt seamlessly to various screen sizes, including mobile, tablet, and desktop.
  • It should be lightweight, ensuring that it doesn’t significantly affect page load times.
  • Support for nesting accordions (accordion within an accordion) should be considered.
  • An option to search or filter items within the accordion would be a useful feature for content-heavy implementations.

Author Requirements:

  • The Touch UI interface should display clear labels or icons indicating functionality, like “Add”, “Re-order”, or “Delete Accordion Item.”
  • The Touch UI interface should allow content author’s to customize the accordion title; each accordion title added under the multi-field list will render an accordion content area (accordion body) on the editor.html page.
  • Each accordion content area should allow author’s to drag and drop any amount of “Sourced Code Content” Components, allowing for diverse rich content options.
  • A preview option should allow authors to view their changes in real-time before saving or publishing.
  • Expected Touch UI interface:
    Tab1: Items
    -- default: EMPTY
    + (default) componentType = 'container'
    + accordion title label

    Tab2: Properties
    [checkbox] Single Item Expansion
    -- default: unchecked
    -- help: Forces a single accordion item to be expanded at a time. Expanding one item will collapse all others.

    [dropdown-multi-select] Expanded Items
    -- default: Select
    -- help: The items that are expanded by default.

    [text-field] ID
    -- default: EMPTY
    -- help: HTML ID attribute to apply to the component.

Accessibility Requirements:

  • ARIA landmarks, roles, and states (like `aria-expanded`) should be implemented for the accordion to convey its status and function to assistive technologies.
  • Logical tab order should be maintained, ensuring that keyboard users navigate through accordion elements in a coherent sequence.
  • A “skip to content” link should be available, permitting users to bypass the accordion if they don’t wish to interact with it.

Acceptance Criteria:

  • The accordion should be responsive, ensuring usability across devices from mobile to desktop.
  • Users must be able to expand or collapse content by clicking/tapping the accordion header.
  • Clear visual indicators, like ‘+’ for collapsed and ‘−’ for expanded sections, should be present.
  • Accordion design should permit a minimum of one item and a maximum of ten items.
  • By default, accordion content should remain collapsed unless an author configures it otherwise.
  • As styled per Figma.

Author Acceptance Criteria:

  • Content authors should be able to drag the accordion component from the component panel and drop it into their desired page location.
  • Authors should find easy-to-identify areas or placeholders within the accordion where they can add text, images, videos, or other content types, from the accordion content area.
  • Rearranging should involve simple drag-and-drop mechanics from the Touch UI interface. If an author wants to move the third accordion item to the first position, they should be able to do this intuitively.
  • Configuration options must be present, allowing authors to set which accordion items are expanded when the page loads, mechanics from the Touch UI interface.
  • An easy-to-spot toggle option should let authors expand or collapse all accordion items with a single click, mechanics from the Touch UI interface.

Accessibility Acceptance Criteria:

  • Keyboard focus should move sequentially through accordion headers using the Tab key. Reverse navigation should be facilitated with Shift+Tab.
  • When focused on an accordion header, pressing Enter should change its state from collapsed to expanded or vice-versa.
  • Screen readers should provide feedback on the accordion’s state and content, such as “Item 1 expanded” or “Item 2 collapsed.”
  • Text-to-background contrast ratios must adhere to WCAG guidelines, ensuring content is discernible for users with visual challenges.
  • Testing should confirm compatibility with widely-used assistive technologies like JAWS and NVDA.


In developing the accordion component, it’s paramount to blend aesthetics, functionality, and accessibility. This component reflects our dedication to crafting user-centric and inclusive digital experiences.

Hello, I am an enthusiastic Adobe Community Advisor and a seasoned Lead AEM Developer. I am currently serving as an AEM Technical Lead at, bringing over a decade of extensive web engineering experience and more than eight years of practical AEM experience to the table. My goal is to give back to the AEM Full Stack Development community by sharing my wealth of knowledge with others. You can connect with me on LinkedIn.

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top