이 글은 Accessible Culture의 Programmatically Determined라는 글의 일부 발번역과 나의 견해가 포함된 글임을 알린다.

프로그래밍 방식으로 결정

"프로그래밍 방식으로 결정" 이라는 문구는 61개의 WCAG 2.0 성공 기준 중 6개에서 눈에 띄는 항목이다. 그것은 아마 처음으로 접근성과 WCAG를 접하는 사람들에게는 약간은 어려울지 모르겠지만, 사실은 그렇게 복잡하지는 않다. 사실, 당신이 이 문구 자체에 익숙하지 않더라도 당신은 이미 그것을 다루고 있을 것이다.

어쨌든, 난 "프로그래밍 방식으로 결정"이 웹 개발자들에게 WCAG에 관해 웹 접근성이란 무엇이며 왜 HTML의 적절한 사용이 중요한지 설명할 때 상당히 유용한 개념이라고 생각한다.

HTML에 포함

일반적인 웹 페이지 내용의 기반은 물론 HTML 마크업이다. 제대로 사용하면 그것은 의미론적 구조 그리고 콘텐츠 간 연관 관계 및 차이점을 식별하는 역할을 한다.

대부분의 사람들은 웹 페이지의 HTML을 보지 못한다. 그러나 웹 페이지에 액세스하는 데 사용되는 브라우저는 페이지의 콘텐츠를 이해하기 위해 HTML에 의존한다. HTML은 브라우저에게 다음과 같은 것들을 알려준다.

• 이 콘텐츠는 단락으로 이루어저 있고 2레벨 제목 아래에 제공되고 있다.
• 이것은 5개의 항목을 가진 순서 있는 항목의 3번째 항목이다.
• 이것은 텍스트 입력 필드이고 어떤 이름을 가지고 있다.
• 이것은 그 웹 사이트의 저 페이지로 이동할 수 있는 링크이다.
• 이 웹 페이지는 불어로 되어 있다. 단 이 문장은 영어 등으로 구성되어 있다.

콘텐츠 구조와 관계에 대한 정보를 제공하는 것은 어떻게 HTML이 설계 되었는지와 그것을 사용하기 위한 방법에 대한 기본적인 부분이다.

우리는 그것을 '프로그래밍 방식으로 결정'이라고 부른다.

콘텐츠가 HTML로 적절히 마크업 된 경우, 그 의미론적 구조와 관계는 마크업 자체에 포함된다. 즉, 그것들은 "프로그래밍 방식으로 결정"될 수 있다. 말하자면 이러한 정보는 코드에 포함되기 때문에 지원 기술은 프로그램을 통해 그것을 해석하여 사용자에게 다른 방식으로 제공할 수 있다. 이 정보는 "다른 감각 형식(예. 비주얼, 음성) 혹은 개인 사용자들의 요구에 맞는 표현 양식으로 변경"될 수 있다. 이것이 접근성 있는 웹 콘텐츠와 WCAG 2.0의 핵심 컨셉의 중요한 측면이다.

이러한 정보는 브라우저를 통해 다양한 디바이스 혹은 소프트웨어가 그것을 이용 가능한 형태로 전달될 수 있다. 스크린리더, 음성 인식 소프트웨어, 대체 입력 장치 등이 각각의 콘텐츠가 무엇인지 이야기하고 사용자가 적절하게 그것들과 상호 작용하도록 할 수 있다.

위의 인용문은 WCAG 등 웹 접근성 규격에서 말하는 "프로그밍 방식으로 결정"이 무엇인지를 설명하고 있다.

쉽게 말해 HTML을 의미에 맞게 작성하면 브라우저나 보조 기기에서 그 의미를 해석하여 나름대로 가공하여 사용자에게 전달할 수 있고 이것은 곧 해당 콘텐츠가 "프로그래밍 방식으로 결정"될 수 있다고 할 수 있다.

링크를 a 요소가 아닌 span 같은 요소로 구현하고 키보드 접근성을 위해 tabindex를 0으로 주고 자바스크립트로 링크처럼 구현했다고 치자. 자바스크립트 비활성화 경우는 차치하고 무슨 문제가 있을까? 결론은 해당 링크가 "프로그래밍 방식으로 결정"되지 못한 것이 문제이다. 사용자는 링크처럼 클릭해서 사용할 수 있지만 브라우저나 보조 기기는 해당 콘텐츠가 링크인지 알 수가 없다는 것이다.

이 문제는 브라우저나 보조 기기가 링크를 가공할 때 도드라진다. 가령 브라우저는 링크를 우클릭할 경우 즐겨찾기에 추가, 새 창으로 열기 등 관련 편의 기능을 제공하고 스크린리더는 링크만 모아서 제공하거나 "무슨 무슨 링크"라고 읽어주는 등의 기능을 제공하는데... 위의 경우 그것이 불가능하게 된다.

