Landmark roles는 정적인 웹 페이지에 책갈피를 달아놓은 것이라고 설명할 수 있다. 이는 HTML을 스타일링하지 않아도 어느 부분이 메인 컨텐츠 영역인지 사이드바(부가 정보) 영역인지 메인 메뉴(내비게이션) 영역인지 명확하게 구분하도록 해준다.

Landmark roles는 현재 다음의 8종류가 있다.

• application: 웹 응용 프로그램에 선언한다. 여기서 웹 응용 프로그램이란 GMail, SVG와 같은 정적인 웹 문서와 반대되는 개념이다. 스펙에 따르면 보조 기기는 이 선언을 만나면 브라우저 탐색 키를 웹 어플리케이션에게 돌려줘야 한다고 한다. (이 개념에 대해서는 독립 주제로 다루어야 할 정도네요.)
• banner: 사이트의 로고(최초의 헤딩) 또는 내부 페이지의 제목을 포함하는 영역. 이 영역의 컨텐츠는 대체로 사이트 전체에 걸쳐 동일하다.
• complementary: 문서의 독립적이고 부가적인 컨텐츠 영역. 메인 컨텐츠에서 분리되어도 그 자체로 의미가 있는 영역이다. 보통 메인 컨텐츠의 오른쪽에(서브메뉴가 왼쪽일 경우) 포함되는 컨텐츠를 이 영역으로 분류할 수 있다. HTML5의 aside 요소와 대응된다.
• contentinfo: 상위 문서에 적용되는 메타데이터를 의미한다. (스펙의 설명은 이렇고 쉽게 말하자면 저작권, 사이트 관련 연락처 - 주소, 전화번호, ... - 등이 포함된 푸터를 이 영역으로 분류할 수 있다.) HTML5의 footer 요소와 대응된다.
• form: 폼 전송 영역(말 그대로 폼). 다만, search role에 해당되는 폼은 제외.
• main: 문서의 메인 컨텐츠. 반드시 1번만 선언되어야 한다.
• navigation: 메뉴(내비게이션 묶음) 영역. HTML5의 nav 요소와 대응된다.
• search: 문서 검색 툴을 의미하며 보통 통합 검색 영역을 지정할 수 있다. 추가로 우리나라에서 통용되는 게시판 목록의 검색 폼에도 사용하면 좋을 것이라고 생각한다.

Landmark roles 작성법은 여기까지다. 정말 쉽지 않은가?

그런데 landmark roles를 쓰면 뭐가 좋은걸까?

우선, 보조 기기의 사용성이 향상된다. Screen Readers And WAI-ARIA Landmark Roles라는 글에 따르면 현재 스크린리더 중 Jaws와 NVDA에서 landmark roles를 지원한다. Landmark roles를 지원하는 스크린리더 사용자는 landmark role간을 탐색하는 핫키를 이용하여 영역을 탐색할 수 있다. 문서를 순차적으로 읽어내려가는 스크린리더 사용자에게 이는 스킵 내비게이션과 비교했을 때 훨씬 유용한 것으로 생각된다. 스킵 내비게이션은 물리적으로 문서의 맨 처음에서만 접근 가능한 대신 landmark role은 필요할 때 핫키를 통해 문서의 주요 시작점을 자유롭게 탐색할 수 있기 때문이다.

참고한 글들 중 보조 기기의 사용성 향상 이외에 다른 장점에 대해 언급한 것은 없다. 그래서 아래에 개인적으로 생각한 장점들에 대해 나열해본다.

첫째, 사람이 HTML 코드를 이해하기 쉬워진다. 굳이 주석을 달지 않아도 어느 태그가 메인 영역을 감싸고 있고 어느 태그가 푸터 영역을 감싸고 있는지 코드로 설명된다. 쓸데없는 주석이 줄어들 수 있겠다.

둘째, 기계가 HTML 코드를 이해하기 쉬워진다. 웹 페이지의 일반적인 레이아웃 구조가 프로그래밍 방식으로 결정 되는 것이다. 예를 들어 검색엔진 입장이라면 극단적으로 main landmark의 컨텐츠만 검색하거나 아니면 main landmark의 컨텐츠의 중요도를 높게 취급한다면 검색 품질의 향상을 꾀할 수 있을 것이고 브라우저는 인쇄용 CSS를 메인 컨텐츠용으로 따로 준비하지 않았다고 하더라도 "메인 컨텐츠만 인쇄하기" 같은 메뉴를 제공할 수 있을 것이다. 또 나같이 지저분한 사이트(광고로 도배된 신문사 사이트)를 혐오하는 사람들을 위해 부가 정보(complementary role) 숨기기 같은 옵션을 제공할 수도 있을 것이다.

