드롭다운(Drop-down)으로 불리는 것들에 대하여

11분

2021.08.26.

12.1K

본문은 위시켓과 번역가 윌리(Willy)가 함께 만든 해외 콘텐츠 기반 번역문입니다. 사용자 인터페이스와 관련된 다양한 정보를 다루는 ‘Adrian Roselli’의 블로그 글을 번역했습니다. 필자인 애드리안 로젤리(Adrian Roselli’)는 컨설턴트이자, 사용자 인터페이스와 멀티미디어 및 소프트웨어 응용 프로그램을 위한 인터페이스를 개발하고 있습니다. 본문은 드롭다운(Drop-down)으로 불리는 용어들에 대해 정리한 내용으로, 앞으로 어떻게 부를지에 대해 함께 고민해보셔도 좋겠습니다.

저는 네이티브 플랫폼 개발자와 웹 개발자 모두와 함께 일해봤습니다. 컴포넌트의 이름은 다르더라도 동일하게 동작한다면 큰 문제가 되지 않았죠. 예를 들어 텍스트박스(TextBox)라고 말하면 사람들은 어려움 없이 HTML의 <input type="text"> 컴포넌트를 떠올렸습니다. 적어도 1995년에는 그랬습니다. 그리고 광고 에이전시에서 웹 개발팀과 함께 일한 경험도 있습니다. 그들이 사용하는 하이퍼카드(HyperCard) 또는 디렉터(Director)와 같은 툴에 관련된 기술 용어를 프로젝트 곳곳에서 찾아볼 수 있었습니다. 그래서 디자인의 어떤 요소를 하이퍼텍스트라 부르면, 아마 HTML 링크를 말하는 것이라고 가정할 수 있었습니다.

드롭다운(Drop-down)이라는 용어는 두 그룹에서 공통으로 사용하고 있었습니다. 그러나 같은 용어를 사용했음에도 불구하고 때로는 웹에서 구현이 불가능한 디자인이 튀어나오곤 했습니다. 모든 사람이 동시에 같은 회의실에 참석하지 못하고, 드롭다운이라는 용어에 대해 모두가 공통된 이해가 없는 이 상황을 어떻게 해결할지 고민하기 시작했습니다. 디자인, 문서화, 개발을 시작할 때 무엇을 왜 만드는지 이해하는 것은 매우 중요합니다. 누군가 여러분에게 "드롭다운"이라고 말했다면 아래 중 무엇을 의미할까요? 고객은 어떻게 생각할까요? 디자이너는? 개발자는? 뿐만 아니라 사용자(콜센터에 문의하는 사람), 스크린리더[1], 음성인식 소프트웨어 등 다양한 시각에서 고려해야 합니다.

1.<select>

HTML에서 기본적으로 제공하는 네이티브 <select>를 의미한다면 "셀렉트(select)"라고 부르세요.

그 단어 자체가 기술적으로 어떻게 구현해야 하는지, 그리고 어떤 제약이 있는지를 잘 설명해줍니다. 디자인 문제에대한 해답은 여러분이 생각하는 것보다 가까이 있습니다. 스크린리더 사용자에게 <select>를 설명하는 경우 macOS & iOS의 VoiceOver와 Android의 TalkBack은 이를 팝업 버튼이라 부른다는 사실을 숙지해야 합니다. JAWS[2]와 NVDA[3]에서는 이를 콤보박스(combobox)라고 부릅니다.

모두가 <select>를 싫어하는 이유는 단지 끔찍한 UI 때문이 아니라 커뮤니케이션 문제가 크다고 생각합니다. 고객이 개발 책임자에게 "드롭다운"을 추가해 달라고 했을 때 개발 책임자는 개발 스펙에 "드롭다운"이라 적어 디자이너에게 전달합니다. 디자이너는 드롭다운에 대한 본인의 이해를 바탕으로 디자인을 제작하고 최종적으로 개발자에게 전달하지만, 개발자가 사용할 수 있는 도구는 <select>밖에 없습니다.

2. ARIA 리스트박스

