GY's Diary

1 

 글은 웹접근성, 웹표준 전문 솔루션 컴플리언스 셰리프 Compliance Sheriff (http://www.sheriff.co.kr)와 함께 합니다. 

지난 글 보기

대한민국에서 웹접근성과 웹표준 얘기하기 – 무엇을 위한 웹인증이며, 누구를 위한 웹진단 솔루션인가?

웹인증 진단을 한 방에! – 웹표준, 웹접근성 진단 솔루션 Compliance Sheriff 리뷰

웹접근성, 웹표준, 웹접근성 인증 실전 가이드 1

웹접근성, 웹표준, 웹접근성 인증 실전 가이드 2 

 지난 글에서는 웹접근성 개발의 Flow에 대해 살펴보았다. 이번에는 웹접근성 개발의 핵심 축인 웹퍼블리셔의 입장에서 해야 할 일과 주요 기술을 정리해보고자 한다.

1.   웹퍼블리셔는 웹접근성 전문가?

 구인, 구직 사이트를 살펴보면 이와 같은 인식이 깔려 있는 것을 볼 수 있다. 우리 나라의 경우는 웹퍼블리셔라는 직책 자체가 웹표준과 웹접근성이 이슈로 떠오르면서 생겼기 때문이다. 그리고 이는 현장에서 웹퍼블리셔라는 타이틀을 달고 있는 분들 또한 가지고 있는 인식이다. 아직까지는 웹퍼블리셔의 역할에 대해서 명확하게 정의가 안된 상황이라, 웹퍼블리셔의 위치와 역할에 대해서도 명확한 정의가 없다. 굳이 정의를 해보자면, 웹퍼블리셔는 코더보다는 향상된 기술과 안목을 가진 상태에서, 웹개발 프로젝트에서 웹표준을 준수하고 웹접근성을 유지하도록 만들어야 할 책임이 있는 사람이라고 할 수 있다.

 그러나 사실 웹표준 준수나 웹접근성 유지에 대한 책임은 웹퍼블리셔만의 몫이 아니다. 웹개발에 참가하는 전 팀원에게 있으며, 이에 따라 웹접근성 가이드, 웹표준 가이드는 각 파트별로 각각 제작되어 현장에 배포되어야 한다. 그리고 당연히 이 역할은 웹퍼블리셔의 몫이 아니다. 프로젝트를 총괄하는 PM의 몫이다.

 우리 나라에서는 웹을 애플리케이션으로 보고 개발로써 접근을 하지만 실제로 웹은 문서다. 따라서 웹사이트를 제작하는 것은 책을 만들듯이 출판(퍼블리싱)하는 것으로 봐야 한다. 단지 출판물이 배포되는 장소가 서점이 아닌 웹인 것 뿐이다.

 웹퍼블리셔라는 직책은 그렇기 때문에 출판사에서 편집자의 역할이다. 출판사에서 작가들이 써온 원고와 삽화가들이 그려온 그림 등을 모아서 책으로 펴내는 역할을 편집자들이 하는 것처럼, 웹퍼블리셔는 기획자들이 만들어낸 콘텐츠와 개발자들이 만든 애플리케이션, 그리고 디자이너가 만든 디자인들을 조합하여 한 편의 완성된 문서로 만들어내는 것이다.

 웹표준과 웹접근성이 이슈가 된 것은 이 문서를 읽는 기기들이 한 가지가 아니라는 데 있다. 이런 점에서 다양한 기기와 환경에서 읽을 수 있는 문서를 만들어낼 책임이 웹퍼블리셔에게 있지만, 애초에 그것이 퍼블리셔만의 책임은 아니다.

 잘 만든 책이란 무엇일까? 우선은 책의 내용(콘텐츠) 자체가 좋아야 하고, 그 다음에는 그 내용을 잘 편집하여 효과적으로 독자에게 전달할 수 있어야 한다. 웹퍼블리셔에게 어찌보면 더 중요한 것은 그렇기 때문에 웹표준을 준수했느냐, 웹접근성을 유지했느냐보다는 웹이라는 특성을 잘 이해하여 콘텐츠를 얼마나 효과적으로 전달시켰느냐에 있다. 웹퍼블리셔가 한 편으로는 UI개발자로 불리어지는 것은 이 때문이다. 전통적으로 이는 디자인의 영역이었다. UI, UX 모두 디자이너들이 다루어야 할 문제라고 본 것이다. 그러나 웹의 경우, 이를 위해서는 디자이너가 CSS를 이해하여야 한다는 전제가 따르게 된다. 그러나 이는 현실적으로 무리한 요구이다. 또한 디자이너들에게 코드 작성까지 요구할 경우, 자칫 창의성을 상실할 가능성이 크다. 따라서 디자이너에게는 순수한 디자인을 맡기고 이를 CSS를 사용하여 웹상에서 구현하는 것이 웹퍼블리셔의 역할이 되어야 한다. 그러나 이 과정에서 웹퍼블리셔가 UI, UX에 대한 개념이 없다면 디자인을 제대로 살리지 못하게 될 것이다. 더 나아가 비현실적인 디자인을 해왔다며 오히려 디자이너를 구박할 수도 있다. 사실 이 부분은 웹퍼블리셔의 스킬에 전적으로 달려있다. 여기서 말하는 스킬은 단순히 CSS를 얼마나 잘 알고 있느냐가 아니다. 포토샵을 잘 다룬다고 훌륭한 디자이너가 아닌 것처럼, CSS는 단지 디자인을 구현하는 tool일 뿐이다. 웹문서의 다양한 레이아웃과 편집 방식에 대한 이해가 있어야 한다. 그리고 이를 바탕으로 사전에 웹디자이너와 앞으로 만들 웹사이트의 UI와 레이아웃에 대해서 얘기를 해야 한다.

 

2.   웹퍼블리셔의 기술

 

(1)   구조화 (Structuring)

 여기에는 두 가지 차원의 구조화가 필요하다. 하나는 내용을 구조화 하는 것이고 다른 하나는 표현을 구조화 하는 것이다. 표현의 구조화는 바로 아래 챕터에서 다루도록 하고 여기서는 의미의 구조화에 대해서 얘기해보자.

 우리가 흔히 글을 작성할 때, 제목을 정하고 각 목차를 만들어서 장문의 글을 나누듯이 웹으로 퍼블리싱 되는 콘텐츠도 이러한 내용상의 구분에 따른 구조화를 해야 한다. 이에 대한 개념과 방법에 대해서는 시만틱 웹(Semantic Web)’에 대해서 검색해보면 알 수 있을 것이다. 웹퍼블리셔는 따라서 Symantic Markup의 전문가여야 한다. 근데 문제는 이것이 현재까지 나온 검사 도구로는 체크가 불가능하다는데 있다. 당장 html 페이지를 만들어서 검사기를 돌려보자. <h1> tag가 하나도 없어도 ok 사인을 내보내 준다. 근데 상식적으로 Symantic Markup을 했다면 <h1> tag가 없을 리 없다. 현재의 검사 도구들-셰리프Sheriff 같은-은 따라서 반쪽 짜리 검사임을 알아야 한다. 워드 프로그램에 비유하면 현재의 검사 도구들은 맞춤법을 검사하는 것이다. 그것 또한 중요하다. 아무리 명문이라도 기본적인 맞춤법이 틀린다면 챙피한 일일 것이다. 마찬가지로 각종 규약에 맞게 tag를 작성하는 것은 기본이다. 그러나 웹퍼블리셔는 단순히 tag를 본래의 용도에 맞게 사용해야 할 뿐만 아니라, 이러한 tag들을 콘텐츠의 구조에 맞게 서로 의미가 전달될 수 있도록 사용해야 한다.

아래의 그림을 참조하기 바란다.

사용자 삽입 이미지

출처 : Daum IWA

 

(2)   표현 (rendering)

 앞서도 언급했지만 웹퍼블리셔는 디자이너가 가져온 디자인을 CSS등을 이용하여 웹문서로 표현하는 사람이다. 그러자면 먼저 디자이너가 가져온 디자인을 이해할 수 있어야 한다. UI, UX 등의 전문가가 될 필요는 없겠지만 최소한 그것들이 실제로 어떻게 동작해야 하는지, 어떻게 보여주어야 하는지는 알고 있어야 한다. 그 다음 이것을 기술적으로 어떻게 구현하면 좋을지 생각해야 한다.

 ‘(X)HTML=구조언어’, ‘CSS=표현언어라는 개념을 유지하여 표현 요소를 CSS로 모두 옮겨 기록하는 것은 기본이다. 문제는 오늘날 추세인 RIA(Rich Internet Application)를 구현하기 위해서는 CSS만 잘해서는 안 된다는 것이다. Ajax, Javascript, Flash, Flex에 대해서도 다룰 수 있어야 한다. 다행스럽게도 이에 대해서는 국내에서도 가이드가 나온 것이 있으니 아래 URL을 참조하기 바란다.

 

(3)   호환성 (compatibility)

 웹문서는 다양한 기기에서 읽혀진다. 모든 기기에서 동일한 환경을 유지하는 것은 불가능하겠지만 최소한 기기가 바뀌었다고 해서 콘텐츠 자체를 접근 못해서는 곤란한다. 이에 대해서는 구조(xHtml)-표현(CSS)-행동(Script)을 제대로 분리 했다면 대부분 해결되지만 일부tag는 그렇지 않은 경우도 있다. 이는 결국 경험에 의존할 수 밖에 없는데, 각각의 tag가 각 브라우저에서 어떻게 해석 되어지는지를 직접 시행착오를 통해 익히는 것이다.

 다만 이러한 시행착오를 줄일 수 있는 방법이 있는데 이는 웹브라우저 표준 지원화 표를 사용하는 것이다. 코딩을 해나감에 있어 이 표를 참조한다면 이러한 시행착오를 줄일 수 있다.

 

웹브라우저 표준 지원화 표(http://www.webdevout.net/browser-support)



이상으로 웹접근성, 웹표준에 관한 개발에 있어 웹퍼블리셔에 대해서 알아보았다.사실 웹접근성, 웹표준은 웹퍼블리셔만의 역할이 아니다. 책을 출판하는데 있어 맞춤법을 아는 것이 편집자만의 몫이 아닌 것처럼, 웹개발에 있어서도 콘텐츠를 만드는 모든 이가 웹표준과 웹접근성을 알아야 할 필요가 있다. 그런 면에서 개발자가 아니더라도 범용으로 쓸 수 있는 검사 도구의 사용은 중요하다. 앞서 소개한 셰리프Sheriff 같은 Tool이 그 중의 하나가 될 수 있을 것이며, 그 외에도 각자의 환경에 맞게 적합한 Tool을 현장에 도입하는 것이 필요할 것이다.

 

크리에이티브 커먼즈 라이센스
Creative Commons License
2010/07/10 17:24 2010/07/10 17:24
Posted by 그냥
Web Technology l 2010/07/10 17:24

 글은 웹접근성, 웹표준 전문 솔루션 컴플리언스 셰리프 Compliance Sheriff (http://www.sheriff.co.kr)와 함께 합니다. 

지난 글 보기

대한민국에서 웹접근성과 웹표준 얘기하기 – 무엇을 위한 웹인증이며, 누구를 위한 웹진단 솔루션인가?


웹인증 진단을 한 방에! – 웹표준, 웹접근성 진단 솔루션 Compliance Sheriff 리뷰
웹접근성, 웹표준, 웹접근성 인증 실전 가이드 1


지난 글에서는 웹접근성 개발 시 주의할 사항에 대해 살펴보았다. 이번에는 웹접근성 개발의 Flow와 주요 핵심 내용을 정리해보고자 한다.


1.  웹접근성 개발 Flow (웹표준 개발 Flow)

 기존의 웹개발 방식은 Waterfall 방식이라고 불리는 선형적인 밀어내기 식으로 진행해왔다. 그림으로 표현하면 아래와 같다.

사용자 삽입 이미지

 이 방식의 장점은 이해가 쉽고 구조가 단순하다는 데 있다. 따라서 프로젝트 진행 방식 자체를 설명할 필요가 없어서 새로운 인력이 투입되거나 중간에 인력이 교체되어도 Flow 자체를 설명할 필요는 없다. 이 때문에 웹개발 초기부터 많이 쓰이는 방식이며 현재도 많은 곳에서 쓰이는 방식이다.

 그러나 이 방식의 문제점은 어느 한 Flow에서 병목현상이 발생할 경우, 그 다음 단계에서는 무작정 기다려야 한다는데 있다. 즉 병목현상에 대한 대처가 거의 불가능하다. 또한 이 Flow에서는 코딩이 디자이너 또는 개발자 어느 누군가의 책임으로 규정되어 버리기 때문에 구조화된 HTML문서를 만들어내기가 어렵다. 또한 이 Flow에서는 각 단계별로 역할을 맡은 이가 매우 명확해서 각 분야별로 업무 하중이 심하게 걸릴 경우 이를 분산시킬 방법이 없다.

 웹접근성을 고려한 개발을 하겠다는 것은 결국 웹표준에 따른 개발을 하겠다는 것이 된다. 웹표준 개발 Flow에서 기존 개발 Flow와 가장 차별화되는 점은 웹퍼블리셔의 등장이다. 이 웹퍼블리셔가 기획자, 디자이너, 개발자 사이에서 커뮤니케이션하며 구조화된 웹사이트를 만들도록 하는 것이다.

 그러면 웹퍼블리셔는 어떠한 존재인가? 한국소프트웨어진흥원에서 편찬한 실전웹표준가이드’(2005)에는 아래와 같이 명시되어 있다. 

 웹 상에 정보를 출판(publish)하기 위해 필요한 기술을 갖추고 이를 목적에 맞게 활용할 수 있는 전문가

  그러면 웹표준 개발의 Flow를 살펴보자.

사용자 삽입 이미지

출처 : ‘실전웹표준가이드’(2005) 193p.

 그러나 위 Flow를 실무에 그대로 적용하기에는 여러 가지 애로사항이 있다. 그래서 아래와 같이 개량을 해보았다. 현장에서는 오히려 아래와 같은 방식이 더 적합할 것이다.

사용자 삽입 이미지

 

그러면 이제 각 Flow를 하나씩 살펴보자.

 

(1)  기획에서 기획서 작성까지

 (기획/분석, 시안제작, UI설계, 프로세스 분석/설계, 디자인가이드 제작, 콘텐츠 명세서 제작, DB설계, 개발명세서 제작, 개발가이드 제작)

 이는 전통적인 Waterfall flow 때와 동일하다. 새로운 프로젝트가 생기면 기획자는 이번에 제작하는 웹사이트가 갖추어야 할 요구사항을 정리한다. 이는 클라이언트로부터 수집할 수도 있고 실사용자들에 대한 자료를 각종 DB로부터 수집할 수도 있다. 그러나 요구사항에 대한 정리가 끝난 후, 기획서를 만드는 과정에서 디자이너와 개발자, 퍼블리셔가 모두 참가한다는 점이 기존 방식과 다르다.

 전통적인 방식에서 기획서는 보통 2가지다. 하나는 클라이언트에게 보여주기 위한 PPT와 다른 하나는 프로젝트 멤버들이 개발에 참고하기 위한 스토리보드이다. 이 두 가지를 만드는데 있어 기획자는 매우 큰 업무 하중에 걸리게 된다. 또한 이 두 가지 문서가 나올 때까지 다른 멤버들은 기다리게 된다. 사실 그렇게 유능한 기획자가 많지도 않을뿐더러, 이는 매우 비효율적인 방식이다.

 웹표준의 핵심은 구조와 행동, 디자인을 분리하여 이해하기 쉽고, 디버깅 하기 쉬운 웹페이지를 제작하는 데에 있다. 따라서 클라이언트에게 보여주기 위한 PPT를 제외하면, 기획서는 3가지가 나와야 한다. 하나는 기획자가 만드는 콘텐츠 명세서이며, 다른 하나는 디자이너가 만드는 디자인 가이드이며, 마지막 하나는 웹사이트의 프로세스를 분석한 내용을 바탕으로 한 개발 가이드(DB구조도와 개발명세서도 넓은 의미의 개발가이드에 포함한다.)이다. 그리고 향후 이 3가지가 만나서 정리되는 것이 퍼블리셔가 만드는 구조화된 html문서이다. 따라서 요구사항을 기획자가 명확히 정리하고 나면, 그 요구사항을 어떻게 구현할 것인지에 대해 디자이너와 개발자는 각각 기획자와는 다른 관점에서 접근하여 기획을 하게 된다. 이 과정에서 디자이너와 개발자가 요구사항을 잘못 이해하고 있는 부분이 있다면 기획자가 클라이언트 또는 실사용자와의 중간 커뮤니케이션을 통해 정리해준다. 디자이너는 UI와 전체적인 이미지에 대해 고민을 할 것이고, 개발자는 웹사이트가 동작하는 방식. 즉 프로세스에 대해 고민하고, 이를 구현하기 위해 어떠한 프로그램을 만들고 DB는 어떻게 만들지 고민하게 될 것이다. 그리고 기획자는 각 페이지에 들어갈 세부적인 콘텐츠에 대해 고민하게 될 것이다.

 

(2)  구조화/코딩

 퍼블리셔는 만들어진 3가지 기획서. 디자인 가이드, 콘텐츠 명세서, 개발가이드(DB구조도와 개발명세서도 넓은 의미의 개발가이드에 포함한다.)를 보고 구조화된 html 페이지를 만든다. 제대로만 만들어졌다면 디자인이든 프로그램이든 모두 모듈화가 되어 이 구조화된 페이지에 끼워 넣기만 하면 그대로 웹사이트가 동작을 할 것이다. 그렇기에 웹표준 개발 프로세스에서 전통적인 방식의 스토리보드를 대체하는 것이 바로 구조화된 html 문서이다.

 그러나 이는 실무적으로는 어려움이 있다. 개발자라면 모르지만 디자이너에게 코드를 이해하도록 요구하는 것은 무리가 있기 때문이다. 또한 아직 대한민국에는 이 역할을 완벽하게 소화할 퍼블리셔가 거의 없는 편이다. 따라서 아래와 같이 디자인과 세부코딩을 다시 분리하여 진행하여야 한다.

 

(3)  디자인, CSS 제작

 아직까지 디자이너들에게는 코드를 던져 주기보다는 콘텐츠 명세서와 디자인 가이드를 주는 쪽이 더 작업하기에 수월하다. 특히 다수의 디자이너가 참가하는 대형 프로젝트라면 디자이너 역량이 천차만별인 만큼, 그들에게 웹표준 교육을 따로 시키는 것보다 디자이너라면 누구나 이해할 수 있는 디자인 가이드와 콘텐츠 명세서를 제공한 후 일을 시키는 것이 더 적합하다.

 이후 디자이너가 어떠한 형태로 결과물을 퍼블리셔에게 줄 것인가 하는 문제는 전적으로 퍼블리셔와 디자이너가 협의해서 정할 문제이다. 가능하면 코딩하기 편한 형태로 주면 좋겠지만 이는 각 프로젝트에 참가한 사람들의 역량과 전체 스케줄에 따라 달라질 것이다.

 퍼블리셔가 디자이너로부터 받은 결과물을 바탕으로 CSS를 제작하면 웹디자인 작업은 마치게 된다.

 

(4)  프로그래밍/디버깅, 세부코딩

개발자가 각 프로그램의 개발을 마치고 웹페이지에 넣을 스크립트를 알려주면, 앞서 만든 CSS와 조합하여 최종 웹페이지를 퍼블리셔가 만들게 된다.

 

(5)  표준화 준수 확인

 표준화가이드에서는 이를 퍼블리셔의 역할로 규정지었지만 대부분의 경우, 자기가 작성한 코드의 오류를 자기가 찾아내기는 어려운 편이다. 따라서 체크 작업은 일반적으로 웹개발 프로젝트에서 PM을 맡게 되는 기획자가 하는 것이 더 바람직하다. 또는 아예 이를 전담하는 QA들을 두는 것도 하나의 방법이다.

 요즘에는 누구나 쉽게 검사할 수 있는 프로그램들이 많이 나와있으므로 전문지식을 갖춘 퍼블리셔가 아니더라도 체크하는 것이 어렵지는 않을 것이다.

 

2.  웹접근성 개발의 핵심 (웹표준의 핵심)

 핵심을 하나로 정리하자면 아래의 그림과 같이 나타낼 수 있다.

사용자 삽입 이미지

 본래 html tag에는 구조를 나타내기 위해 사용하는 tag와 표현을 나타내기 위해 사용하는 tag가 구분되어 있다. 예를 들어 h1이라는 tag는 해당 내용이 headline depth 1이라는 것을 나타내는 구조를 나타내는 tag이지만 많은 웹개발자들이나 웹디자이너들이 이를 굵은 글씨의 큰 글자를 출력하는데 사용하는 것을 종종 본다. 이 경우, 당연히 웹브라우저마다 h1을 표현하는 방식이 달라서 각각 다르게 나타나게 된다. 보통 이를 해결하기 위해 하는 가장 미련한 방법이 자신이 만든 소스를 각각의 브라우저에서 모두 돌려보는 거다. 그러나 애초에 html 페이지를 만들 때, 디자인 요소를 구조에서 분리시키면 이렇게 하지 않아도 된다.

 궁극적으로 웹표준에 따라 웹사이트를 제작하게 되면, 동일한 웹사이트에서 css를 바꾸는 것만으로 마치 스킨을 바꾸듯이 전혀 다른 디자인 형태로 웹사이트가 나타나게 된다. 실제로 이와 같은 원리로 사용자 접속 환경을 인식하여 각각의 환경에 맞게 디자인된 화면을 출력하게 해준다. 또 마찬가지로 동일한 디자인에서 script만 교체해주면 프로그램 교체가 가능하다. 만약 게시판 프로그램이 맘에 안 든다거나 쇼핑몰 프로그램이 맘에 안 들어서 교체하고 싶을 경우, 예전 방식 데로라면 웹사이트를 전부 리뉴얼해야 했지만, 웹표준에 맞게 제작되었다면 프로그램만 교체하면 된다. 이 모든 것이 가능하게 해주는 핵심은 html page 내에 예전처럼 덕지덕지 디자인에 관련된 css tag, 그리고 프로그램 기능 수행과 관련된 script를 넣지 않는 것에 있다. Html 페이지 안에는 누가 봐도 한 눈에 파악할 수 있을 정도로 구조만 표현하는 것이다. 그리고 각 구조에 맞게 콘텐츠(text image)만 넣어주면 된다.

크리에이티브 커먼즈 라이센스
Creative Commons License
2010/06/20 13:54 2010/06/20 13:54
Posted by 그냥
Web Technology l 2010/06/20 13:54

글은 웹접근성, 웹표준 전문 솔루션 컴플리언스 셰리프 Compliance Sheriff (http://www.sheriff.co.kr)와 함께 합니다. 

지난 글 보기

대한민국에서 웹접근성과 웹표준 얘기하기 – 무엇을 위한 웹인증이며, 누구를 위한 웹진단 솔루션인가?


웹인증 진단을 한 방에! – 웹표준, 웹접근성 진단 솔루션 Compliance Sheriff 리뷰


 지난 2회의 글에서 웹접근성의 의의 그리고 전문적인 웹접근성 진단 솔루션에 대해서 살펴보았다면, 이번부터는 웹접근성, 웹표준을 고려한 사이트를 개발하는 방법에 대해서 안내해보고자 한다.

 

1.    왜 웹접근성을 고려하여 사이트를 만드는가?

 이에 대해서는 지난 글(http://gy.pe.kr/tc/495)에서 충분히 얘기되었다. 지금 다시 이를 묻는 것은 그것을 몰라서가 아니라, 실제 개발에서는 그 취지를 망각하는 경우가 있어 상기시키기 위함이다.

 많은 클라이언트들이 단순히 웹접근성 인증을 받으려고만 한다. 이러한 접근 방식은 실무 개발자들에게 웹접근성을 고려한 개발이 단지 정해진 기준을 통과시키기 위한 요식행위로만 느껴지게 한다. 그러나 이는 대단히 잘못된 접근이다. 애초에 이런 자세로는 다양한 기준들을 충족하기도 어렵지만, 프로젝트 종료 후, 그렇게 만들어진 사이트들은 장애인들 같은 실수요자들의 입장에서 보면 웹접근성을 어떻게 고려했다는 건지 알 수 없는 오히려 불편한 사이트인 경우가 많다.

 웹사이트를 제작하면서 웹접근성을 고려하겠다고 선언하는 것은 그동안 우리가 놓쳐왔던 다양한 사용자들을 고려하겠다는 것이다. 크로스브라우징 테스트를 해야 하는 것은 기본이며, 직접 시각장애인이 사용하는 센스리더기를 구매하여 테스트하지는 않더라도 그들이 사용하는 프로그램들이 사이트에 담긴 콘텐츠를 무리 없이 읽어낼 수 있도록 alt tag 등을 넣어주는 노력을 해야 한다.

2.    웹접근성을 고려한 사이트 개발 시, 놓치기 쉬운 것들

 당연히 웹사이트를 개발하는 사람은 장애인이 아닌 경우가 대부분이다. 그렇다보니 실제로 장애인들의 입장에서 필요한 것들이 무엇인지 모르는 경우가 많다. 아래는 웹접근성 사이트 개발 시, 장애인의 관점에서 필요한 것들을 나열한 것이다. 이러한 것들은 KWCAG WCAG 등에 나와 있는 것은 아니지만 현장에서는 중요한 것들이니 잊지 말자. 그리고 이 부분들은 웹접근성 인증에서 사용자 심사 시 모두 플러스 점수로 작용할 수 있는 것들이다.

(1)   색 대비를 활용한다.

약시 및 저시력의 장애인의 경우는 색대비를 통해 사이트를 이용한다. 그런데 만약 회색버튼에 하얀색 글씨가 쓰여져 있다면 사실상 읽어내지 못할 것이다. 이러한 것들 것 고려하여 디자인시 색대비가 필요하다.

(2)   Title tag의 내용을 정확하게 기입한다.

보통 title tag는 무시하거나 신경 안쓰기 마련이다. 그러난 이 title tag는 일반인들이 웹브라우저에서 즐겨찾기에 북마크를 할 때에도 기본 제목으로 사용될 뿐더러, 특히 장애인들의 경우에는 리더기를 통해 현재 브라우저가 사이트의 어느 위치에 있는지를 파악하는 수단으로 애용한다. 예를 들면 아래와 같다.

) 네이버 부동산 :: 내집마련의 시작 매물

이러한 까닭에 가장 피해야 할 것이 iframe이다. Iframe을 사용하게 되면 title바가 변동하지 않는 상태에서 사이트가 변경되기 때문이다.

(3)   frame으로 만들어진 경우, 모두 이름을 붙여주어야 한다.

이름이 안 써있으면 그냥 frame이라고 리더기가 읽어준다. 이 경우 자신이 선택한 게 어느 프레임인지 알 수도 없을 뿐더러, 프레임 구조에 대한 파악도 안 된다.

(4)   로그인 박스의 tab 순서는 지켜주어야 한다.

보통 아래와 같은 순서로 tab 이동이 이루어질 것이다.

ID입력 필드  id저장 체크 박스 버튼  비밀번호 입력 필드  로그인버튼

 이게 별거 아닌 것 같지만, 일반인처럼 화면을 보고 마우스로 클릭하는 것이 아닌 단축키를 외워서 키보드로 웹사이트를 이용하는 시각장애인의 경우는 순서가 바뀔 경우 혼란이 오게 된다. 가능한 위 순서를 지켜주자.

(5)   대체 컨텐츠를 마련한다.

이는 대부분의 방송사 사이트의 경우에는 기본으로 지키고 있는 것들이긴 한데, 일반 기업 사이트에서는 자주 간과하는 것 중에 하나이다.

예를 들어 동영상의 경우, 동영상의 내용을 text로 보여주는 것이 필요하다.

[참고]

사용자 삽입 이미지

위 사진을 보면, 동영상 우측에 방송전문이 text로 나타나 있다. 이렇게 하면 동영상을 보지 못하는 사람도 리더기가 읽어주는 글 내용을 통해 동영상의 내용을 파악하게 된다.

이와 마찬가지로 요즘에는 플래쉬만을 이용해서 UI를 꾸미는 경우가 많은데, 이는 웹접근성 면에서 보면 좋지 않은 방법이다. 만약 영화 홍보 사이트처럼 감각적인 디자인을 살리기 위해 플래쉬로 UI를 구성했다면, 플래쉬 없는 사이트를 같이 만들어서 첫화면에 이 둘을 선택할 수 있게 해주어야 한다. (이는 장애인이 아니더라도 플래쉬를 사용하지 않는 웹브라우저를 쓰는 사람들을 위해 꼭 필요한 조치다.)

(6)   보안 문자는 alt text를 반드시 병행 출력하도록 프로그래밍해야 한다.

요즘 들어 프로그램을 통한 회원가입이나 도배글 작성을 막기 위해, 랜덤하게 문자를 출력시키고는 사용자가 입력하게 하는 경우가 많다. 근데 이게 시각장애인들에게는 아예 회원가입을 못하게 막거나, 게시물 작성을 못하게 막는 장치로 작용해버린다. 이때 생성된 보안문자 이미지 파일에 동일한 내용의 alt text만 출력시켜줘도 이를 해결할 수 있다. 아니면 아예 인증 방식을 바꾸는 것도 고려해 볼 필요가 있다. 신용카드인증, 휴대폰인증, ARS인증. 찾아보면 인증방법은 많다.


3.    웹사용성(Web Usability) 웹접근성(Web Accessibility) 웹표준(Web Standard)

  웹접근성 인증을 위한 사이트를 개발할 경우, 실무에 적용되는 개념은 결국 위 3단계로 나뉘어 볼 수 있다.

(1)  웹사용성(Web Usability)

실무적으로 보았을 때, 웹사용성을 적용했다 함은, 사용자 편의를 고려하여 제작된 웹사이트를 말한다. 예를 들면 사이트 네비게이션을 기획활 때, 최소한의 클릭으로 원하는 컨텐츠를 찾아갈 수 있게 한다거나, 각각의 양식은 최대한 컨트롤하기 쉽게 만드는 것이 그것이다.

(2)  웹접근성(Web Accessibility)

웹접근성을 적용하는 것은 웹사용성에서 한 발 더 나아가는 것이다. 단순히 편리함을 넘어 누구나 구조를 파악하기 쉽고, 다양한 사용자가 다양한 환경에서 사이트를 이용할 수 있도록 만다는 것이다. 가장 대표적인 예가 마우스 없는 경우, 키보드로만으로 사이트를 이용 가능하게 만드는 것이다.

(3)  웹표준(Web Standard)

웹표준을 적용하는 것은 W3C같은 공공의 기관이나 단체에서 만든 기술적 규약에 따라 웹사이트를 제작하는 것이다. 모든 웹표준들은 앞서 얘기한 개념들을 모두 고려하여 만들어진 경우가 대부분이므로, 결국 웹접근성 개발은 기술적으로 보면 웹표준에 따라 웹사이트를 만드는 것이 된다.

다음에는 웹접근성 개발의 Flow와 웹표준 개발의 핵심 내용에 대해 살펴보겠다.

크리에이티브 커먼즈 라이센스
Creative Commons License
2010/05/29 15:17 2010/05/29 15:17
Posted by 그냥
Web Technology l 2010/05/29 15:17

 앞서 웹접근성과 웹표준에 대한 장문의 글을 올리기는 했지만, 실제로 개발하는 분들의 입장에 서 이를 준수한 개발을 하기란 여간 까다로운 것이 아니다. 존재하는 많은 가이드들의 내용을 머리 속에 넣어놓고 그에 따라 개발을 해야 하는데, 개발자가 모두 천재도 아니고, 또 대부분 큰 사이트들은 혼자 개발하는 것이 아니기 때문에 이를 모든 개발자들에게 요구하는 것은 매우 어려운 일이다. 결국 누군가가-보통은 PM- 나서서 이를 진단해야 하는데 그 작업만으로도 별도의 공수를 잡아먹는 작업이다 보니 이는 다시 비용 증가의 원인이 되고 있다.
 필요는 공급을 낳는 법. 이에 따라 시중에는 이를 자동으로 처리해주는 자동 진단 프로그램과 컨설팅 서비스들이 생겨나고 있다.
 이번 글에서는 그 중 웹표준, 웹접근성, 개인정보보호, Site Quality 등을 모두 진단해주는 종합 웹진단 솔루션 Compliance Sheriff에 대한 리뷰를 해보고자 한다.


1. 개요


 Compliance Sheriff는 미국 HiSoftware(http://www.hisoftware.com/)에서 개발한 프로그램이다. HiSoftware는 1998년 설립되어 현재까지 웹 컨텐츠들이 위험요소는 없는지, 보안에 문제는 없는지, 각 규정은 잘 지키고 있는지를 진단하고 모니터링하는 프로그램 분야에서 시장을 선도하고 있는 기업이다. 현재 전세계 88개국 국가에서 4000개가 넘는 단체들이 이 회사의 프로그램을 사용하고 있으며, HP, Microsoft와 파트너쉽이 체결되어 있다.
 HiSoftware는 두 가지 방식으로 제품을 판매한다. 하나는 직판이며, 다른 하나는 인증 받은 리셀러를 통해서이다. 우리나라에서는 ㈜티엘정보통신(http://www.tlinc.co.kr/)이 총판을 맡고 있다.
HiSoftware 홈페이지

HiSoftware 홈페이지

(주)티엘정보통신 홈페이지

(주)티엘정보통신 홈페이지


2. 실행 환경

HiSoftware사의 웹사이트에 나와 있는 Compliance Sheriff의 실행환경은 아래와 같다.

사용자 삽입 이미지
 Server에서 Windows Task Scheduler를 요구하는 것은 정기적으로 모니터링 결과를 발송할 때, 이 프로그램이 사용되기 때문이다. 사실 실행 환경은 매우 범용적이다. 각각의 항목을 일일이 나열했기 때문에 복잡해 보일 뿐, 결국 보통의 윈도우 서버와 윈도우 클라이언트만 있으면 프로그램을 실행시킬 수 있다.


3. 설치 및 실행

 설치는 매우 간단하다. 사실 설치라고 말할 것도 없는 것이 IIS기반의 서버 프로그램이기 때문에, 구동하고자 하는 윈도우 서버에서 설치 프로그램을 실행만 시켜주면 된다. 이후에는 웹브라우저를 통해 프로그램이 설치된 서버에 접속하는 것으로 바로 사용이 가능하다.


4. 기능 소개

각각의 메뉴를 통해 기능을 살펴보면,

 대시보드(Dashboard)

 진단하고자 하는 웹사이트들을 등록하여 붙여놓는 곳이다. '추가하기'버튼을 클릭하여 등록을 하면 각 사이트들의 상태가 그래프로 나타난다. 글자 그대로 대시보드-계기판-이다. 하나 또는 복수 개의 사이트들을 동시에 살펴볼 수 있으며, 나열 방식도 자유로이 선택이 가능하다. 또한 각 대시보드에서 보여줄 항목도 직접 수정 가능하다.
사용자 삽입 이미지
 스캔(Scan)
 스캔은 하나 또는 복수개의 사이트들에 대한 진단 결과를 보여준다. 그리고 각 사이트의 진단 일정은 예약이 가능하기 때문에 현재 불합격된 사이트들에 대한 수정 일정을 잡았을 경우, 수작업으로 진단을 진행할 필요 없이 해당 일에 자동으로 재진단이 이루어지고 합격 여부를 판단할 수 있게 한다.

 또한 각 사이트별 진단 항목에 대해서는 각각 다르게 설정이 가능하다. 예를 들어 A라는 사이트는 국내 사이트라서 KWCAG 1.0과 개인정보보호 정책을 체크하게 해놓고, B라는 사이트는 미국 사이트라서 WCAG 1.0과 Section 208을 체크하게 해놓을 수 있다. 복수 개의 프로젝트를 진행하는 웹에이전시나 SI업체들이 환영할만한 기능이다.


 모니터(Monitor), 뷰(View), 통지(Report)
 이 기능이 Compliance Sheriff의 또 하나 주목할만한 점이다. 모니터 메뉴는 이미 만들어진-또는 검수를 통과한- 사이트라도 향후 그 사이트가 갱신되어 가는 과정에서 각 규정을 위반한 내용은 없는지, Bad Link 등이 발생하여 Site Quality가 떨어지지는 않았는지 정기적으로 체크하게 해준다.
 내가 아는 어떤 사람은 'Update가 없는 웹은 죽은 것이다'라는 말을 나에게 해준 적이 있다. 그 말처럼 웹사이트는 단 한 차례의 개발 작업으로 끝나는 것이 아니다. 마치 살아 있는 생명체처럼 끊임없이 변화, 성장해가는 공간이다. 따라서 웹표준이나 웹접근성 등과 관련해서도 정기적으로 계속 진단하는 것이 필요하다.
 Compliance Sheriff는 자동으로 이를 해줄 뿐만 아니라 그 결과를 원하는 형태로 출력하여 메일로 발송해준다.
사용자 삽입 이미지

  체크포인트(Checkpoint)
 Compliance Sheriff는 오늘날 웹진단 솔루션의 보편적 트렌드인 CCE(Custom Checkpoint Editor)를 지원한다. 체크포인트는 검사 항목을 직접 수정할 수 있는 메뉴로 이를 통해 프로그램 구매 후, 각 규정들이 변경, 추가되더라도 유연하게 대처가 가능하다.

 수정(Repair)

 Compliance Sheriff는 로컬 파일의 경우, 자동으로 수정해주는 기능을 갖고 있다. 수정 항목들을 등록해놓으면 자동으로 수정이 이루어진다.


 관리메뉴 - 설정, 관리자
 관리 메뉴는 simple하다.
 설정에서는 기본적인 설정을 변경할 수 있고, 관리자 메뉴에서는 각 사용자를 등록, 삭제할 수 있다.



 5. 장점과 단점

 장점

 1) 웹 기반 인터페이스
 Compliance Sheriff는 앞서 실행 환경에서 언급했듯이 웹 기반 프로그램이다. 따라서 웹브라우저로 구동된다. 이는 다수의 프로젝트 참가자가 별도의 클라이언트 설치 없이 언제 어디서나 개발 중인 웹사이트를 진단 가능할 수 있는 환경을 만들어준다. 그리고 당연히 이 프로그램은 다양한 웹브라우저에서 모두 실행이 가능하다.
 이것이 의미하는 바는 매우 크다. 각각의 작업자가 FTP에 해당 내용을 업로드 한 후, 바로 자신이 개발한 부분에 대해서 체크가 가능하기 때문이다.

 2) 다양한 진단 기준 내장
 영문 소개 자료에는 'Out-of-Box'라고 표기가 되어 있던 부분인데, 우리 말로 번역하면 '당장 꺼내 쓸 수 있는' 정도의 의미이다. 무슨 얘기냐 하면, 이미 기본으로 내장되어 있는 기준들이 훌륭하다는 것이다. 기본으로 내장된 진단 모듈은 아래와 같다.

 [ 웹접근성 진단 ]
- Section 508
- WCAG 1.0 / 2.0
- Common Look and Feel (CLF)
- XML Accessibility Guidelines (XAG)
- 이 밖에 WCAG와 Section 508에서 파생된 모든 기준
 (예를 들어, 우리나라의 경우 KWCAG)

[ 개인정보보호 진단 ]
- Children's Online Privacy Act (COPPA)
- Gramm-Leach Bliley Act (GLBA)
- Health Insurance Portability and Accountability Act (HIPAA)
- California SB1386 and AB 1950
- Safe Harbor - EU
- Section 208 - US
- Privacy Act - US
- UK Data Protection Act
- Personal Information Protection and Electronic Documents Act - Canada (PIPEDA)
- EU Data Protection Directive 1995/46
- EU Privacy and Electronic Communications Directive 2002/58

[ Brand / Site의 품질 관리 ]
- 각 링크 주소가 올바른지 체크
- 사이트 목록 체크
- 검색엔진에 잘 검색이 되도록 최적화 - SEO(Search Engine Optimization) 기능
- 스펠링 체크   * 이건 영어 단어 틀린 것들만 교정해주는 듯.
(그러나 사용자 사전 기능이 있기 때문에 한국어도 추가하면 가능하다.)
- 웹페이지 변화 내용 체크
- 각 페이지가 참조하는 항목 체크

[ OPSEC 진단 ]
 The Operational Security (줄여서 OPSEC), 우리 말로 옮기면 '작전 보안' 정도가 되는데, 미국에 있는 사이트에 해당되는 진단 기준이다. 적국에게 보안상 위험이 될 수 있는 정보가 노출되거나 활용되는 걸 막는 것을 말한다. 이 모듈 또한 Compliance Sheriff에 내장되어 있다.

또한 CCE를 지원하기 때문에 각 진단 기준 모듈에 대한 추가, 수정이 자유롭다.

 3) 관리 및 보고 기능

 앞서 기능 소개에서 언급했듯이 Compliance Sheriff는 사이트를 정기적으로 진단, 그 결과를 원하는 형태로 담당자에게 메일로 보내주는 기능을 가지고 있다. 이는 단순히 개발된 사이트를 진단하는 것을 넘어 지속적으로 사이트를 유지보수, 관리할 수 있게 해준다.

 4) CCE에서 다양한 문서 타입 지원
 새로운 진단 기준을 추가할 때, MS Office 문서(DOC, DOCX, XLS, XLSX, PPT, PPTX 등)를 지원하는 것은 물론 Adobe사의 PDF도 지원한다. 솔직히 PDF까지 지원하는 것은 예상 밖이었다.

 5) 디버그(Debug) 기능
 Compliance Sheriff는 진단 결과, 오류를 발견하면 해당하는 부분을 붉은색으로 하이라이트 해서 보여준다. 또한 자동 수정 기능을 통해 반복되는 부분은 일괄 수정이 가능하다.

 6) Microsoft SharePoint 지원
 HiSoftware사가 Microsoft사와 파트너쉽을 맺고 있어서 그런지 Microsoft의 SharePoint를 지원한다. Compliance Sheriff는 SharePoint에 대한 진단, 관리 솔루션으로써도 사용이 가능하다.

  단점
 스크린샷을 통해서도 알 수 있지만 Compliance Sheriff는 Text기반에 웹페이지로 이루어져 있다. 그러다보니 오늘날 화려한 비쥬얼을 가진 프로그램들에 비하면 볼품없게 느껴진다. 이렇게 개발한 이유가 짐작이 가긴 한다. 진단 프로그램으로서는 신뢰성을 높이기 위해 먼저 프로그램 자체가 수많은 기준들을 충족시켜야 했을 것이고 그 과정에서 자연히 화려한 요소들은 배제되었을 것이다. 그러나 오늘날 UI, UX의 중요성이 강조되는 시대에서 텍스트 기반으로 간다 하더라도, 화면 구성이나 메뉴의 클릭 순서 같은 사용자 편의성을 고려하여 UI가 만들어졌으면 좀 더 낫지 않았을까 하는 아쉬움이 든다. 일반 사용자를 대상으로 하는 범용 프로그램이 아니기 때문에 막상 고객들로부터는 그러한 요구사항이 없었을지도 모르겠지만.

 6. 전망

 우리나라뿐만 아니라 여러 나라에서 웹표준, 웹접근성을 지키도록 요구되어지고 있기 때문에, 이를 자동화 해주는 프로그램이나 서비스에 대한 수요는 앞으로 늘어갈 것이라고 본다.
 Compliance Sheriff는 이러한 경향 속에서 개발자들의 고민을 해결해줄 수 있는 매우 훌륭한 프로그램이다. 지금 웹접근성 진단에 대해 고민하는 회사나 개발자들이 있다면 이 프로그램을 추천하고 싶다.