결론 요약

가능하다면, 적절한 HTML 요소와 속성을 사용하라. 내용의 구조와 관계가 표현되게끔 마크업을 작성하라.

• 그것은 어떤 종류의 콘텐츠인가?
• 주위 콘텐츠와의 관계는 무엇인가?
• 기능을 제공하는 경우 그것은 무엇을 하는가? 이름, 역할, 상태, 그리고 값이 마크업에 드러나는가?

이러한 질문에 대한 답변을 HTML과 WAI-ARIA 마크업만으로 명확하게 제공된다면, 이는 곧 이와 같은 정보가 브라우저에 의해 프로그래밍 방식으로 결정되는 것이고 이는 곧 보조 기술 및 장치를 지원한다는 것을 뜻한다.

결국 인용한 글의 결론과 같이 의미있는 웹 콘텐츠가 있을 때 해당 의미가 HTML에 포함되도록 HTML 코드를 만들면 "프로그래밍 방식으로 결정"이라는 명제를 만족할 수 있다.

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분만 투자하면 바로 적용할 수 있을 것이다!

마크업과 자바스크립트를 아래 코드와 같이 작성하면 된다.

<script type="text/javascript">
// <!--
$(function() {
    $('#tabs').flowTab();
    // $('#tabs').flowTab({tabSelector: '> .heading'});
});
// -->
</script>
<div id="tabs">
    <h2 class="heading">tab1</h2>
    <div>tab1 content <a href="#">link example</a></div>
    <h2 class="heading">tab2</h2>
    <div>tab2 content <a href="#">link example</a></div>
    <h2 class="heading">tab3</h2>
    <div>tab3 content <a href="#">link example</a></div>
</div>

flowTab plugin은 몇가지 옵션이 있다.

• tabSelector: 탭을 가리키는 jQuery 선택자. (기본값: "> .heading")
• tabEnabledClass: 활성화된 탭 요소에 추가될 class명. (기본값: "headingEnabled")
• contentDisabledClass: 비활성화된 탭 내용 요소에 추가될 class명. (기본값: "contentDisabledClass")

예제와 다운로드

예제: jQuery flowTab plugin example

다운로드: jquery.flowTab.js

no jQuery 버전

탭 이외에 특별히 jQuery를 사용하지 않는 사이트는 no jQuery 버전이 더 가볍게 동작한다.

jQuery 버전과의 약간 옵션 차이가 있다: tabSelector 옵션 대신 tabClassName 옵션을 사용한다. 루트 요소에서 탭을 찾을 때 tabClassName에 기재된 클래스명으로 찾는다. 기본값은 "heading".

아래는 코드 예제

<script type="text/javascript">
// <!--
// onload 구현은 알아서...;;
window.onload = function() {
    new flowTab(document.getElementById('tab'));
    // new flowTab(document.getElementById('tab'), {tabClassName: 'heading'});
};
// -->
</script>
<div id="tabs">
    <h2 class="heading">tab1</h2>
    <div>tab1 content <a href="#">link example</a></div>
    <h2 class="heading">tab2</h2>
    <div>tab2 content <a href="#">link example</a></div>
    <h2 class="heading">tab3</h2>
    <div>tab3 content <a href="#">link example</a></div>
</div>

다운로드(no jQuery): flowTab.js

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에 대한 설명

오페라10 알파 버전이 공개되었습니다. 다양한 기능과 속도 향상과 더불어 웹 폰트도 지원하는군요. 파이어폭스 3.1도 웹 폰트를 지원하니 이제 모든 주요 브라우저(IE와 사파리 포함)가 웹 폰트를 지원하게 되었네요.

EOT냐 TTF냐 하는 이슈가 있긴 합니다만, Ajax 등장시절 구글 지도가 그랬던 것처럼 Best Case가 나오면 붐이 일 수도 있지 않을까 싶어요.

관련 읽을거리들

• 오페라10 알파 버전 공개
• Webfonts.info
• For & against standardizing font embedding

우리는 자신의 전자 시종에게 억압당하고 있다.

이 책을 우리의 해방을 위해 바친다.

사내의 동료들(웹 클라이언트 개발자들)과 Humane Interface (인간 중심 인터페이스)를 읽기 시작했습니다. 인간-기계 사이의 인터페이스는 무엇보다 인간이 사용하기 편해야한다.라고 이야기하는 이 책은 우리가 일상적으로 사용하고 있는 기계들에 대하여 알고 있는 불편한 점이나 혹은 익숙해져 불편한지 조차 모르는 것들을 끄집어내고 인간중심으로 바꾸어가는 방법과 그러기 위해 인터페이스를 담당하는 사람들이 해야할 것들에 대해 얘기하고 있습니다.

