메뉴 건너 뛰기 링크란 하나의 웹 사이트에서 모든 페이지에 걸쳐 반복해서 등장하는 글로벌 네비게이션과 로컬 네비게이션을 건너 뛸 수 있는 링크를 말합니다. 마우스를 함께 사용하는 사람은 이 링크가 왜 필요한지 알기 어렵지만 키보드만으로 웹을 탐색하는 사람들에게는 상당히 중요한 의미를 갖습니다.

2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A) 2.4.1 블럭 우회: 여러 웹 페이지에서 반복되는 콘텐츠 블럭을 우회할 수 있어야 한다. (수준 A)

WCAG 2.0 : 2.4.1

헤딩은 콘텐츠 블럭을 우회하는 가장 효과적인 방법

시각 장애인은 마우스 포인터를 볼 수 없기 때문에 키보드만으로 웹을 탐색을 합니다. 물론 Tab키와 방향키 만으로 탐색을 하는 것은 아닙니다. 화면 낭독 프로그램은 ‘링크만, 헤딩만’ 따로 모아서 탐색할 수 있고 특히 ‘링크’ 텍스트를 설명력 있게 제공하는 것도 당연히 좋지만 적절한 ‘헤딩’을 제공하는 것은 더더욱 중요합니다. 헤딩은 콘텐츠 블럭을 건너 뛸 수 있는 단서가 되기 때문이고 시각 장애인에게는 불필요한 콘텐츠를 잘 건너 뛰게 해주는 것이 매우 중요합니다. 시각이 있는 사람들도 자각하지 못하는 사이에 이미 불필요한 콘텐츠를 무시하는 것에 학습되어 있습니다. 눈에 잘 띄도록 만든 배너를 빠르게 무시하는 것은 방법이라기 보다 본능적인 반응에 가깝습니다. 헤딩은 콘텐츠 블럭을 우회하는 가장 효과적인 방법 입니다.

반복되는 콘텐츠 블럭을 우회하는 방법

콘텐츠와 콘텐츠 사이를 빠르게 건너뛰기 위하여 시각 장애인에게 헤딩(h1, h2, h3, h4, h5, h6) 정보가 중요하다는 사실을 말씀드렸습니다만 사실 오늘의 주제는 ‘메뉴 건너 뛰기’ 입니다. 메뉴에 헤딩을 제공하는 사람은 별로 없고 제공해야 한다는 지침도 없으며 오히려 제공했을 때 더 어색하고 불편할 수 있습니다. 따라서 메뉴에는 보통 헤딩이 없습니다. 하지만 한 두 페이지 정도만 탐색해 보면 시각이 있고 없고를 떠나서 누구나 그것이 메뉴라는 것을 알게 됩니다. 같은 패턴의 데이터가 반복 되기 때문입니다.

이렇게 모든 페이지마다 지속적으로 반복되는 네비게이션들을 키보드 사용자는 어떻게 탐색해야 할까요? Tab키를 계속 누르고만 있어야 할까요? 다 필요해서 있는 것이니 반복 되더라도 계속해서 탐색하고 듣고 있어야 하는 것일까요? 아닐껍니다. 건너 뛸 수 있는 장치를 제공해 주어야 합니다. 이미 위에서 ‘WCAG 2.4.1′ 구절을 인용했지만 블럭을 우회할 수 있어야 한다는 지침은 ‘수준 A’ 입니다. 수준 A는 최소한 지켜야 하는 수준으로써 가장 중요하다는 의미와 맞닿아 있습니다. 우리는 반복되는 콘텐츠 블럭을 건너 뛸 수 있도록 하기 위하여 ‘메뉴 건너 뛰기’ 링크를 제공할 수 있습니다.

메뉴 건너 뛰기 링크에 관한 쟁점

메뉴 건너 뛰기 링크를 제공해야 한다는 의견에는 거의 모든 웹 접근성 전문가들이 동의하지만 그것을 제공하는 방법에는 크게 다음과 같은 세 가지 다른 구현 방법이 있습니다.

• 메뉴 건너 뛰기 링크는 시각이 있는 사람도 볼 수 있도록 웹 페이지 최 상단에 항상 노출해야 한다.
• 메뉴 건너 뛰기 링크는 시각이 있는 사람에게는 방해가 되므로 숨김 처리하고 키보드가 접근할 때에만 노출해야 한다.
• 메뉴 건너 뛰기 링크는 시각이 있는 사람에게는 방해가 되므로 항상 숨김 처리 해야 한다.

여러분은 어떤 의견에 동의 하시나요? 저는 두 번째 방법을 가장 좋은 방법이라고 생각하고 있습니다. 만약 여러분이 ‘네이버’ 웹 페이지를 개발한다면 여러분들은 모든 네이버 웹 사이트 최 상단에 ‘메뉴 건너 뛰기’ 링크를 넣어야 한다고 생각 하시나요? 저는 그렇게 생각하지 않습니다. ‘메뉴 건너 뛰기’ 링크는 시각이 있는 사람에게는 오히려 건너 뛰고 무시해야 할 콘텐츠가 됩니다. 마우스를 조작하는 사람에게 이 링크는 필요치 않으니까요.

그렇다고 해서 항상 숨김 처리 하는 것도 문제가 됩니다. 왜냐하면 시각 장애인만 이 링크를 사용하는 것은 아니기 때문 입니다. 시각은 있지만 손과 발을 자유롭게 사용할 수 없는 지체 장애인은 마우스 스틱이라는 빨대 모양의 막대를 이용해서 키보드만으로 웹을 탐색 합니다. 손과 발이 자유롭지 못하기 때문에 입에 막대를 물고 키보드를 두드립니다. 메뉴 건너 뛰기 링크에 접근 했을 때 링크가 화면에 보여야 하는 이유는 이렇게 시각은 있지만 키보드만을 사용할 수 밖에 없는 장애인들에게 유용하기 때문 입다. 간혹 TV에서 팔이 없는 지체 장애인이 발로 마우스를 조작하는 모습을 본 기억이 있으실 껍니다. 하지만 발이 있다고 해서 모든 지체 장애인이 발로 마우스를 자유롭게 조작하는 것은 아닙니다.

키보드 사용자에게만 유용한 메뉴 건너 뛰기 링크

키보드 사용자에게만 유용한 메뉴 건너 뛰기 링크 예제를 만드는 것은 정말 쉽습니다. 자바스크립트는 필요치 않고 HTML과 CSS만으로 가능합니다. <a> 요소의 width, height, overflow 속성을 조절해서 기본적으로 화면에 보이지 않도록 처리한 다음 a:focus 상태일 때에는 width, height 값이 auto가 되도록 처리하는 것입니다.

글로벌 네비게이션을 본문 콘텐츠보다 늦게 마크업 하는 경우

글로벌 네비게이션을 본문 콘텐츠보다 나중에 마크업 하는 경우도 있습니다. 화면에 보이는 것과 마크업 순서를 다르게 처리 한다고 해서 항상 논리적인 순서가 잘 못 되었다고 말 할 수는 없습니다. 지금 제가 사용하고 있는 Textyle 블로그와 Wordpress 블로그는 모두 본문 콘텐츠가 먼저 마크업 되고 글로벌 메뉴가 나중에 마크업 되어 있습니다. 이런 경우라면 ‘메뉴 건너 뛰기’ 링크보다 ‘본문 건너 뛰기’ 링크가 더 적절할 것이고 나아가 ‘건너 뛰기 링크’는 생략해도 됩니다. 본문 콘텐츠는 모든 페이지에서 반복되는 내용도 아니고 많은 링크가 포함되어 있지도 않기 때문 입니다.

지나치게 많은 ‘** 건너 뛰기’ 제공은 오히려 공해