셋째, Landmark roles라는 약속된 규칙에 의해 이정표를 삽입하는 것이기 때문에 Landmark roles를 지원하는 웹 페이지들은 일관성 있는 탐색을 보장할 수 있게 된다.

센스리더에서는 지원하지 않지만 이미 iPhone에 내장된 스크린리더인 VoiceOver에서 지원중이다. 게다가 적용하는게 망설일 필요도 없을 만큼 쉬운 것이 landmark roles다! 이미 만들어져 있는 사이트도 5분만 투자하면 바로 적용할 수 있을 것이다!

WAI-ARIA 저작 가이드 문서의 tab 부분을 보면 탭 인터페이스를 구현하는 방법을 자세히 소개하고 있는데 그 중 키보드 인터페이스에서 좌/우, Ctrl+Tab/Ctrl+Shift+Tab, Ctrl+PageUp/Ctrl+PageDown 키를 이용하여 탭과 탭을 이동하는 기능을 구현하도록 문서화되어 있는데 좌/우 키는 기존에 웹 페이지에서 탭 키를 통해 링크를 이동하던 사용자에게 혼란을, Ctrl+Tab/Ctrl+Shift+Tab이나 Ctrl+PageUp/Ctrl+PageDown 키는 브라우저의 탭간 이동에 사용되고 있어 중복된다. (문서에 이 내용도 언급이 되어있다! -_-)

현재 탭(처럼 보이는) 마크업에는 크게 2가지 코드 형태가 사용된다고 생각한다.

<div class="tabpanel">
    <ul class="tablist">
        <li><a href="#tab1">Tab1</a></li>
        <li><a href="#tab2">Tab2</a></li>
        <li><a href="#tab3">Tab3</a></li>
    </ul>
    <div id="tab1">
        <h1>Tab1</h1>
        Tab1 Content</div>
    <div id="tab2">
        <h1>Tab2</h1>
        Tab2 Content</div>
    <div id="tab3">
        <h1>Tab3</h1>
        Tab3 Content</div>
</div>

<div class="tabpanel">
    <h1>Tab1</h1>
    <div id="tab1">Tab1 Content</div>
    <h1>Tab2</h1>
    <div id="tab2">Tab2 Content</div>
    <h1>Tab3</h1>
    <div id="tab3">Tab3 Content</div>
</div>

[코드1]에는 문제가 발생할 여지가 많다. 탭에서 href="#tab1"와 같은 링크가 생략되는 경우, 링크가 올바로 컨텐츠를 가리키지 못하는 경우, 컨텐츠에 헤딩이 누락되는 경우 등이다. 그리고 [코드1]을 자바스크립트를 통해 구현한 경우 보통 탭의 링크를 취소(preventDefault) 시키기 때문에 다른 탭들을 건너뛰어 해당 내용으로 이동해야 하기 때문에 마우스 사용자 이외에는 비효율적이다. 탭이 많으면 많을수록 더욱 더 비효율적이 된다.

[코드2]는 코드1의 키보드 비효율성이 전혀 없다. 코드1의 문제가 발생할 여지들도 애초에 차단된다. 탭 UI를 위해 헤딩을 작성하도록 유도시키고 빼먹거나 잘못 구현할지 모르는 탭 링크들을 애초에 제거하였다.

웹 어플리케이션 위젯을 OS의 그것들처럼 인식시키려고 하는 ARIA의 구현방식에서 볼 때는 코드2와 같은 구현이 적절하지 않다고 생각되기도 한다. 하지만 마우스 사용자에게는 어차피 상관없는 문제이고 키보드 사용자에게는 이전의 웹 페이지들과 다른 사용행태에 대한 혼란을 없앨 수 있다(익숙함을 유지하는 것을 영원히 장점이라고 하긴 어렵지만…). 무엇보다 개발자들에게 오류 발생 가능성을 상당히 줄여줄 수 있다는 사실 때문에 앞서 언급했던 ARIA tab의 문제들을 제거한 라이브러리들이 등장하기 전까지는 코드2와 같은 구현 방식을 추천하고 싶다.

• WAI ARIA Live Regions – MDC
• How to use ARIA Live Regions for dynamic content – CodeTalks

