웹에 화살표로 탐색하는 대화형 목록이 필요한 이유

웹 플랫폼에 새 기능을 추가할 때는 개발자와 디자이너가 이미 HTML·CSS·자바스크립트로 구현하는 UI를 살펴보고, 이를 웹 표준에 포함하는 ‘사람들이 이미 만든 길을 닦기(pave the cowpaths)’ 방식을 쓸 수 있다. 웹 접근성 표준에도 이 원칙을 적용하면 널리 쓰이는 UI 패턴에 적절한 의미 구조와 여러 기기·설정·보조 기술에서 이해하고 조작할 수 있는 상호작용 방식을 마련해야 한다. 사라 히글리(Sarah Higley)는 웹에 그런 지원이 없는 익숙한 패턴 가운데 하나로 ‘대화형 목록’을 제안하며, ARIA 표준 논의에 참여할 수 있다고 설명한다.

대화형 목록이 필요한 곳

대화형 목록은 데이터 그리드의 1차원 버전으로 볼 수 있다. 데이터 그리드가 표(<table> 또는 role="table")의 대화형 형태라면, 대화형 목록은 정적 목록(<ul>, <ol> 또는 role="list")의 대화형 형태다. 앱 안의 카드 묶음도 맥락에 따라 대화형 목록으로 표현할 수 있다.

데이터 그리드처럼 대화형 목록은 탭 키로 한 번에 진입하는 복합 위젯이어야 하며, 목록 항목 사이를 화살표 키로 이동하는 동작을 제공한다. 따라서 콘텐츠 중심 웹사이트보다는 웹 앱에 가까운 인터페이스에 더 유용하다.

앱 내 탐색 영역은 보통 탭 키로 이동할 수 있는 링크 묶음으로 만들면 충분하다. 하지만 이메일 받은 편지함이나 웹용 PowerPoint처럼 데스크톱 앱과 비슷하게 작동하는 환경에서는 탐색 영역 전체를 탭 정지점 하나로 만들고 화살표 키로 항목을 오가는 편이 도움이 될 수 있다. 탭 목록(tablist)을 쓸 수도 있지만, 자식 링크를 포함한 대화형 목록은 화살표 키 탐색과 함께 화면 어디서든 화면 낭독기의 링크 대화상자를 여는 기능 등 링크의 이점을 유지한다. 탭 목록은 탐색 영역에 흔히 필요한 정적 섹션·그룹 제목도 지원하지 않는다.

이메일 앱 같은 다단계 탐색에는 트리를 쓰기도 한다. 그러나 링크가 들어 있는 중첩 목록은 트리보다 배우기 쉽고, 가상 커서 탐색과 링크 대화상자 사용도 유지할 수 있다. 페이지 수가 많을 수 있는 페이지 이동 기능도 대화형 목록에 적합하다. 특정 페이지로 이동하는 링크가 있다면 중첩 버튼을 둔 대화형 목록으로 만들 수 있고, 그런 링크가 없다면 내부에 다른 대화형 요소를 둘 필요가 없다. 페이지 이동을 활용 사례로 제안한 실비아 비예가스(Sylvia Villegas)에게 감사의 뜻을 전한다. ARIA 표준에는 이슈가 18페이지에 걸쳐 있다는 언급도 덧붙였다.

AI 챗봇은 성가실 수 있지만 채팅 인터페이스는 접근성을 갖춰야 한다. AI 채팅의 각 응답에는 긴 구조화 콘텐츠와 링크, 인용, 동작 버튼이 들어가는 경우가 많다. 개별 메시지는 보통 하나의 주된 동작이나 선택 상태를 갖지 않아 그 자체로 대화형이라고 하기는 어렵다. 그래도 채팅 창의 모든 콘텐츠를 탭 키로 통과해야 입력창에 도달하는 구조는 피해야 한다. 대부분의 채팅 앱은 지난 메시지를 화살표 키로 이동하고, 페이지 아래·페이지 위 키로 여러 메시지를 건너뛰는 기능도 제공한다.

캐러셀을 쓰지 말아야 한다는 말은 흔하지만, 캐러셀은 계속 만들어지고 스트리밍 서비스처럼 어느 정도 표준이 된 사례도 있다. 넷플릭스처럼 캐러셀이 연달아 있는 화면에서는 원하는 카테고리까지 탭 키로 빠르게 이동한 뒤, 해당 캐러셀의 항목을 화살표 키로 탐색할 수 있어야 한다. 다만 모든 캐러셀이 대화형 목록에 맞는 것은 아니다. 각 항목에 주된 동작이 있고 항목 사이의 화살표 탐색이 적절한 스트리밍 서비스 카테고리나 상품 캐러셀 같은 경우에 한정된다. 접근성에는 모든 상황에 통하는 한 가지 방식이 없다.

파일 탐색기는 화면 배치에 따라 대화형 목록, 여러 열에 세부 정보를 보여주는 그리드, 폴더를 그 자리에서 펼칠 수 있는 트리로 구현할 수 있다. 파일 선택 기능이 있더라도 주된 동작은 파일 열기다. 이 원칙은 파일 목록뿐 아니라 항목마다 하나의 주된 동작이 있는 다른 목록에도 적용된다.

이때 listbox 역할을 쓰고 싶을 수 있지만 적절하지 않다. listbox는 옵션의 선택 상태를 전제로 하고, 옵션을 가상 커서로 안정적으로 탐색하기 어렵고, 선택이 아닌 동작을 주된 기능으로 지원하지 않는다. GitHub의 리뷰어 목록은 현재 화살표 키 탐색을 구현한 사례는 아니지만, 맥락에 따라 탭 정지점 하나인 복합 위젯으로 만들 수 있는 UI를 보여준다. 각 사용자의 주된 동작은 프로필 보기이고, 리뷰 재요청 버튼은 그 안의 부차적 동작이다.