반복되는 블럭을 건너 뛰어야 한다는 지침을 잘 못 이해해서 모든 웹 페이지 상단에 굉장히 많은 ‘** 건너 뛰기’ 링크를 제공하는 경우가 있습니다. 이것은 오히려 건너 뛰어야 할 공해 콘텐츠가 됩니다. 건너 뛰어야 할 것은 ‘반복되는 블럭’인데 마치 한 페이지의 ‘목차’ 처럼 제공하는 경우가 있다는 것입니다. 건너 뛰기 링크는 보편적인 경우에 ‘메뉴 건너 뛰기’ 하나면 충분 합니다. 한편 모든 페이지에서 반복되지는 않지만 상당히 많은 버튼이나 링크가 존재한다면 해당 블럭을 건너 뛸 수 있도록 건너 뛰기 링크를 제공하는 것이 좋습니다.

• 네이버 뉴스 클러스터링 – 키보드가 접근 할 때 화면에 보이는 메뉴 건너 뛰기 링크 하나를 제공하고 있다.
• 네이버 스마트에디터 베이직(오픈소스) - 본문에 등장하는 콘텐츠로써 키보드가 접근 할 때 도구 모음을 건너 뛸 수 있는 링크를 제공하고 있다.
• 미디어 다음 – 화면에 보이지 않는 메뉴 건너 뛰기 링크 하나를 제공하고 있다.

메뉴 건너 뛰기에 관한 더 많은 의견들

• Skip Navigation은 Quick Link가 아닙니다. - 성민장군
• KWCAG 2.0 의 Skip Navigation(건너뛰기 링크) – 본문으로 가면 그만? - 양군팩토리

미리 알려드립니다만 저는 주로 인터렉션을 프로토타이핑 해서 보여줄 목적으로 자바스크립트를 작성하기 때문에 제 블로그에서 보여드리는 예제 코드가 모두 XE에 반영되는 것은 아닙니다.

예제를 새 창으로 보기

HTML

• ‘LOG-IN’ 링크에 accesskey 속성을 사용. ‘Alt+L’ 또는 ‘Alt+Shift+L’ 키를 사용하면 링크에 직접 접근.
• 논리적인 키보드 접근 순서. 로그인 레이어를 열거나 닫더라도 포커스는 초기화 되지 않고 문맥에 알맞게 순서를 유지.

CSS

• 화면 전체를 덮는 반투명 레이어.
• 로그인 상자를 화면의 정 중앙에 배치.
• 서밋 버튼을 텍스트로 처리해서 텍스트를 교체할 수 있음.

Javascript

• ‘LOG-IN’ 링크를 클릭해서 모달 윈도우 처리된 레이어 띄우기.
• 인풋에 포커스가 들어가거나 빠질 때 ‘레이블’ 텍스트를 숨기거나 보여주기.
• ‘로그인 유지’ 항목에 체크하면 경고문 보여주기.
• ‘ID/PW’를 입력하지 않았을 때 상황에 맞는 알럿 띄우기.
• ‘Open ID’ 링크를 클릭하면 오픈 아이디 화면으로 전환하기.
• ‘ESC’키를 누르거나 ‘여백’ 또는 ‘X’ 버튼을 클릭하면 창 닫기.

P.S.

저는 얼마 전부터 텍스타일에서 글을 쓰고 있습니다. 여러분이 만약 이 글을 제 워드프레스에서 보셨다면 배달된 글을 보고 계신 겁니다. 텍스타일에서 작성한 글은 워드프레스, 미투데이, 트위터 등으로 자동으로 배달 된답니다. 번거롭게 퍼다 나르고 다닐 일이 없어서 좋네요. 텍스타일 한 번 사용해 보세요. 즐거운 글쓰기 경험도 해 볼겸 해서 말이죠. ^^

서식 제어 요소의 디자인을 제한하는 이유

이런 서식 제어 요소들의 디자인을 변경하는 것은 일단 브라우저들이 지원하지 않습니다. 이런 이유 때문에 이것을 디자인 하려는 시도는 실제로는 기능하지 않는 가짜 마크업을 남발하게되고 웹 접근성을 떨어뜨리는 요인으로 작용합니다. 하나의 콘트롤을 디자인 하기 위하여 화면에 보이는 마크업과 실제로 기능을 수행하는 마크업을 각각 따로 작성하게 되면 화면낭독기 사용자들은 화면 표시를 위한 가짜 마크업 때문에 곤경에 빠지는 상황이 연출됩니다.

그리고 간혹 단순한 텍스트 링크 기능을 수행함에도 불구하고
라디오 버튼을 장식적인 요소로 사용한 다음 라디오 콘트롤에 자바스크립트를 입혀서 페이지 이동을 처리하는 고품격(?) 사용자 경험을 제공하기도 하는데 매우 잘못된 방법중의 하나 입니다.

모든 서식 제어 요소들은 사용자가 ‘전송’ 버튼을 누르기 직전까지 아무짓도 하지 않고 기다려야 할 의무가 있습니다. 왜냐하면 그것이 바로 서식 제어 요소들의 올바른 사용법이고 시각 장애인들은 그런 표준화된 그리고 전통적인 사용자 인터렉션에 의지해서 웹을 탐색하고 있기 때문입니다.

"라디오 버튼을 눌렀을 뿐인데 페이지가 이동할 줄은 몰랐어요. 저는 전송 버튼을 누르지도 않았거든요."

<select> 콘트롤을 본래 목적에 맞게 사용하기

한편 서식 제어 요소를 사용할 때 사용자 입력을 전송하는데 쓰지 않았다고 해서 무조건 틀렸다고 말할 수도 없습니다. CSS가 일반적으로 널리 퍼지기 이전에 서식 제어 요소들은 다른 HTML 요소들이 흉내낼 수 없는 효과적인 UI 콘트롤을 제공했기 때문에 그 이점만을 취하기 위한 활용사례가 많았습니다. 현재까지도 흔하게 볼 수 있는 예가 바로 <select> 콘트롤 입니다. 본래의 목적은 단일 또는 다중 선택된 사용자의 선택값을 서버측에 전송하기 위한 목적이었지만 ‘패밀리 사이트 바로가기, 유관 기관으로 이동’과 같이 단순하게 텍스트 링크로 처리해도 될만한 UI에 지금까지도 여전히 <select> 요소를 사용하고 있습니다. 이 때 자바스크립트로 URL 값을 처리해서 넘기는 경우도 있고 서버측 스크립트로 값을 처리해서 넘기는 경우도 있는데 어느편이 더 유니버설한 설계 방법인지는 여러분이 직접 판단해 보시기 바랍니다.

하지만 한 발 더 나아가 저는 더 이상 <select> 콘트롤을 이용하여 페이지 이동하는 기법을 사용할 필요가 없다고 생각합니다. 자바스크립트나 서버측 스크립트를 작성해서 페이지를 이동하는 방법보다 더 쉬운 방법이 있기 때문입니다. CSS 배워서 이런데 써먹을 수 있습니다. <select> 콘트롤은 이제 그만 휴가 보내고 CSS에게 일을 시켜 보세요. <select> 요소의 드롭다운 콘트롤은 고작 ‘숨은 링크 목록’을 토글해서 보이거나 숨기는 인터렉션일 뿐입니다.

그럼에도 불구하고 <select> 콘트롤이 사랑받는 이유

요소 본래의 목적에 맞지 않는 마크업과 복잡한 스크립트의 사용을 유발함에도 불구하고 <select> 콘트롤은 여전히 기획자, 디자이너, 개발자에게 사랑받고 있습니다. 왜 그럴까요?

• 좁은 공간을 효과적으로 사용할 수 있기 때문에
• 클릭하면 숨은 목록을 볼 수 있는 전통적인 인터페이스로써 이미 대중에게 학습되었기 때문에
• 오랜 세월에 걸쳐 잘 작성된 레거시 코드가 있고 새로 만들 때 복사 후 붙여넣기만 하면 되니까

