보통 웹 문서에 있는 제목들 간의 구분을 위해 우리는 자신의 취향에 맞는 여러 형태의 글자들을 사용해 왔다. 하지만, 이런 글자들이 화면 해독기 사용자들에게는 그저 무의미한 글자로 들릴 수도 있음을 생각해 본 적이 있는가?

이런 제목들 간의 구분을 위해 사용된 글자들이 화면 해독기에서 과연 어떻게 들리는지에 관한 글을 읽어보면, 구분 글자들의 사용에도 세심한 배려가 필요하다는 것을 깨닫게 된다.

물론, 위의 글에 예시된 보기들은 영어판 JAWS 화면 해독기를 본보기로 들었지만, 시각 장애인들이 처해있는 상황을 이해하는 데에도 도움이 될 수 있을 것이다.

요는, »와 같은 반복적인 글자 형태로 된 것은 피하고, → (→)와 ★ (★)와 같은 특수 유니코드 글자들은 화면 해독기가 올바로 읽어들이지 못할 수도 있으므로 사용에 주의를 요한다.

결국 가장 무난한 것은 수직 막대 (|), 점 (·) 혹은 수평 막대 (-)가 사용될 수도 있겠지만, 가장 중요한 것은 구분 글자들 주의에는 항상 빈 공간으로 둘러싸서 시각 장애인이든 아니든 모두에게 제목들 간의 구별을 쉽게 해주라는 것이다.

여기서, 제목들 사이를 구분해 놓는 글자로 많이 쓰이는 수직 막대(|)의 경우에는, 차라리 다음과 같은 CSS의 테두리 적용 용법을 사용해서 시각적 효과에 관련된 내용은 아예 웹 문서에서 따로 빼줄 수도 있을 것이다.

#navlinks li {
  display: inline;
  margin-right: 0.5em; padding-right: 0.75em;
  border-right: 1px solid #99C;
  font-weight: bold;
}
 
#navlinks li.last {
  border-right: 0;
}

이 글을 읽으면서 또 한 가지 발견한 사실은 청각 기능을 담은 CSS 표준의 존재이다. 물론, 이것도 영어를 기준으로 한 것이지만, 이런 청각 CSS 표준을 지원하는 화면 해독기가 발표된다면, 웹 접근성에 민감한 개발자들은 더욱 세심한 주의가 필요할 것이다.

아무리 웹 접근성을 주장해도 현실은 아직 갈 길이 멀고, 웹 개발자들에게는 더욱 세심한 관심이 요구된다.

제목은 말 그대로, 정확한 적용 시점은 아직 알려지지 않았으나, 차기 버전의 WebKit의 변화에 대비하기 위한 Dashboard Widget 개발자들이 취해야 할 조치사항이다.

Surfin’ Safari의 Blog에 올려진 글에 의하면, 차기에 발표될 WebKit에서는 그 동안 HTML과의 호환성을 이유로 여러 요소들에 사용되었던 XML 형태로 된 단독 꼬리표 닫침 용법(예를 들어, <script src="myscript.js" />)들을 실제로 꼬리표가 적절하게 닫힌 것처럼 인식하게 하는 기능이 제거될 것이며, 따라서 이러한 꼼수(hack)들을 수정하지 않으면 해당 widget들의 스크립트는 코드가 실행되지 못하게 되면서 제대도 작동하지 않을 것이라고 경고하고 있다.

그래서, 차기 버전의 WebKit에서도 자신의 widget들이 제대로 작동되게 하려면, 단독 꼬리표 닫침 용법을 사용했던 <script><canvas>의 경우 또 하나의 닫침 꼬리표를 추가해주어야 한다.

<script src="myscript.js"></script><canvas></canvas>

개인적으로, 앞에 공백 하나를 더한 단독 꼬리표 닫침 용법이 단지 HTML과의 호환성을 위한 하나의 hack이였다는 사실을 미쳐 눈치채지 못했다.

결국, Doctype!을 지정하였더라도 xhtml 문서를 application/xhtml+xml 혹은 text/xml MIME 형태로 서버에서 전달하지 않는 한은, 일반 html 문서일 수밖에 없다. 그렇다고, 웹 문서를 진정한 xhtml 형태로만 전달할 수는 없는 이유는 썩을 놈의 Microsoft Internet Explorer가 진정한 XHTML 문서를 전혀 다룰줄 몰라서 단지 문서 통채를 내려받기 때문이다.

이러한 상황에서, 굳이 xml 형태의 문서가 필요하지 않는 경우, XHTML을 가장한 HTML을 작성할 것이 아니라, 아직은 HTML4 형태의 문서로도 충분할 것이라고 말을 끝맺고 있다.

