내용 요약
“꼬리표(tag) 생성” 에서부터 “WYSIWOYS 생성”까지. Roberto Scano씨의 글에는 웹 세대 간 웹 접근성에 관한 문제들과 현재의 위치, 그리고 앞으로 우리가 기대할 수 있는 것들에 관해서 요약해 놓았다. 웹 접근성에 대해서 이해하고 고민하는 데 도움이 되는 글로 이곳에도 옮겨 놓는다.
저자: Roberto Scano
Open Web 짝사랑. iOS Programming.
“꼬리표(tag) 생성” 에서부터 “WYSIWOYS 생성”까지. Roberto Scano씨의 글에는 웹 세대 간 웹 접근성에 관한 문제들과 현재의 위치, 그리고 앞으로 우리가 기대할 수 있는 것들에 관해서 요약해 놓았다. 웹 접근성에 대해서 이해하고 고민하는 데 도움이 되는 글로 이곳에도 옮겨 놓는다.
저자: Roberto Scano
여기에 옮긴 글은 웹 개발 시에 항상 주의해야 할 비교적 긴 몇 가지의 항목들을 열거해 놓았다. 여기에 나열된 실수들을 모두 피할 수만 있다면 그것은 무난한 웹 개발이 잘 진행되고 있다는 뜻일 것이다. 고백하자면, 과거에는 나 자신도 이들 중 적어도 몇 가지는 같은 실수를 범했을 수 있으나, 이 항목들을 참고로 앞으로는 적어도 같은 실수를 피하는 데 도움이 되었으면 한다. 웹 개발시 저지르는 실수들(이)란 제목의 글 마저 읽기 →
개인적으로 한국 사용자들을 위한 Dashboard Widget을 개발하면서 몸소 느끼고 체험했던 몇 가지 사실들을 적어놓고자 한다.
사실 하나.
대부분의 한국 웹 사이트들은 그 구조가 아직 XHTML 형태로의 전환을 이루지 못하고 있다. 따라서, widget에서 원하는 정보를 XMLHttpRequest Object를 사용해서 가져오는데 상당한 벽에 부딪히게 된다.
이것은, 필요한 정보를 XML 데이터 형태로 직접 접근할 수 없게 됨으로써, 클라이언트 쪽에서는 입맛에 맞는 Document Object Model(DOM)로의 접근과 수정이 차단되어 버린다.
결국, 차선책으로 XMLHttpRequest Object의 responseText 속성을 가지고서 원하는 정보에 접근할 수밖에 없게 되는 샘.
이쯤 와서, 그나마 막강한 힘을 발휘하게 되는 것이 바로 JavaScript의 RegExp Object이다.
물론, DOM 형태로의 유연한 접근과 수정이 불가능하고, 어쩌면 거치지 않았어도 될 불필요한 과정이겠지만, 어쨌든 원하는 정보를 그야말로 긁어올 수는 있다. 하지만, 여전히 아쉬운 것은 마찬가지.
사실 둘.
웹 표준 준수의 문제.
한국 대부분의 사이트는 표준 준수에 따른 이점들을 제대로 인식하고 있지 못하는 듯하다.
이것이 widget 개발과 무슨 상관이 있느냐고?
엉성한 구조로 된 웹 페이지로의 접근은 어떠한 user agent들에도 불리한 영향을 끼치기 마련이다.
사실 셋.
웹 정보 접근 용이성의 문제.
가끔은, 심한 경우 웹 사이트의 특정 정보가 Windows에서만 적용되는 ActiveX control 혹은 JScript (Windows Script Technologies) 등의 기술만 사용해서 전달되어 보이는 경우가 있다. 이렇게 되면 다른 플랫폼을 통한 정보 접근은 완전히 막히게 된다. 다른 길로 돌아가는 접근 방도가 전혀 없을 때에는, 다른 곳으로 눈을 돌릴 수밖에.
짧지만, 이렇게 해서 지금까지 적어놓은 내용을 한 문장으로 정리를 한다면, 불행하게도 “한국 사용자들을 겨냥한 widget을 개발하려면, 웹 표준의 파괴로 인해 생긴, 높은 장벽들로 둘러쌓여 진 정보에도 무사히 접근할 수 있는 여러 꼼수들에 단련이 되어 있어야 한다.“가 되겠군.
끝으로, 그나마 잘 갖추어진 한국의 인터넷 하드웨어 기반 환경에 걸맞은 잘 짜인 웹 사이트가 많이 늘어나길 기대하며…
웹 표준이란 말은 사람마다 다른 뜻을 지닐 수도 있다. 어떤 이들에게 이것은 ‘테이블을 안 쓰는 사이트’일 수도 있고, 또 다른 이들에게는 ‘표준에 맞는 코드를 사용하는 것’일 수도 있다. 하지만, 웹 표준이란 이런 것들보단 훨씬 더 광범위한 뜻을 내포하고 있다. 웹 표준에 맞게 제작된 사이트는 표준(HTML, XHTML, XML, CSS, XSLT, DOM, MathML, SVG 등)을 준수해야 하며 그에 따른 올바른 용례들(표준을 준수하는 코드, 접근이 쉬운 코드, 의미 구조론적으로 올바른 코드, 알아보기 쉬운 URLs 등)이 적용되어야 한다.
한 마디로, 웹 표준에 맞게 제작된 사이트란 군더더기 없고, 깨끗하며, CSS 기반에, 접근이 쉽고, 사용하기 쉬우며, 검색 엔진들이 색인하기에도 쉬운 사이트를 말한다. 웹 표준 검사 항목(이)란 제목의 글 마저 읽기 →
요새 폭설 피해 기사들을 보면서, 별 도움은 안 되겠지만, 뜬구름 widget에도 기상 특보 상황을 표시해 주는 기능을 추가해 놓으면 알맞겠다는 생각에 기상청 홈페이지를 살펴보았다. 물론 기상 특보 상황은 대문에서 바로 살펴볼 수 있으니, 문제는 이놈을 XMLHttpRequest Object로 끌어오기만 하면 되는 샘.
생각보다 쉬우리라는 기분으로 기능을 추가하고 뜬구름을 실행시켜 보았으나…감감무소식이다.
결국, 이런저런 궁리 끝에 console.log를 살펴보니, 다음과 같은 자국이 찍혀 있다.
[526] http://www.kma.go.kr/index.jsp:Error - DOM Exception 3
DOM Exception 3? 뭐지? Document Object Model Exception 3???
문제의 원인은, 기상청 홈페이지의 html 소스를 보면 금방 알아차리게 된다.
맙소사. !DOCTYPE은 물론이고 <html> 시작 꼬리표까지 없단다. (그렇다면, 맨 밑의 </html> 꼬리표는 실수로 붙었단 말이냐?)
정부 사이트들이 웹 표준 나 몰라라 하는 상황은 이미 알고 있었지만, 이 정도일 줄이야…
이것은 사이트 제작자의 실수 이전에, 기본을 지킬 수도 없는 무지에서 나온 결과랄 수 밖에 설명할 도리가 없다.
앞니가 빠진 꼬리표 덕분에, html 문서도 일반 글자 문서(plain text)도 아닌 어처구니 없는 상황인지라 XMLHttpRequest로는 원하는 정보를 끌어올 방법이 없다. (물론, 다른 꼼수는 있겠지만, 힘 빠지는 것은 마찬가지.)
그나마 아쉬운 마음에 대문에 쓰여 있는 국민으로부터 사랑받는 열린 기상청
이라는 문구 때문에라도, 소귀에 경 읽기 심경으로, 문의 게시판에 정정 요구를 해봤지만, Safari와 Firefox에서는 글도 올라가지 않는다. 참으로 징하다. 🙁
전자 정부 부르짖는 그들은 실로 대~충 그까짓 거 뚝딱 정부로세. 👿
또 다른 탄생을 준비하고 있는 대~충 그까짓 거 뚝딱 현장 방문하기 << 말이 디지털이지 그 속 내는 그까짓 거 대~충하는 섬세하지도 못한 아날로그이다.