정도로 요약할 수 있겠습니다. 결국 우리는 <select> 라는 콘트롤을 본래의 목적에 맞게 사용하되 ‘긴 직사각형의 우측 끝에 화살표가 달린 모양’만 취하면 되는 겁니다.

결론 : <select> 형태는 취하고 마크업은 버리자

예제를 새 창에서 보기

위의 두 예제는 같은 모양을 하고 있지만 첫 번째 예제는 링크이고 두 번째 예제는 단일 선택을 위한 폼 콘트롤 입니다. 폼 콘트롤 우측에 ‘GO’ 버튼이 보이시나요? ‘사용자가 폼을 전송하기 전까지는 아무짓도 하지 않아야 한다’는 원칙을 실천하기 위하여 존재하는 버튼 입니다. ‘GO’ 버튼이 없으면 어떻게 되냐구요? 아마도 키보드 사용자는 다른 항목을 선택할 기회를 갖지 못하고 첫 번째 항목을 선택하는 순간 이미 다른 페이지로 이동되어 있거나 또는 전송 버튼을 찾느라 곤경에 빠질 것입니다. 저 ‘GO’ 버튼이 있음으로 인해서 마우스를 사용하는 대부분의 사용자들은 불편함을 느낄 수도 있을 것입니다. 하지만 ‘누구나 사용’할 수 있도록 유니버설하게 개선되었기 때문에 ‘인류 행복의 총량’에는 큰 변화가 없을 것입니다. 

다행히도 저렇게 단일 선택 옵션이 하나만 존재하는 경우 폼 대신 첫 번째 예제와 같이 링크로 처리할 수 있는 경우가 거의 대부분 입니다. 폼 대신 링크로 처리하게 되면 ‘GO’ 버튼이 필요가 없기 때문에 모든 사람들이 더 기뻐할 것입니다. 링크 목록은 클릭하기 전까지 펼침 상태로 존재하고 Enter 키를 받아야만 페이지 이동을 하기 때문에 ‘GO’ 버튼이 없어도 키보드만으로 제어를 할 수가 있죠.

위 제시된 예제는 처리해야 할 콘텐츠가 ‘링크’ 인지 또는 ‘진짜 폼의 선택’을 위한 것인지 명확하게 이해한 다음 사용해야 합니다. 단순히 링크로 처리해야 할(처리해도 될) 항목을 두 번째 예제로 마크업 한다면 오늘 제 포스팅은 말짱 도루묵 입니다. 부디 의미와 목적에 맞는 마크업을 선택해서 사용해 주실것을 부탁 드립니다. 이번 예제도 행복한고니로부터 도움을 받았습니다. 요즈음은 행복한고니가 짬짬이 알려주는 jQuery 덕분에 아주 즐거운 나날들을 보내고 있답니다. ^^

이번에는 운이 좋게도 디자인팀으로부터 지원을 받았는데요. 이렇게 디자인팀으로부터 지원을 받은 디자인은 품질이 상당히 좋아서 한 번 쓰고 말기에는 정말 아깝더라구요. 재 활용 가치가 있는 UI 콤포넌트는 가끔 처음부터 재 사용을 염두해 두고 설계를 합니다. 물론 시간이 무척 오래 걸리는 단점은 있지만 다른 누군가의 시간을 분명히 단축해 줄꺼라 믿고 있습니다.

오늘 공유해 드릴 UI 콤포넌트는 평범한 네비게이션 바 입니다. 이런 종류의 네비게이션은 너무 흔해서 일년에 열두번도 더 코딩을 하지만 항상 재 사용을 염두하지는 않았기 때문에 할 때마다 새로 만들고 처음부터 다르게 코딩 합니다. 물론 디자인이 조금씩 달라지는 것도 이유가 있겠지만 다소 소모적인 부분이 있었던 것도 사실입니다. 보기에 평범해 보이지만 재 사용과 보편적 설계를 위해서 제가 이 네비게이션 바에 얼마나 많은 정성을 쏟았는지 한 번 설명드려 보겠습니다.

보편적이고 사용성이 좋은

수평 네비게이션은 보편적인 형태지만 하위 메뉴를 처리하는 방법에는 크게 두 가지 형태가 있습니다. 하위 메뉴를 수평으로 늘어뜨리거나 또는 위 예제와 같이 수직으로 늘어뜨리거나. 그런데 이 두 가지 형태의 메뉴 구조는 사용성이 크게 다릅니다. 하위 메뉴를 수직으로 늘어뜨리는 것이 사용성과 확장성이 훨씬 좋습니다.

하위 메뉴를 수평으로 열게 되면 사용자는 정확하게 선택하기 위하여 ‘L’자 모양으로 마우스 포인터를 이동시켜야 합니다. 게다가 하위 메뉴 영역을 벗어날 때 하위 메뉴가 사라지도록 처리하는 경우 사용성은 더 나빠집니다. 원하는 메뉴 링크까지 이동하려면 조심스럽게 마우스 포인터를 옮겨야 하니까요. 하위 메뉴를 수직으로 펼치면 마우스의 이동 괘적은 ‘I’자 모양을 그리게 되고 마우스를 옮기는 과정에서 메뉴가 닫힐 위험은 사라집니다. 

웹 표준과 접근성을 지키는

이런 메뉴 구조를 테이블 <table> 요소를 사용해서 마크업하면 의미에도 맞지 않고 접근성도 떨어집니다. 네비게이션 요소는 HTML로 표현할 때 ‘목록’ 요소 <ul>, <li>로 마크업 해야 합니다. 동등한 수준의 내용이 같은 계층에서 여러번 반복 된다면 ‘목록’입니다. 시각장애인이 사용하는 화면 낭독기는 이런 목록에 대하여 목록의 ‘시작, 끝, 단계 그리고 항목의 개수’를 음성으로 알림으로써 목록에 대한 이해를 돕습니다. 상기 예제에서 ‘CSS X’ 버튼을 누르면 네비게이션이 어떤 HTML 구조로 마크업 되어 있는지 확인할 수 있습니다. 이렇게 코딩된 네비게이션 바는 다음과 같은 장점을 갖습니다.

• 상-하위 계층 관계가 논리적으로 처리되어 CSS를 지원하지 않거나 걷어낸 장치(예:모바일)에서도 이해하기 쉽습니다.
• 모든 항목에 키보드 접근이 가능하고 키보드 접근 순서가 의미있게 처리되어 있습니다.

이 네비게이션 바는 키보드만을 사용할 수 밖에 없는 시각장애인과 지체장애인도 사용할 수 있습니다. 키보드만으로 탐색을 시도해 보세요.

유연하고 확장하기 좋은

하위 메뉴의 개수가 상당히 많이 늘어나는 상황에서 수평으로 열리는 하위 메뉴는 필연적으로 줄바꿈을 동반하거나 메뉴의 개수를 제한하게 되지만 수직으로 열리는 메뉴는 그럴 필요가 없기 때문에 메뉴 데이터가 가변적인 상황에서 확장성이 더 좋습니다.

메뉴의 전체적인 너비는 레이아웃에 맞게 가변폭으로 조절되고 메뉴 항목의 너비도 메뉴 이름의 길이에 따라 모두 가변폭으로 처리되어 있습니다. 디자인 때문에 글자 개수를 자르거나 제한 할 필요가 없습니다.

네비게이션 바의 색상을 바꾸기 위해 새로 이미지를 컷팅할 필요가 없습니다. CSS 편집을 통해 배경색과 보더 색상만 변경해 주면 끝입니다. 은은하게 처리된 그라디언트 효과는 배경색상 위에 반투명 흰색 그라디언트 PNG 이미지를 덧붙이는 기법으로 처리 했습니다.

이미 널리 쓰이고 있는