ARIA는 일반적으로 전체 위젯 내에서 필요한 UI 요소를 하나의 컨테이너로 묶어 정의하는 역할을 합니다. listbox role은 기본적으로 네이티브 <select>와 같은 역할을 합니다. listbox 하위의 자식 요소들은 role 속성에 "option"이라 정의하여 네이티브 <option>과 동일한 역할을 합니다.

이 컴포넌트를 지칭하려면 "ARIA 리스트박스(listbox)"라고 부르세요.

이 용어를 사용하면 결과물이 어떨지 예상할 수 있고, 디자이너는 브라우저의 기본 <select>가 가진 제약에서 벗어날 수 있습니다. listbox를 사용해 목록을 구현하는 방법은 여러 가지가 있으며 동작 방식에 확연한 차이점이 존재합니다.

3. <datalist>

Windows의 스크린리더가 <select>를 콤보박스로 인식하지만 "콤보박스"란 용어는 일부 개발자, 특히 과거 Windows Forms 개발자에게 특별한 의미가 있습니다. 웹 기술 관점에서 보면 이는 텍스트 필드를 가진 <select>라고 할 수 있습니다. 최근까지도 HTML에는 네이티브 콤보박스가 없었기 때문에 <datalist>/<option>을 통해 비슷하게 구현해 왔습니다. 스크린리더는 플랫폼에 따라 이를 다르게 부르고 있습니다. iOS에서는 리스트박스 팝업(listbox pop-up), macOS에서는 텍스트필드(text field), Android에서는 에디트박스(edit box), IE11 JAWS에서는 텍스트 입력(type in text), Chrome JAWS에서는 콤보(combo), Firefox JAWS에서는 텍스트 팝업(text pop-up)이라고 부릅니다. 또한, NVDA는 자동 완성 기능을 제공합니다.

이 HTML 컴포넌트를 지칭하려면 "데이터리스트(datalist)"라고 부르세요.

브라우저에서 기본적으로 지원하기 도구를 콕 집어서 요청했기 때문에, 개발자와 디자이너는 완성된 결과가 어떻게 보일지 구체적인 그림을 그리고 작업을 시작할 수 있습니다.

4. ARIA 콤보박스

콤보박스를 원한다면 ARIA로 개발할지 아니면 네이티브 HTML로 개발할지 선택하는 것이 좋습니다. (<datalist> 참조) 얼마나 많은 커스터마이징이 필요한지에 따라 이러한 선택이 달라질 것입니다. ARIA combobox role을 지원하지 않는 브라우저라면 일반적으로 textbox role과 listbox role을 함께 사용함으로써 어느 정도 대체할 수 있습니다.

이 컴포넌트를 지칭하려면 "ARIA 콤보박스(combobox)"라고 부르세요.

이 용어를 사용할 경우 실제 어떤 방식으로 구현될 것인지 예상할 수 있고, 디자이너는 브라우저의 기본 <datalist>가 가진 제약에서 벗어날 수 있습니다. 더 나아가, 여기 소개된 ARIA 1.1 콤보박스, 기존 ARIA 1.0 콤보박스, ARIA 1.2 콤보박스(draft 버전) 중 특별히 원하는 것이 있다면 테스트해 보는 것도 좋은 생각입니다.

5. 자동완성

사용자에게 제공하는 것이 DOM[4]의 기본 컴포넌트가 아닌 경우 먼저 명확히 짚고 넘어갈 필요가 있습니다. autocomplete 속성(WCAG SC 1.3.5: Identify Input Purpose)을 사용하기 원하는 경우 별도의 구현이 필요하지 않습니다. 이는 브라우저에서 지원하는 기능으로 기존 <input>, <select>, 또는 <textarea> 필드를 사용합니다.

autocomplete 속성을 사용하지 않는 경우 XMLHttpRequest를 사용한 별도의 구현을 통해 사용자의 키보드 입력에 반응하여 select 옵션을 추가해 나갑니다. 만약 자동완성이 사용자가 입력하지 않은 값에 대해서도 동작해야 할 경우 (예: 다음 예제에서와 같이 한/영 전환 없이 영문으로 입력했을 때 한글로 동일한 키 입력에 해당하는 결과를 보여줌) 다른 방식이 필요할 수도 있습니다.

위의 경우 요구사항을 좀 더 명확하게 정의할 필요가 있으므로 일단 "자동완성(autocomplete)"이라고 불러도 무방합니다.

