Make accessible carousels  |  Blog  |  Chrome for Developers
Blog

Make accessible carousels  |  Blog  |  Chrome for Developers

2026.03.25
·Web·by 이호민
#Accessibility#Carousel#CSS#Frontend#Web Development

핵심 포인트

  • 1캐러셀의 접근성 문제는 복잡하며, Chrome 팀은 이를 해결하기 위해 CSS Overflow Module Level 5의 대화형 CSS 캐러셀 기능을 Chrome 135에 도입했습니다.
  • 2이 기능은 `scroll-state` 컨테이너 쿼리와 `interactivity` 속성을 활용하여 off-screen 요소를 비활성화하고 스크린 리더 공지를 개선하는 등 접근성 문제를 해결합니다.
  • 3이 글은 단일 항목, 페이지 매김, 다중 항목 캐러셀 유형에 맞는 `semantic HTML`, `CSS scroll snapping`, `ARIA` 속성 적용 가이드를 제공하며, 궁극적으로 완전한 접근성 테스트를 통해 견고한 사용자 경험을 보장합니다.

이 문서는 캐러셀(carousels)의 접근성(accessibility) 문제를 해결하기 위한 Chrome 팀의 노력과 그 결과물인 CSS Overflow Module Level 5의 새로운 기능들을 소개합니다. 캐러셀은 널리 사용되지만, 포커스(focus) 관리, 스크린 리더(screen reader) 공지, 화면 밖 요소 처리 등 여러 문제로 인해 접근성 구현이 어렵다는 점을 지적합니다.

본문은 이러한 문제를 해결하기 위해 Chrome 135에 출시된 CSS Overflow Module Level 5의 주요 기능들, 특히 scroll-state 컨테이너 쿼리(container query)와 interactivity 속성을 활용한 접근성 높은 캐러셀 구현 방법을 자세히 설명합니다. 또한, 커뮤니티 피드백을 반영하여 discretenavigational scroll marker modes 지원, alt text 내 카운터(counters) 지원, ::scroll-button 비활성화 상태의 스크린 리더 인식 문제 해결, ::scroll-marker의 ARIA 레이블(label) 문제 해결, ::scroll-marker의 "selected" 중복 읽기 문제 해결 등 개선 사항들도 언급합니다.

핵심 방법론 (Core Methodology)

이 문서에서 제시하는 접근성 캐러셀 구현의 핵심은 다음과 같습니다:

  1. 선언적(Declarative) 제어: JavaScript 없이 CSS만으로 캐러셀의 동작과 접근성을 선언적으로 제어합니다.
  2. scroll-state 컨테이너 쿼리 활용: 이는 요소가 스크롤포트(scrollport) 내에서 스냅(snapped)되었는지(snapped: inline)와 같은 스크롤 상태에 따라 스타일을 적용할 수 있게 해주는 새로운 CSS 기능입니다. 이를 통해 현재 보이는 활성(active) 슬라이드에만 특정 스타일이나 동작을 부여할 수 있습니다.
  3. interactivity 속성 사용: 이 속성은 요소의 콘텐츠가 인터랙티브(auto)한지 또는 비활성(inert)한지(interactivity: inert)를 제어합니다. interactivity: inert를 사용하면 해당 요소와 그 자식 요소들이 포커스를 받거나 클릭되는 것을 방지하고, 접근성 트리(accessibility tree)에서 제외되게 할 수 있습니다. 이를 통해 화면 밖(off-screen)에 있는 슬라이드의 요소들이 의도치 않게 포커스되는 문제를 해결하여 tabindex를 수동으로 관리할 필요가 없어집니다.

캐러셀 유형별 접근성 전략

