본문 바로가기

내문서

[접근성] RIA가 웹을 불필요한 제약으로 만들고 있나요

반응형
RIA가 웹을 불필요한 제약으로 만들고 있나요
월간 마이크로소프트웨어 2008년 7월호

지난 4월 11일 장애인차별금지법이 발효되었다. 내용 중에서 ‘정보접근 및 의사소통에 대한 차별 금지’ 조항으로 ‘공공기관 등이 배포하는 정보에 접근함에 있어 장애를 이유로 차별되어서는 안되며 또한 장애인의 장애 특성에 맞추어 수화나 문자 등의 정보이용 및 의사소통에 필요한 수단을 제공해야 한다. 라고 규정하고 있다. 하지만 대부분의 국내에서 웹서비스를 제공하는 사업자들은 이러한 규정에 대하여 모르거나 무관심한 것으로 나타나고 있다고 한다. 시행령 또한 웹 접근성에 대한 의무 시점을 2009년부터 순차적으로 하도록 되어 있어서 직접적인 행동으로 이끌어내기에는 부족함이 많이 있다.
최근 기업 내 인트라넷 또는 임원정보 시스템을 중심으로 RIA 로의 시스템 전환에 대한 요구가 많은데 이러한 과정에서 기업 내 장애인들에 대한 배려는 더욱이 이루어지지 않고 있다. 시각적인 화려함만을 요구하고 사용자의 요구에 맞게 설계, 구현이 진행되다 보니 인식을 달리하면 누구나 정보에 접근할 수 있도록 할 수 있음에도 불구하고 그러한 부분을 외면하고 있다.

2000년도에 출판된 ‘Designing the User Experience’을 보면 다음과 같은 설명이 있다. ‘네비게이션 항목과 같은 중요한 컨텐츠는 Internet Explorer 2.0에서 볼 수 없는 Flash movie 나 Javascript 와 같은 기술은 사용하지 말아야 한다. 이미지도 마찬가지이다. Alt 태그 없이 컨텐츠를 사용하여 이미지를 지원하지 않는 특정 브라우저를 사용하고 있는 사용자는 컨텐츠를 볼 수 없도록 하는 것도 불필요한 제약이다.’
얼마 전까지만 해도 브라우저시장은 지금은 역사 속으로 사라져버린 넷스케이프(Netscape)가 주된 브라우저였고 IE 는 특정기술을 지원하지 못하는 브라우저였던 적이 있었다. 그리고 마지막 문장에 불필요한 제약이다라는 말이 이번 주제에 적절한 표현인 것 같다. 건물을 지을 때 미관상의 문제로 문을 만들지 않는다고 한다면 정상적인 건물로 인정하지 않을 것이고 허가조차 나지 않을 것이다. 또한 비상구나 화재시설등 비상시에 대처할 수 있는 설계를 의무화하고 있다. 하지만 웹에서는 이러한 설계구조는 고사하고 문을 찾아 들어가는 것조차 힘들게 만들어진 곳을 수시로 만나게 된다.
최근 크로스 플랫폼(Cross-Platform), 크로스브라우징(Cross-Browsing) 에 대한 관심이 많아지고 있어 여러 기술적인 내용이나 관련된 서적 등을 통하여 많은 내용들이 이야기되고 있고 실제 사이트 개발 시에 파이어폭스(Firefox)에서는 사이트에 깨지거나 네비게이션에 불편함이 없도록 신경 쓰는 사이트들이 늘어나고 있다. 하지만 여전히 오페라(opera)나 사파리(safari) 등 다른 브라우저에서는 깨지는 사이트들이 많으며 국내 사이트의 경우에는 액티브X 설치를 하여야만 사이트 접근이 가능한 경우가 많이 있어서 크로스브라우징 이슈조차 머나먼 이야기가 되어가고 있다.(대표적인 예로 요즘에는 통합된 하나의 사이트에서 관리가 되지만 얼마전까지만 해도 연말정산 한번 하고 나면 PC를 포맷할 지경에 이르고는 했다. Flex 로 개발되는 사이트 역시 다른 부가적인 인증이나 기능 때문에 IE 전용 웹사이트가 되어버리는 경우를 많이 보고 있다.)

접근성이라는 것이 무엇인가요