뭐 아직 1장만 읽었을 뿐이라 더 자세히 설명드리기는 부족하네요. ㅎ 아무튼 매우 재미있는 시간들이 될 것 같습니다. 아, 혹시 다른 분들과 책을 함께 읽어보고 있는 분들은 오픈마루 개발자 권남씨의 스터디하는 법을 참고해보세요. 저희도 비슷하게 진행하고 있습니다.

그리고 첫 시간에 생각나는 게 있어 하나 적어봅니다.

은행 자동 입출금기(ATM)에서 출금이 카드 인식, 비밀번호 입력, 출금 금액의 순서로 진행되잖아요?

그런데 제가 비밀번호를 입력했는데 화면이 그대로여서 비밀번호 끝자리 1자리를 빼먹었나 싶어 마지막 1자리를 누르려는데 누르기 직전에 화면이 바뀌어서 출금 금액 중에 제일 큰 70만원을 선택해버렸어요. 그랬더니 이 기계가 바로 그냥 70만원을 주더라고요.

책 읽기 중 어떤 분의 경험담을 들은 것인데 요는 비밀번호 입력 후 입력이 잘 되었고 다음 단계로 진행중이라는 피드백이 적절하게 제공되지 않은 것이다. 그런데 요즘 웹 사이트들을 돌아다니다 보면 이와 같은 피드백이 상당히 불편하다.

웹에서 표현을 담당하는 CSS에는 사용자의 동작에 대한 여러가지 피드백을 제공할 수 있는 기능이 있다. 바로 동적 가상 클래스(dynamic pseudo class)인데 그 종류에는 link, visited, hover, active, focus가 있다.

active와 같은 경우에는 요즘 인터넷 회선 속도가 너무 빨라져 거의 사용되지 않고 있는지 모르겠지만 누구나 게시판 등의 폼 전송 시 진행이 되지 않는 것 같아 전송 버튼을 여러번 클릭해본 경험이 있을 것이다. 물론 페이지가 이동되면서 브라우저 자체적인 피드백이 제공되기는 하지만 Ajax 등의 RIA라면 또 얘기가 달라진다.

나머지 경우들에 대해서도 상당히 간과되거나 미적 요소 정도로 치부되는 경향이 있는 듯 하다. 심지어 focus 되었을 때 브라우저에서 기본적으로 제공되는 테두리 점선이 이쁘지 않다는 이유만으로 없애버리는 경우도 있고…

얘기가 딴데로 새고 반말, 존대말 섞어가며 저부터 이 글을 읽는 분들께 혼란을 드린 듯 합니다. 죄송합니다. (__)

여하튼 책 읽기 들어가는 마당에 많은 것을 느꼈는데 중요한 건 최소한 직접 인간이 사용하게 될 무언가를 만드는 사람으로써 이 분야에 대한 공부는 생각보다 훨씬 중요하다는 겁니다. :)

신현석님의 접근성을 해치지 않는 자바스크립트의 사용이라는 글을 읽어보셨는지요? 혹시 어렵고 복잡하다고 생각하실지 모르나 자바스크립트 기술 위에 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까지 적용했다고 합시다. 그런데 보조기기들은 아직이라면? 답은 의외로 간단합니다. 보조기기 사용자들이 자바스크립트를 꺼둔 상태로 사이트를 작동할 수 있는 기능(문서 시작점에 이 기능에 대한 링크를 제공한다던지…)을 주면 됩니다. :)

정보를 꾸며주기 위한 <img> 태그

<img> 태그는 사전적으로는 정보를 지닌 – 의미 있는 – 시각 요소를 문서에 삽입하기 위한 태그이지만, 앞서 언급한 표현의 제약으로 인해 폰트 등을 원하는 대로 표현하기 위한 용도로 사용하기도 하다. 예전부터 – 대다수의 웹 제작자들이 마크업을 표현을 위한 용도로 사용하던 시절부터 – 국내의 거의 모든 사이트들이 사용하는 방법이기도 하다.

문제점

우선 <img> 태그의 남용이 마크업의 의미를 떨어뜨린다. 단순 텍스트와 <img> 태그는 기본적으로 의미하는 바가 다르다. 이미지 검색엔진의 결과물로 나타나는 수많은 텍스트 꾸밈용 이미지들을 보면 <img> 태그의 남용이 잘못된 마크업이라는 생각을 할 수 있다.

또, 남용된 <img> 태그는 구조와 표현의 분리라는 CSS의 목적을 달성하는 데 장애물이 된다. 마크업에 박혀있는 특정 시각 디자인 결과물을 위한 <img> 태그들은 다양한 표현의 걸림돌이다. <img> 태그가 남용된 사이트에서 프린트를 위한 CSS를 제작한다면 그 결과물은 어쩔 수 없이 스크린의 그것에서 크게 달라질 수 없을 것이다. 스크린 디자인을 위해 사용된 <img> 태그의 모양새는 바꾸기가 어렵기 때문이다.

CSS를 이용한 이미지 대치법(Image Replacement)