* 보다 자세한 정보를 원하시는 분은 ㈜티엘정보통신 홈페이지(http://www.tlinc.co.kr/)를 참조하시기 바랍니다.
크리에이티브 커먼즈 라이센스
Creative Commons License
2010/04/30 00:01 2010/04/30 00:01
Posted by 그냥
Web Technology l 2010/04/30 00:01
 국내 웹 환경에서 저 두 가지 말을 꺼내는 것은 매우 사치스러운 얘기일 수 있다. 우리나라는 이미 널리 알려졌다시피 웹 환경이 특정 기술에 종속되어 있고, 개발 과정에서도 대부분의 코더들이 특정 소스를 Tip이라고 부르며 복사해서 웹 개발을 해오고 있기 때문이다.

 만약 웹이라는 공간이 특정한 대상, 특정한 지역에서만 접근 가능하다면 지금 상태로도 큰 문제는 없다. 그러나 우리가 흔히 웹을 지칭할 때 쓰는 말인 정보의 바다는 누구나 접근 가능하고 누구나 정보를 올릴 수 있기 때문에 만들어진 것이다. 웹은 애초에 특정한 지역과 특정한 대상을 구분하여 제공하는 서비스가 아니다.

 웹접근성을 얘기할 때, 보통 실무자들에게서 많이 듣는 얘기는 왜 소수 이용자까지 배려해야 하느냐?”이다. 예를 들면 크롬이나 파이어 폭스 브라우저 사용자에게는 서비스를 제공할 생각 없으니, 불편하면 쓰지 마라.” 라거나 “TTS(Text to Speech)를 사용해야만 웹사이트를 이용할 수 있는 시각 장애인들은 쓰지 마라.” 라는 얘기다. 그러나 전 세계에서 인터넷 익스플로러 점유율이 비정상적으로 높은 나라는 우리나라와 중국뿐이고, 우리나라에서도 점점 다른 브라우저의 점유율이 올라가는 추세다. 그리고 유럽의 사례에서 보듯이 윈도우에서 기본 브라우저로 인터넷익스플로러를 제공하는 것이 독과점법 위반으로 철퇴를 맞을 가능성은 국내 및 중국에서도 언제든지 가능하다. 또한 장애인을 배려한 웹사이트 개발은 정부 관련 사이트나 공공기관 사이트에서는 의무화되어 있으며, 의무화시키는 수위나 강도는 갈수록 더욱 강해지면 강해졌지 약해질 거라고 생각되지 않는다. 우리나라에서는 장애인차별금지법 및 권리구제 등에 관한 법률 21조 및 동법 시행령 제 14조에 웹접근성 준수가 명시되어 있고 미국은 장애인 복지법의 수정 조항인 508조에 총 16개의 지침을 포함하여 규정하고 있다.

장애인 차별 금지법의 단계적 범위

<2015년까지는 거의 모든 웹사이트에 ‘장애인차별금지법’에 따른 웹접근성 준수가 의무화되고 있다. 그러나 아직 우리 나라에 웹접근성 수준은 많이 부족한 상황이다.> (관련기사 : http://www.dt.co.kr/contents.html?article_no=2010041602010660600002)

 그나마 다행인 것은 위 기사에도 나오는 것처럼 웹접근성 관련 회사나 단체 등도 생기고 전보다는 많은 이들이 여기에 관심이 있다는 점이다. 그러나 이들 대부분이 장애인들과 같은 소수자들에 대한 배려 하에 웹접근성을 바라보기 보다는 법을 통과하기 위한, 또는 정부나 대기업의 수주를 따내기 위한 인증마크 획득 수단의 일환으로 접근하고 있다는 점이 문제다. 일부 웹에이전시에서는 소량의 콘텐츠만 개발하여 인증을 받은 후, 다시 웹사이트를 재작업하는 때도 있다고 한다. 이런 식이라면 진정한 의미에서의 웹접근성 개선은 이루어지기 어렵다.

 현재 웹접근성에 대한 인증은 웹접근성연구소(http://www.wah.or.kr)에서 이뤄지고 있다. 심사는 크게 자동심사와 수동심사로 이뤄지는데, 자동심사는 위 연구소에서 개발한 K-WAH라는 프로그램을 통해 이뤄진다. 이 프로그램은 누구나 위 연구소 사이트에서 다운 받을 수 있으며 이를 통한 자체평가도 가능하다. 문제는 아직 이 프로그램이 웹접근성 심사에서 요구하는 모든 기준을 완벽하게 체크하지 못하는 데에 있다. 이 때문에 자동심사 통과 후, 이어서 전문가 심사와 사용자 심사를 다시 받게 된다. 이 모든 심사가 통과된 후에야 '웹접근성 품질마크 인증위원회'에 상정되어 인증마크를 받을 수 있게 된다. 그리고 인증은 1년마다 갱신하게 되어 있다.

 이 모든 과정들이 웹에이전시나 개발자 입장에서는 참으로 귀찮은 작업일 수 있다는 것을 안다. 사실 개인 사이트나 규모가 영세한 중소기업들에까지 이것들을 요구하는 것은 무리라고 생각한다. 그러나 정부기관이나 대형 기업들의 사이트에서는 법으로 마련되어 있지 않더라도 준수해야 하는 상황이라고 본다. 장애인은 국민이 아닌 건가? 또한 인터넷 익스플로러를 사용하지 않는 사람은 국민이 아닌 건가? 웹접근성을 고려하지 않은 사이트들은 웹 환경에서 정보 습득의 기회를 제한시켜 상대적으로 정보 차별을 발생시킨다. 특히 외출이 쉽지 않은 장애인들의 경우, 가장 많이 이용을 원하는 것이 온라인 쇼핑몰인데 이러한 쇼핑몰들이 대부분 웹접근성을 고려하고 있지 않아서 그들에게 큰 불편을 안겨주고 있다.


 이러한 웹접근성을 고려한 개발을 하는 데 있어 가장 효율적인 방법은 효과적인 진단 Tool을 사용하여 서비스 전에 이를 검토하는 것이다. 또한 서비스 런칭 후에도 이러한 진단 Tool을 통해 지속적인 모니터링을 하여 업데이트 된 내용이 웹접근성을 해치지 않는지 검토하는 것이 필요하다. 이를 위한 진단 Tool에는 여러 가지가 나와 있는데, 웹개발자로서 가장 추천할 만한 것은 Compliance Sheriff(http://www.sheriff.co.kr)이다. Compliance Sheriff W3C에서 제정한 WCAG와 국내 기준인 KWCAG의 모든 항목이 진단 가능하고, 모니터링 할 사이트를 지정해놓으면 정기적으로 모니터링 결과를 보내준다. 또한 웹표준, Site Quality, 개인정보보호정책까지 일괄로 진단이 가능하다.

 사실 웹접근성과 웹표준을 지키는 것은 이미 무시할 수 없는 트랜드다. 최근 리뉴얼하거나 오픈한 글로벌 서비스 중에 웹표준을 지키지 않는 사이트가 있는지 찾아보라. 얼마 전 유튜브(You Tube)는 아래와 같은 공지를 메인 화면에 올린 적이 있다.
사용자 삽입 이미지

 위 공지를 한마디로 요약하면 개정된 웹표준 기술을 지원하지 않는 브라우저를 대상으로 서비스하지 않겠다는 얘기다. 이는 매우 상식적인 얘기다. 표준이라는 것은 항상 미래를 지향해서 제정하는 것이다. 웹사이트가 아닌 일반 프로그램을 만들 때도 마찬가지인데, 이 때문에 항상 상위 호환성(Forward Compatibility)을 확보하는 것은 매우 중요한 문제이다. 이를 역행하는 것이 오히려 이상한 것이다. 그런데 국내에서 웹서비스를 사용하다 보면 이런 비상식적인 얘기를 종종 듣게 된다. 제일 대표적인 경우가 더 낮은 버전의 브라우저로 변경하라는 것이다. 처음 그 소리를 들었을 때 나는 내 귀를 의심해야 했다. 자동차에 비유하면 신형 소나타는 정비소에서 지원하지 않으니, 고객에게 다시 중고차로 바꿔 타라고 말하는 격이다. 이게 무슨 헛소리?

 현재 국내에서 최신 컴퓨터를 구매하면 윈도우7을 기본 OS로 제공한다. 그리고 윈도우7에는 당연히 인터넷 익스플로러8을 기본 웹브라우저로 제공한다. 그리고 인터넷 익스플로러8은 최근에 나온 웹브라우저이기 때문에 웹표준 기술을 지원하도록 만들어져 있다. 그리고 더는 사용하지 않기로 합의한, 인터넷 익스플로러 6.0에서만 동작하는 자바스크립트나 Tag 등은 당연히 지원하지 않는다. 이미 폐지된 기술을 사용하여 웹사이트를 만든 사람이 잘못인 건가? 아니면 최신 브라우저를 사용한 고객이 잘못인 건가?

 웹표준에 따라 사이트를 만드는 것은 트랜드다. 바꿔 말하면 대한민국은 지금 그 트랜드를 역행하는 중이다. (인터넷에 역주행 놀이가 유행이던데 국내 웹개발자들도 동참 중?)

 웹표준에 따른 개발 관련해서는 아래의 사이트들을 참조하기 바란다.

NHN 웹표준화팀이 운영하는 웹표준화 가이드 : http://html.nhndesign.com/978#12

Daum의 개발 가이드 : http://ui.daum.net/ftdev/guideline

한국소프트웨어 진흥원 - 실전 웹표준가이드 : http://www.mozilla.or.kr/ko/docs/web-d ··· ndard%2F

행정안전부 - 전자정부 웹표준 강화 종합대책 (클릭)

 웹접근성을 고려하고 웹표준에 따라 사이트를 제작하는 것은 이제는 보편적인 트랜드일 뿐만 아니라, 우리나라에서는 웹 환경이 특정 회사의 기술에 종속되는 것을 벗어나는 길이다.

 웹접근성과 웹표준은 특정한 누군가를 위한 것이 아니다. 그렇기에 형식적으로 규정을 따르는 척 하거나 강제 사항이 없으면 무시할만한 것이 아니다. 사용자 측면에서 보면 모든 사람이 차별 없이 웹 환경에서 정보를 습득할 수 있게 하는 것이며, 개발자 측면에서 보면 누구나 쉽게 이해하고 유지 보수 가능한 사이트를 만들 수 있게 하는 것이다.

 아무쪼록 국내 웹서비스에서도 웹표준을 준수하고 웹접근성을 고려하여, 서비스가 향상되기를 바란다.


크리에이티브 커먼즈 라이센스
Creative Commons License
2010/04/20 03:22 2010/04/20 03:22
Posted by 그냥
Web Technology l 2010/04/20 03:22
1 

카테고리

전체 (500)
Diary (109)
Il-chi Lee (58)
Kook-hak (28)
Earth (29)
Economics (11)
Politics (43)
Business (1)
Issue (107)
Game (26)
English (17)
media (14)
IT (28)
iPhone (7)
Web Technology (5)
Travel (15)

달력

«   2012/05   »
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
get rsslazylogs Tistory Tistory 가입하기!