웹 접근성에 대한 오해

이 글은 특정 업체를 비방하기 위한 목적으로 작성된 것이 아님을 밝힙니다.

이 포스트들의 내용을 한마디로 요약하자면 현재의 국내 웹 사이트의 접근성을 향상 시키기 위해서는 우리 회사 제품을 쓰는 게 좋다고 말하고 있는 내용이다. 다분히 광고의 의도가 포함된 글이기에 이렇게 반박의 글을 쓰는게 우스운 모양새가 될지도 모르겠지만, 분명하게 짚고 넘어가야할 부분이 있어 키보드를 잡고 앉게되었다.

별도의 웹 사이트는 최후의 수단

위의 포스트에는 특정 TTS 도구를 홍보하면서 비전문가에게 웹 접근성 지침의 내용을 오해하도록 유도하고 있다.

KWAG1.0 기준에도 Text형 홈페이지를 제공하는 것은 장애인에게 웹접근성을 제공하는 효율적인 수단으로 준수 항목에 기재되어 있으며 실제로 장애인에게는 반드시 필요한 서비스 입니다.

물론, IWCAG 1.0의 제일 마지막 항목은 별도의 웹 사이트 제공에 대한 내용이며, 위의 해석이 아주 틀렸다고 볼 수는 없다. 다만 반드시 필요한 서비스가 아니라 조건적으로 필요한 서비스이다. 현재 웹 접근성에 관한 국내 지침인 IWCAG 1.0의 내용을 살펴보자.

항목 4.2 (별도 웹사이트 제공) 콘텐츠가 항목 1.1에서 4.1에 이르는 13개 검사 항목을 만족하도록 최대한 노력하였으나 해결되지 않는 부분이 남아있다면 텍스트만의 콘텐츠를 제공하는 웹 페이지(또는 웹사이트)를 별도로 제공해야 한다.

용어 정리

텍스트만의 콘텐츠(text-only contents)란 텍스트 아닌 콘텐츠가 포함되지 않고 텍스트로만 구성된 콘텐츠를 의미한다.

요구 조건

가능한 보조기술 수준이 미흡하여 장애인이 접근 가능한 웹 콘텐츠를 제작할 수 없는 경우에는 텍스트로만 구성된 대체 페이지를 마련하고 기존의 웹 콘텐츠의 첫 페이지에 대체 페이지로 이동하는 링크를 제공하여야 한다.

제공하는 대체 페이지는 기존의 웹 콘텐츠가 포함한 정보나 기능을 모두 포함하여야 한다.

제공하는 대체 페이지는 기존의 웹 콘텐츠의 개정 주기에 맞추어 개정되어야 한다.

적용시 장점

새로운 웹 콘텐츠 제작기술의 개발로 인하여 아무리 노력하여도 원래의 웹 콘텐츠에 포함된 일부 또는 모든 콘텐츠 요소들을 장애인의 접근이 가능한 콘텐츠로 수정할 수 없을 경우가 있다. 이 경우 대체 텍스트로 구성한 페이지를 별도로 구성하여 운영하면 장애인의 접근성이 충분히 지원된다.

적용 예

한글97 문서 : 별도의 웹 페이지로 구성
한글97로 작성된 문서를 콘텐츠로 제공하는 사이트의 경우, 스크린 리더를 통하여 한글97 문서를 읽을 수 없다. 이 경우에 동일한 내용을 별도의 HTML 문서로 제작하여 링크한다면 이러한 문제점이 해소된다.

여기서 우리가 주목할 것은 가능한 보조 기술 수준이 미흡하여 장애인 접근 가능한 웹 콘텐츠를 제작할 수 없는 경우라는 부분이다. 이는 새로운 웹 콘텐츠 제작기술의 개발로 인하여 아무리 노력하여도 원래의 웹 콘텐츠에 포함된 일부 또는 모든 콘텐츠 요소들을 장애인의 접근이 가능한 콘텐츠로 수정할 수 없을 경우라는 내용과 상통한다. 그러나 현재 우리가 웹에서 사용하는 기술 중에 자체적인 접근성을 보장할 수 없는 경우가 얼마나 있을까?

RIA도 자체적인 접근성을 보장한다

웹접근성 준수를 위해 웹표준을 준수하여 웹사이트를 개발하면 된다고 얘기들 하고 있지만, 정작 그러한지 몇 가지 사항들을 짚어 봅시다.

국내외 웹사이트는 UI개발이나 디자인 부분에서 신기술(플랙스, 플래쉬, 실버라이트 등)의 도입이 계속되고 이미지 등의 심미적인 영역 뿐만 아니라 정보를 제공하는 페이지의 역할까지 영역을 넓혀가고 있으며 이는 웹표준 준수와 상관없이 기존 관점의 웹접근성 보장이 어려운 환경을 초래하고 있습니다.

