본문으로 건너뛰기

웹 접근성에 대한 오해

Posted in IT/웹

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

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

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

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

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

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

항목 4.2 (별도 웹사이트 제공) 콘텐츠가 항목 1.1에서 4.1에 이르는 13개 검사 항목을 만족하도록 최대한 노력하였으나 해결되지 않는 부분이 남아있다면 텍스트만의 콘텐츠를 제공하는 웹 페이지(또는 웹사이트)를 별도로 제공해야 한다.
  1. 용어 정리
    1. 텍스트만의 콘텐츠(text-only contents)란 텍스트 아닌 콘텐츠가 포함되지 않고 텍스트로만 구성된 콘텐츠를 의미한다.
  2. 요구 조건
    1. 가능한 보조기술 수준이 미흡하여 장애인이 접근 가능한 웹 콘텐츠를 제작할 수 없는 경우에는 텍스트로만 구성된 대체 페이지를 마련하고 기존의 웹 콘텐츠의 첫 페이지에 대체 페이지로 이동하는 링크를 제공하여야 한다.
    2. 제공하는 대체 페이지는 기존의 웹 콘텐츠가 포함한 정보나 기능을 모두 포함하여야 한다.
    3. 제공하는 대체 페이지는 기존의 웹 콘텐츠의 개정 주기에 맞추어 개정되어야 한다.
  3. 적용시 장점
    1. 새로운 웹 콘텐츠 제작기술의 개발로 인하여 아무리 노력하여도 원래의 웹 콘텐츠에 포함된 일부 또는 모든 콘텐츠 요소들을 장애인의 접근이 가능한 콘텐츠로 수정할 수 없을 경우가 있다. 이 경우 대체 텍스트로 구성한 페이지를 별도로 구성하여 운영하면 장애인의 접근성이 충분히 지원된다.
  4. 적용 예
    1. 한글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에서는 이를 실현할 수 있도록 기술 표준안을 내놓고 있다.

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

무단 횡단을 하지 맙시다

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

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

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

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

이 글은 웹 접근성에 대한 오해(총 2편) 시리즈의 1번째 글입니다.