문제점

앞서 언급한것처럼 <img> 태그는 많은 문제점이 있지만 CSS를 이용한 이미지 대치법 역시 많은 문제를 가지고 있다. 가장 대표적으로 대다수의 이미지 대치법이 텍스트를 숨기거나(display: none;) 화면 밖으로 위치시키는 방법(text-indent: -999em;)을 사용하기 때문에 CSS 활성화·이미지 비활성화 상태에서 화면 상에 아무것도 출력하지 못하며 이 방법을 프린트용 CSS에 동일하게 적용하였을 때 보통의 웹 브라우저들이 기본적으로 배경 이미지를 출력하지 않기 때문에 백지 상태의 인쇄물을 보게되는 경우가 생긴다. (<img> 태그 사용시에는 사용자가 의도하지 않은 사이에 프린터의 잉크나 토너가 낭비된다!)

약간의 해결책

CSS 활성화·이미지 비활성화 상태의 경우 Gilder/Levin의 방법이나 Gilder Levin Ryznar Jacoubsen의 방법을 통해 해결할 수 있다. 하지만 이 방법은 이미지 뒤에 가려진 텍스트가 표시될 수 있는 충분한 공간이 확보되지 않으면 무용지물이 될 수 있다. z-index를 이용한 이미지 대치법도 하나의 방법인데 대치할 요소의 부모 요소에 배경색이 들어가있거나 한 경우에 문제가 생길 수 있다. 그리고 앞의 방법들과 마찬가지로 텍스트의 공간에 대한 문제가 있다. 그리고 이 모든 방법들은 의미없는 추가적인 마크업을 필요로 한다.

프린트 시의 문제는? 프린트용 CSS를 별도로 제작하면 바로 해결된다. 설마 로고와 메뉴가 덕지덕지 붙은 화면을 사용자에게 그대로 출력시키게 하는 것을 그냥 지켜보고 있다면 바로 당신이 관리하는 사이트에 프린트용 CSS를 추가하라.

어떤 것을 선택하느냐?

<img> 태그, 이미지 대치법(Image Replace). 이 방법들 중 어떤 것도 완벽하지 않다. 다만 각 방법들이 서로 다른 문제를 가지고 있고 어떤 것을 선택하느냐에 앞서 이 방법들의 문제점들에 대해 이해한 후에 선택하는 것이 필요하다.

자바스크립트를 통한 IE의 <button> 태그 버그 극복

<button> 태그가 IE에서만 문제가 되고 있고 IE는 특별한 조치 없이는 자바스크립트를 기본적으로 사용하기 때문에 자바스크립트를 통해 IE의 버그를 극복할 수 있다고 생각되었다. 그래서 찾아보니 Multiple Buttons IE Workaround라는 글이 있었다. 이 글이 제시하는 방법은 버튼을 클릭할 때 value 속성(값)을 IE의 버그로 인한 값에서 정상적인 값으로 돌려주는 것이었는데 이것은 폼의 제출 시에는 정상적으로 작동할 수 있으나 onsubmit 이벤트에서 폼 제출을 중지하는 경우 등의 상황에서 얘기치 않은 결과를 가져왔다.

IE Button Fix

그래서 위의 단점들을 해결하고 여전히 문제를 가지고 있던 IE5까지 해결한 IE Button Fix를 만들었다. 문제를 해결하면서 새로운 제약사항이 생겼는데 이는 사용시에 사용할 웹 사이트의 성격과 제약사항을 잘 파악하여 사용여부를 판단할 수 있을 것이다.

<button> 태그는 <input> 태그에 비해 많은 장점을 갖는다. IE의 버그는 그 동안 이래저래 <button> 태그의 장점을 사용할 수 없도록 제한해왔지만 IE Button Fix가 이를 어느정도 보완해줄 수 있으리라 생각한다.

웹 접근성 가이드라인과 Ajax

KWCAG 1.0 에는 Flash나 동영상 등의 외부 플러그인에는 적절한 대체 컨텐츠를 제공하여야 한다는 내용이 담겨 있다. 그와 더불어 자체적인 접근성(키보드 조작 가능)이 보장되어야 한다는 내용도 있다. 이는 Ajax 어플리케이션에도 동일하게 적용되는 내용이지만 Drag & Drop이나 위지윅(wysiwig) 에디터 등 키보드 만으로 조작 가능하게 만들기도 불가능한 어플리케이션은 자체적인 접근성을 지니기가 힘들다.

99% 부족한 접근성 보장

