• W3C 한글 번역문 HTML 4.01 규격 (http://trio.co.kr/webrefer/html/cover.html)
  W3C 추천안, 1999년 12월 24일

• 초보용 HTML 배우기(http://trio.co.kr/webrefer/httut/htutmain.html)

참고 Site

• CSS Validation Service(http://jigsaw.w3.org/css-validator)
CSS 스타일 시트 기능 검증 서비스를 받을수 있는 페이지입니다. CSS Validator version 2.0 CSS검증 소프트웨어도 다운받으실수 있습니다.

• CSS1 카스케이딩 스타일쉬트 규격 번역문(http://trio.co.kr/webrefer/css1/rec-css1.html)
  W3C 추천안 1996년 12월 17일, 1999년 1월 11일 수정
  Translator: 이태호 (Taeho Lee)

• CSS2 규격 한글 번역문(http://trio.co.kr/webrefer/css2/cover.html)
  w3c 추천안 1998년 5월 12일
  Translator: 이태호 (Taeho Lee)

• CSS 매뉴얼 CSS 소개(http://trio.co.kr/webrefer/css/cssintro.html)

• YAHOO! YUI Reset CSS(http://developer.yahoo.com/yui/reset/)

• YAHOO! YUI Base CSS(http://developer.yahoo.com/yui/base/)
  

참고 서적

• CSS 마스터 전략 : 고급 웹 표준 사이트 제작을 위한(CSS Mastery: Advanced Web Standards Solutions)
  Andy Budd, Simon Collison, Cameron Moll 지음 | 박수만 옮김

몇년전쯤만 하더라도, 여러 지자체에서 자신의 홈페이지에서 TTS(Text To Speech :음성 출력 솔루션)를 적용하였었다.

시각장애인들을 위한 서비스로 꼭 해야만 되는줄 알았던 시절(나 역시 그랬었다).

많은 돈을 들여 TTS를 도입하고, TTS가글을 정상적으로 읽어 주지 못해 페이지들을 조정하고...

하지만, 2006년에 있었던 '웹2.0 시대의 웹 접근성 제고 전략세미나'에서 시각 장애인의 시연과,

제발 TTS좀 설치하지 말아달라는 이야기를 듣고는 내가 좁은 범위에서만 생각을 하고 있었구나 하는 것을 느끼게 되었다.

지금은 대부분 진행하는 지자체 사업에서 있었던 TTS를 걷어 내고 작업을 하고 있다.

하지만, 2009년 웹 접근성 준수 의무화(장애인 차별금지 및 권리구제 등에 관한 법률; 2009.04.11) 가 되고 나서

지자체들로 이상한 전화가 걸려 오고 있다. 웹접근성을 준수하려면 TTS를 해야 한다고...

연배가 있으신 과장님이나 계장님에게서 뿐만 아니고, 실제적으로 홈페이지를 담당하고 있는 전산 담당자에게서도

장애인 단체에서 문서가 하나 왔는데 우리 사이트에 TTS를 설치해야 하는 것이 아니냐는 이야기가 나올때는

참 어디서 부터 어찌 설명해야 할지...

나 역시초반에 TTS가 시각장애인의 웹 사이트 이용에도움을 줄것으로 생각했었다.

하지만,웹에 접근하는 시각장애인들은 자신의 컴퓨터에 스크린리더가 설치되어 있다는 것을 인지하고 생각해보자.

그들의 입장에서보면, ActiveX 설치나 기타 등등의 부분을 제외 하더라도 TTS가 적용되어 있는 웹사이트에 접근하는 순간

2가지 음성이 들려오게되어 결국 TTS를 통해서 나오는 소리는 소음에 불과하게 된다.

TTS 역시 분명히 쓰여져야 할 곳은 있다고 생각되어진다. 하지만 홈페이지만을 놓고 본다면,

차라리 스크린리더에서 정상적으로 정보를 읽을 수 있도록 SITE 구축에 신경을 쓰는 것이 웹 접근성 부분에서는

정답이 아닐까 싶다.

웹 접근성이라는 이야기가 나오기 시작한 이후, 여러 사이트에서 웹 접근성을 적용하면서 느낀 것은 다음과 같다.

먼저, 웹 접근성 강화 프로젝트에서의 가장 중요한 것은 현재 사이트의 상태를 파악하는 것이였다.
현상태를 파악함으로서 전체일정을 계획할 수 있으며,

개발사가 같은 하나의 사이트는 보여지는 웹 접근성의 취약 부분이 거이 모든 페이지 들에 대하여

공통적으로 나타나는 것들이 많아,

그런 부분들에 대하여 정리하고, 처리 방법을 정규화 하여지시하면, 고급의 기술을 가진 개발자나, 코더가 아니더라도

학습에 의하여 많은 부분의 해결이 가능하며, 추후 관리가 용이하였다.

또한, 그렇게 판별 되어진 웹 접근성 취약점을 종류 별로 분류고,

페이지 별로 단순한 작업으로 보완이 가능한 부분과, 그렇지 않은 부분을 서로 다른 작업을 시키는 것이 가능하였다.

실예로, 초급자들에게 alt 태그에 대한 부분을 처리하게 하고,

이보다 난이도가 있는 웹접근성 취약점 개선은 경험이 있는 개발자/디자이너/코더 들에게 맞겨 작업 시간을 단축하였다.

마지막으로, 서로 작업한 부분을 교차 체크 하여,미처 처리하지 못하고 지나가는 취약점을 최소화 하였다.

이런 과정에서어려웠던 부분은 웹 접근성과 관련하여 문제(막히는 부분)이 발생 했을시,

즉시 대답해줄 수 있는사람이 없어, 나름의 해답을 찾기 위한 예상치 못한 시간 소요가 있었다는 것과,

담당자의 몰이해에 따른 웹 접근성에 위배되는 요구사항들(팝업, 플래시의 기능, 입력 Fome에서의 자동 이동 등)

에 대하여 이해를 시키는 과정(100% 이해 시키고 웹 접근성에 맞게 구축 하지 못한 부분도 있음)을 들 수 있겠다.