jQuery 자바스크립트 프레임웍을 사용했기 때문에 약간의 자바스크립트 코드를 추가하거나 변형하면 누구나 쉽게 사용할 수 있습니다. 물론 지금 그대로 사용해도 될만큼 이미 스크립트가 잘 처리되어 있습니다. 자바스크립트는 행복한고니에 의해 처리 되었습니다.

브라우저 호환성

다음과 같은 브라우저에서 테스트 되었고 호환성이 확보되어 있습니다.

• Internet Explorer 6
• Internet Explorer 7
• Internet Explorer 8
• Firefox 3
• Chrome 4
• Safari 4
• Opera 10

이 네비게이션을 처리하기 위하여 테스트 했던 거의 모든 브라우저들의 버그를 다 만났던것 같습니다. 여러분이 보시기에 HTML 코드에 ‘이건 왜 이렇게 마크업을 했지?’ 라고 의문이 든다면 그 부분이 바로 그 흔적 입니다. 특히 IE7 브라우저의 경우 링크 영역(width)을 제대로 렌더링하지 못하는 버그 때문에 상당히 고전을 했는데 결국 방법을 찾지 못하고 자바스크립트의 도움을 받아서 디버깅 했습니다. 코딩하는데 1.5일이 걸렸고 디버깅하는 시간도 1.5일이나 걸렸습니다. 3일동안 쳐다보고 있으니 아주 지겨워 죽겠더라구요.

이미 알고있는 분들도 계시겠지만 저는 오픈소스 XE의 UI 개발을 담당하고 있습니다. 모든 오픈소스가 그렇지만 저희 팀원들의 모토 가운데 하나도 ‘내가 불편한 것을 바꾸고 내가 쓰고 싶은 도구로 만들자’입니다. 이런 모토는 팀원들이 스스로 동기를 유발해서 열정적으로 XE를 개선하는데 도움이 됩니다.

그러나 오픈소스팀이라고 해서 주어진 일정이 없고 언제나 하고 싶은 일만 골라서 할 수 있는것도 아니기 때문에 즉시 실행으로 옮길 수 있는 일이 아니면 개인적으로 마음 한 켠에 쌓아놓을 뿐입니다. 물론 좋은 아이디어를 공유하지 않고 혼자 쌓아두는 것이 좋은 습관은 아니지만 아이디어를 제시하고 토론하는 과정에서 무척 많은 에너지를 필요로 하고 현재의 일에 몰입하는데 방해가 되기 때문에 자주 그러지 못할 뿐입니다.

제가 오늘 하고 싶은 이야기는 XE의 불편한 사용자 경험에 대한 이야기 입니다. XE는 아직 충분히 좋은 사용자 경험을 갖추지 못했지만 고객들은 그걸 잘 모릅니다. "XE는 어렵다" 또는 "XE를 배워야겠다"라는 말을 들을때마다 정말 미안해서 미칠 지경입니다. XE 사용자가 그렇게 말하는 이유는 사용자가 바보이기 때문이 아니라 XE의 사용자 경험이 좋지 않다는 뜻이고 그 책임의 일부는 저에게도 있기 때문입니다. 사용성이 좋지 않은 소프트웨어를 대할 때 사람들은 제품의 문제라고 생각하지 않고 스스로를 비난하는 경향이 있으며 5명 중 1명 정도만 문제제기를 한다고 합니다.

XE와 같은 설치형 소프트웨어의 사용자층은 크게 둘로 나눌 수 있는데 XE를 설치 운영하는 집단과 XE라는 사실조차 알지 못한채로 그저 가볍게 이용하는 사용자 집단 입니다. XE 공식 웹 사이트에 등록되는 버그 또는 이슈들은 대부분 XE를 설치 운영하는 사용자 집단으로부터 나온 것으로써 XE를 가볍게 사용하는 사람들의 문제는 거의 표면적으로 드러나지 않고 있습니다. 따라서 우리는 스스로 문제를 찾아내서 해결해야 합니다.

XE 개발자는 UX 전문가가 되어야 한다

지금까지 그러지 못했다는 것이 아니라 충분하지 않다는 의미 입니다. 설계 과정에서 항상 고려가 되지만 섬세하지 못했거나 우선순위가 낮았고 물려받은 유산들 때문에 미시적으로만 접근하는 측면이 있어왔습니다. 이런 문제를 해결하려면 개발자들이 사용자의 심리상태를 이해해야 하는데 사실상 그것은 거의 불가능에 가깝습니다. 프리젠테이션 젠이라는 책에서는 이런것을 두고 지식인의 저주라는 표현을 씁니다. 이미 너무 많은 것을 알기 때문에 모르는 사람들의 상태를 절대 이해할 수 없다는 것입니다. 사용자경험에 대하여 보다 진지하게 이해하고 연구해야 하며 보다 거시적으로 접근할 필요가 있습니다. XE의 Ajax/Javascript UI 개발을 담당하고 있는 행복한고니는 항상 웹 개발에 문외한인 와이프를 가상의 사용자로 가정한다고 하는데 이런 방법은 비용대비 효과가 괜찮은 작은 실천 중의 하나라고 생각합니다.

선택의 폭을 줄이고 만족도를 높여야 한다

XE의 장점 가운데 하나는 많은 사용자로부터 오는 공통된 불만사항을 빠르게 개선해서 반영한다는 점입니다. 이것은 사용자가 답이라는 zero님의 운영 철학 가운데 하나 인데요. 이런 철학 때문에 실제로 사용자들이 상상하는 대부분의 모듈들은 이미 존재하거나 개발자가 마음만 먹으면 쉽게 만들 수 있습니다.

그러나 선택의 폭을 줄여야 한다는 주장은 상황에 따라서 zero님의 운영 철학과 충돌하는 측면도 있습니다. 왜냐하면 사용자들의 공통된 피드백을 모두 반영하다보면 그만큼 사용자들은 더 많은 선택의 기로에 놓이게 되는데 이것은 곧 XE가 복잡해진다는 것을 의미하고 사용자들의 만족도를 떨어뜨리는 방향으로 작용할 가능성이 있습니다. XE 관리자 페이지에는 무수히 많은 인풋과 선택지가 있는데 이런 경향이 사용자 페이지에 그대로 전이되는 경우가 있습니다. 딱히 뭘 더 줄이자는 이야기를 여기서 하기에는 너무 지엽적인 문제이기 때문에 언급하지 않는것이 좋겠습니다.

장사가 잘 되는 유명한 식당에 가보면 한 가지 음식만 제공해서 메뉴판이 아예 없는 경우도 있는데 오히려 사람들은 굉장히 만족스러워 합니다. 만약 그 식당의 음식들을 고스란히 뷔페로 옮겨놓으면 어떻게 될까요? 장담컨데 같은 음식에 대한 만족도는 확연하게 차이가 날 것입니다. 뷔페의 음식들은 모두 충분한 퀄러티를 가지고 있지만 모두 그저 그렇게 보이고 딱히 만족스럽지 않는 이유는 너무 많은 선택지가 제공되면서 모든 음식들이 서로의 비교 대상이 되기 때문입니다. 맛있는 음식을 더 많이 제공하면 만족도가 더 많이 올라갈것 같지만 절대로 그렇지 않습니다. 저는 신 김치를 딱히 좋아하지 않지만 다른 반찬이 제공되지 않는다면 맛있게 먹을수 있습니다. 너무 많은 선택지와 옵션을 제공하지 않아야 하는 이유 입니다.

인간의 생리와 문맥을 고려해야 한다

XE는 다른 설치형 소프트웨어들와 다르게 기본적으로 다국어환경을 가정합니다. 따라서 기본으로 제공되는 레이아웃을 사용하게 되면 언어를 변경할 수 있는 메뉴가 항상 따라다니는데 유용한 기능임에도 불구하고 좋지 않은 사용자 경험을 제공하는 경우가 훨씬 더 많습니다.

