웹표준·크로스브라우징 붐이 불었던 2004년 당시에는 W3C validator이 상당히 중요했습니다.
정확히 뭔지는 모르겠지만, 웹표준이 붐이라 하고 그걸 검사해 주는 사이트에서 통과만 되면 배너를 달 수 있고 무언가 있어 보이게끔 만들 수 있었기 때문입니다.
따라서 당시 웹표준 검사기를 통과한 사이트들 하단에는 위와 같은 배너들이 달려있는 것을 많이 볼 수 있었습니다.
W3C validator에 통과되었다고 웹표준과 접근성을 준수했다는 의미는 아닙니다.
실제로 문법과 지정된 HTML DTD에 해당하는 엘리트먼트들이 있는지만 체크하고 판단하기 때문입니다. HTML 문서 내에 적절한 엘리트먼트들을 사용했는지는 판단하지 못합니다. 따라서 검사기 통과를 목적으로 마크업을 했다고 웹접근성이 향상되고 모든 브라우저에서 동일하게 구현된다는 생각은 잘못된 생각입니다.
장애인차별법(이하 장차법) 시행으로 인해 공공기관·대기업은 웹 접근성을 준수해야 하고 국가에서 한국 웹 접근성가이드를 만들어 배포했지만, 실제 장애인들이 이용할 때 불편함을 많이 호소합니다. 없는 것보다는 낫지만 접근성 가이드를 준수한다 하여 장애인들이 정말 편하게 이용할 수 없는 것과 같이, «W3C validator에 통과한다 하여 완벽한 웹사이트를 제작했다는 것이 아니다.»라는 것을 말하고 싶습니다.
그럼, 왜 블로그에 소개하는가?
제가 다니는 곳은 웹디자인·마크업 과정이 전공필수입니다.
비개발 학과기에 웹표준과 접근성, 올바른 엘리트먼트 사용에 대한 개념을 기반으로 하지는 않지만 하드코딩으로 웹진을 만드는 과정을 거쳤습니다.
여기서 많은 학생들이 어려움을 호소한 것이 «자기가 생각한 대로 안 나오고 깨진다는 것»입니다.
특정 브라우저를 기준으로만 작업했기에 크로스브라우징 고려는 제외로 하고 원인을 찾아봤더니 태그를 사용할 때에 열고 닫는 것을 까먹거나 제대로 입력 하지 않아서(없는 속성을 삽입한다던지) 발생한 것이었습니다.
주변에 도움을 요청하지만, HTML 퍼블리싱에 최적화된 에디터를 사용하는 것도 아니고 모든 것이 메모장에서 이루어진 것이기 때문에 가독성이 딸리고, 특정한 규칙이나 Indent를 주면서 마크업을 한 것이 아니라 원인을 찾아내기가 쉽지 않습니다.
처음 마크업을 접하는 사람들은 반드시 W3C validator을 이용하자
웹 표준, 접근성, 크로스 브라우징에 도움은 되지 않지만, 적어도 기본문법과 자신이 실수한 부분을 파악하기 위해서 웹 퍼블리싱을 처음 접하는 사람들에게 W3C validator를 권하고 싶습니다.
HTML/CSS는 어렵지 않아요.
PHP, C, Javascript, Phython에 비하면 정말 쉬운 언어입니다. 하지만 초보자들은 어려워합니다. 정말 이 분야에 관심 있어하는 게 아니라 반 강제로 하는 경우가 많기 때문에 큰 관심을 가지지 않습니다. 아무리 옆에서 설명해 줘도 한 귀로 듣고 흘려버립니다. 그리곤 나중에 동일한 문제로 또 질문합니다.
따라서 자기가 직접 왜 문제가 있는지 찾고 스스로 해결할 수 있도록 해주는 것이 중요하다고 생각합니다. 이것의 기본이 W3C validator이라 생각합니다.