지난 7일
행정안전부가 주최하고
한국정보문화진흥원이 주관한
2009년 상반기 웹 접근성 기술동향 및 향상방안 세미나가 있었습니다. 이날 부족한 제게도 기회가 주어져 발표를 할 수 있었고, 오늘
정보통신 접근성 향상 표준화 포럼을 통해서
발표 자료(PDF)가 공개되었습니다.
사실 이번 발표를 위해서 나름 준비를 열심히 했는데 막상 너무 큰 자리에 서다 보니 반쯤 얼어서 제대로 전달하려고 했던 내용의 반도 전달해 드리지 못한 것 같아 혼자 많이 속상해 했었습니다. 단상에서 내려오고 나니 빠뜨린 내용이 적지 않더군요. 그래서 발표용으로 작성했던 메모를 정리해서 이렇게 글로써 다시 '발표'를 하려고 합니다.
웹 개발자가 알아야할 웹 접근성이라는 주제를 받고, 한참을 고민했습니다. 지난 몇년간 있어온 여러번의 세미나를 통해서 몇번이고 반복되었던 내용들의 반복이 되고 싶지는 않았습니다.(결국은 그렇게 되었지만) 그래서 나름 고민을 거듭해서 3가지 수칙을 정하고, 그에 따라 내용을 붙여 보게 되었습니다. 첫번째 수칙은 ‘항상 공부하라’입니다. 우리가 필요로 하는 정보들이 어디에 있고, 어떻게 찾아 보면 좋을지를 알려드립니다. 두번째 수칙은 ‘습관을 버려라’입니다. 과거로부터 이어진 좋지 않은 개발 관행의 4가지 사례를 살펴보도록 하겠고, 세번째 수칙 ‘사람을 믿고, 기계를 의심하라’에서는 함께 일 하는 동료들과 에디터, 시스템 등 작업 환경에 대한 이야기를 하고자 합니다.
다음은 순서입니다:
- 수칙 1. 항상 공부하라
- 1.1 웹 표준 기술을 제대로 알고, 가까운 곳에 스펙을 둬라
- 1.2 새로운 정보와 이슈를 놓치지 말라
- 수칙 2. 습관을 버려라
- 수칙 3. 사람을 믿고, 기계를 의심하라
수칙 1. 항상 공부하라1.1 웹 표준 기술을 제대로 알고, 가까운 곳에 스펙을 둬라제가 생각할 때 웹 개발자에게 있어서 웹 접근성 향상을 위해서 가장 중요한 것은 웹 표준 기술을 가장 잘 이해하고 사용하는 것입니다. 따라서 첫번째 수칙으로 ‘항상 공부하라’고 했습니다. 그리고 수칙 1-1로 ‘웹 표준 기술을 제대로 알고, 항상 가까운 곳에 스펙을 둬라’고 정해 보았습니다.
어떤 분들은 기억력이 좋으셔서 한 두번 본 내용을 곧 잘 기억해 내십니다. 하지만 저는 그게 참 안되었습니다. 그래서 제 책상 위에는 W3C의 온갖 스펙이 출력되어 있고, 책 제본을 쌓여 있습니다. 그냥 아무렇게나 출력해 놓은 것들은 처음 한 번 이후에는 잘 보지 않게 되기도 하고, 쉽게 이면지함으로 들어가죠. 하지만 회사에 제본기가 한 대 있어서 스펙들을 한데 묶어 책으로 만들어 두시면 보기가 편할 뿐더러 보관에도 좋습니다. 그리고 브라우저의 즐겨찾기는 당연하겠죠. 의외로 많은 분들이 스펙과 관련된 궁금증을 풀기 위해서 커뮤니티 게시판을 이용합니다. 가장 먼저 스펙을 찾아보는 습관을 갖는 것이 좋습니다. 다음은 웹개발자들에게 필요한 주요 북마크입니다.
W3C에 권고안으로 공개된 표준 스펙 문서들과 MS, Mozilla, Opera가 운영하고 있는 레퍼런스 사이트들입니다. 실제로 찾아보시면 이보다 훨씬 더 많은 스펙 문서들과 레퍼런스 사이트들이 있습니다. 제 블로그를 통해서도 소개드린 것들이 있고, 정찬명님의 나라디자인 위키 페이지에서
UI개발자들을 위한 북마크를 운영하고 계시기도 합니다. 웹 개발자 분들께 유용한 자료가 될 것으로 생각됩니다.
1.2 새로운 정보와 이슈를 놓치지 말라수칙 1.2는 '새로운 정보와 이슈를 놓치지 말라'입니다. 개발 분야 만큼 빠르게 새로운 정보와 이슈가 쏟아지는 분야도 드믈 것이라고 생각됩니다. 겨우 하나의 언어와 기술을 익혔는데 어느새 또 다른 언어가 나오고 방법론이 제시됩니다. 특히 웹이 대중화된 이후는 그 속도가 더욱 더 빨라지고 있는 추세입니다. 그런 빠름을 쫓아가지 못한다면 계속해서 뒤쳐질 수 밖에 없는 것이 또한 이 분야인 것 같습니다.
RSS는 여러 사이트의 새로운 글을 아주 쉽게 읽을 수 있도록 도와줍니다.
구글 리더와 같은 피드 구독기를 적극 활용하면 수 많은 블로그와 홈페이지의 최신 정보를 쉽게 얻을 수 있습니다. 파이어폭스와 같은 최신의 브라우저는 아주 쉽게 피드를 구독할 수 있도록 기능을 지원하고 있기도 합니다. 또 다른 하나는
Delicious와 같은 SNS기반의 북마크 서비스를 이용하는 것입니다. HTML, CSS, Web Standards 등 관련 태그를 통해서 다른 사람들이 북마크한 유용한 정보와 사이트들을 쉽게 찾아볼 수 있습니다.
수칙 2. 습관을 버려라세살 버릇 여든까지 간다고 합니다. 한번 몸에 벤 습관이 그만큼 무섭다는 뜻입니다. 초중고와 대학을 지나면서 그리고 사회 초년생일 때- 처음 개발을 배우고 이 바닥에 발을 들이기 시작해서 처음 만났던 사수로부터 배웠던 기술들. 아무것도 몰랐던 우리는 습자지처럼 새로운 기술들을 받아 들이고 배워왔습니다. 하지만 알게 모르게 잘못된 정보와 기술을 가려 내지 못하고 무분별하게 배워왔다는 사실입니다. 책이라고 해서 다르지 않습니다. 외서의 경우 오역되거나 잘못된 의미를 전달하기도 하고, 바람직하지 않은 기술을 권장하는 듯 써 놓은 것을 그대로 믿어버린 경우가 부지기수입니다.
때문에 웹 접근성과 웹 표준을 대하는 개발자에게 있어서 가장 큰 충격은 자신의 지식에 대한 확신의 흔들림입니다. 뒤에 간단한 설문 조사 결과를 통해서도 말씀 드리겠지만 자신이 알고 있는 표준에 대한 지식이 과연 옳은 것이었는가? 하는 의심을 가질 필요가 있습니다. 그래서 두번째 수칙은 ‘관성을 버려라’ 그리고 ‘항상 현재의 방법이 최선인지를 의심하라’라고 하였습니다.
그럼 웹 개발자들이 일반적으로 잘못 알고 있었던 사례들은 어떤 것들이 있는지 살펴보겠습니다.
습관 하나. 비동기 통신은 Frame으로 구현해야 하나?첫번째 사례는 비동기 통신을 사용하기 위해서 프레임을 사용하는 경우입니다. 최근에는 Ajax를 이용한 개발이 붐을 일고 있기는 하지만 여전히 Frameset을 설정하여 무의미한 frame을 만들어 놓고, 비동기 통신을 구현하고자 하는 개발자들이 있었습니다. 조금 더 자세히 살펴보겠습니다.
Frame 기술의 발전하다가 Ajax에게 그 자리를 내주고 있다.
Frame은 Netscape 2.0(1996)에서 최초로 지원되었고, HTML 4.0(1997)에 이르러 공식적으로 도입되었습니다. Hidden Frame 기술은 Frameset을 설정하여 하나의 Frame의 높이를 ‘0’로 만들어 서버와의 통신을 처리하는데 사용한 최초의 비동기 요청/응답 모델이었습니다. 이후 마이크로소프트사가 자바스크립트를 이용하여 동적으로 페이지의 일부를 수정할 수 있는 기술인 DHTML을 만듭니다. Hidden Frame 기술은 이 DHTML을 만나 페이지의 어느 부분이라도 서버 정보를 가지고 언제든지 새로고침할 수 있도록 해 주었습니다. 하지만 Hidden Frame 기술은 반드시 프레임셋을 설정해야만 한다는 단점이 있었는데, iframe 엘리먼트가 HTML 4.0에 포함되면서 Inline Frame 기술을 사용할 수 있게 됩니다. 이후 CSS와 결합하여 Hidden Inline Frame 기술로 발전되어 사용되기 시작합니다. 하지만 더이상 Frame을 사용하여 웹사이트의 구조를 분리할 필요성(퍼포먼스 향상을 위해)도 없으며, 비동기 통신을 위해서라면 이미 Ajax와 같은 기술이 그 자리를 대체해 나가고 있다. 그럼에도 이같은 frame의 발전은 많은 웹개발자들이 Frame기술을 이용한 잘못된 습관을 가지게 만드는데 일조를 하게 됩니다. 다음의 마크업을 보겠습니다.
<frameset rows="*,0" frameborder="0" border="0" border="0">
<frame src="main.html" name="main" scrolling= "auto">
<frame src="blank.html" name="hidden" scrolling= "auto" >
</frameset>
경력이 적은 분들이라 하더라도 이와 같은 마크업을 한 두번쯤은 보셨을 것으로 생각됩니다. 이같은 프레임셋을 설정하는 이유에는 지금 설명드린 비동기 통신을 구현하기 위한 목적 외에도 도메인을 깔끔하게 유지하고자 하는 목적도 있습니다. 하지만 두 가지 이유 모두 접근성 측면에서 바람직하지 않습니다. 바로 이어서 설명드리겠습니다.
습관 둘. 고정 URL은 보안이 좋다?과거에는 URL을 통한 해킹 공격이 이루어졌던 사례들이 있었습니다.
Query Injection이라고도 하는 이 해킹 방법(SQL Injection이 좀 더 정확한 표현이라고 합니다)은 이와 같이 URL이나 사용자 서식 요소의 필드를 통해서 특정 SQL Query를 입력함으로써 웹사이트 가입자의 비밀번호나 주민등록번호와 같은 정보를 노출시키는 방법입니다. 또한, 꼭
Query Injection 이 아니더라도 간단히 도메인 뒤에 따라 붙는 Query String의 값을 조작하는 것만으로도 웹사이트에 비정상적인 동작을 요청할 수 있습니다. 이 때문에 많은 사람들이 URL에 Query String을 보이지 않도록 눈속임을 했었습니다. 거기에 마우스 우클릭을 막아 컨텍스트 메뉴가 뜨지 않게까지 했습니다. 이렇게 하면 사용자가 임의로 웹 페이지의 전체 URL을 알 수 없을 것이라고 생각했던 것이지요.
네이버와 같은 포털의 URL은 숨겨져 있지 않다
하지만 어느 사이트보다도 보안이 생명인 검색 사이트나 포털 사이트 어느 곳도 전체 주소를 감추거나 하지 않습니다. URL을 감추고, 컨텍스트 메뉴를 무력화 시키는 것이 결코 해커의 공격을 막는 방법이 되지 않는다는 것입니다.
그럼 이러한 프레임셋 구조가 웹접근성 측면에서는 어떨까요?
프레임셋을 사용하게 되면 일단, 개별 웹 페이지의 고유 주소를 상실하기 때문에 고유성이 상실됩니다. 이것은 결국 정보와 위치의 불일치를 가져오게 됩니다. 즉, 절대 주소가 공개되지 않은 경우 사용자는 찾고자 하는 정보를 다시 얻기 위해서 웹 사이트의 초기 페이지부터 탐색을 반복해야 하는 번거로움을 가지게 됩니다. 이는 파리를 여행하는 사람에게 세계 지도를 던져 주며 에펠탑을 찾아 가 보라는 것과 다를게 없습니다.
같은 URL을 가진 서로 다른 페이지
입니다. 홈페이지와 관계규정 내용을 담고 있는 페이지의 URL이 www.kecs.go.kr로 동일함을 볼 수 있습니다. 관련 내용을 인용하기 위해서 URL이 필요한 경우에도, 다른 사람에게 해당 페이지의 내용을 소개하고 싶을 때에도 또같은 URL을 사용해야 합니다. 심지어 자신이 북마크를 해 놓고 다시 열고 싶을 때에도 국정원 사이트의 홈페이지부터 재 탐색을 해야합니다. 이것은 일반인에게도 매우 불편합니다.
그럼에도 불구하고 Frame을 사용해야 한다면 다음을 기억하십시오:
- DTD(HTML 4.01 Frameset 또는, XHTML 1.0 Frameset)의 명확한 정의
- title 속성을 이용한 정확한 이름을 부여
- 최소 사용
습관 셋. alt? title? 그런거 없어도 아무 문제 없더라
alt는 툴팁이 아닙니다
다음으로 소개드릴 것은 대체 텍스트와 제목에 관해서입니다. alt 속성은 이미지의 텍스트로 대체하기 위한 속성입니다. 시각 장애가 있는 사람은 이미지의 내용을 파악할 수 없기 때문에 alt 속성의 내용으로 대신 인지합니다. 또한, 검색 엔진 역시 인간과 같이 시각 정보를 가질 수 없기 때문에 alt 속성을 통해서 정보를 수집합니다. 그런데 IE는 alt 속성을 풍선 도움말(툴팁)로 처리해서 보여주는 기능을 하고 있습니다. 일반인들이 뜬 눈으로도 이미지의 내용을 파악하지 못한다고 생각해서였을까요?
title 속성 역시 alt 처럼 스크린리더를 통해서 음성 정보를 지원하고, 일부 엘리먼트를 제외한 거의 모든 엘리먼트의 제목으로 사용될 수 있습니다. 특히 frame 엘리먼트와 label 엘리먼트를 함께 쓸 수 없는 서식 요소의 제목으로사용되면 접근성을 높일 수 있습니다. 하지만 alt와 title 속성을 처리하는데 있어서 스크린리더마다 방식이 다를 수 있기 때문에 이에 대한 사전 조사와 테스트가 필요합니다.
미투데이는 다양한 스타일시트를 포함하고 있고, title을 부여하고 있다.
미투데이 사이트는 여러개의 테마 스타일시트를 포함하고 있습니다. 개별 스타일시트를 연결하는 link 엘리먼트에는 해당 스타일시트의 제목이 title로 정의되어 있음을 볼 수 있습니다.
Doday는 alt 속성을 잘못 처리하고 있다
반면에, 비교적 웹 표준을 잘 준수한
Doday 서비스의 경우 메인 페이지 ‘요즘 이야기’부분에서 사용자 프로필 이미지들에 대한 alt 값이 모두 ‘님의 프로필 이미지’로 똑같습니다. 사용자 아이디를 넣어줘야 하는 부분에서 개발자가 실수로 빠뜨리지 않았나 싶습니다. 결과적으로 시각 장애인 및 검색 엔진은 서로 다른 이미지들을 모두 똑같은 의미의 이미지로 파악할 우려가 있습니다. (
4월 7일 오전 저의 버그 신고로 인해 바로 수정되었습니다.)
alt와 title을 이야기하면서 항상 빠지지 않는 것이 언제 alt를 쓰고, 언제 title을 써야 하는지에 대한 문제입니다. 이 문제는 네이버 카페 ‘
하드코딩을 하는 사람들’이나 ‘
CSS Design Korea’에서의
논의와
'한국 모질라 커뮤니티'에서 논의가 이루어졌었고,
일모리님의 블로그에 잘 설명되어 있습니다. 참고해 주시기 바랍니다.
대체 텍스트를 사용하기에 앞서 다음과 같은 고민이 있을 수 있습니다. 첫째, 의미를 가진 이미지인가 꾸밈용 이미지인가 하는 것입니다. 단지 꾸밈용이라면 불필요한 대첵 텍스트가 오히려 접근성과 사용성을 떨어 뜨릴 수 있습니다. 둘째, 이미지 자체를 대체하는 것인지 아닌지를 판단하여 alt를 사용할지 title을 사용할지 적절히 판단할 수 있어야 합니다. 셋째, 대체 텍스트의 길이가 긴 경우 longdesc 속성을 이용하거나, IR기법 등 다른 방법을 고민할 수 있어야 합니다.
습관 넷. Label? 개발자는 다 안다고? 웹 개발자들이 자주 간과하고 있는 것 들 중 또다른 하나가 바로 label 요소입니다. label요소는 input과 같은 사용자 서식 요소에 대한 정보를 첨부하며 연관을 맺습니다. 주로 서식 요소의 제목 요소로 적용되고 있으며, 서식요소와 1:1로 관계를 갖습니다. 이같은 마크업은 서식 요소에 대한 접근성을 높여줍니다. 다음은 label을 적용하는 방법입니다.
명시적 선언
<label for="userId">아이디</label>
<input type="text" id="userId" />
암시(묵)적 선언
<label>비밀번호
<input type="text" id="userPw" />
</label>
Title 선언
<input type="text" id="phoneHead" title= "전화 앞자리" />
<input type="text" id="phoneBody" title= "전화 뒷자리" />
label을 마크업하는 방법에는 명시적 선언과 암시적 선언 두가지가 있습니다. 1:1로 대응되는 서식 요소에 대해서 id와 for 속성을 통해서 연결하는 방법이 명시적 선언이며, 서식 요소를 label 엘리먼트로 감싸는 것이 암시적 선언입니다. 암시적 선언인 경우에 label엘리먼트의 for 속성은 생략이 가능합니다. 하지만 전화번호와 주민등록번호와 같이 동일한 의미를 갖는 서식요소가 둘 이상의 필드로 구성된 경우 label 엘리먼트와 1:1로 대응시키는 것이 비효율적인 경우가 있습니다. 이런 경우 각 서식요소에 title 속성을 이용해서 제목을 달아 주는 것이 좋습니다.
하지만 이렇게 의미적으로 하나의 정보를 위해서 둘 이상의 필드로 구성하는 것은 사용성 입장에서도 별로 바람직하지 않은것 같습니다. 각 필드를 채우고 Tab키를 눌러서 이동해야 하는 번거로움을 차치하더라도, 필드가 채워지면 자동으로 다은 필드로 이동하는 기능의 경우에는 시각 장애인에게는 접근성을 저해하는 요소가 된다는 사실을 알아두실 필요가 있을 것 같습니다. 하나의 필드로 구성하여 자바스크립트와 서버 개발을 통해서 얼마든지 유효성 검증과 데이터 처리를 할 수 있을 것입니다.
네번째로 말씀 드릴 내용은 form 엘리먼트 처리에 관한 것으로, 자바스크립트를 이용해서 서식 요소의 값을 서버에 전달하는 경우 자바스크립트가 지원되지 않는 환경에서 ‘전달’ 자체가 이루어지지 않는 문제가 있습니다. 따라서 서식 요소의 데이터를 서버에 넘기는 작업은 form 엘리먼트의 본래 기능을 그대로 이용하는 것이 좋습니다. 실생활에서의 배달과 전달을 UPS와 같은 전문 전송 업체에게 맡기듯 서식 요소의 데이터는 form에게 믿고 맡기는 것이 좋습니다.
더불어 서식 요소에 대한 유효성 검증을 자바스크립트로만 처리하는 경우가 종종 있습니다. 이 역시 바람직하지 않은 것으로, 반드시 클라이언트와 서버 양쪽 모두에서 유효성 검증에 대한 처리를 해 주어야 사용자의 실수로 인한 문제를 막을 수 있습니다.
다음은 꼭 한번 읽어보세요: (
오픈 웹은 현재
구글 그룹스로 변경되어 아래 링크를 확인할 수 없을 수 있습니다)
수칙 3. 사람을 믿고, 기계를 의심하라지금까지는 지식과 정보, 기술적인 부분에 대해서 두가지 수칙을 들었고, 그 안에서 몇가지 작은 이야기들을 전해 드렸습니다. 이제 세번째 수칙으로 ‘사람을 믿고, 기계를 의심하라’고 말씀을 드리면서 수칙 3.1 ‘사람을 믿어라’라고 부탁드리고 싶습니다.
3.1 동료를 믿어라첫번째로 웹 기획자는 그 누구보다 열심히 웹 접근성와 사용성에 대해서 고민을 하는 사람입니다. 그들이 다소 거만하고 잘난 체를 할지 모르지만 그들의 머리 속에는 우리들이 걱정하는 것 이상으로 많은 것들을 고민하고 있다라는 사실을 잊지 마시길 바랍니다.
웹 에이젼시에서 일을 했던 경험을 돌이켜보면 제가 사내에서 웹 접근성과 표준에 대한 이야기를 꺼낼 때 그리고 설득하는 과정에서 디자이너를 이해시키는 일이 가장 쉽지 않았었습니다. 그러던 중 함께 스터디를 하던 디자이너 친구 한 명이 이런 질문을 하더군요. ‘과연 웹 표준을 지킬 수 없는 디자인이 있느냐? 있다면 어떤 디자인이냐?’라고 말이죠. 그날 스터디에서는 저를 비롯해서 여러명의 사람들이 한국의 비주얼이 강한 디자인 때문에 표준을 적용하기 어렵다라고 목소리를 높이고 있었거든요. 하지만 막상 그 디자이너 친구의 질문에 어떤 디자인이 절대 표준 기술만 가지고 만들 수 없다라고 대답하지 못했습니다. 물론, 실무에서 작업을 하다 보면 디자인 때문에 마크업과 css 작업에 애를 많이 겪고 있고, 종종 해결책을 찾지 못하고 CSS Hacks을 사용하기도 합니다. 하지만 돌이켜보면 정말 길이 없어서 그랬다기 보다 시간이 부족해서 차선책을 택했던 적이 더 많았음을 스스로 깨닫게 됩니다. 저는 그 날 이후로 함께 일 하는 웹디자이너를 설득하는 일을 그만 두었습니다. 그리고 까짓것 한 번 해볼테니 날 믿고 디자인을 해달라고 부탁하곤 했습니다.
이 자리에 모인 대부분의 분들이 웹 퍼블리셔 또는 UI 개발자라는 명함을 가지고 계실것으로 생각됩니다. 그만큼 그 어느 직군보다 웹 표준과 접근성에 대해서 관심이 높고, 열정이 대단하다고 생각합니다. 어떤 일이든 시작이 가장 어렵고 첫 걸음을 옮기는 것이 가장 힘듭니다. 그 큰 걸음을 지금 여러분이 떼고 있으신 겁니다. 때문에 저는 감히 여러분 모두를 웹 표준 전문가라고 말씀드립니다. ASP든 JSP든 서버단에서 개발 업무를 보고 계신 개발자님들 동료 UI개발자 분들의 실력을 믿어보시길 바라겠습니다.
문화적인 차이일 수 있겠지만 한국은 지나치게 고객을 무시하고, 의심하는 경향이 있습니다. 사이트 발주자인 클라이언트의 무지함을 욕하고, 사이트 사용자인 고객의 멍청함에 잔득 걱정을 합니다. 때문에 온갖 보안 프로그램을 깔기를 강요하고 프레임셋으로 URL을 감추고, 우클릭을 막아버리고, 온갖 문서를 보면서 동의를 강요합니다.
개발자들의 논리 중에 가장 우수운 것이 바로 ‘자신 역시 한 명의 사용자(고객)이다’라는 점입니다. 그렇게 사용자들을 무시하면서 자신을 또 한 명의 사용자로 생각한다는 것. 결국 누워서 침을 뱉은 것 아닌가요.
또 한가지 개발자들은 오로지 코딩만 잘 하면 된다고 생각합니다. 발주자건 사용자건 그들을 상대하는 건 기획자라고 생각합니다. 웹 접근성과 웹 표준에 대한 인식 제고나 설득 역시 기획자가 해야할 것이라고 생각하고, 웹 퍼블리셔니 UI개발자니 하면서 갑자기 한 자리를 차지하기 시작한 사람들이 해야 한다고 생각합니다.
만약 개발자 직군이 명확하게 클라이언트단과 서버단으로 구분되어 서버사이드개발자가 순수하게 로직만 작성한다면 반드시 틀린 말은 아닐 수 있습니다. 하지만 제가 서두에서 개발자의 범위를 포괄적 개발자로 설정한 것 처럼 현실은 그렇치 않습니다. 그리고 앞으로도 상당한 기간동안 지금의 현실이 갑자기 바뀌지도 않을 것으로 생각됩니다. 지금, 개발자인 사람들 모두가 같은 고민과 철학으로 고객을 바꾸고 변화 시킬 필요가 있는 겁니다.
3.2 기계를 의심하라개발 경험이 오래되신 분들은 과거
핫도그 웹 에디터나
나모 웹 에디터 등을 기억하실 겁니다. 어도비의
고라이브도 있군요.
드림위버의 초기 버전도 언듯 떠오르실 분도 계실겁니다. 당시의 이런 에디터 툴은 편리하게 홈페이지를 만들어 주기는 했지만 웹 표준을 몰랐던 브라우저들 처럼 툴 역시 웹 표준을 인식하지 못했습니다. 때문에 불필요한 마크업과 CSS를 만들어 냈고, 호환성이 확보되지 않은 자바스크립트 코드를 마구 집어 넣었습니다. 지금은 드림위버등 많은 에디터들이 웹 접근성과 웹 표준 스펙을 반영하고 있지만 여전히 일부 에디터는 잘못된 코드와 DTD의 생략을 기본 값으로 설정해 놓고 있습니다.
특히 나모 웹 에디터는 저 역시 98년 당시에 많이 사용했던 에디터입니다. 이 에디터는 자바스크립트를 자동으로 생성해 주는 마법사 툴이 있었는데, 호환성이 확보되지 않은 스크립트 코드를 만들어 냈던 것으로 기억합니다. 그 코드가 IE전용이었다는 사실은 한참이나 지나서야 알게된 사실들이었습니다. 초기 드림위버가 만들어낸 코드 역시 엉망진창이었습니다. 초기 버전에서 만들어낸 엉망의 코드 때문에 많은 개발자들이 워지익 툴의 편리함에도 불구하고 나모 웹 에디터나 드림위버 등의 사용을 꺼리게 되기도 했었습니다. 다행히 최근 출시된 새로운 버전이나 에디터들은 많은 향상이 있어 과거처럼 엉망인 경우는 드믄것 같습니다. 옛 말에 장인은 연장 탓을 하지 않는다고 하죠. 훌륭한 웹 개발자라면 툴 때문에 웹 표준을 지키기 어렵다라는 말은 하지 않아야겠죠. 하지만 툴이 가져다 주는 편리함과 생산성은 역시 무시할 수 없을 것입니다. 때문에 어떤 툴을 자신의 주력 툴로 결정한 것인지는 매우 중요하고, 잘 선택되어야 합니다. 무료든 유료든 아주 다양한 에디터들이 존재하고 있습니다. 충분히 검증된 제품을 선택하시길 바랍니다.
또 한가지, 개발자들의 PC는 회사 사정에 따라 차이는 있겠지만 일반적으로 부족하지 않은 스펙을 가지고 있습니다. 하지만 인터넷에 접속하는 모든 PC가 아이온과 콜 오브 듀티같은 인기 게임을 실행시킬 수 있을 만큼 멋지진 않습니다. 학교나 관공서같은 곳의 PC는 생각보다 오래된 것이 많습니다. 이미지와 플래쉬 무비로 무겁게 제작된 사이트들 때문에 PC를 몇 번이나 리부팅해야 하는 사람들도 있을 것입니다.
Markup Validation Service
마지막으로 웹 표준을 열심히 지키고 계신 여러분들이 절대로 잊지 말아야 할 한가지를 말씀 드리겠습니다. HTML과 CSS에 대해서 충분히 의미 있게 그리고 호환성이 확보된 표준 스펙을 따랐을 경우에 우리는 W3C의 벨리데이션 서비스를 통해서 이같은 유효성 검사 통과 화면을 받아 볼 수 있습니다. 하지만 이 순간 여러분은 과연 이 결과가 타당한지에 대한 의구심을 가질 필요가 있습니다. 벨리데이션 검사는 단지 코드에 대한 문법 검사일 뿐입니다. 파란 하늘 이미지에 ‘용광로’라고 적어 넣은 alt 속성을 확인 했더라도 이 검사는 초록색 ‘성공’ 메세지를 멋지게 보여줄 것입니다. 과연 제대로 만든 페이지였을까요?
마치며큰 수칙 3가지를 전해 드리면서 그리고 첫번째 수칙을 통해서 웹 개발자에게 있어서 웹 접근성을 향상시키는 가장 확실하고 정직한 방법은 '공부'라고 했습니다. 웹 표준 스펙을 얼마나 제대로 알고 있는지 그리고 얼마나 명확하게 적용할 수 있는지가 가장 중요하다고 생각합니다. 그래서 저는 웹 표준을 웹 개발자에게 있어서 '기술'이라고 생각하고, 웹 접근성은 다른 사람을 생각하고 타인을 배려하고자 하는 '철학'에 빗대어 의미를 전달해 드리고자 했습니다. 기본적으로 웹 접근성 역시도 여러가지 명세와 가이드로 틀을 갖춰 나가고 있지만 근본적으로 사람에 대한 마음을 담는 것이라고 생각하기 때문입니다. 개발자는 코드만 잘 짜면 된다라는 생각은 이제 버려야 합니다. 이 코드가 사람을 차별하는 칼이 될 수 있음을 아셔야 합니다. 그래서 더욱 더 왜 내가 웹 접근성을 고민해야 하는지에 대한 자기 철학이 필요한 이유입니다. 끊임 없는 자기 계발과 철학의 발견. 이 이야기를 해 드리고 싶었습니다.