예를 들면 시각장애인이 플랙스나 플래쉬, 실버라이트 등으로 구성된 UI(User Interface)사이트에서는 스크린리더를 통해 읽을 수 있는 방법이 없습니다. 또한 웹접근성 평가툴로도 평가 할 수 없는 기준이라는 겁니다.

이렇게 접근성 향상을 위한 수단으로 웹 표준에 대한 비판을 하며 대안으로 별도의 텍스트 홈페이지 구축을 이야기한다. 물론, 텍스트 홈페이지 구축은 장애인 접근성의 측면에서 한가지 대안이 될 수 있다. 하지만, 플래시나 실버라이트 같은 RIA가 접근성 보장을 어렵게 한다는 것은 금시 초문이다. 실제로 Adobe에서는 Flash나 Flex에서 접근성을 향상시킬 수 있도록 가이드라인을 제공하고 있고, MS 역시 실버라이트에 UIA 기술을 채택하고 있다.

ActiveX는 웹이 아니다

물론, ActiveX가 웹 페이지를 통해서 제공되는 경우가 대부분이지만, 실제로 이는 Windows라는 운영체제를 기반으로 동작하는 어플리케이션이다. 기본적인 인터페이스 또한 앞에서 언급한바 있는 UIA를 따르고 있기에 운영체제에서 동작하는 스크린리더를 이용할 경우 내용을 인식하는 것이 가능하고, 키보드 컨트롤 역시 가능하다.

기술이 발전하는 이유는 더 효율적이고 편리한 것을 사용자에게 제공하기 위해서라 할 수 있다. 그리고, (안타깝게도) 외국에서 제작되는 대부분의 개발 도구는 접근성이라는 측면을 고려하여 만들어지고 있다. 우리가 기간에 그 도구를 제대로 쓰지 못했기 때문에 야기된 문제를 또 다른 도구로 해결하려는 것은 나중에 더 많은 작업을 요구하는 일이라는 것이다.

장애인용 웹 사이트를 권장하지 않는 이유

기간의 정부기관이나 공공기관 사이트를 보면 장애인이라는 이름을 달고 별도의 웹 사이트를 제공하는 경우가 있다. 이런 경우에는 크게 두가지 패턴이 있는데, 첫째는 대부분 해당 기관에서 장애인을 위해서 어떤 일을 하고 있는지를 다루고 있는 홍보 사이트였다. 둘째로는 장애인이 이용할 수 있도록 하는 텍스트 사이트였는데 대부분 본래의 사이트와는 상이한 내용을 다루거나 같은 내용을 다루더라도 업데이트가 함께 이루어지지 않는 문제가 있었다.

웹 접근성 전문가들이 장애인용 웹 사이트를 권장하지 않는 것에는 위와 같은 이유도 있지만, 현재의 기술 수준을 고려했을 때 별도의 웹 사이트를 제작해야할만큼 접근성을 보장할 수 없을만한 신기술이 없다고 보기 때문이다. 또한 별도의 웹 사이트를 구축하기 위한 시간과 노력, 비용을 고려한다면 오히려 하나의 사이트로 모든 사람이 이용 가능하도록 만드는 것이 더 효율적이라 할 수 있기 때문이다.

하나 덧붙인다면, 장애인용이라는 이름을 달고 별개의 사이트가 존재하는 것 자체가 일종의 차별이 아닐까.

링크 하나만 더 넣으면 되는데

일반적으로 홈페이지는 표현과 내용이 결합된 형태로 서비스 되는 게 일반적인 홈페이지 입니다. 이걸 분리해서 홈페이지를 만든다고 해도 장애인이 스크린 리더를 통해 표현부분(디자인이나 네비게이션 부분)을 거쳐 내용(콘텐츠)에 도달하는 데는 많은 노력과 시간이 소요 되는 게 현실입니다.

따라서 홈페이지의 내용에 직접적으로 도달할 수 있는 다시 말해 일반인을 위한 불필요한 표현요소를 제거한 내용만을 직접적으로 전달해 줄 수 있는 별도의 홈페이지가 있다면 장애인이나 정보취약계층이 일반인과 같은 수준으로 손쉽게 콘텐츠에 도달 할 수 있는 것 입니다.

웹 표준에서 말하는 구조와 표현의 분리를 내용과 표현의 분리로 이야기하고 있는데, 먼저 이 내용에서는 표현이라는 단어를 오해하고 있다고 말하고 싶다. 웹 사이트를 편리하게 사용하기 위해서 제공되는 메뉴는 그 자체가 표현을 위해서 존재하는 것이 아니며, 웹 페이지의 내용 중 일부분이다.