사용자는 보통 다국어 메뉴를 통해서 현재의 웹 사이트에 대한 모든 표현들이 자신의 언어로 변경되는 것을 기대하지만 XE는 이런 기대를 충족해 주지는 않습니다. 아니 정확히 말해서 XE가 충족해 주지 못하는 것이 아니라 XE를 사용하는 콘텐츠 제작자들이 그렇게 해주지를 못하는 것입니다. 다국어는 기계적으로 번역이 되는것이 아니라 콘텐츠 제작자에 의해서 수작업으로 번역이 되는데 대부분의 제작자는 이 기능을 제대로 사용하지 않습니다. 따라서 보통의 사용자들은 다국어 메뉴를 사용할 때 좌절하게 됩니다. 콘텐츠 제작자가 다국어 지원을 하지 않는 경우 다국어 지원 메뉴는 아예 보이지 않도록 처리해야 하는것이 인간의 생리와 문맥을 고려한 설계인데 이것은 문맥을 고려한 설계에 대한 다양한 문제 가운데 한 가지 예시일 뿐입니다.

또한 다국어환경 지원 문제는 다음과 같은 상황에서 매우 까다롭습니다. "A 카테고리에서 검색된 B 키워드가 C개 입니다" 라는 메시지를 출력한다고 가정할 때 이렇게 작성된 한글을 영어 또는 기타 외국어로 변환할 때 어순이 바뀌어야 하는데 저 문장은 A, B, C 를 포함한 6개의 변수로 작성되어 있고 언어 선택에 따라 어순이 바뀌도록 하는 것은 거의 불가능에 가깝기 때문에 실제로 저런 문장은 XE에서는 사용할 수가 없습니다. 이런 문제에 대해서 딱히 해법을 가진것은 아니지만 고민해 볼 필요는 있겠습니다. 다국어 환경 지원 때문에 인간이 쓰는 자연어를 오히려 사용하지 못하게 되는 것이 모순입니다.

맺음말

XE뿐만 아니라 모든 웹 개발자는 사용자 환경을 이해하기 어렵고 적절한 피드백을 받는것도 한계가 있기 때문에 사용자 경험에 대한 연구를 통해 직접 문제를 발견하고 해결해야 합니다. 사용자들은 자신들이 스스로 원하는 것을 모두 안다고 생각하지만 실제로는 그렇지 않으며 이슈트래커에 등록된 문제들은 실제 사용자들이 격는 문제의 20% 밖에 되지 않습니다. 인간의 생리를 이해하고 문맥을 고려한 설계를 통해서 사용자 스스로 자각하지 못했던 문제들에 대한 불편함을 개선해야 합니다. 사용자 경험은 UX 전문가들의 고유한 업무 영역이 아니라는 점도 상기해야 합니다. 모두에게 책임이 있다는 뜻입니다.

저는

1. 기대하고 예측한대로 작동하지 않는 기능은 두 번 다시 거들떠 보지도 않고
2. 전화기를 PC에 연결한다거나 부가 어플리케이션을 설치하는 것을 굉장히 귀찮아 하고
3. 기기 매뉴얼 따위를 읽어보는 것을 끔찍이도 싫어하는

상식적인(?) 사람입니다.

올 한 해동안 사용한 세 종류의 기기는 모두 그 특징이나 호불호가 뚜렷하게 갈리는 제품인데 가장 마지막에 구입한 블랙베리는 아이폰 따위를 잊어도 좋을만큼 제 기대에 충분히 부응하는 그런 스마트폰 이었습니다. oojoo님께서는 꿩 대신 닭이라는 표현을 쓰시던데 저는 닭 먹어보니 꿩 안먹어도 될 것 같습니다.

내가 스마트폰을 사용하는 이유.

제가 스마트폰을 사용하는 이유는 다음과 같습니다.

1. 웹을 통해서 읽고 쓰고 사람들과 소통합니다.
2. 인맥과 일정을 관리합니다.
3. 전화를 합니다.

다른 분들은 ‘음악을 듣는다. 게임기로 쓴다. 네비게이션으로 쓴다.’ 같은 더 많은 이유가 있던데요. 저는 단지 AUX(차량 외부 입력단자)에 연결해서 차 안에서 MP3를 들으면 참 좋겠다는 생각만 가지고 있을 뿐. 이것도 귀찮아서 언제 전화기에 MP3를 옮겨다 놓을지 모르겠습니다. 이쯤 되면 제가 어떤 스타일인지 눈치 채셨겠지요? 단순하고 무식하고 멍청한 스마트폰 사용자 입니다. 저와 비슷한 유형의 소비자들이라면 어떤 기준으로 스마트폰을 선택해야 하는지 약간은 조언을 드릴 수 있을 것 같습니다.

나의 스마트폰 선택 기준.

1. 웹을 브라우징 할 수 있어야 하고 웹과 무선으로 동기화 되어야 한다.
2. 매뉴얼을 읽지 않은 상태로 조작했을 때 기대한 대로 되어야 한다.
3. 꼭 필요한 어플리케이션은 이미 탑재되어 있어야 한다.
4. 반응 속도와 입력 속도가 빨라야 한다.

웹을 브라우징 할 수 있어야 하고 웹과 무선으로 동기화 되어야 한다.

WAP은 콘텐츠도 빈약하고 폐쇠적인데다가 시장도 정체되어 있어서 올해를 기점으로 이미 사양길로 접어들었다(T스토어 접속 웹이 46%로 가장 많음)고 생각 합니다. 저는 올 해 초부터 스마트폰에서 풀브라우징을 통해 웹을 사용하기 시작했고 지금은 전화기를 구매할 때 전화를 할 수 있는지 아닌지의 여부보다 ‘웹을 사용할 수 있는지 아닌지’를 더 중요한 선택 기준으로 생각합니다. 하루 중 약 2시간 가까이 모바일 기기로 웹 서핑을 합니다.

스마트폰을 사용하면서 만족했던 기능은 구글 싱크 였습니다. 구글 싱크를 한번이라도 제대로 사용해 보신 분이라면 다른 스마트폰을 구입할 때 구글 씽크의 지원을 받을 수 있는지 아닌지의 여부는 매우 중요한 구매 조건이 될 것입니다. ‘T*옴니아, 아이팟터치, 아이폰, 블랙베리’는 모두 구글 씽크가 지원하는 기기 입니다. 전화기를 바꿀 때마다 ‘주소록, 일정’ 따위를 옮기기 위하여 ‘전화기를 PC와 연결’하는것은 정말 짜증나는 일입니다. 구글 씽크는 간단하게 무선으로 웹 데이터를 스마트폰과 동기화 시켜 줍니다.

다행히도 올 한해동안 사용한 세 종류의 모바일 기기는 모두 ‘웹을 사용하고 동기화 할 수 있어 만족’ 했습니다.

메뉴얼을 읽지 않은 상태로 조작했을 때 기대한 대로 되어야 한다.

메뉴얼 없이 조작할 때 기대한 대로 되지 않는다는 것은 복잡한 UI를 잘못 설계했다는 의미 입니다.

이 기준으로 제가 사용했던 기기들을 줄을 세워보면 ‘T*옴니아 > 블랙베리 > 아이팟 터치’ 순입니다. T*옴니아는 정말 기능이 많고 조잡하며 예측 불가능한 UI가 많은데 아이팟 터치는 애플 제품이 대부분 그렇듯 매우 단순하고 직관적 입니다. 블랙베리는 단순하지는 않지만 UI를 효과적으로 설계해서 어렵다는 생각이 들지 않습니다. 기대한 대로 찾아가면 거기에 찾는게 있고 기능키도 PC에서 사용하던 것들을 연상해서 눌러보면 예측한 대로 동작해서 착착 감기는 맛이 있다고나 할까요.

이 부분에 대해서는 아이팟 터치를 통한 경험으로 미루어 볼 때 ‘아이폰’과 ‘블랙베리’에게 동등한 점수를 주고 싶지만 평소 PC에 익숙하지 않은 사람이라면 ‘아이폰’을 더 쉽다고 느낄 것입니다.