모든 웹 브라우져들이 아직 XHTML을 제대로 처리하지 못하는 과도기적 상황에서 웹 개발자들에게는 XHTML로의 완전한 이주는 험란한 일이겠지만, 과거에만 머물러 있을 수도 없는 노릇이다. 그래서, 정작 중요한 것은 단지 표준에 맞는 마크업(markup) 뿐만이 아니라, HTML4 시절에는 더딜 수밖에 없었던 내용으로부터의 표현과 동작의 완전한 분리, 웹 접근성 그리고 의미론적 마크업이 XHTML로 전진해야 하는 이유일 것이다.

위 내용과 관련해서 추가 참고가 될 만한 글들:

웹의 정신 중에는, 모든 이들에게 공평한 지식의 전달에 가치를 두고 있으며, 여기에는 어떠한 접근의 차별도 없어야 한다.
그렇다면, 혹시라도 있을 수 있는 정보 접근의 장애물들을 없애기 위해 자신이 사용하고 있는 블로그(blog)에는 어떠한 것들을 점검해 볼 수 있을까?

여기서는 참고를 위해서 American Foundation for the Blind(AFB)에 계시된 글들 중에서, 시각 장애인들에게도 접근이 용이한 블로그 만들기라는 제목의 글을 옮겨놓는다.
시각 장애인들에게도 접근이 용이한 블로그(이)란 제목의 글 마저 읽기 →

테이블(table) 꼬리표는 1994년 HTML 2.0에서 소개되었다. 이들의 등장은 원래 산출 테이타들을 담아 놓을 목적이었으나, 잘 못된 습관으로 웹 페이지의 내용들을 레이아웃(layout)하기 위한 수단으로 오용되어 왔으며, 현재는 이것이 주 사용 목적이 되어버린 상태이다.
지금은 많은 웹 표준화 노력들로 그 수가 줄어들기는 했지만, 아직까지도 화면 글자 해독기의 접근을 방해하는 등의 웹 접근성을 떨어뜨리는 이들의 무분별한 사용은 여전하다.

웹 페이지의 레이아웃과 전달을 위해 Cascading Style Sheets(CSS)이라는 훌륭하고 바람직한 수단이 존재하고 있는 지금, 더 이상 레이아웃을 위한 테이블의 사용은 단지 불합리한 악습을 털어내지 못하는 의도적 무관심일 뿐이다.

그렇다면, 접근 용이한 테이타 테이블은 무엇이고, 어떻게 구현되어야 하는가?
아래의 글들에 그 내용과 본보기들이 잘 설명되어 있다.

올바른 용법의 구현은 효율성 극대화의 원천이 된다.

여기서 Microsoft 헐뜯기 하나 더 – 예전 보다는 많이 줄어들었지만, 아직도 그들의 홈 페이지는 웹 페이지 구획을 위해 테이블 꼬리표들을 사용하고 있다.
이유는 분명하다. 그들의 대표 브라우져인 Internet Explorer 6는 아직도 발표된 지 벌써 8년이 지난 CSS2를 제대로 지원하지 않고 있다. 그렇다고 차기에 발표될 IE 7에서는 상황이 더 개선될 것이라는 기대를 할 수도 없는 상황이란다.

Markdown은 간단히 말하면 웹 저자들을 위한 글자-HTML 변환 도구이다. 그래서, 읽기 쉽고 쓰기 쉬운 일반 글자 형태의 글을 손쉽게 (X)HTML 문서로 변환할 수 있단다.

이미, WordPress에서는 1.2 버전부터 이 Markdown plugin을 제공하고 있었지만, 여태 모르고 무심결에 넘겼었다. (WordPress v2.0부터는 새로 추가된 시각적 HTML 편집기로 인해, 이 기능을 꺼놓지 않는 이상은 더 이상 사용할 수 없단다.)

요새는 거의 누구나가 자기 blog를 운영하고 있듯이 기본 HTML 문서를 다룰 일들이 많은 환경에서 Markdown은 또 하나의 유용한 도구로 사용될 수 있을 듯 한데, 부담이 되는 것은, 또 하나의 문법을 익혀야 한다는 것이다.
하지만, 처음 소개 문장에서도 밝혔듯이 Markdown의 기초 문법은 비교적 간단하며, 한 번 익히고 나면 직접 (X)HTML로 쓰는 것보다 시간과 노력이 덜 들어갈 듯 하다.

그리고, HumaneText.service라는 것을 설치하면, 어느 글자 편집기에서든 메뉴막대의 서비스 항목에서 선택하여, Markdown 형식의 글을 XHTML로 간편하게 변환할 수도 있단다.

당분간, MarkDown Cheat Sheet을 붙여놓고 참고하면 금새 익힐 수 있을 듯. 😉