6. ARIA 메뉴

마우스 우클릭 메뉴와 같은 기본 메뉴를 나만의 스타일로 재창조하려면 ARIA menu role을 사용할 수 있습니다. Windows나 Mac 애플리케이션의 기본 메뉴와 비슷하게 구현하려면 menubar role이 가장 적합할 것입니다.

둘 중 어느 것을 택하더라도 "ARIA 메뉴(menu)"라고 부를 수 있습니다.

이 메뉴에 대한 도입을 검토할 때 한 가지 분명히 해야 할 부분은, ARIA 메뉴는 OS의 기본 기능을 흉내 내기 위한 것이지, 웹 사이트 탐색이나 기타 일반적인 웹 콘텐츠를 표시하기 위한 도구가 아니라는 것입니다. 이에 대해 좀 더 자세한 정보가 필요하다면 제가 작성한 Don’t Use ARIA Menu Roles for Site Nav 글을 참고해주세요.

7. <details>/<summary>

<details>와 <summary>는 손쉽게 콘텐츠를 숨기고 표시하기 위한 기본 요소로써 비교적 최근에 와서야 브라우저에서 이를 지원하기 시작했습니다. (IE와 Edge 구버전에서는 지원 불가) 지원하지 않는 브라우저의 경우 자바스크립트 폴리필(polyfill)이 필요합니다.<details>/<summary>은 브라우저에서 제공하는 기본 도구로써 원하는 부분을 효과적으로 숨기거나 표시할 수 있습니다. 기존 요소들과는 차이점이 있기 때문에 사용 전에 반드시 테스트해 보시기 바랍니다.

이 컴포넌트를 지칭하려면 "디테일(detail) 및 서머리(summary)"라고 부르세요.

유능한 웹 전문가라면 여러분이 웹 폼(form)이 아니라 새로운 인터랙티브 도구에 대해 이야기하고 있다는 것을 눈치챌 것입니다.

8. 디스클로저 위젯

<details>/<summary>의 ARIA 버전이라 부를 수 있지만 ARIA role을 사용하여 제어 기능을 추가할 수는 없습니다. aria-expanded와 aria-controls(지원 종료 예정) 속성을 가진 <button> 하나와, 숨기거나 보여줄 콘텐츠를 포함한 컨테이너가 하나가 필요합니다.ARIA Authoring Practices 문서에 디스클로저 위젯에 대한 설명이 잘 나와있으며 이를 가져와 빠르게 개발을 시작할 수 있습니다. 완성도가 높은 패턴으로, 내비게이션에도 사용할 수 있습니다.

이 컴포넌트를 지칭하려면 "디스클로저 위젯(Disclosure Widget)"이라고 부르세요.

9. 아코디언

위에서 알아본 디스클로저 위젯과 마찬가지로 ARIA에는 아코디언 role이 존재하지 않습니다. 디스클로저 위젯과는 달리, 이를 사용하기 위한 기본 HTML 요소 또한 없습니다. ARIA 탭(tab)은 수직 방향으로 사용해도 접히면서 펼쳐진 공간을 되돌아오지 않기 때문에 여기에 적합하지 않습니다. ARIA 탭이 요구사항을 만족하는지 먼저 확인해야 합니다.ARIA Authoring Practices 문서에 아코디언 위젯에 대한 설명이 잘 나와있으며 이를 가져와 빠르게 개발을 시작할 수 있습니다. 아코디언 헤더 부분에 aria-expanded와 aria-controls(지원 종료 예정) 속성을 가진 <button> 하나, 숨기거나 보여줄 콘텐츠를 포함한 컨테이너가 하나가 필요하며 아코디언의 동작에 따라 나머지 콘텐츠 컨테이너 또한 화면에서 사라지게 됩니다.

이 컴포넌트를 지칭하려면 "아코디언(accordion)"이라고 부르세요.

10. 플라이아웃(Fly-out) 내비게이션