앞서 언급한 Drag & Drop이나 위지윅(wysiwig) 에디터 등의 접근성 문제를 해결하는 데에는 여러 가지 방법이 있을 수 있다. 사용성은 떨어지지만 키보드로 구현할 수 있으며 시각장애인을 위해 부가적인 설명을 달아줄 수 있다. 하지만 결과적으로 어떤 이들에게는 사용성의 증대의 좋은 결과를 가져다 준 기능이 어떤 이들에게는 사용성의 저하라는 결과를 가져다 주고 말게 된다. 다양한 환경을 고려하여야 사용성의 저하이지 현재 웹 상의 Ajax는 대부분 키보드만으로, 혹은 스크린리더 등으로 접근할 수 없다.

"자바스크립트 언어로 구현된 Ajax 어플리케이션의 경우 <noscript> 태그를 통해 모든 기능을 구현해 주었다. 무엇이 문제냐?" 하고 묻는다면 "자바스크립트를 사용할 수 있는 경우라도 무조건 마우스를 사용할 수 있는 것이 아니다"라고 얘기하겠다. "자바스크립트 기능을 끄고 사용하면 되지 않느냐?" 하고 묻는다면 "IE6에서 자바스크립트 기능을 한 번 꺼보라"고 얘기하겠다. 매일 인터넷을 이용하는 사람들조차 거의 자바스크립트 기능을 끄는 법을 알아내기가 쉽지 않다. 자바스크립트 기능을 끄는 법을 어플리케이션의 장치 의존적 특성과 함께 해당 어플리케이션이 담긴 페이지 내에서 설명한다면 어느 정도 접근성은 향상시킬 수 있다고 하겠으나, 브라우저의 설정 도구 깊숙히 숨어있는 옵션을 제어하기 위해 설명을 읽고 시간을 허비한다면 결코 접근성이 보장된 어플리케이션이라고 얘기할 수 없다.

대체 기능의 제공

내가 생각하는 최선(最善)은 대체 기능의 제공이다. Ajax 기능은 사용할 수 있지만 장치의 문제 상 단순히 HTML만으로 이루어진 페이지보다 접근성이나 사용성이 떨어지는 경우에는 해당 어플리케이션을 표시하기 전에 분명히 장치 의존적 특성을 설명하고 같은 기능을 다른 방법으로 – 단순한 HTML 등 – 수행할 수 있는 링크를 제공하여야겠다. Drag & Drop 어플리케이션의 대체 기능을 제공한다면 화면의 모양은 다음과 같을 것이다.

대체 기능 제공을 위하여 대체 기능을 사용할 수 있는 사용자의 범위를 인식하고 그 범위의 사용자들에게 명시적으로 대체 기능의 목적과 이용방법을 제공하여야 할 것이다. 자세한 설명을 별도의 설명 페이지를 통해 할 수 있지만 예제에 표시된 정도의 메시지는 기본적으로 포함되어야 한다. 어떤 사용자는 어플리케이션의 대략적인 성격과 이용가능여부를 다른 페이지를 보고 나서야 알 수 있다면 상당한 사용성의 침해를 받을 것이기 때문이다.

Ajax를 이용할 수 있는 모든 장치를 지닌 사용자라도 무조건 배제할 수는 없다.

대체 기능을 제공할 사용자 범위 산정에 있어 사용자의 이용 환경만을 생각하면 안된다. 예로 마우스 롤오버 시에 작은 이벤트로 또 다른 기능을 제공하는 경우라면 민첩하지 못한 사용자나 인터넷 초심자 – 노인, 어린이, 지체장애인 등 – 에게는 오히려 방해가 될 수 있는 것이 Ajax이다. 이런 사용자에게도 확실하게 어플리케이션의 성격과 이용 시에 야기될 수 있는 문제점들을 알리고 그 대안(대체 기능)을 제공하는 것이 진정한 Ajax의 접근성이라고 하겠다.

포털들의 웹 접근성 보장 노력을 보다.

포털들은 빠르게 바뀌어가고 있지는 않지만, 점진적으로 그리고 체계적으로 웹 접근성을 업무에 도입하고 있다. 예전에 만들었던 table 레이아웃을 하나 둘 씩 덜어내고 제대로 된 markup, 웹 표준 준수, 시각장애인들과의 교류를 통한 실제로 도움이 되는 웹 접근성 테스트 등을 진행하고 있다.

Ajax 접근성의 가이드라인 부재

RIA의 편의성이라는 장점과 접근성의 보장이 힘들다는 단점을 언급한 섹션이 있었는데 결론이라고는 달랑 well-made Javascript(혹은 Ajax)를 만들자. 였다. 확실히 현재 국내 웹 시장에는 AJAX, Flash 등의 RIA에서의 접근성 보장에 대한 기준이 미흡하다. 장치(마우스 등) 의존적인 UI, 시각에 의존적인 UI 등 어떤 사용자에게는 도움이 되는 UI가 그 기능을 사용할 수 없는 사용자들을 위해서는 어떻게 설계되어야 하는지에 대한 것이 필요할 것이다.

혼자서는 이룰 수 없는 웹 접근성