또한, 지침의 항목 2.5 (반복 네비게이션 링크(repetitive navigation link))에는 내용만을 직접적으로 전달하는 것보다 웹 페이지의 내용으로 직접 이동할 수 있는 링크를 제공할 것을 규정하고 있다. 원하는 콘텐츠에 접근하기 위해서 반복적인 키보드 컨트롤을 하지 않도록 하려면, 네비게이션을 건너뛰는 링크(Skip Navigation link)를 제공하는 것으로 충분하다. 이것이 싫으면 콘텐츠가 먼저 배치되도록 내용을 작성하고 네비게이션의 위치는 CSS로 조정해줄 수도 있다.

웹 접근성을 향상 시키려면 웹 표준을 지켜라?

국내 웹접근성 지침을 준수하려면 기존 웹사이트의 이미지나 플래쉬에 대체텍스트를 넣은 방법 이외에도 테이블명 등을 상세히 기입해 주어야 하며, 스크린리더에서 장애인이 원할 히 콘텐츠를 취득하려면 사이트 구조 설계 시 본문 이외에도 전체적인 메뉴체계 등이 포함 된 영역까지 네비게이션 규칙이 준수된 CSS구조로 변경을 해 줘야 한다, 또한 저시력자, 노인 등을 위한 글자확대, 축소, 색약관련 색상변경기능 등의 적용이 가능하도록 설계되어야 하며, 다용한 브라우저사용자를 고려하여 익스플로어, 파이어폭스 등의 크로스 브라우징에 맞추어 사이트를 구축하여야 한다. 이와 같이 웹접근성을 준수하며 웹사이트를 구축하고 관리하기위한 수많은 노력과 그에 따른 비용이 발생 된다.

인용한 글의 요지는 현재까지의 개발 방식을 고려했을 때 웹 접근성을 지키려면 너무 많은 비용과 시간과 노력이 들어간다는 점이다. 물론 현실적으로 이런 문제들은 분명히 존재한다. 아직까지 웹 접근성이 뭔지도 모르는 사람도 여전히 많고, 이를 지키는 방법을 강구하기 위해 많은 노력이 이루어지고 있다. 그렇다고 해서 이런 과정을 빼고 특정 요소를 대체할 솔루션을 도입한다면 웹 사이트는 이후에 더 복잡한 유지보수 과정과 이를 위한 비용을 필요로하게 될 것이다.

웹 접근성 지침에서는 웹 표준을 이용하여 웹 사이트 전반을 구축하길 희망하지만 그렇다고 해서 배치용 테이블(layout table)과 같이 비표준적인 요소를 완전히 배제하지 않는다. 이는 코드 자체가 어떻게 쓰이든 접근가능성(Accessibility)에 더 무게를 두기 때문이다. 웹 접근성 향상을 위해서 웹 표준 준수를 요구하는 것은 그것이 가장 좋은 방법이기 때문이다. 웹 표준이 가져다주는 이익에 대해 여기서는 따로 언급하지 않겠다. 다만, IWCAG는 WCAG를 근간으로 하고 있고 W3C에서는 이를 실현할 수 있도록 기술 표준안을 내놓고 있다.

별도로 한가지 지적하고 싶은 것은 웹 접근성과 관계없는 내용이 거론되고 있다는 점이다. 다용한 브라우저사용자를 고려하여 익스플로어, 파이어폭스 등의 크로스 브라우징에 맞추어 사이트를 구축하여야 한다라는 내용은 지침의 어디에도 나와있지 않다. 크로스브라우징은 웹 표준을 지켰을 때 얻을 수 있는 부가적인 효과일 수는 있어도 접근성 지침이 보장을 바라는 내용은 아니다.

무단 횡단을 하지 맙시다

웹 접근성 전문 교육 때도 한번씩 언급했던 내용이지만, 장차법은 도로교통법과 비슷한 점이 있다. 무단 횡단을 해도 경관에게 걸리지 않으면 넘어가듯이 웹 접근성 지키지 않아도 걸리지만 않으면 된다. 그렇다고 몰래 무단횡단을 하라는 이야기는 아니지 않은가. 무단횡단하지 않으려고 횡단보도를 들고다닐 수는 없는 노릇이다. 횡단 보도를 찾기 위해서 조금 더 걷는 과정은 필요하다는 이야기다.

더 많은 노력이 필요한 상황일지라도, 사이트를 한번 잘 만들어두면 유지보수도 수월해질 수 있고 누구나 웹 사이트를 무리없이 쓸 수 있게 된다. 지금 힘들다고 길을 가로지를 생각보다는 장기적인 관점에서 사이트 제작을 준비하려는 자세를 요구하고 싶다.

무엇보다도, 규칙은 피하라고 있는 것이 아니라 지키라고 있는 것이다. 이 점을 잊지말자.

정찬명님께서 비슷한 내용의 글을 하나 올려주셨습니다.