꼭 필요한 어플리케이션은 이미 탑재되어 있어야 한다.

토핑한다는 표현을 쓰죠. 어플리케이션 내려받아서 설치하고 사용하는 것을 즐거워하는 분들이 많은데 저는 그걸 굉장히 귀찮아 하고 약간의 거부감이 있습니다.

사실 이 부분은 어플리케이션 설치 UI와도 밀접하게 관련이 되어 있는데 어플 설치가 쉬우면 재미를 느끼지만 그 과정이 조잡하면 짜증이 납니다. 어플 설치할 때 보통 PC와 연결해야 하는 ‘T*옴니아’는 가장 짜증 스러웠고 ‘아이팟 터치’는 국가별로 제공하는 어플 목록이 달라서 해외 계정과 국내 계정을 오락가락 하려면 PC와 연결해야 하기 때문에 좀 번거롭지만 저 같은 사람에게도 토핑하는 재미를 주었으며 ‘블랙베리’는 한 마디로 토핑할 필요가 거의 없는 ‘있을건 있고 없을건 없는’ 폰 입니다. 딱히 대중적이지는 않지만 ‘스마트폰 구매자’가 찾을만한 웬만한 기능은 다 있다는 뜻입니다.

‘블랙베리’에서 제가 가장 감동했던 것은 ‘음성인식 콜’ 기능이고 그 다음은 ‘메신져(구글톡, MSN, 야후, AIM, ICQ …)’ 였는데 ‘음성인식’ 기능은 음성 녹음 없이 실시간으로 들리는 한국어 음성을 주소록에서 바로 찾아 전화를 걸어주는 기능 입니다. ‘우리집’ 이라는 단어를 녹음해야 하는줄 알고 불러봤는데 그냥 바로 전화가 걸려버려서 깜짝 놀랐지요.

반응 속도와 입력 속도가 빨라야 한다.

반응 속도를 결정하는 것은 운영체제이고, 입력 속도를 결정하는 것은 입력 인터페이스 입니다.

‘윈도우즈모바일’은 너무 느린데다가 ‘T*옴니아’의 ‘감압식 터치’ 방식은 임계치 이상의 압력을 주어야 하는데 사람의 감각이 그리 정확하지 않기 때문에 정확도가 떨어져서 제게 최악의 경험을 주었습니다. 게다가 ‘스타일러스 펜’은 넣고 빼기가 정말 귀찮고 걸리적 거립니다.  T*옴니아는 느리고 불편하고 정확하지 않았던 거죠.

아이팟 터치는 빠르고 ‘정전기식 터치’ 방식이라서 민감하게 반응했지만 QWERTY 키보드를 누르는것만큼 빠르고 정확하지는 않았습니다. 입력 지연 시간이 있고 엄지 손가락의 살점을 이용하기 때문에 QWERTY에 비하면 오타율이 높을 수 밖에 없습니다. 그러나 웹 브라우징시 ‘줌인/줌아웃’ 할 때 사용하는 ‘듀얼 터치’ 방식은 현존하는 방식 가운데 최고라고 생각합니다.

블랙베리는 자체 운영체제를 쓰고 있는데 거의 지연되는 상황이 없고 QWERTY 키보드는 입력 딜레이와 오타율이 적어서 모바일 기기에서 채용했을 때 가장 효과적인 입력방식 이라고 결론을 내렸습니다. 블랙베리의 트랙볼 조작은 화면을 직접 클릭하는 터치 방식보다 포인터 이동에 좀 더 시간이 걸리는 단점이 있지만 경쾌한 조작감을 줍니다.

결론. 블랙베리, 나의 스마트폰 선택 기준.

지극히 주관적이고 편향적이겠지만 제가 세운 기준에 따라 스스로 평가하고 내린 결론은 이렇습니다.

1. 웹을 브라우징 할 수 있어야 하고 웹과 무선으로 동기화 되어야 한다. = ‘T*옴니아, 아이팟 터치, 블랙베리’
2. 매뉴얼을 읽지 않은 상태로 조작했을 때 기대한 대로 되어야 한다. = ‘아이팟 터치, 블랙베리’
3. 꼭 필요한 어플리케이션은 이미 탑재되어 있어야 한다. = ‘블랙베리’
4. 반응 속도와 입력 속도가 빨라야 한다. = ‘블랙베리’

블랙베리의 한글 서체가 너무 마음에 들지 않는다는 분도 많이 계신데 저도 처음에 그렇게 생각 했었지만 지금은 생각이 바뀌었습니다. 서체는 마누라 얼굴 같다는 생각이 듭니다. 시간이 지나면서 못생긴 얼굴은 점점 이뻐 보이고 이쁜 얼굴은 그냥 그렇게 보입니다. 불편한게 아니라 단지 좋은 첫 인상을 주지 못할 뿐이죠. 사용하다 보면 어느 순간부터 아무렇지도 않고 점점 예쁘게 변하는것 같습니다.

오늘은 웹 전문가들 사이에서 필요로 하는 몇 가지 개념에 대한 이야기를 하려고 합니다. "저 친구는 사람은 좋은데 이 분야에 대한 개념이 좀 없더라구" 이런 소리를 듣지 않으려면 이 분야에서 쓰는 용어에 대한 개념 정도는 탑재를 하는게 좋겠지요. 차라리 "저 친구 네가지는 없는데 이 분야에 대한 개념은 있더라구" 라는 말을 듣는게 더 낫지 않겠습니까?

• "웹 2.0 서비스 구현을 위한 웹 표준."
• "ActiveX를 사용하면 접근성이 떨어진다."
• "1%를 위한 접근성 때문에 99% 사용자를 위한 사용성을 포기 하라구요?"
• "상호 운용성이나 호환성이나 뭐가 달라요?"
• "접근성이나 보편적 설계나 결국 같은 말 아닌가요?"

이런 개념 없는 대화의 주인공 속에는 저도 포함되어 있습니다. 제 블로그 포스트나 댓글에서도 찾을 수 있구요. 지금도 그다지 개념이 충만한것 같지는 않지만 멀리 떠난 개념 찾아 오늘 한번 떠나 보렵니다. 웹 개발자가 기본적인 소양으로 알아 두어야 할 개념 몇 가지를 소개하려고 하는데 사전적인 정의는 위키백과에서 참고하는 것을 더 권장 드립니다. 제가 소개하는 각 용어들의 개념은 백과 사전에는 없는 다소 주관적인 관점 입니다.

웹 표준

W3C는 웹이 상호 운용성(어떤 소프트웨어나 하드웨어에서도 접근 가능한 웹)을 갖는 것을 목표로 하고 있는데 이 때 상호 운용성을 확보할 수 있도록 주요한 수단으로써 제시하고 권고하고 있는 것이 바로 웹 표준 입니다. 여기서 흔히 발생하는 실수는 웹 표준 자체를 목표로 삼는 것입니다. 상호 운용성이라는 목표는 궁극의 가치로써 변하지 않는 것이고 변해서도 안되나 웹 표준이라는 수단은 상황에 따라서 적절히 변형하거나 포기하는등의 방법으로 현실에 임해야 하는데 수단을 목표로 삼게 되면 웹 표준에 고집스럽게 집착하게 됩니다. 단적으로 말해서 웹 표준에 집착하게 되면 정책 결정 과정에서 자칫 현실 감각을 잃고 원래의 목표인 상호 운용성을 포기해 버리는 우스운 상황도 발생하게 됩니다. 저는 웹 표준을 신뢰하고 웹이 표준에 기대는 방법으로 구현되어야 한다고 철썩같이 믿고 실무에 응용하며 지지하는 사람이지만 웹 표준이 현실을 반영하지 못하는 상황에서까지 웹 표준을 물고 늘어지고 싶지는 않습니다. 웹 표준을 이해하되 한계를 알고 표준 자체가 목표가 되어서는 안된다는 생각을 하고 있습니다.