이 글을 통해 ARIA 개발의 감각을 끌어올릴 수 있기를 바라며 스펙(Taxonomy of WAI-ARIA States and Properties)에 더 많은 내용이 있으니 참고바란다. 예제들은 ARIA를 지원하는 스크린리더(Korean JAWS for Windows (한글용; 유료), NVDA (영어용; 무료))로 어떻게 동작하는지 테스트해볼 수 있다.

Live Region이란?: 개발자가 웹 문서의 특정 부분을 동적인 컨텐츠라고 명시할 수 있는데 그 영역을 일컬어 Live Region이라고 할 수 있다.

개요

과거에는 웹 페이지 변경은 전체를 읽어주게 하거나 거의 읽어주지 않아서 일부 혹은 전체의 정보에 접근할 수 없도록 만들어 종종 사용자를 짜증나게 했다. 최근까지는 보조기기는 이를 개선할 수 없었다. 왜냐하면 변경에 대응하여 보조기기에 경고해줄 수 있는 마크업 표준이 없었기 때문이다. Live Region은 이 차이를 메우고 보조기기에 DOM 변경을 알려줄 수 있는 설정을 제공하였다. 설정은 언제 어디서 업데이트가 발생하고 얼마나 중요한지를 포함한다. Live Region을 사용하는 목표는 가장 먼저 관련 정보를 제공하고 가능한한 사소한 정보는 제한하는 것이다. 웹 개발자는 Live Region 사용에 익숙해져야 하고 웹 사이트의 사용자 인터페이스를 설계할 때 이것을 고려해야 한다.

Live Region state

페이지를 다시 로드하지 않고 업데이트 되는 동적 컨텐츠는 반드시 Live Region을 표시해야한다. Live Region은 ARIA 가이드라인 상태의 영향을 받으며 많은 사용자 정의 설정들은 가지고 있다. 다음은 각 관련 설정의 목록과 그 설명이다.

aria-live: (aria-live=POLITENESS_SETTING)

보조기기가 live region의 업데이트를 처리하는 우선순위를 설정하는데 사용된다. 가능한 설정들은 “off/polite/assertive“이며 기본값은 off.

설정값

• aria-live="off": live region의 업데이트를 알리지 않음.

  예제: http://accessibleajax.clcworld.net/simple/live_off.htm

• aria-live="polite": live region의 업데이트를 사용자의 현재 동작이 끝날 때 알림.

  예제: http://accessibleajax.clcworld.net/simple/live_polite.htm

• aria-live="assertive": live region의 업데이트를 사용자에게 바로 알림.

  예제: http://accessibleajax.clcworld.net/simple/live_assertive.htm

aria-relevant: (aria-relevant=[LIST_OF_CHANGES])

live region이 변경될 때 보조기기로 하여금 어떤 변경을 주시하도록 할 것인가를 설정한다. 여기서의 변경은 의미있는 변경 – 예를 들어, 온라인 친구목록에서 친구 리스트 한개가 없어졌다면 이는 친구가 오프라인이 되었다는 의미 – 가능한 설정들은 “additions/removals/text/all“이고 기본값은 “additions text“.

설정값

• aria-relevant="additionals": 추가되는 요소를 감시한다.

  예제: http://accessibleajax.clcworld.net/simple/relevant_additions.htm

• aria-relevant="removals": 제거되는 요소를 감시한다.

  예제: http://accessibleajax.clcworld.net/simple/relevant_removals.htm

• aria-relevant="text": 변경되는 요소를 감시한다.

  예제: http://accessibleajax.clcworld.net/simple/relevant_text.htm

• aria-relevant="all": 위의 세가지 변화를 감시한다.

  예제: http://accessibleajax.clcworld.net/simple/relevant_all.htm

aria-atomic: (aria-atomic=BOOLEAN)

live region이 변경될 때 보조기기가 live region 중 변경된 요소만을 알려줄지, live region 전체를 알려줄지 설정한다. 가능한 설정들은 “false/true“이고 기본값은 false.

설정값

• aria-atomic="false": live region 중 변경되는 요소만 알려주도록 설정한다.

  예제: http://accessibleajax.clcworld.net/simple/atomic_false.htm

• aria-atomic="true": live region이 변경되면 영역 전체를 다시 알려주도록 설정한다.

  예제: http://accessibleajax.clcworld.net/simple/atomic_true.htm

aria-controls: (aria-controls=[IDLIST])