슈퍼맨은 홀로 지구를 지켜 나아가지만, 슈퍼 웹 퍼블리셔는 혼자서는 아무것도 할 수 없다. 작게는 웹 사이트를 만드는 모든 사람들(기획자, 디자이너 등)에서부터 크게는 회사의 이익 추구의 최전선의 경영진, 그리고 지금 인터넷을 사용하는 모든 사람들의 인식이 확립되어야 한다. 웹 접근성은 특정 사람들(시각장애인 등)만을 위한 것임이 아님을, 설마 하고 접근성의 고려 없이 만든 조그마한 사이트도 누군가에게는 불편과 아픔을 가져다 준다는 사실을 알아야겠다.

키보드로 제어할 수 있는 슬라이더

제목에서도 알 수 있지만 Accessible Unobtrusive Slider는 키보드로 제어할 수 있는 슬라이더 라이브러리이다. 슬라이더 UI는 HTML5에서 지원 예정인데, 현재로서는 표시할 방법이 자바스크립트를 이용한 라이브러리를 통하는 수 밖에 없다. 그래서 많은 관련 라이브러리들이 공개되어 있는데 키보드 제어 가능한 라이브러리는 드문 편이다.

마우스 휠을 활용할 수 있는 슬라이더

Accessible Unobtrusive Slider는 마우스 휠을 통한 제어가 가능하다. 마우스 휠 제어는 상당히 편리한 기능인 것 같다. 현재 마우스 휠 방향과 슬라이드 되는 방향이 잘 맞지 않은 경우가 있어 불편한 느낌이 드는데 이는 어서 수정되었으면 하는 사항이다.

스크린 리더를 사용하는 시각장애인에게는 불편함을 가중시키는 라이브러리

마우스 사용자 뿐 아니라 키보드 사용자에게 까지도 멋지게 제어 가능한 라이브러리이지만 시각장애인에게는 오히려 방해요소가 되고 있다. 라이브러리가 슬라이더로 지정한 폼 컨트롤의 label을 가로채어 <button> 태그로 마크업된 슬라이더 UI에 배정하는데 label의 대상(for 속성)을 왜곡시키고 다른 속성(labelledby 속성)을 통해 슬라이더 UI와 label을 연결시켜주고 있다. <button> 태그에 title 속성을 통한 UI 사용법에 대한 간단한 설명을 넣거나 원래의 폼 컨트롤을 가리키는 label을 가공하지 말아야 할 것이다.

단순히 시각적인 것 이상을 생각한 훌륭한 라이브러리

Accessible Unobtrusive Slider는 시각적인 것 이상을 고려한 것만으로 의미있고 유용한 라이브러리이다. 위에 언급한 단점들을 보완할 수 있으면 모든 사용자에게 훌륭한 UI 개선 도구가 될 것이다.

덧) IE6에서 마우스를 갖다 대었을 때 많이 버벅댄다. 나만 그런가? 사용 전 충분한 테스트는 꼭! :)

웹 페이지를 제작하면서 자바스크립트를 어떤 부분에 사용해야겠다라고 마음 먹으면 우리는 자바스크립트를 표시하는 <script> 태그를 쓴다. 앞서 얘기한 설계대로 <script> 태그의 사용 가능하지 않은 경우를 위해 <noscript> 태그를 쓸 수 있다. 어플리케이션 레벨이 아닌 마크업이 잘 되어 정상적인 기능을 하는 HTML 문서에 부가적인 사용자 편의성의 증대를 목적으로 사용하는 자바스크립트라면 <script> 태그가 동작하지 않을 경우 자바스크립트가 없는 HTML 문서와 같이 작동하게 되므로 굳이 <noscript> 태그가 필요하지 않을 것이다.

<form action="insert" id="f">
    <fieldset>
        <label for="yourjob">당신의 직업</label>
        <input type="text" name="job" id="yourjob" />
        <a href="javascript:checkForm();">전송</a>
    </fieldset>
</form>