또한 웹 2.0이라는 용어를 웹 표준과 함께 섞어 쓰는 표현은 요 몇해를 통틀어 가장 우스운 표현 가운데 하나라고 생각 합니다. 웹 표준은 웹 2.0 이라는 마케팅 용어가 등장하기 이전부터 이미 존재하는 개념인데 마치 웹 표준이  웹 2.0의 필수 요소이고 기술 스펙이며 트랜드가 된 것처럼 취급하는 문장이 만연 합니다. 웹 2.0 서비스라고 불리우는 웹 사이트들이 상호 운용성을 확보하기 위해 웹 표준에 기대는 경향이 있는 것은 사실이지만 웹 표준이 웹 2.0의 필수 요소도 아니고 웹 2.0 이라는 용어를 기술 스펙 처럼 이해하는 것도 문제라고 생각 합니다. 웹 2.0이 특정 기술 스펙을 요구하고 있다는 식으로 접근하는 것은 잘못된 현상이며 현재의 사회/문화적 측면을 해설하기 위해 창조된 용어로써 이해해야 한다는 겁니다. 좀 더 까칠하게 이야기 하면 웹 2.0 이라는 용어는 마케팅 수단에 불과하다는 생각도 가지고 있습니다.

웹 접근성

웹 접근성은 장애인이 웹을 이용할 수 있는 상태 또는 그것을 측정하는 개념 입니다. 하지만 W3C에서 조차도 이 개념을 이렇게 정의해 놓고 비 장애인들의 접근 환경을 아우르는 개념을 WCAG(Web Content Accessibility Guidelines) 지침에 추가로 언급 함으로써 웹 접근성의 개념 자체를 모호하게 만드는데 일조하고 있다고 생각 합니다. 저도 오랜시간 장애인이 아닌 사용자들의 접근환경을 측정할 때 웹 접근성이라는 개념을 사용해서 잘못된 지식을 전파하고 다녔습니다. 비록 그것이 결과적으로 긍정적이었을지는 모르지만 논란을 불러 일으킬 수 있는 표현이었음을 인정하지 않을 수 없습니다.

ActiveX와 같은 부가 애플리케이션이 비록 Microsoft에 종속된 기술로써 상호 운용성이 없을 지언정 접근성이 없다고 단언하는 등 잘못된 표현을 해왔던 것입니다. 웹 접근성은 장애인이 웹에 접근할 수 있는지를 측정하는 개념이기 때문에 장애인이 IE 브라우저를 통해서 ActiveX를 설치 및 실행할 수 있다면 그것은 자체적으로 웹 접근성을 확보한 상태이기 때문에 접근성이 없다는 표현은 틀린 표현 입니다.

비 장애인의 웹 접근에 관한 개념을 설명할 때에는 ‘상호 운용성, 호환성, 사용성’ 따위의 개념을 빌어 설명하거나 측정해야 합니다. 앞으로 웹 접근성이라는 개념을 사용할 때에는 그 중심에 ‘장애인’이 포함된 개념인지를 분명히 짚고 넘어가 주시기 바랍니다.

사용성

사용성은 효율과 효과를 측정하는 개념 입니다. 흔하게 발생하는 오해는 사용성이 비 장애인들만을 평가 대상으로 하고 있다는 점입니다. 하지만 사용성은 장애인들의 사용 효율과 효과를 측정할 때에도 필요한 개념으로써 사용성 자체는 장애인과 비 장애인을 구분하지 않습니다. 사용성이 비 장애인들의 효율과 효과를 측정하는 개념이라는 오해는 마우스와 같은 특정 입력 장치에만 인터렉션을 의존하도록 만들었습니다.

마우스 클릭 횟수를 줄이고 마우스 휠을 이용해서 탐색하는 방법을 도입함으로써 사용성을 높였다고 말하지만 왜 거기서 장애인과 키보드를 선호하는 고급 사용자는 제외되어야 하나요? 사용성은 그런 개념이 아닙니다. 일단 장애인도 접근할 수 있도록 구현해 놓고 그 안에서 다양한 유형의 사용자 패턴을 모두 고려해야 합니다. 신체 건강한 20~30대 성인 8명쯤 모아놓고 사용성 테스트 진행하면서 얻을 수 있는 결론만으로 웹의 만족도를 10% 증가 시켰다는 이야기는 키보드를 선호하는 사용자들 눈에 그들만의 잔치일 뿐입니다.

사용성 테스트가 뽑아내는 숫자 놀이에 ‘모든 사람의 만족’ 이라는 개념이 빠진것은 아닌지 점검해 봐야 한다고 생각 합니다.

상호 운용성 & 호환성

상호 운용성과 호환성이라는 용어는 사실 둘 중 어느 것을 선택 하더라도 개념 없다고 표현할 만큼 명백하게 구분되는 개념은 아닙니다. 하지만 한 가지 분명한 것은 상호 운용성은 소프트웨어와 하드웨어를 넘나드는 호환성을 지녔을 때 또는 그런 개념을 측정할 때 사용한다는 것이고 호환성은 특정 소프트웨어 또는 특정 하드웨어 안에서만 제한적으로 호환이 될 때에만 사용한다는 점이 다릅니다. 호환성이 있다고 표현할 수 있는 대표적인 기술은 ActiveX 이고 상호 운용성이 있다고 표현할 수 있는 기술은 HTML 정도가 되겠습니다.

만약 앞으로 이런 용어를 사용한다면 그것이 특정 하드웨어 또는 소프트웨어 안에서만 실행 가능한 것인지 하드웨어와 소프트웨어를 넘나드는 것인지를 분별해서 보다 정확한 용어를 사용해야 할 것입니다.

유니버설 디자인

웹 접근성이라는 개념의 중심에 ‘장애인’이 있었다면 유니버설 디자인의 중심에는 ‘모든 사람’이 있다는 점이 다릅니다. 유니버설 디자인은 설계에 있어서 장애인과 비 장애인을 구분하는 것을 금기하고 있으며 모든 사람이 되도록 동일한 방법으로 사용하고 동일한 만족을 얻을 수 있도록 개선하는 것에 초점을 맞추고 있습니다.

웹 접근성이나 사용성은 웹을 측정하는 개념으로써 주로 장애를 제거하거나 개선하기 위하여 사용되는 개념인 반면 유니버설 디자인은 철학 또는 이념으로 이해해야 합니다.

저는 웹 표준, 웹 접근성, 사용성과 같은 각각의 개념들이 모두 모여도 웹을 바르게 구현하는데 한계가 있고 서로 충돌하는 가치도 발생하기 때문에 그 한계를 극복하기 위한 철학으로써 이것이 필요하다고 주장하고 있습니다. 다소 추상적인 개념으로 다가올 수 있으나 유니버설 디자인은 보다 균형잡힌 시각을 길러주고 웹 개발의 궁극의 목표를 잃어버리지 않는데 도움이 될꺼라고 믿습니다.

대화의 기술

이런 주제로 결론을 맺는 것은 아직 세상 덜 살아본 저 자신에게 다소 부담스러운 주제이기도 한데요. 3학년이 되니까 선배랍시고 자꾸 2학년 후배들에게 잔소리를 하고 싶어지네요. 전문 분야에 대한 해박한 지식을 가지고도 대화의 기술이 부족해서 종종 트러블 메이커가 되거나 좋지 못한 평판을 받는 후배들을 응원하고 싶은 겁니다. 3학년 선배들도 2학년땐 그랬거든요.