9 Comments

  1. 웹 기반 TTS(Text To Speech) 솔루션 백해무익….

    2009년 4월 11일 부로 ‘장애인차별금지 및 권리구제 등에 관한 법률‘ 이 공공기관 웹사이트에 적용되기 때문에 이에 대한 관심이 고조되고 있습니다. 웹 접근성 전문 교육을 받지 못했…

    2009년 6월 13일
    |Reply
  2. 웹 접근성에 대한 오해 2…

    이 글은 전에 작성했던 웹 접근성에 대한 오해 포스트의 답변에 대한 글입니다…….

    2009년 5월 11일
    |Reply
  3. Na!
    Na!

    찬명님의 비슷한 글을 먼저 읽고 덧글을 쓰고 왔습니다만. 이쪽은 덧글쓰기가 어렵군요. 논의가 생겨버려서.

    제가 보기에는 [추가되는 편의를 제공 방법]과 [장애물을 제거하여 원래 것을 그대로 전달]하자는 방법론의 차이에 대한 논의가 아닌가 합니다만.

    [추가되는 편의]가 사용자측에도 정말 편의가 될수 있는지에 대한 고민과 [전달하고자 하는 것]에 대한 이해가 선행되어야 논의가 진행될수 있지 않을까 합니다.

    뭐.. 딴이야기이지만.. 새해복 많이 받으십시요.. 남는건 저 주시면 됩니다.

    2009년 1월 2일
    |Reply
  4. 글을 쓴 원천 저작자입니다.

    맞습니다. 당사제품을 소개하기위한 의도로 글을 쓴것이 맞습니다. 하지만 글의 주 내용은 제 생각에 대해 적은 것이며 이또한 얼마든지 주장할 수 있다고 생각 합니다.

    웹사이트를 표준 또는 KWAG1.0에 맞추어 무조건 만들어야 한다고 주장하시는 분들은 공통점이 있는것 같습니다.

    1. TTS도구를 일방적으로 비난만 하고 있습니다. 답변)시각장애인이 사용하는 스크린리더도 TTS의 일종입니다. 서비스 형태가 서버기반의 TTS라는 점 이외에는 동일한 엔진을 사용하는 것으로 알고 있습니다. 제가 홍보한 제품은 단순히 TTS만 있는 제품이 아닙니다. Text기반 웹사이트를 구성해 주는 솔루션 입니다. 거기에 부가적 지원 방안으로 음성서비스 기능이 들어가 있는 형태 입니다.

    2. 웹접근성 지침에 대한 오해를 유도했다는 주장 가능한 보조기술 수준이 장애인 접근 가능한 웹 콘텐츠를 제작할 수 없는 경우가 얼마나 있을까? 답변)과연 우리나라의 보조기술 수준을 어느 정도로 평가하고 있는지 한번 물어보고 싶습니다. 아직 장애인용 보조기술은 세계적으로도 풀어야 할 숙제이고 기술의 진보와 함께 새로운 시도들이 계속 되고 있습니다. 언제까지 1999년에 제정된 WCAG1.0기준에 맞춰 사이트 제작을 해야 한다고 주장 할 겁니까? 해외 사이트들도 그렇게 하지 않습니다. 이미 WCAG2.0기준이 2004년 부터 초판이 나와 있고 2008년 드디어 최종안이 발표 되었습니다. 이미 노후한 과거의 규칙에 얽매이지 마십시오. 그렇게 사이트를 제작한다고 해서 실질적인 장애인 사용성이 얼마나 나아지는지 알고 있습니까? 또 그로인해 겪을 수 있는 사이트 주이용자인 일반인 들이 받아야 하는 심미적이거나 기능적인 요소의 역차별적 요소가 된다고 생각 하지 않습니까?

    3. RIA도 자체적인 접근성을 보장한다. 답변) 제가 얘기한 요지를 정확히 이해하지 못한 내용으로 판단 됩니다. KWAG1.0기준을 따르는 기존 접근성평가도구나 KADO의 품질인증 기준관점에서 RIA는 평가할 수 없고, 오히려 배제 요소에 해당한다는 것이 요지인 글 입니다. RIA가 자체적인 접근성을 보장한다는 건 잘 알고 있습니다. 심미적요소 혹은 기능적 요소로 활용되는 RIA에 대해 콘텐츠에 대해 접근성을 준수 하더라도 정확한 콘텐츠의 표현의 여부가 중요합니다.

    4. ActiveX는 웹이 아니다? 답변)저희 제품에 대해 오해가 있는 글인것 같군요. 저희 제품 기능중 TTS 제품은 다른TTS솔루션 과 달리 ActiveX 등 별도 프로그램 다운로드 방식이 아니고 서버에서 전송되는 음성 서비스 입니다. 타 TTS제품과 혼동 없으시기 바랍니다. 외국의 예를 드셨는데 서버기반 TTS전송은 네트워크 전송속도와 PC사양만 해결된 환경이라면 얼마든지 활용할 수 있는 좋은 기술이라 생각 합니다. 브로드밴드가 일반화된 국내 환경에선 충분한 활용도로 다양한 취약계층에 도움이 될 수 있는 서비스라 생각 합니다. 외국 역시 브로드밴드가 확산 되고 있는 추세 이기 때문에 향후 도입사례가 많이 나올게 분명 합니다. 당사 제품도 해외에 수출하지 못하리란 법이 없지 않습니까?

    5. 장애인용 웹사이트를 권장하지 않는 이유? 누가 권장하지 않는 다는 겁니까? 당신이 아니면 혹 누군가가? 당사 제품으로 제작되는 사이트는 홍보사이트도아니고 본래 사이트와 상이한 내용이나 업데이트가 이루어지지 않는 사이트 가 아닙니다. 동등한 콘텐츠를 텍스트형태로 동기화된 업데이트 기능을 제공합니다. 또한 음성, 글자확대/축소, 색약지원, 키보즈제어 등의 다양한 장애유형을 고려한 기능을 제공하는 Text형 홈페이지를 제공하는 제품 입니다.

    현재의 기술수준을 고려한다는게 어느시점의 고려인지 알고 싶습니다. KWAG2.0기준에 나와 있는 얘기를 잠깐 소개하지요. 인지성 세번째 조항 ‘1.3 정보와 구조 손실 없이 콘텐츠를 다른 방식(예를들면 더욱 간단한 형태로)들로 표현될 수 있어야 한다.’ 상세설명 ‘지침 [1.3 의향서] 이 가이드라인의 목적은 모든 정보가 모든 사용자에 의해 예를 들면 소리 또는 좀더 단순한 시각적 형태로 표시된 인지될 수 있는 형태로 사용가능한지 확인하는 것 입니다. 만약 모든 정보가 소프트웨어로 결정지어질 수 있는 형태가 가능하다면, 사용자에게 다른 방법들(시각적, 청각적, 촉각적 등)으로 표시될 수 있습니다.

    장애인용 이름을 달고 별개의 사이트가 존재한는것이 일종의 차별이라는 관점은 항상 나를 실소하게 만듭니다. 장애인용 화장실 과 장애인용 경사로, 장애인용 휠체어 이동기 등도 차별 입니까? 생각해 봅시다. 일반인과 차별을 하지말라는 것이지 분명한 차이가 있다는 점까지 무시할 수는 없는 겁니다.

    1. 링크 하나만 더 넣으면 되는데? 과연 장애인이 얼마나 빨리 반복네비게이션 링크를 찾을 수 있는지 알고 있는지 묻고 싶다. 또한 콘텐츠를 먼저 배치되도록 내용을 작성하고 네비게이션 위치는 CSS로 조정된 사이트의 예시가 있으면 누가 알려 주기 바란다.

    2. 웹접근성을 향상시키려면 웹표준을 지켜라? 상기에 지적한 WCAG2.0이 나왔다 확인해 보라. 내 얘기의 논점은 원천콘텐츠 접근성 준수가 더욱 중요하지 매번 개편되는 사이트 구조가 중요한건 아니라는 것이다. 기존적인 원천콘텐츠 준수가 필요없다는 얘기가 아니다 오해 없기 바란다. 웹호환성 문제는 KWCAG1.0의 근간이 되는 WCAG1.0기준에 분명히 나와 있다.

    3. 무단 횡단을 하지 맙시다. 횡단보도를 찾기위해 조금 더 걷는 과정이 필요하다… 작금의 상황은 횡단보도를 찾기위해 수십리, 수백리를 갈지도 모를 상황으로 판단 됩니다. 사이트는 개편됩니다. 1년, 2년만이든 사이트를 한번 잘만들고 수십년 사용할 수 있는게 아니라는 겁니다. 진화화는 웹기술과 트랜드에 맞춰 서비스 개편은 계속적으로 요구 된다는 겁니다. 현명한 대안책에 대한 판단은 여러분의 몫이라 고 봅니다.

    2008년 12월 30일
    |Reply
    • 좋은 의견 주셔서 감사합니다.

      오해를 피하기 위해서라도 한가지만 간단히 말씀드리자면,

      저는 해당 글 전체에 대한 반박을 한 것이 아니었고, 특정 부분만 인용하여 그 내용에 대한 반론을 폈습니다. 또한 “TTS 도구를 홍보하며 지침의 내용을 오해하게 만든다”라고 말했을 뿐이지 글의 의도가 TTS 도구 자체를 비난하는 것에 있지 않습니다.

      TTS 도구가 1급 시각장애인이 아닌 다른 분들께 도움이 될 수 있다는 바를 모르는 것이 아닙니다. 그러나 실질적으로 웹 사이트에 TTS를 설치하는 이유가 무엇인지를 생각한다면 대부분의 경우 웹 기반 TTS를 오용한다는 점을 부정할 수 없을 것이라 생각합니다. 솔루션의 대표 기능을 TTS인 것처럼 표현한 것은 제가 잘못한 점입니다. 사과드립니다.

      주신 의견에 대해 답변을 쓰다보니 너무 길어져서 별도의 포스팅을 할까 합니다. 글이 완성되는 대로 올리도록 하겠습니다.

      2008년 12월 30일
      |Reply
  5. 글 잘 읽었습니다^^ 크리스마스는 잘 보내셨어요~? 제가 오픈캐스트에서 소개한 글을 반박하신거네요 ㅎㅎ 오픈캐스트에서 소개하는 글들은 제 기준으로 ‘옳거나 그른’것을 구분하지 않고, 다양한 생각이나 의견, 다소간의 광고나 기업 입장이어도 소개를 하기로 정한 것이어서 올린거예요. 웹표준이나 접근성에 대한 사회적인 인식자체가 여전히 많이 부족한 것이 사실이기 때문에 많은 정보를 일반인에게도 노출하는 것 자체도 중요하다고 생각했거든요. 물론 지나친 광고는 피해가야겠죠^^ 지적 감사했구요. 저 덕분(?)에 좋은글 올리셨잖아요 ㅎㅎ 감사합니다~

    2008년 12월 27일
    |Reply

댓글 남기기