사용된 요소가 컨트롤하는 요소들을 나타내는데 사용된다. 값에는 컨트롤하는 요소들의 ID가 공백으로 구분되어 들어갈 수 있다. 예) aria-controls="myRegionID1 myRegionID2"

예제: http://accessibleajax.clcworld.net/simple/controls.htm

aria-labelledby: (aria-labelledby=[IDLIST])

live region에 해당하는 레이블들을 나타내는데 사용된다. live region에 사용하며 값에는 레이블 요소들의 ID가 공백으로 구분되어 들어갈 수 있다.

예제: http://accessibleajax.clcworld.net/simple/labelledby.htm

aria-describedby: (aria-describedby=[IDLIST])

live region에 해당하는 설명들을 나타내는데 사용된다. live region에 사용하며 값에는 설명이 포함된 요소들의 ID가 공백으로 구분되어 들어갈 수 있다.

예제: http://accessibleajax.clcworld.net/simple/describedby.htm

KWAG 12번째 모임 발표자료 WAI-ARIA in Real World(on slideshare.net)입니다.

첫 발표라 긴장되고 어색했다는 느낌이 드네요. 죄송해요. ㅠ_ㅠ

발표에서 빼먹었던 내용들

이렇게 큰 모임에서의 발표는 처음이었던 관계로 긴장이 되어 준비했던 것들을 다 전달해드리지 못했습니다. 아쉬운 마음 글로나마 보충해봅니다. 참가하셨던 분들 중에 몇 분이나 보실지는 모르겠지만 도움이 되셨으면 좋겠네요.

브라우저별 ARIA 지원표에서…

프리젠테이션 10번 슬라이드의 내용입니다. 브라우저별 ARIA 지원표의 마지막 업데이트는 2009년 9월 23일이었고 1년 가까이 지난 관계로 더욱 향상되었을 것입니다. (모든 브라우저들이 적극 ARIA 지원의사를 밝혔으니까요.) 지원표는 Windows Vista의 MSAA role에 대한 지원 정도를 나타냅니다.

Widget Roles의 구현은 자바스크립트로만!

프리젠테이션 17번부터 시작되는 슬라이드의 내용입니다. Tab 같은 Widget Role은 자바스크립트가 비활성화된 경우 선형화된 컨텐츠로 표시되도록 Progressive Enhancement 방식으로 개발하시죠? 따라서 자바스크립트가 비활성화된 경우는 Tab도 일반 컨텐츠이기 때문에 Widget Role은 자바스크립트로 구현합니다. role attribute나 aria-* attribute를 자바스크립트에서 페이지가 로딩된 즉시 부여한다는 이야기입니다.

다만, Landmark Role은 정적인 문서의 영역을 표시해주는 역할을 하기 때문에 HTML에 직접 attribute로 삽입합니다.

Widget Role의 개발 시 추가 참고 문서

Widget Role 개발 시 보여드린 각 Role별 스펙에 추가로 Authoring Practices 스펙의 각 Role별 interaction 구현 방법을 참고하셔야 합니다. 원래 각 Role별 스펙에서 각 Role별 interaction 구현 방법으로 링크가 걸려있어야 할 것 같은데 아직 스펙의 링크들이 정돈되지 않아보이네요.

참고 링크

• The Paciello Group Blog: ARIA role support: how the Windows browsers stack up – Update: 브라우저별 ARIA 스펙 준수 테스트 결과 (Windows Vista MSAA 기준)
• Official Google Reader Blog: Reader and ARIA: A new way to read: 구글 리더 제작팀 블로그의 ARIA 지원 알림
• The Roles Model | Accessible Rich Internet Applications (WAI-ARIA) 1.0 » Landmark Roles: 문서의 내비게이션, 메인 영역 지정들을 위한 Landmark Roles 스펙
• The Roles Model | Accessible Rich Internet Applications (WAI-ARIA) 1.0 » Widget Roles: 탭, 다이얼로그 등의 RIA(리치 인터넷 어플리케이션) 위젯 접근성을 위한 Widget Roles 스펙
• The Roles Model | Accessible Rich Internet Applications (WAI-ARIA) 1.0 » tab (role): Widget Roles의 하나인 Tab Role 스펙
• The Paciello Group Blog: WAI-ARIA Implementation in JavaScript UI Libraries – updated: WAI-ARIA가 구현된 자바스크립트 라이브러리 목록
• 3.2.5 Content models — HTML5 (Edition for Web Authors) » 3.2.6 Annotations for assistive technology products (ARIA): HTML 5 스펙의 ARIA에 대한 설명