우리는 웹 사이트 내비게이션을 드롭다운이라고 불러왔습니다. 이러한 방식의 내비게이션은 2003년 Suckerfish 드롭다운이라는 이름으로 일상적으로 쓰이는 용어를 사용해 등장했습니다. 하지만 최상위 메뉴를 탭하거나 마우스를 올렸을 때 하위 메뉴가 중첩되어(nested) 표시되는 것을 보고 있자면 무언가 더 나은 이름이 필요하겠다는 생각이 듭니다. WAI[5]가 제공하는 다양한 UI 패턴에 대한 설명 중 플라이아웃 메뉴가 이에 가장 적합해 보입니다. 이는 사실 새로운 용어가 아니라 Suckerfish 이전부터 있어왔습니다.

이러한 방식의 내비게이션을 사용 중이라면 "플라이아웃(Fly-out)" 또는 "플라이아웃(Fly-out) 내비게이션"이라고 부르세요.

11. 커스텀 디스플레이 셀렉터(Custom Display Selector)

이것은 모든 것을 포괄하는 용어입니다. 저는 개발자들이 동적인 UI를 구현할 때 일단 화면에서 특정한 컨테이너를 안 보이게 숨겨놓고 애니메이션 효과와 함께 등장시키는 트릭을 사용하는 것을 많이 봤습니다. 이러한 방식은 고려하고 있다면 다시 한번 생각해 보세요. 이는 보통 웹 접근성을 지원하지 않으며, 위에 소개한 패턴 중 하나로 구현할 수 있습니다. 감에 의존하여 혼자만 이해할 수 있는 새로운 패턴을 발명하기 전에 다시 돌아가 고객이 진짜로 원하는 것이 무엇인지 다시 한번 검토해보세요.

이러한 접근방식은 다른 말로 "컨설팅"이라 부릅니다.

기타 관련 용어

누군가는 이 글을 보고 <menu>나 <menuitem>은 어디갔나고 물어볼 것입니다. 그러나 이 요소들은 사용도가 떨어져 지원이 중단됐습니다. 비슷한 요구사항이 있는 경우 위에 소개된 ARIA 메뉴로 구현할 수 있습니다.저는 드롭다운 대신 팝업(Pop-up)이라는 용어가 쓰이는 것을 봤습니다. 팝업은 툴팁(tool-tip), 네이티브 대화상자, 모달(modal) 대화상자, 또는 새 창을 의미할 수도 있는 오해의 소지가 다분한 용어입니다. 팝업이 <select>와 같이 사용되면 스크린리더가 인식하는데 어려움을 겪게 됩니다.

누군가 팝업을 만들어달라고 요청하면 이것이 대화상자, 폼 UI, 디스플레이 위젯 중 무엇을 의미하는지 명확히 구분할 필요가 있습니다. 그런 다음 커뮤니케이션에서 해당 용어를 적극적으로 사용해야 합니다. 메뉴(menu)라는 용어도 <select>, 콤보박스, 내비게이션과 함게 사용될 때 혼란을 가중시킵니다. 메뉴가 다른 의미로 해석될 가능성은 드롭다운 보다는 적지만 위에서 적용한 것과 동일한 방식으로 혼선을 줄일 수 있습니다. <select>, <listbox>, 또는 <combobox> 패턴에 대해 더 자세히 알아보고 특히 이를 직접 구현하려는 경우 Sarah Higley의 다음 글을 강력히 추천합니다.

한 줄 요약

"드롭다운"이란 용어를 무조건 사용하기 보다는 원하는 도구를 정확히 지칭할 수 있는 용어를 선택해 사용해보세요.

[1] 시각장애인들에게 컴퓨터의 화면과 자신이 입력한 키보드 정보 그리고 마우스 좌표 등을 음성으로 알려 주어 컴퓨터를 사용할 수 있도록 도와주는 소프트웨어.

[2] PC 기반의 스크린리더로 화면에 있는 내용을 TTS 엔진을 통해 음성으로 출력해준다.

[3] 다국어를 지원하는 무료 오픈소스 스크린리더.

[4] 문서 객체 모델(DOM, Document Object Model)은 XML이나 HTML 문서에 접근하기 위한 일종의 인터페이스.

[5] 웹 접근성 이니셔티브(Web Accessibility Initiative) 또는 줄여서 WAI는 장애인들의 월드 와이드 웹에 대한 접근성을 향상시키기 위해 W3C에서 만든 개념이다.

로그인하고 자유롭게 의견을 남겨주세요.