접근성(Accessibility)이라는 단어에 대하여 위키백과에 정의된 내용을 보면(http://ko.wikipedia.org) ‘산업디자인, 사용자 인터페이스 디자인, 건축, 시스템 공학, 인간공학 등의 분야에서 쓰이는 용어로, 사용자의 신체적 특성이나 지역, 성별, 나이, 지식수준, 기술, 체험과 같은 제한 사항을 고려하여 가능한 많은 사용자가 불편 없이 이용할 수 있도록 제품, 서비스를 만들어 제공하고 이를 평가할 때 쓰이는 말이다’ 라고 정의하고 있다. 웹의 창시자로 알려진 팀 버너스 리는 ‘웹의 힘은 그 광범위함에 있다. 장애에 관계없이 모든 사람이 접근할 수 있다는 것이 절대적인 장점이다.(The power of the web is in its universality. Access by everyone regardless of disability is an essential aspect.) “라고 이야기하고 있다. 태생적으로 웹이라는 것은 누구나 접근할 수 있는 가능성을 가지고 있다는 것이다. 하지만 변질된 기술의 발달이 이러한 접근성을 오히려 막고 있는 불필요한 제약이 되고 있다는 것이다. 얼마 전 아이뉴스24(http://www.inews24.com)에서는 ‘웹 접근성을 높이자’ 라는 제목의 기사가 연재되었다. 내용을 보면 198개 조사대상국가중에서 세계 전자정부 평가는 1위를 차지하면서 웹접근성 부분에서는 43위로 크게 미흡한 수준이라고 보도되었다. 또한 장애인의 인터넷 이용률은 50%에도 미치지 못하는 결과가 나왔는데 그만큼 인터넷을 이용하는 것 자체에 장벽이 많다는 것이다. 2005년도의 세계보건기구의 자료에 의하면 전 세계 인구 중 1/6 정도가 일정 수준의 언어, 시각, 행동, 청각, 인지 장애를 가지고 있다고 발표한 바 있다고 한다. 또한 인구의 고령화로 인하여 보조공학(Assistive Technology) 산업은 점점 큰 규모로 성장해가고 있다. 기술의 힘은 부정적인 면에서 본다면 세대간의 격차를 커지게 하고 정보에 대한 차별적인 접근을 하게 하는 측면이 있지만 반대로 기술의 힘을 빌려 삶을 되찾을 수도 있다는 의미를 가진다. 장애인 차별금지법에서는 2015년까지는 대부분의 민간기업이 장애인들의 웹 접근성을 보장해야 한다고 규정하고 있다. 한국정보문화진흥원의 조사에 따르면 웹개발자나 홈페이지 관리가 300명중에서 웹접근성이라는 용어에 대하여 들어본적이 없다라는 응답이 전체의 74% 였다고 한다. 물론 4월 시행령 발표 이후 언론등에서 여러번 반복된 기사가 올라오기 때문에 조금은 인식이 달라졌을 수 있겠지만 여전히 부족한 부분이 많다. 좀 더 효율적인 개발방법을 지금부터 고민하고 실천하지 않는다면 법적인 피해를 입을 수도 있고 또 다가오는 많은 기회들을 그냥 놓치는 일이 될 수 도 있다.

일상 속에서의 접근성

스크린 리딩 소프트웨어인 JAWS를 설치하고 웹사이트를 브라우저를 통해 방문하게 되면 해당 웹페이지에 기록되어있는 정보를 읽어준다. 시각장애인의 경우 마우스를 사용하지 않고 대부분의 작업을 키보드를 통해 정보를 조회하게 된다. 웹사이트의 첫 번째 대문에서 어떻게 안내해주는가에 따라 정보를 그만큼 쉽게 획득할 수 있게 된다. 어도비 웹사이트에 가보면 탭(Tab)키를 통해 첫 번째 만나는 메뉴가 접근성에 관련된 항목이다. 화면에는 해당 메뉴가 보이지 않지만 첫 번째 탭에서 접근성 관련 설정 항목(Accessibility on Adobe.com)으로 이동하게 하여 HTML 만으로 정보를 볼 것인지 Flash를 포함한 상태로 볼 것인지 등의 항목을 선택하게 된다.

<a href="/help/accessibility.html" tabindex="1" id="accesslink">Accessibility</a>

화면에 보이지도 않는 한 줄의 코드이지만 스크린 리딩 소프트웨어를 사용할 때에는 좀 더 쉽게 정보를 찾을 수 있도록 도와준다. PDF 문서를 읽기 위한 어도비 리더의 경우에도 최초 보조 기술을 사용하는 경우에 자동으로 감지하여 접근성 관련 설정 도우미를 동작하도록 한다. 설정한 옵션은 이후 동일한 PC 에 적용되어 사용자가 보조 기술을 적절하게 활용할 수 있도록 지원하여 준다.

<그림 1 : 어도비 리더에서 접근성 설정 도우미>

<그림 1 : 어도비 리더에서 접근성 설정 도우미>


이러한 일련의 기술을 보조공학이라고 하는데 소프트웨어뿐만 아니라 하드웨어부분까지 생각하지 못한 다양한 부분에서 사용성을 지원하는 기기들이 개발되고 있다. 한국장애인고용촉진공단의 보조공학센터를 방문해보면 관련기기들에 대한 정보를 조회해볼 수 있다. 평소에 관심을 가지고 있지 않았다면 이런 기기들이 있다는 것에 대하여 놀라움을 가질 것이다. 이러한 기기들을 개발할 때에는 표준적인 기술기반으로 작업이 진행될 것이다. 웹이나 응용프로그램부분에서도 여러 업체들이 연합하여 표준을 만들고 해당 표준을 통해 프로그램이 개발될 수 있도록 지원하고 있다. 물론 개발 역할에 있어서 어느 쪽에서 코드를 분석하여 접근하여야 하느냐 라는 논쟁이 있기도 하지만 개발 프로세스를 표준화할 수 있다면 그리 어려운 해결책은 아닐 것이다.
Daum(http://www.daum.net/) 에서는 UI 개발직군중 웹접근성 향상을 위한 그룹으로 IWA(Improve Web Accessibility) TFT를 운영하고 있다고 한다. 그리고 최근 개발되는 사이트들은 웹표준을 지켜 코드에 반영하고 있어 향후 접근성 등의 작업을 용이하게 설계하고 있다고 한다. 이러한 노력들이 개발자들이 공감할 수 있는 부분으로 확대되고 많은 사례를 만들어내는 것이 중요할 것이다.

RIA 에서의 접근성

국내의 웹 접근성에 있어서 애니메이션이나 플래시를 사용하는 사이트들은 접근하기 어렵다 라는 생각과 개발하는 쪽에서도 사용자를 제한하고 개발하는 경향이 있는 것 같다. 뿐만 아니라 Ajax 와 같은 기술도 이러한 부분에서 공공의 적이 되어버린다. 플래시와 Ajax를 같이 사용한 웹 응용프로그램에서 국내 스크린 리더기 테스트 결과를 보면 결코 이와 같은 기술이 접근성에 제한만을 가하지는 않는 것이라는 것을 알 수 있다.(http://www.diakonia.co.kr/swf/mgbook.html) 일단 플래시와 같은 콘텐츠가 포함된 화면을 접하게 되는 경우 기술적으로 플래시 내에서 처리되는 부분 이전에 플래시 자체를 사용할 수 없는 환경이라면 어떻게 처리할 것인지에 대한 대안을 고민하여야 할 것이다. 그 대안으로는 동등한 대체 콘텐츠를 제공하는 것이다. 위에서 언급한 어도비 웹사이트에서 플래시를 제외한 HTML 콘텐츠를 우선적으로 선택할 수 있는 것이 그 대표적인 예가 될 것이다. 6월 달에 진행된 리믹스행사 안내페이지(http://www.visitmix.co.kr/)를 보면 실버라이트로 제작되어있지만 실버라이트 콘텐츠를 볼 수 없는 브라우저 환경에서도 행사에 대한 안내와 신청을 할 수 있는 페이지를 기본적으로 제공하고 있다. 특히 국내 스크린리더 프로그램 같은 경우에는 MSAA를 지원하지 못하는 경우도 있기 때문에 대체 텍스트 제공이 기본적인 접근성을 위해 필요한 부분이 되겠다.

<그림 2 : 리믹스 행사 안내 페이지>

<그림 2 : 리믹스 행사 안내 페이지>


전체페이지를 플래시와 같은 콘텐츠로 구성하였을 경우라면 위와 같이 대체할 별도의 콘텐츠를 마련해야 할 것이고 날짜표기와 같은 특정 영역에 반영되는 경우에는 충분하게 대체 텍스트를 통하여 동일한 정보를 제공할 수 있다.
아래에서 언급할 MSAA 같은 경우는 OS 에 의존적인 부분이라 태생적인 한계를 가지고 있으나 Ajax 나 자바스크립트 뿐 아니라 MSAA를 지원하는 여타 RIA 관련 제품군에서 사용이 가능하다는 장점을 가지고 있다. 그리고 이러한 문제를 해결하기 위한 대안으로 UIA 나 IAccessible2 와 같은 API 들이 제안되고 있다.
어도비 플렉스, 오픈라즐로, 마이크로소프트 실버라이트 3가지 제품은 공통적으로 MSAA(Microsoft Active Accessibility)를 지원한다. 플렉스와 오픈라즐로는 플래시 플레이어를 기준으로 관련 기능이 구현되었고 실버라이트는 1.0 에서는 MSAA를 지원하며 2.0 에서부터는 UIA(User Interface Automation) 를 지원하게 된다. 마이크로소프트에서는 시각, 청각 등으로 불편한 사용자가 응용프로그램을 사용할 수 있도록 하는 접근성에 대하여 두 가지 방법을 제공하고 있다. 그 중 하나는 윈도우 시스템에서 고대비 옵션을 사용하는 것이다. 고대비(high contrast) 라는 것은 흑백과 같이 대비차가 매우 크도록 조정하여 화면에 표시하도록 하는 방식이다. 색각(색맹, 색약) 이상자의 경우에도 정보에 혼동을 일으키지 않게 되고 저 시력의 사용자에게도 충분한 명암대비가 되도록 지원하여 내용을 인지할 수 있도록 한다. 윈도우 제어판에서 해당 설정을 바꾸어 사용할 수 있으며 어도비 리더와 같은 소프트웨어에서는 자체적인 고대비 기능을 제공하기도 한다. 두 번째 방법이 앞에서 이야기했던 MSAA 이다. 기본적으로 윈도우 프로그래밍을 하는 경우 Win32 가 제공하는 기본 컨트롤을 사용하여 작업하는 경우에는 이미 관련된 인터페이스가 구현되어 있으며 컨트롤을 직접 구현하는 경우에는 MSAA를 함께 구현하여야 한다고 한다. MSAA 에 관련된 자료가 국내에 소개된 내용은 많지 않지만 각 프로그램 매뉴얼과 'Introduction To Microsoft Active Accessibility‘ 는 기본적인 내용을 이해하는데 많은 도움이 될 것이다. 실버라이트 2부터 지원된다는 UIA 는 올해 1월 장애인의 인터넷 접근성을 향상시키는 제품 제작에 도움이 되는 개발자들 위한 툴인 UIA를 로열티 없이 이용할 수 있도록 하였고 이 툴로 개발되는 모든 응용프로그램은 플랫폼에 상관없이 사용할 수 있도록 공개하였다. 마이크로소프트의 목표는 음성인식 소프트웨어나 화면낭독 소프트웨어의 표준 책정을 목표로 하고 있지만 아직 쉬운 단계는 아닌 듯 보인다. 4월에 진행된 ’웹 접근성 세미나‘ 에 참석하였던 로버트 싱클레어 마이크로 소프트 접근성사업본부장은 UIA 에 대하여 기업이 낮은 비용으로 접근성이 향상된 양질의 제품을 손쉽게 개발할 수 있다고 소개하였다. UIA 는 AIA(Accessibility Interoperatibility Alliance) 에 기증되었으며 AIA 는 어도비, HP, 마이크로소프트, 오라클 등의 기업이 참여하고 있으며 국내업체들도 포함되어 있다고 한다.
그리고 IBM 에서도 IAccessible2 라는 스펙을 공개하였다. 오픈오피스제품군에 해당 스펙을 구현하여 시각장애인들이 ODF(Open Document Format) 문서에 쉽게 접근할 수 있도록 하였다고 한다. 그리고 어도비 리더의 경우에도 9버전부터는 해당 스펙을 지원한다고 한다.

플렉스에도 접근성을 적용할 수 있을까요

플래시는 일반적으로 html 과 같이 직접 접근할 수 있는 형태의 자원이 아니기 때문에 스크린리더기에서도 취약한 부분이 있을 것이라는 선입관을 가지기 쉽다. 하지만 플래시 MX부터 Accessibility 라는 클래스를 제공하여 스크린리더를 지원하도록 해주고 있다. 플렉스에서도 동일한 형식으로 접근하게 된다. 플렉스에서의 접근성 설정은 기본값은 아니지만 개발 툴인 플렉스 빌더를 사용하는 경우 프로젝트 속성에서 체크박스 하나로 설정을 변경할 수 있도록 지원하고 있다.
아래와 같이 테스트를 해보자.
플렉스 빌더에서 프로젝트를 하나 선택하고 파일(File) 메뉴에서 속성(Properties)창을 띄우고 Flex Compiler 설정을 확인한다. 컴파일러 옵션(Compiler options)에서 접근성 있는 SWF 파일 생성하기(Generate accessible SWF file)이 체크되어있지 않은 것을 확인하고 체크를 해주면 일단 기본적인 준비는 끝나는 것이다.
간단한 입력 폼을 만들어 주었을 때 약 78KB 정도의 크기의 swf 파일이 생성된다.(플렉스 빌더 3에서 RSL을 적용하여 컴파일 하였다) 그럼 접근성 관련 설정을 하고 나면 파일의 크기가 어떻게 달라질까. 약 79KB 정도로 거의 파일 사이즈에서는 달라진 것을 느끼지 못한다. 컴파일러 옵션 중에서 -keep-generated-actionscript 이라는 추가적인 옵션을 지정해주면 실제 Flex 로 코딩한 내용이 swf 로 컴파일 되기 전에 생성되어지는 액션스크립트 파일을 확인해볼 수 있다. 내용을 비교해보면 실제는 1개의 파일이 변경된 것을 확인해볼 수 있다.(추가적으로 다른 파일들이 있지만 생성시간등의 주석부분 때문에 다르게 보이는 것뿐이다)

<그림 3 : 플렉스 빌더 접근성 설정화면>

<그림 3 : 플렉스 빌더 접근성 설정화면>


<그림 4 : 접근성 적용후 컴파일 결과 비교화면>

<그림 4 : 접근성 적용후 컴파일 결과 비교화면>


(파일명)_FlexInit-generated.as 파일이 수정되어진 파일이다.
내용을 보면 mx.accessibility 관련된 클래스가 추가되었고 조건이 만족되면 각각 UI 컴포넌트 관련된 접근성 설정을 활성화시키는 내용이 추가되어져 컴파일 된 것을 확인할 수 있다. 코드길이를 극한까지 줄이는 숏코딩(short coding)을 목표로 하지 않는다면 수용할 만한 변경내용인 것이다. 플렉스 빌더를 사용하지 않을 때에는 아래와 같은 형식으로 설정이 가능하다. 각 컴포넌트에 대하여 1KB정도의 추가적인 코드가 들어가게 된다.











 컴파일 형식
 접근성 환경 설정 방법










 직접호출시
 아래와 같이 url 에 파라미터를 추가한다.
http://www.imaso.co.kr/flex/index.mxml?accessible=true










 설정파일 변경  flex-config.xml 파일의 <accessible> 항목을 true 로 변경한다.
<mxml-compiler>
   <accessible>true</accessible>
</mxml-compiler>










 mxmlc
컴파일러 사용
 mxmlc -accessible c:/dev/imaso/appl.mxml
mxmlc –compiler.accessible c:/dev/imaso/viewer.mxml

<표 1: 접근성 관련 컴파일 설정>

접근성환경을 설정하고 컴파일을 하게 되면 스크린리더기에서 이전에는 접근할 수 없었던 정보에 접근할 수 있게 된다.
아래와 같은 폼에 이름을 입력하려고 한다고 한다면 접근성 설정이 되어있지 않을경우에는 탭키를 통하여 이동하여 단순하게 입력박스라는 것만 알게 된다.

<mx:Form width="100%" height="100%">
   <mx:FormHeading label="Input Data to TextInputBox"/>
   <mx:FormItem label="Name">
       <mx:TextInput id="user_name" name="user name" width="200"/>
   </mx:FormItem>
</mx:Form>
<mx:StringValidator source="{user_name}" property="text" minLength="4" maxLength="12"/>


하지만 설정만 바꾸고 컴파일 하였을 경우에는 TextInput 에 대한 기본 정보와 함께 입력된 문자열이 기준에 맞지 않을 경우 기본적으로 체크하는 안내 메시지까지 동일하게 스크린리더기를 통하여 확인할 수 있다. 현재 플렉스에서 지원하는 컴포넌트는 위에서 설명한 TextInput을 비롯하여 28개의 컴포넌트들에 대하여 지원하고 있고 앞으로 계속적인 변경된 내용을 찾을 수 있을 것이다. 별도의 플래시 컴포넌트를 위한 스크립트를 사용한다면 보다 편하게 이용할 수 있다. 하지만 이러한 제약사항들이 또 다른 번거로움을 만들기도 하는 부분도 있다. 스크린리더기의 다양한 기능에 대하여는 야후의 접근성부분 PM 으로 있는 빅터(Victor Tsaran)가 소개하는 동영상을 참고한다면 보다 많은 내용을 얻을 수 있을 것이다.
하지만 플렉스의 경우 xml 기반의 MXML 코드를 사용하면서도 스크립트 언어와는 다르게 swf 로 코딩된 내용을 통하여 브라우저에 접근할 수 있다. 하지만 실버라이트의 XAML(Extensible Application Markup Language) 의 경우에는 스크립트 언어와 컴파일 언어의 장점을 필요에 따라 선택하여 가져갈 수 있다. 위에서 언급한 대체 텍스트라는 점에서 XAML 언어에 조금 더 나은 평가가 주어지는 부분이 이러한 부분이다. 플렉스도 내년에 출시될 예정인 플렉스4 에서는 MXMLG 라는 진보된 개념의 코드가 나온다고 하는데 아직 정확한 스펙이 나오지 않아 다음에 다시 언급해보도록 하겠다. 마이크로소프트에서는 자사 제품이외의 클라이언트 소프트웨어도 XAML을 보다 용이하게 참조할 수 있도록 기술정보를 제공하고 있다. 해당 기술에 대하여는 OSP(Open Specification Promise)를 적용한다고 한다. OSP를 적용하게 되면 해당 기술에 대한 특허권을 주장하지 않게 된다. 이러한 기술정보는 또한 스크린 리딩 소프트웨어 등의 개발에 있어 참고할 수 있는 자료가 되기도 한다. 참고로 XAML을 컴파일 하여 사용하는 경우에는 BAML(Binary Application Markup Language) 이라는 코드로 변환되어진다.

접근성을 적용하는 비용은?

모 신문에 정부부처 웹사이트 평가결과에 대한 보도가 나왔었는데 당시 청와대 웹사이트가 접근성에서 가장 낮은 점수를 받았다고 한다. 이에 대한 관련 해명 자료에서 4월 11일 시행령이 발표된 장애인차별금지법에 따른 ‘웹 접근성 지침’ 에 의하면 공공기관은 1년 이내까지 장애인들이 차별 없이 웹사이트에 접근할 수 있도록 사이트를 규정하도록 하였기 때문에 6월말까지는 접근성 지침에 모두 반영된 개발이 완료될 것이라고 하면서 웹접근성 지침을 반영하여 구축하게 되면 예산 및 작업 기간이 일반 사이트의 2배 이상 소요된다고 하는 자료를 낸 적이 있었다. 실제로 웹접근성 지침이라는 것이 그렇게 비용이 많이 들어가는 것일까. 물론 바라보는 시각에 따라서 비용에 대한 의견은 달라질 수 있을 것이다. 얼마 전 일본 총무성에서 인터넷에 올라온 살인예고를 탐지하는 소프트웨어를 개발한다고 하면서 수억 엔의 예산을 책정했었는데 잘 알려진 웹 개발자인 야노사토루(http://satoru.net/)가 2시간에 걸쳐 수억 엔짜리 사이트를 개발해냈다고 한다. 물론 개발스펙의 차이가 있다고 할 수도 있겠지만 실제 활용할 수 있는 내용과 비용과는 비례하지 않다는 생각이다.
웹접근성에 있어서도 기본적인 표준개발항목만 지켜도 지침에서 요구하는 웬만한 항목은 보완할 수 있는 수준이다. 접근성뿐 아니라 향후 유지보수측면에서도 용이하기 때문에 하나하나의 작업들이 버려지는 것이 아니라 웹을 더욱 견고하게 만들어내는 것이다. Flex를 비롯한 RIA 개발에 있어서도 대체할 수 있는 콘텐츠를 만들거나 개발방법에 대하여 언급된 것처럼 코딩습관을 바꾼다면 그렇게 어렵지 않은 부분이다. 기술적으로 아직 부족한 점이 있다고 하더라도 개발자들의 작은 변화로 인하여 접근성 있는 사이트를 만들기 위하여 별도의 비용을 들이지 않고도 충분히 효율적인 작업이 가능할 것이라고 생각된다. 
또하나 이슈가 되고 있는 부분중 하나가 공공기관 홈페이지등에서 TTS(Text to Speech) 엔진을 탑재한 음성출력 솔루션을 자체 제공하는 사이트들이다. 개인적으로도 RIA에서 접근성 문제를 TTS를 통해 쉽게 해결할 수 있지 않을까 생각했었는데 실제 사용자를 고려하지 않는 책상머리에서 나오는 생각일뿐이라는 것을 알게 되었다. 전맹 사용자의 경우 스크린리더를 사용하게 되는데 스크린리더와 충돌하게 되는 경우가 생기기 때문이라고 한다.

좀 더 공부해야 할 것들

접근성 관련하여 진단서비스가 가능한 사이트도 있다. veryfineweb(http://www.veryfineweb.com/)에서는 무료회원가입으로 메인페이지에 대한 웹접근성에 대한 진단서비스가 가능하다. 방법은 무척 간단하다. 테스트할 url을 입력하고 평가시 적용할 지침을 선택한다. 국내에서 사용하는 KWCAG(한국현 웹 콘텐츠 접근성 지침)1.0을 비롯하여 해외의 기준들도 적용가능하다. imaso 사이트를 테스트해보면 공공단체보다 높은 준수율을 보여주고 있다. 또한 한국정보문화진흥원에서 제공하는 KADO-WAH 프로그램을 다운받거나 온라인에서 항목을 체크해볼 수 있다.

<그림 5 : KADO-WAH 실행화면>

<그림 5 : KADO-WAH 실행화면>


RIA 에서의 접근성에 관하여 이야기한다고 하였지만 실제 해당 보조기기를 이용해서 테스트해본것도 아니고 실제 사용자들을 인터뷰해본것도 아니기 때문에 설득력에 한계를 가질 것이라 생각한다. 하지만 많은 개발자들이 이러한 내용이 있는 것조차 모르고 있고 인식을 바꾸어가는 것은 하루아침에 이루어지지 않을 것이라는 생각에 부족하나마 내용을 정리해보았다. 한국모질라사이트 내에 포럼(http://forums.mozilla.or.kr/)에서는 웹표준화와 관련된 여러 이슈들에 대한 토론이 이루어지고 있으며 도움이 될만한 내용들이 많이 올라와있다. 한국정보문화진흥원(KADO)에서 운영하는 웹접근성 연구소(http://www.iabf.or.kr/Lab/)에서는 인터넷 웹 콘텐츠 접근성 지침을 비롯한 많은 자료들을 찾아 볼 수 있다. 그 밖에도 부족한 것 같지만 변화를 위한 도구들이 많이 준비되어있다.
접근성은 ‘사용할 수 있다’ 는 것에 목적을 두고 있다. 그래서 접근성을 고려하게 되면 ‘사용할 수 없는 것’을 ‘사용할 수 있는 것’으로 바꿀 수 있다고 한다. 사용할 수 있는 것을 만드는 것은 개발자들에게도 어떠한 일을 해야 하는지 알려주고 있다.

참고자료
1. 정보통신 접근성 향상 표준화 포럼
- http://www.iabf.or.kr/
2. 한국장애인고용촉진공단 보조공학센터
- http://www.atc.or.kr
3. 한국 웹접근성 그룹
- http://kwag.net/
4. Accessible Rich Internet Applications (WAI-ARIA) Version 1.0
- http://www.w3.org/TR/wai-aria/
5. Ajax 웹표준화에서 어떻게 받아들여야 하나?
- http://forums.mozilla.or.kr/viewtopic.php?f=9&t=6143
6. 스크린 리더 소개(한글자막)
- http://jayr.egloos.com/1318039
7. Introduction To Microsoft Active Accessibility(한글번역)
- http://junhoryu.com/wiki/?IntroductionToMicrosoftActiveAccessibility
8. 수억 엔의 프로젝트를 2시간에 뚝딱 만들어낸 웹 개발자
- http://www.hatena.co.kr/521
9. [Flash 웹접근성] 내 책목록 스크린리더 테스트
- http://blog.naver.com/starcman79/90016139173


728x90