한참 군생활 하던 시절에 소대 하사관이 "너희들 동그라미가 되고 싶은 세모의 마음을 아느냐" 라는 쌩뚱맞은 질문을 해서 참 실없다 하고 웃고 말았는데 그 질문이 살다보니 한 10년도 지나서 이해가 되더라구요. 지금은 모가 나서 잘 움직이지도 못하고 때로는 다른 사람에게 뾰족한 모서리로 상처를 주기도 하지만 동그라미가 되고 싶은 세모의 마음을 가끔씩 헤아려 봐 주세요.

블로그 포스트를 읽거나 미투데이를 사용하다 보면 다양한 분들의 이야기를 듣게 되는데요. 종종 반박의 여지를 남겨두지 않는 강한 표현들과 비난 수준의 비판이 심심치 않게 발견 됩니다. 부정적인 표현은 긍정적인 표현으로 바꾸는 연습도 해보세요. 욕이 고통을 감소시켜 준다는 실험결과도 있다고 하는데요. 욕을 듣는 사람의 입장을 배려하면 공공 장소에서 함부로 배설하지 않는게 에티켓 이겠죠.

대화의 기술은 나의 지식이 완전하지 않고 세상 속에서 타인들과 부대끼며 다듬어 질 필요가 있다는 것을 깨닫는 것으로부터 출발한다고 생각 합니다. 전문분야의 해박한 지식과 함께 네가지를 갖춘 UI 개발자가 되었으면 좋겠습니다. 일단 저부터 좀 되구요.

1. 문서형(DTD)을 꼭 선언해야 하나요?
2. 문서형(DTD)의 종류가 많던데 권장하는 것은 무엇입니까?
3. XHTML의 문법은 HTML과 비교해서 무엇이 다른가요?
4. HTML과 XHTML 가운데 어떤 문서형(DTD)을 사용하는 것이 좋을까요?
5. 문자셋(charset)으로 UTF-8을 권장하는 이유는 무엇인가요?
6. 휴먼 랭귀지(human language)가 무엇인가요?
7. 문서의 제목 <title>…</title>을 어떻게 작성하는것이 가장 좋을까요?
8. 의미론적 마크업(semantic markup)이란 무엇입니까?
9. 제목 요소 <hx>…</hx>는 어떻게 작성하는 것이 가장 좋을까요?
10. 의미론적 마크업을 잘 하는 방법이 있을까요?
11. 논리적인 순서란 어떤 것입니까?
12. 논리적 마크업을 위해서 화면 배치를 위한 <table>…</table>을 사용하지 않기로 했습니다. 이제 무엇으로 마크업 하나요?
13. 논리적인 마크업 예제를 한번 볼 수 있을까요?
14. 컬럼 구조 레이아웃을 위한 CSS 기법이 궁금합니다.
15. ‘id/class’ 선택자 사용 기준은 무엇이고 어떻게 네이밍 하는것이 좋을까요?
16. 이미지 대체 텍스트 속성 alt="*" 어떻게 작성하는 것이 가장 좋은가요? title="*" 속성과는 어떻게 다르죠?
17. 이미지에 포함된 텍스트의 양이 너무 많습니다. 어떻게 처리하죠?
18. 모두가 이용할 수 있는 longdesc 텍스트를 제공하고 싶습니다.
19. 웹 브라우저 호환성을 유지하기 위한 CSS 기법은 무엇이 있나요?
20. IR(Image Replacement) 기법이란 무엇입니까?
21. Image Sprite 기법이란 무엇입니까?
22. 동영상 대체 콘텐츠는 무엇이고 어떻게 처리해야 합니까?
23. 프레임셋 <frameset>…</frameset>의 문제는 무엇인가요?
24. 프레임셋 <frameset>…</frameset>을 사용한다면 무엇을 주의해야 하나요?
25. 서버와 데이터를 주고 받기 위해 내용 없는 빈 <iframe>…</iframe>을 사용하고 있습니다. 이런 빈 프레임에도 title="*" 속성을 이용해서 설명해야 하나요?
26. 모든 기능을 키보드로 이용할 수 있도록 하려면 무엇을 주의해야 하나요?
27. onclick과 onkeypress, onkeydown, onkeyup 이벤트 헨들러를 함께 사용하면 안되는 이유가 무엇입니까?
28. <a>…</a> 요소를 마크업 할 때 href 속성의 값으로 "#"을 사용하면 안되나요?
29. <button type="button">…</button> 요소의 의미와 사용법을 알려주세요.
30. <button type="button">…</button> 요소의 디자인을 CSS로 제어할 수 없나요?
31. CSS 기반의 가변폭 텍스트 버튼을 만들고 싶습니다.
32. 키보드의 논리적인 접근 순서를 위해 tabindex="*" 속성을 사용해도 될까요?
33. 건너뛰기 링크는 어떻게 구현하는 것이 가장 좋을까요?
34. 자바스크립트를 이용한 팝업 띄우기는 무엇이 문제인가요? 어떻게 하면 되죠?
35. 데이터 테이블 <table>…</table>을 의미있고 논리적으로 작성하는 방법은 무엇인가요?
36. 탭 메뉴 형태의 네비게이션은 무엇으로 어떻게 마크업 해야 합니까?
37. <label>…</label> 요소는 어떻게 사용하나요?
38. 플래시 <object>…</object> 네비게이션의 문제는 무엇인가요?
39. 겸손한 자바스크립트(Unobtrusive JavaScript)란 무엇입니까?
40. Ajax의 접근성 문제는 무엇입니까?
41. 시각 장애인을 위하여 CSS { display:none } 처리된 콘텐츠를 제공하는 것이 왜 나쁜가요?
42. CSS Framework이란 무엇 입니까?
43. 드림위버와 같은 위지윅(WYSIWYG) 도구는 웹 표준이나 접근성을 지원 하나요?
44. 드림위버는 너무 무거운 프로그램 아닌가요?
45. CSS 파일을 부를 때 <link />와 @import의 차이는 뭔가요? 어떤 방법이 더 좋죠?
46. 인쇄용 CSS를 어떻게 작성하는 것이 좋을까요?
47. IE 6 브라우저는 #id.class 다중 선택자 조합을 지원하지 않습니다.
48. IE 6 브라우저는 .class.class 다중 선택자 조합 일부를 지원하지 않습니다.
49. IE 6 브라우저는 float 처리된 요소의 margin을 두 배로 처리하는 버그가 있습니다.
50. IE 6~7 브라우저는 float된 요소의 문자를 복사하는 버그가 있습니다.
51. IE 6~7 브라우저는 float된 요소 주변에 등장하는 absolute 요소를 표시하지 않는 버그가 있습니다.

허걱 벌써 다 보셨나요? 저는 몇일 걸렸는데. ㅡㅡ;

‘세상에는 차별이 존재하고 우리들은 그런 사람들을 위해서 특별한 배려를 해왔지만 배려의 방법은 성숙하지 못했다. 다양한 지침들이 존재하지만 지침을 준수하는 것만으로는 여전히 풀리지 않는 문제 상황들을 만나기 때문에 그것을 해결해야 하는게 우리들의 과제다. 특별한 장애 유형을 위한 특별한 배려를 하지 말자. 장애를 구분하지 말고 은폐해야 한다. 이것이 유니버설 디자인의 철학이자 방법론이다.’

라는 메시지를 전달하려고 했었습니다. 여유있는 상황에서 작성한 것이 아니라(핑계) 정리가 좀 덜 된 느낌이고 이야기 전개가 매끄럽지도 못한것 같아서 보여드리기가 좀 부끄럽지만 혹시나 한 분이라도 잘 봐주시면 좋을것 같아서 공유하려고 합니다. 슬라이드 장수가 150여장 정도로 많지만 글자는 많지 않아서 약 15분 정도면 보실 수 있을것 같습니다. 프리젠테이션 버전, PDF 버전, TXT 버전.

PC에 과부하를 주는 문제가 있어 본문에 삽입했던 프리젠테이션을 제거 했습니다. 프리젠테이션 버전 링크를 이용해 주세요. 감사합니다.