<script type="text/javascript">
// <![CDATA[
function checkForm() {
    var form = document.getElementById("f");
    if (form.elements["job"].value == "") {
        alert("직업을 입력해주세요.&quot);
    } else {
        form.submit();
    };
};
// ]]>
</script>

<form action="insert" id="f">
    <fieldset>
        <label for="yourjob">당신의 직업</label>
        <input type="text" name="job" id="yourjob" />
        <input type="submit" value="전송" />
    </fieldset>
</form>

<script type="text/javascript">
// <![CDATA[
if (document.getElementById && document.getElementById("f")) {
    var form = document.getElementById("f");
    form.onsubmit = function() {
        if (this.elements["job"].value == "") {
            alert("직업을 입력해주세요.&quot);
            return false;
        };
    };
};
// ]]>
</script>

모든 사용자가 당신의 자바스크립트 코드를 실행할 수 있을 것이라고 기대하지 말아야 한다. 또, 어떤 사용자는 당신의 자바스크립트 코드 중 어떤 부분을 제대로 해석하지 못한다는 것을 알아야 한다.

자바스크립트는 플래시, ActiveX와 같은 외부 플러그인과 개념 상 다르지 않다. 오히려 언급한 것처럼 사용자에 따라 불완전하게 실행될 가능성이 있기 때문에 더 다루기 어려운 기술임을 인식하여야 한다.

참고 링크

• Unobtrusive JavaScript – wikipedia
• Behavior Seperation – A List Apart
• 자바스크립트를 올바르게 사용하기 – Sangini World
• 접근성을 해치지 않는 자바스크립트의 사용 – 신현석

마지막 업데이트: 2008년 4월 25일 04시 30분

DOM Script의 저자 제레미 키스(Jeremy Keith)가 쓴 방탄 Ajax가 출간되었습니다. DOM Script에서 올바른 DOM, 겸손한(unobtrusive) 자바스크립트에 관한 이야기를 했다면 이번엔 올바른 Ajax의 활용, 접근성을 확보하는 Ajax 개발론, 즉 겸손한(unobtrusive) Ajax에 대해 이야기하고 있습니다.

이 책에서의 Ajax는 Asynchronous JavaScript and XML가 아닌 미국과 영국 등에서 과거에 쓰였던 Ajax라는 단어의 뜻으로서 정의하고 있습니다. 쉽게 말해 Flex, Silverlight 등의 RIA을 포괄하는 의미라는 것입니다.

모든 웹 사이트, 웹 어플리케이션의 기본은 문서이다. 라고 이야기하는 이 책에서는 기본적인 문서((X)HTML)로 부터 출발하여 점층적으로 CSS, Ajax를 덧붙여 나아가는 개발 방식을 이야기하고 있습니다. 기본적으로 하위 호환성과 접근성이 보장된 문서((X)HTML)의 틀에서 점층적으로 새로운 기술들을 적용해 나아간다면 겸손한(unobtrusive) Ajax의 제작이 어렵지 않을 것이라는 이야기입니다.

Ajax 기술들은 아직 충분히 접근성이 검증되어 있지 않은 새로운 기술들입니다. 방탄 Ajax는 그에 대해 지적하며 Ajax 기술 적용 시에 잃을 수 있는 것들에 대해 경고하고 있습니다. 저는 이것이 이 책이 얘기하는 주제라고 생각합니다. 눈 앞에 펼쳐질 화려한 효과에 앞서 고려하지 않으면 잃게 될 것이 무엇인지, 잃게 될 것들을 지키려면 어떻게 해야 할지가 명확하지 않다면 이 책을 볼 충분한 이유가 될 것 같습니다.

덧) 항상 좋은 책을 볼 수 있게 해주시는 명수씨, 감사합니다! :)

그럼 실제로 각 글에 체크박스가 있어서 체크 후 삭제 혹은 이동하는 기능이 있는 게시판 목록을 만들어보자. 결과물은 다음의 그림과 같을 것이다.

그림을 보고 HTML 페이지를 만들어보자.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ko">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>여러개의 폼 제출 버튼 예제</title>
</head>
<body>
    <form action="test.html">
        <h1>여러개의 폼 제출 버튼 예제</h1>
        <table summary="게시판 목록">
            <thead>
                <tr>
                    <th>선택</th>
                    <th>제목</th>
                    <th>작성자</th>
                    <th>작성일</th>
                    <th>조회수</th>
                </tr>
            </thead>
            <tbody>
                <tr>
                    <td><input type="checkbox" title="1번글 선택"
                         name="check1" value="Y" /></td>
                    <td>게시판 제목1</td>
                    <td>아무개</td>
                    <td>2007년 10월 13일</td>
                    <td>4</td>
                </tr>
                <tr>
                    <td><input type="checkbox" title="2번글 선택"
                         name="check2" value="Y" /></td>
                    <td>게시판 제목2</td>
                    <td>아무개</td>
                    <td>2007년 10월 13일</td>
                    <td>4</td>
                </tr>
                <tr>
                    <td><input type="checkbox" title="3번글 선택"
                         name="check3" value="Y" /></td>
                    <td>게시판 제목3</td>
                    <td>아무개</td>
                    <td>2007년 10월 13일</td>
                    <td>4</td>
                </tr>
                <tr>
                    <td><input type="checkbox" title="4번글 선택"
                         name="check4" value="Y" /></td>
                    <td>게시판 제목4</td>
                    <td>아무개</td>
                    <td>2007년 10월 13일</td>
                    <td>4</td>
                </tr>
            </tbody>
        </table>
        <p>
            <input type="submit" name="delete_selected"
                value="선택된 글 삭제" />
            <input type="submit" name="move_selected"
                value="선택된 글 이동" />
        </p>
    </form>
</body>
</html>