기존 웹 역할로는 부족하다

윈도우, macOS, iOS, 안드로이드에는 대화형 목록에 해당하는 기본 UI가 이미 있다. 보조 기술 사용자가 이 방식에 익숙해 새로운 사용법을 배울 필요가 없고, 기술·표준 측면에서도 접근성 API 매핑이 마련돼 있다는 점에서 중요하다. 기본 플랫폼에 이 상호작용 방식이 존재한다는 사실은 대화형 목록에 타당한 사용 사례가 있음을 뒷받침한다.

대화형 목록의 의미와 동작을 정하려면 다른 복합 위젯 가운데 내부에 링크·버튼·제목·목록 등을 유연하게 넣을 수 있는 그리드, 기본 의미 구조인 정적 목록, 실제 개발자들이 만드는 목록형 UI를 함께 참고해야 한다.

기본적으로 가로 또는 세로 방향으로 배열된 대화형 항목을 화살표 키로 탐색하고, 항목을 누르면 일반적인 동작을 수행할 수 있어야 한다. 이 기능만으로도 앞서 든 넷플릭스식 캐러셀 사례를 만들 수 있다. 그 밖에 필요한 조건은 다음과 같다.

• 파일 목록처럼 선택 기능을 지원하되 필수로 만들지 않아야 한다. 그리드처럼 단일 선택과 다중 선택을 모두 지원해야 한다.
• 그리드와 마찬가지로 중첩된 대화형 요소를 허용해야 한다. 그래야 중첩 링크가 있는 탐색 영역, 채팅, 추가 메뉴 버튼이 있는 빠른 접근용 파일 카드, 리뷰 재요청 버튼이 있는 GitHub 리뷰어 목록을 표현할 수 있다.
• 제목·목록·표 같은 중첩 구조 콘텐츠를 허용해야 한다. 채팅이나 파일 이름을 제목으로 표시하는 빠른 접근용 파일 카드를 지원하는 데 필요하다.
• 가상 커서 탐색이 가능해야 한다. 특히 탐색 영역, 카드, 채팅에서는 가상 커서를 선호하는 사용자가 많을 수 있다. 윈도우 화면 낭독기의 가상 커서 모드에서도 목록 콘텐츠를 탐색하고 목록 항목을 활성화할 수 있어야 한다.

정적 목록과 일반적인 복합 위젯의 기본 기능도 필요하다. 사용자가 항목을 이동할 때 목록의 구조와 관계를 전달해야 한다. 예를 들어 목록에 처음 진입할 때 전체 항목 수를 알리고 현재 항목의 순서를 알려야 한다. 키보드 조작은 탭 정지점 하나에서 화살표 키로 항목을 이동하는 방식이어야 한다. 자동 모드 전환 기능이 있는 윈도우 화면 낭독기는 그리드나 탭 목록에 진입할 때처럼 대화형 목록에 진입할 때 포커스 모드로 전환해야 한다.

ARIA에는 listbox, menu·menubar, radiogroup, tablist, toolbar 등 1차원 복합 위젯 역할이 있지만, 이 역할을 조합해도 대화형 목록의 일반적인 용례를 모두 다룰 수 없다. radiogroup과 listbox는 선택 전용 폼 컨트롤이므로 주된 클릭 동작이 선택이 아닌 UI에는 맞지 않는다. menu와 menubar는 앱 메뉴나 문맥 메뉴만을 위한 역할이며, 모든 화면 낭독기에서 가상 커서 탐색을 지원하지 않는다. listbox도 같은 문제가 있다. tablist는 연결된 tabpanel의 표시 콘텐츠를 바꾸기 위한 역할이고, 조금 더 유연한 toolbar도 페이지의 관련 영역에 영향을 주는 버튼과 폼 컨트롤을 위한 것이다. 이 역할들은 중첩된 구조 콘텐츠나 보조 대화형 컨트롤을 허용하지 않는다.

정적 목록을 쓰고 목록 항목 사이의 포커스를 직접 관리하는 방법도 충분하지 않다. 이 방식은 윈도우 화면 낭독기의 모드 전환을 올바르게 유도하지 못하고, 정적 컨테이너로 정의된 목록 항목을 화면 낭독기나 음성 제어로 직접 눌러 활성화할 수도 없다.

ARIA 제안과 참여 방법

ARIA에는 대화형 목록을 추가하자는 제안이 진행 중이며, 2026년 10월 말에 논의될 예정이다. 주요 표준 이슈는 #2036이다. 2023년 대면 회의를 정리한 마리오 바투시치(Mario Batušić)의 대화형 목록 제안과, 제안된 표준 문구를 담은 대화형 목록 제안 문서도 참고할 수 있다. 게시 시점에는 listview 역할을 추가하는 PR은 아직 준비 중이며, 링크는 추후 추가할 예정이라고 밝혔다.

ARIA에 대화형 목록이 추가되면 새로운 focusgroup 토큰을 만들어 HTML에서도 사용할 수 있다는 제안이다. 그러면 다음처럼 작성할 수 있다.

<ul focusgroup="list"> <li>Arrowing is fun</li> <li>But only where appropriate</li> <li>Like in application-style interfaces</li> <li>Let's not mess this up</li> <li>By doing things like using it for standard website navigation</li> <li>Pretty please</li></ul>

대화형 목록으로 표현할 수 있는 UI 사례나 빠뜨린 기능에 대한 의견은 10월 26일 논의 전까지 Bluesky 게시물에 답글을 달거나 ARIA GitHub 이슈에 남길 수 있다.

부록: 원문 예시

), an interactive list would be the interactive version of a static list (i.e.