문서는 세 가지 일반적인 캐러셀 유형에 대해 각각의 접근성 고려 사항과 모범 사례를 제시합니다.

  1. 단일 항목 캐러셀 (Single-item carousels):
    • 한 번에 하나의 슬라이드만 완전히 보이고 인터랙티브합니다 (예: 영웅 배너, 슬라이드쇼).
    • 구현 방법:
      • scroll-snap-type: inline mandatory;scroll-snap-align: center;를 사용하여 스크롤 후 슬라이드가 항상 정확한 위치에 스냅되도록 합니다.
      • 캐러셀 컨테이너에 role="region"role="region", aria-label (예: "Slideshow"), arialive="polite"aria-live="polite" 속성을 추가하여 스크린 리더 사용자에게 캐러셀 진입 및 슬라이드 변경을 알립니다. arialive="polite"aria-live="polite"는 슬라이드 변경 시 스크린 리더가 사용자에게 방해되지 않도록 부드럽게 공지하도록 합니다.
      • interactivity: inert;를 기본값으로 설정하여 모든 슬라이드를 비활성화한 다음, container-type: scroll-state;@containerscrollstate(snapped:inline)>.contentinteractivity:auto;@container scroll-state(snapped: inline) { > .content { interactivity: auto; } }를 사용하여 현재 스냅된(즉, 보이는) 슬라이드만 인터랙티브하게 만듭니다.
  1. 페이지 매겨진 캐러셀 (Paginated carousels):
    • 콘텐츠가 페이지로 그룹화됩니다 (예: 제품 갤러리).
    • 두 가지 접근 방식:
      • discrete 페이지를 가진 캐러셀:
        • role="region"role="region" 컨테이너 내부에 단일 role="tabpanel"role="tabpanel" 요소를 사용합니다. arialive="polite"aria-live="polite"는 스크롤 시 너무 많은 공지를 유발할 수 있으므로 사용하지 않습니다.
        • interactivity: inert;를 기본으로 하고, animation-timeline: view(inline);을 사용하여 view() 타임라인(timeline)에 따라 현재 보이는 항목만 인터랙티브하도록 만듭니다.
      • 콘텐츠 목록 (List of contents):
        • 콘텐츠가 본질적으로 목록인 경우 <ul><ul> 요소를 사용하여 올바른 의미론(semantics)을 부여합니다.
        • 이 경우 interactivity 속성을 사용하여 화면 밖 콘텐츠를 inert로 만들지 않습니다. 왜냐하면 그렇게 하면 스크린 리더가 항목 수를 잘못 계산할 수 있으므로 모든 콘텐츠가 접근성 트리에 남아 있어야 합니다.
  1. 다중 항목 캐러셀 (Multi-item carousels):
    • 여러 자식 요소가 동시에 보이고 읽을 수 있는 캐러셀입니다 (예: "관련 제품" 섹션).
    • 두 가지 접근 방식:
      • 표시된 항목 중 단일 인터랙티브 항목:
        • 여러 항목이 보이지만, 기본 또는 "현재" 항목만 인터랙티브하고 다른 보이는 항목은 inert입니다.
        • 단일 항목 캐러셀과 동일한 패턴을 사용합니다. scroll-state 컨테이너 쿼리를 사용하여 비활성 항목에 interactivity: inert를 적용합니다. 각 항목이 기본 위치(예: 스크롤포트 중앙)에 스냅될 수 있도록 충분한 패딩(padding)을 추가합니다.
      • 모든 보이는 항목이 인터랙티브:
        • 사용자가 보이는 모든 항목과 자유롭게 상호 작용할 수 있도록 합니다.
        • 콘텐츠가 의미론적으로 목록이라면 <ul><ul> 요소를 사용합니다.
        • interactivity 관리(예: interactivity: inert 사용)를 하지 않습니다. 모든 보이는 콘텐츠는 접근성 트리에 남아 있어야 하며 키보드 tab 이동으로 접근 가능해야 합니다.

결론적으로, CSS Overflow 5의 새로운 기능들을 활용하면 의미론적인 HTML, scroll-stateinteractivity와 같은 최신 CSS, 적절한 ARIA 역할 조합을 통해 높은 성능과 접근성을 갖춘 캐러셀을 선언적으로 구축할 수 있습니다. 하지만, 어떤 UI(User Interface)든 완벽한 접근성을 보장할 수는 없으므로, 항상 철저한 접근성 테스트가 필수적임을 강조합니다.