선택된 글 삭제와 선택된 글 이동 버튼을 submit 타입의 input 태그로 주고 각각에 name 속성을 부여하였다. 여기에서 1번글을 선택하고 선택된 글 삭제 버튼을 누른다면 제출된 값은 다음과 같을 것이다.

check1 = "Y"
delete_selected = "선택된 글 삭제"

마찬가지로 이동 버튼을 누른다면,

check1 = "Y"
move_selected = "선택된 글 이동"

위와 같은 값이 제출될 것이다.

"선택된 글 삭제"와 같은 값을 다른 원하는 임의의 값으로 줄 수 없을까? 답은 불가능하다. 화면에 보여지는 값을 그대로 사용해야 한다. 이 것이 필자가 설명한 방식의 한계이다. 개발자들은 보통 "Y" 혹은 "delete"와 같은 명확한 코드 형식의 단어를 사용하고 싶어할 것이다. 하지만 자바스크립트를 사용할 수 없는 사용자들의 불평을 듣고 싶지 않다면 현재로서는 어쩔 수 없다. IE(IE7 포함) 사용자는 submit 타입의 input 태그 외에 submit 타입의 button 태그나 image 타입의 input 혹은 button 태그에 name 속성을 통해 제출 값을 구분할 수 없기 때문이다.

이미지 버튼일 경우는 어떻게 하나? image 타입의 input 태그를 사용할 수 없다면? 답은 Image Replacement이다. Image Replacement를 사용할 수 없는 상황이라면 폼 제출 버튼을 이미지 – 배경 이미지 제외 – 로 하지 않는 디자인을 고려해보아야 할 것이다.

<style type="text/css">
input.delete-selected {
    width: 100px;
    height: 20px;
    background: url(delete_selected.gif) no-repeat;
    text-indent: -5000px;
}
input.delete-selected {
    width: 100px;
    height: 20px;
    background: url(move_selected.gif) no-repeat;
    text-indent: -5000px;
}
</style>
<!-- 중략 -->
<p>
    <input type="submit" class="delete-selected"
        name="delete_selected" value="선택된 글 삭제" />
    <input type="submit" class="move-selected"
        name="move_selected" value="선택된 글 이동" />
</p>

글의 코드는 아래의 첨부파일을 다운로드를 통해 실행해볼 수 있다.

select.html

그림1은 현재 게시판의 분류나 바로가기 메뉴 등에서 선택 시 바로 폼을 전송시키거나 자바스크립트를 이용하여 페이지 전환을 하는 용도로 쓰이고 있다. 그러나 키보드 사용자나 자바스크립트를 사용할 수 없는 사용자를 고려하였을 때 위와 같은 사용은 불가하다. 자바스크립트가 불가능한 사용자를 위해 <noscript> 태그를 이용하여 서브밋 버튼을 추가하면 되지 않느냐? 그것은 반쪽짜리 접근성이다. 마우스 기능을 사용할 수 없는 사용자의 접근성이 상당히 저하되기 때문이다. 키보드 사용자는 select 태그의 목록을 활성화 시킨 후 아래 방향키를 한 번 누르는 순간 select 태그의 자바스크립트가 활성화되어 마치 목록 두 번째 요소를 선택한 듯한 결과를 보게 될 것이다.

(그림2. 전송 버튼이 적용된 select 태그)

전송 버튼을 넣고 select 태그의 onchange 이벤트를 제거하여 모든 사용자에 대한 접근성을 확보할 수 있다. 마우스 사용자들의 편의성 문제는 어떻게 하는가? 결국 판단은 제작하는 사람의 몫이지만 누군가의 접근성을 저해하면서 얻는 편의는 기능에 대한 남용이다.

이밖에 장애인이 공공부분의 인터넷 사이트를 손쉽게 이용할 수 있도록 `웹 접근성 준수’를 제도화하기 위해 올해안에 웹 접근성 국가표준을 개정하기로 했으며 공공기관은 물론 민간기관들의 참여를 이끌어내기 위해 `웹 접근성 품질 마크’를 적극적으로 부여하기로 했다.

정부 차원에서 장애인들의 IT 활용 활성화를 추진하고 있다는 기사가 났다. 웹 접근성에 대해 국가 차원의 관심과 필요성이 더욱 늘어나게 되었다는 이야기이다. 좋던 싫던 관심이 있던 없던 웹 표준과 접근성은 점점 피할 수 없는 필수요소가 되어가고 있다. 장애인의 인터넷 접근 장치는 점점 늘어가는데 정보를 얻는 통로인 웹사이트가 그들을 소외시킨다면 정부의 이런 정책은 아무런 의미가 없을 것이다.

기사대로라면 2012년에는 접근성을 보장 여부가 13만명의 잠재 이용자를 잡느냐 놓치느냐를 판가름한다. 웹표준과 웹접근성의 가치가 보다 빠르게 늘어날 것이라는 기대를 해본다.