Horizontal Scroll UX: When It Works and When It Doesn't

How I Got Here

This portfolio uses a horizontal scroll layout. Seven sections — Home, About, Portfolio, Blog, Services, FAQ, Contact — arranged side by side, navigated by scrolling, swiping, arrow keys, or clicking dots at the bottom of the screen.

It was a deliberate design decision, and I've thought hard about whether it was the right one. This post documents that thinking.

When Horizontal Scroll Works

Storytelling and linear narratives

Horizontal scroll forces sequential consumption. You can't skip to section 5 without passing through sections 1–4 (without using the nav dots). For a portfolio, that's a feature: the story of who I am, what I've built, how I work, and how to reach me unfolds in order.

This is also why horizontal scroll works well for product landing pages, onboarding flows, and interactive presentations. When there's a narrative arc and you want the user to follow it, the layout enforces that.

Short, distinct content panels

Each section of this portfolio is exactly one viewport. Horizontal scroll breaks down when individual panels have varying heights or long-form content that needs vertical scrolling itself. When every section fits one screen, the mechanic is clean.

If you're thinking about horizontal scroll for a project, ask: can each section be self-contained in one viewport? If not, you'll be fighting the layout.

Desktop-first experiences

On a wide monitor, horizontal space is abundant and often underused. Horizontal scroll reclaims that space and gives the layout a cinematic quality. On mobile, it's a different story (more on that below).

When you want to stand out

Most sites scroll vertically. Horizontal scroll is immediately distinctive. For a portfolio specifically, a memorable layout IS part of the product — you're showcasing what you can build, and this layout demonstrates that you can build something unusual.

When Horizontal Scroll Fights the User

Long-form content

Blog posts, documentation, articles — anything that requires extended reading — should scroll vertically. Readers scan down, not sideways. Forcing horizontal on reading content creates cognitive friction.

This is why the blog posts and service pages on this site break out of the horizontal layout entirely. The home page is horizontal; the subpages are standard vertical scroll.

Content of unknown or variable length

Horizontal scroll requires knowing your content dimensions at design time. If you're building a CMS-driven page where content length varies, each section may overflow its panel unpredictably. You either clip the content or break the mechanic.

Accessibility

This is the most serious concern. Horizontal scroll:

• Disrupts keyboard navigation for screen reader users who expect Tab to move through focusable elements, not trigger section changes
• Fights the browser's default scroll behavior
• Requires explicit handling for all input methods: mouse wheel, trackpad, keyboard, touch swipe, and nav buttons

If you build horizontal scroll, you must handle all five input methods well. This portfolio handles:

• Mouse wheel: Intercepts WheelEvent, translates vertical scroll to section change
• Trackpad two-finger swipe: Detected via deltaX on WheelEvent
• Keyboard: ArrowLeft/ArrowRight mapped to scrollPrev/scrollNext
• Touch swipe: touchstart + touchend delta calculation
• Nav dots: Direct scrollTo with smooth behavior

If any of these break, some percentage of users can't navigate. Build it well or don't build it.

Mobile

On mobile, the native scroll direction is vertical. Users swipe up to scroll — this is a deeply ingrained mental model. Horizontal swipe works on mobile, but it competes with browser back/forward gestures, especially on iOS.

My implementation uses a 50px minimum swipe distance and checks whether the swipe is primarily horizontal before intercepting it. This prevents accidental section changes when users are trying to scroll within a section.

The Implementation

The core mechanic in layouts/horizontal.vue:

const handleWheel = (e: WheelEvent) => {
  if (isScrolling) return

  // Allow natural scroll inside scrollable child elements
  const scrollableParent = (e.target as HTMLElement)
    .closest('.overflow-y-auto')
  if (scrollableParent) {
    // Check if we're at the boundary before capturing the event
    const { scrollTop, scrollHeight, clientHeight } = scrollableParent
    const atTop = scrollTop === 0
    const atBottom = Math.abs(scrollHeight - clientHeight - scrollTop) < 1
    if (e.deltaY > 0 && !atBottom) return
    if (e.deltaY < 0 && !atTop) return
  }

  e.preventDefault()

  const delta = Math.abs(e.deltaY) > Math.abs(e.deltaX) ? e.deltaY : e.deltaX
  if (Math.abs(delta) > 30) {
    isScrolling = true
    delta > 0 ? scrollNext() : scrollPrev()
    setTimeout(() => { isScrolling = false }, 600)
  }
}

Three things matter here:

1. Debounce with isScrolling flag. Without this, a single wheel event fires dozens of times and skips multiple sections.
2. Boundary detection for nested scrollable elements. If a section has its own scrollable area (like a tall services list), vertical scroll should work inside it. Only when you hit the top or bottom should the horizontal navigation take over.
3. The 600ms timeout. This matches the CSS scroll-behavior: smooth animation duration. Too short and sections can be skipped; too long and the layout feels sluggish.

What I'd Do Differently

Add a "scroll to explore" indicator on mobile. Users on mobile who haven't interacted with horizontal layouts before need a cue. An animated swipe hint on first load would reduce the initial confusion.

Make sections individually deep-linkable. Right now, all deep links go to the home page and you navigate from there. Adding URL hash updates (#about, #portfolio, etc.) as sections change would improve shareability and allow direct linking.

Test with real users earlier. I built the mechanic first and refined it based on personal use. A few sessions with people who'd never seen the layout would have surfaced the mobile UX issues faster.

The Verdict

Horizontal scroll works well for this portfolio. The content is panel-sized, the narrative is linear, and the layout differentiates the site from standard template portfolios.

It would be the wrong choice for a blog, a documentation site, a SaaS dashboard, or anything where users need to scan, search, or read long-form content.

The pattern isn't good or bad — it's situational. The mistake isn't using it; it's using it without understanding why.