신현석님의 접근성을 해치지 않는 자바스크립트의 사용이라는 글을 읽어보셨는지요? 혹시 어렵고 복잡하다고 생각하실지 모르나 자바스크립트 기술 위에 HTML 표준에 대한 이해가 수반된다면 크게 복잡한 과정이 아닙니다. 웹 사이트 개발에 들어가기 앞서 위의 과정을 이해하고 있다면 접근성을 해치면서(?) 사용하는 자바스크립트와 같은 비용으로 자바스크립트가 불가능한 환경의 접근성, 검색엔진 최적화(SEO) 등의 이득을 챙길 수 있습니다. 접근성을 보장하는 것이 그렇지 않은 것에 비해 추가비용을 필요로 하는 것은 사실이지만 그 추가비용 안에 위의 언급한 이득은 포함되어 있지 않습니다. 즉, 위의 이득들은 꽁짜란 얘기죠. ㅋ 실제로 미투데이라는 서비스의 경우 자바스크립트를 제거한 상태에서도 정확하게 원하는 기능을 사용할 수 있고, 자바스크립트가 이 기능들을 좀 더 편하고 신속하게 이용할 수 있는 보조장치로 쓰인 모습을 볼 수 있습니다.

그 다음엔?

자… 그럼 이렇게 하면 끝일까요? 사실 아닙니다. 그 이유는 말빨이 부족한 제가 설명하는 대신 유명한 웹 접근성 관련 블로그인 456 Berea Street의 Roger Johansson옹의 글 Reading up on WAI-ARIA에서 따왔습니다.

One of the more problematic areas of web accessibility is how to handle the custom widgets and dynamic changes to content used in most web applications and on many content-based websites.

Using JavaScript to add custom behaviour and update content can cause problems for people who rely on assistive technology (AT) such as screen readers. The problems often consist of the AT not being aware that content on the page has changed, the user not noticing that something has changed, or the user being aware that something changed but not what.

웹 접근성에서 상당히 골칫거리인것들 중에 하나가 커스텀 위젯이나 대부분의 웹 어플리케이션이나 많은 컨텐츠 중심 웹 사이트들에서 사용된 컨텐츠의 동적인 변경을 어떻게 다루느냐하는 것이다.

자바스크립트를 사용하여 특정 동작을 추가하고 컨텐츠를 갱신하는 것은 스크린리더와 같은 보조기기에 의지하고 있는 사람들에게 문제를 일으킬 수 있다. 그 문제란 대개 보조기기가 페이지의 컨텐츠가 변경된 것을 감지하지 못하여 사용자가 무엇인가 바뀌었다는 것을 알지 못하거나, 혹은 사용자가 무엇인가 바뀌었다는 것은 알지만 그게 무엇인지는 모르는 문제를 가리킨다.

그래서 나온게 WAI-ARIA입니다. 자, 그러면 당장 적용을 시키면 되나? 그렇습니…다라고 말씀을 드려야 하지만 좀 상황이 편하지만은 않습니다. WAI-ARIA라는 스펙 자체가 초안(Working Draft) 상태라 아직 표준으로 인정할 수 없는 상태이고 국내에서 유명한 스크린리더인 센스리더는 WAI-ARIA의 W자도 찾아볼 수 없습니다. 구현이 전혀 안되어 있다는 얘기죠.

구글리더는 ARIA 기능을 사용할 수 있는 감춰진 링크를 제공하고 있다.

보조기기들도 지원안하는 WAI-ARIA인지 뭔지 적용하나 마나 쓸모없지 않나?라는 질문을 하실 수 있습니다. 마찬가지로 센스리더 등의 보조기기 제작사에서는 구현된 사이트도 없는데 WAI-ARIA인지 뭔지 적용하나 마나 쓸모없지 않나?라는 질문을 할 수 있고요. -_-;;;

둘 중 누가 먼저라는 걸 서로 주장하는 것도 웃깁니다. 오히려 서로 시급히 도입해야 할 판국이죠. 그렇지 않습니까? ^^

지금 당장은?

우여곡절 끝에 접근성을 해치치 않는 자바스크립트를 사용하고 그 위에 WAI-ARIA까지 적용했다고 합시다. 그런데 보조기기들은 아직이라면? 답은 의외로 간단합니다. 보조기기 사용자들이 자바스크립트를 꺼둔 상태로 사이트를 작동할 수 있는 기능(문서 시작점에 이 기능에 대한 링크를 제공한다던지…)을 주면 됩니다. :)