왜 RSS에 description을 사용해야 하는가.

부분공개(?)가 왜 더 바람직한지는 몇가지 이유가 더 있습니다.
일단, 그 전에 “부분공개”라는 용어는 잘못되었음을 지적하고 싶습니다. “TEXT요약(description)”과 “encoding된 전문(contents)”의 차이입니다.
우선 RSS 2.0의 기본스펙은 description만 존재합니다. description은 HTML코드가 사용되지 않은 Plain Text만 대상으로 합니다. content:encoded는 마크 필그림이 추가로 확장제안(관련링크1, 관련링크2)한 것으로 “표준”은 아닙니다. 따라서 매우 많은 리더기가 content:encoded를 지원하기는 하지만 아닐 수도 있습니다. content:encoded만 사용해서는 안되는 이유입니다.
또한, description에 HTML코드를 담아 보내는 경우도 있는데(일부 국내 블로그들), 이건 RSS 규격 자체를 제대로 이해하지 못한 것입니다. description안에는 반드시, HTML이나 XML이 빠진 Plain Text만 전달해야 합니다. (따라서 description안에 img나 a 태그들이 포함되어 있으면 안됩니다.) - 물론 필요에 따라 CDATA나 Entity처리된 HTML을 보낼 수는 있습니다. 이것을 해석하는 방식은 리더기에 따라 다를 수도 있습니다.

가장 바람직한 것은 description에 해당 컨텐트에 대한 Plain Text로 된 설명을 싣고, content:encoded에 HTML이 들어있는 본문을 싣는 방법입니다. 국내 블로그 서비스들 대부분이 이를 지원하지 않고 있습니다. 몰라서 그럴 가능성이 제일 큽니다.
이게 안된다면 차선책은 Plain Text로 된 description만 사용하는 것입니다.

문제가 되는 것은, description에 Plain Text만 담아서 보내는 건 좋은데, 그것이 “본문의 일부만, 특히 앞부분만 잘라서 보내는 경우”입니다. (소위 말하는 “일부공개”라겠죠. 개념은 틀렸지만.)
저는 이게 문제가 되지 않는다고 생각은 합니다만, 어떤 이들에게는 불만일 수 있습니다.
“요약”도 아니고, “인코딩된 전문”도 아닌 어정쩡한 포지션이라는 생각이 들 수도 있기 때문이겠지요.

사실, 제대로 RSS를 지원하는 블로깅 툴이라면(예:MovableType, WordPress등) 이 description에 사용하기 위한 별도의 excerpt입력항목을 두고 있기 마련입니다.
사용자가 이 항목에 별도의 요약을 입력하면 그 내용을 RSS의 description으로 이용하는 것이 올바른 방식입니다만…
국내에는 제가 알기로는 엔비블로그외에는 이런 시스템이 없습니다.
만약 사용자가 excerpt를 따로 입력하지 않았다면 앞서말한 MT나 WP등은 사용자가 입력한 본문중의 몇자를 따와서 excerpt대신 씁니다. 이게 와전(?)된 것이 국내의 RSS들의 일부공개형식입니다. 그런고로, 사실 국내 블로그툴들이 이렇게 무조건 앞대가리만 떼어서 RSS를 만드는 건 반쪽자리 UX인 셈입니다.

그렇다고는 해도, 비록 앞부분 몇자만 떼어와 만드는 TEXT description이라 하더라도 HTML이 포함된 content:encoded보다는 우선되어야 합니다. content:encoded는 어디까지나 RSS제공자의 선택사항일 뿐입니다.

왜 그런고 하니,

1) 모든 RSS리더기가 content:encoded를 처리할 수 있는 것은 아닙니다.

2) HTML이 포함된 content:encoded는 제공자의 리소스/트래픽뿐만 아니라 구독자의 리소스/트래픽까지 잡아먹기 때문입니다. 비근한 예로 홈페이지에 강제로 음악을 임베딩해놓는 것이 주인장 맘에는 흡족하다 하더라도 방문자의 쾌적한 웹서핑을 방해하는 것과 마찬가지입니다.

3) HTML이 포함된 RSS는 대개 웹접근성을 저해하기 때문입니다. 예를 들어 장애인들이나 기타 다른 장치(PDA등)에서 이용할 때 문제가 되기도 합니다.

4) 이미 RSS에는 그러한 것들을 위한 별도의 엘리먼트들이 있기 때문입니다. 예를 들면 관련링크들을 기술하는 곳, 관련 이미지 리소스들을 적어두는 곳… 딱히 본문을 HTML형태로 다 보여주지 않더라도 본문과 동등한 내용을 전달할 수 있기 때문입니다. (역시 문제는 국내 블로깅 툴들이 만드는 RSS는 그런 것들을 지키고 있지 않아서 문제이긴 합니다.)

5) 펌질/저작권은 오히려 부수적인 문제입니다. 비록 일부만 긁는다고 저작권이 더 잘지켜지거나 하는 건 아닙니다. 따라서 이 부분으로 논점을 옮기는 건 무의미하다고 보구요. 대신 RSS는 공개하는 순간 그것의 사용책임은 전적으로 구독자(수집자)가 져야 합니다. 가져가는 것이 문제가 아니라, 어떻게 사용하는가가 문제일 뿐이지요. 이부분에 대한 논쟁은 다른 주제이므로 여기에서는 그치겠습니다.

개인적으로 description을 지지하는 이유는 1)~3)입니다. 그리고 이에 대해 모든이를 만족시키는 방법은 description과 content:encoded를 같이 제공하는 방법이며, WP나 MT등의 블로깅 툴에서는 모두 이런 방식을 쓰고 있습니다. 따라서 만약 “전문공개”(?)를 주장하고 싶으시다면 TT나 네이버등에 description(별도의 excerpt를 입력받는)과 content:encoded를 모두 지원하라고 요구하는 게 맞습니다. 둘 중의 어느 하나를 선택해야 한다면 저는 단연 description입니다. (둘 중의 하나만 선택해야할 이유따위는 물론 전혀 없습니다.)

이 모든 건 RSS 제공자의 마음이지, 구독자가 뭐라 할 성질은 아닙니다. 아, 물론 자신의 유명세를 빌어 content:encoded만 이용할 것을 요구한 개념없는 외국인 블로거가 있기는 하지요. 정정:그 역시 content:encoded를 이용하려는 이유는 개선된 "광고"를 위해서가 아니었나요?

올바른 타이틀(title) 작성법

웹페이지를 제작할 때 타이틀은 매우 중요하다. 소설을 쓸 때에도 제목을 잘 지어야 하는 것 처럼.

나쁜 예부터 보자.

Bad Case 1. "무제(無題)"
요즘 청소년들도 혼자만의 감상에 못이겨 시를 쓰는지 모르겠는데, 아무튼 한때 문학소년소녀들의 자작시집에는 "무제"가 왜이리 많았는지. 머리통이 좀 굵어지고 난 후에 보기라도 할라치면 어쩌자고 저런 이름을 붙였나 낯뜨겁기까지 하다.

웹 페이지 작성시에도 타이틀을 안붙여주는 경우들이 많은데, 매우 안좋은 습관이다.
타이틀은 웹접근성을 위해서도 매우 중요하다. 시각장애인의 경우, 열려있는 문서와 프로그램들을 타이틀을 통해 구별한다. 타이틀이 없다면 구별이 아주 어렵다. 장애인뿐만 아니라 기계친화적인 문서를 필요로 할 때에도 문제가 된다. 예컨데, 검색엔진에라도 잘 걸리게 하고 싶다면 타이틀은 문서간의 구별과 문서내용을 짐작하게 해주는 아주 중요한 도구가 된다. 습관적으로 무성의 하게 타이틀을 비워두는 버릇은 버려야 한다.

Bad Case 2. "XXX 사이트"
아예 타이틀이 없는 것보다 낫긴 하지만, 그래봤자 오십보 백보. 사이트를 통털어서 모든 페이지가 같은 타이틀을 가지고 있는 것은 비워두는 것과 마찬가지이다.
왜 이런 경우가 생기는가 하면 개발자들이나 코더들이 조금 편해보겠다고 모든 페이지에 고정된 HTML 헤더를 인클루드시켜버리기 때문이다.
모든 페이지마다 독립된 타이틀을 가져야 한다. 이유는 앞 항목에서 이야기 한 것과 같은 이유. 모든 페이지의 타이틀이 같다면 색인을 만드는 기계들도 곤욕이고, 시각장애인들의 경우 자신이 보고 있는 페이지가 무엇인지 알기가 어렵다. 더군다나 팝업이나 새창이라도 몇 개 뜨고 나면 어려움은 몇 배 더 가중된다.

Bad Case 3. "~에 오신 것을 환영합니다."
일단 두번째 케이스의 단점에 준하면서, 거기에다 시각장애인에게 짜증을 더해주는 케이스이다.딴에는 저렇게 공손히 써놓으니 스스로 친절함을 발휘한 것 같아 흐믓할지는 몰라도.
시각장애인들이 사용하는 TTS는 "모든 것"을 읽어준다. 듣기 좋은 소리도 한두번이지, 페이지 이동할 때마다 "~에 오신것을 환영합니다."를 반복해서 듣는 것은 멀쩡한 사람도 노이로제걸리게 하기 딱 알맞다.
꼭 친절함을 표시하고 싶다면, 대문에나 한번 쓰고 말아라.

그럼 어떻게 작성하는게 올바른 방법일까?

Good Case 1. "문서 제목만 쓰기"
예를 들자면, "올바른 타이틀 작성법"처럼 현재 보이고 있는 문서의 제목만 표시해주는 것도 괜찮다. 중언부언 늘어놓는 것보다는 깔끔하게 문서 제목만 보여주자.
게시판 목록 페이지라면 "자유게시판 목록"이라거나, 게시물 읽기 페이지라면 "게시물 제목"을 써주는 식으로.

Good Case 2. "사이트 이름 - 문서 제목"
그러나 문서 제목만 가지고는 창을 여럿 띄웠을 때는 헷갈릴 수도 있다. 그러므로 사이트 이름을 같이 적어주는 것도 괜찮은 방법이다. "DNZIN - 올바른 타이틀 작성법" 이런 정도.

Good Case 3. "Path"
간단한 블로그라면 위의 두가지 정도로도 충분하겠지만, 덩치가 큰 사이트 내에서 단계가 깊은 페이지일 경우에는 경로를 보여주는 것도 좋다.
예를 들자면,
"DNZIN : 블로그 : WebStandard Archive : 올바른 타이틀 작성법" 이런 식이어도 좋을 테고, 대개 타이틀을 착실하게 써주는 사람들은 이런 형식을 선호하는 편이다.
선형 혹은 트리형태의 사이트맵을 가지고 있는 사이트에서 하위 페이지로의 접근이 단계별로 진행되는 경우에는 크게 상관은 없지만, 만약 그렇지 못한 사이트라면 이러한 타이틀은 사용자에게 혼동을 줄 수도 있다. 스파게티처럼 링크들이 얽혀있는 사이트 네비게이션이라면 주의해서 사용해야 한다. 사용자의 UX는 경험상 뒤로가기 버튼을 눌렀을 때 상위 단계로 이동하길 기대하기 때문에 개구리 뜀뛰듯 링크가 얽혀있을 때 이러한 방법은 그다지 좋다고 할 수는 없다. 물론 시각장애인들에게는 그 어려움이 두배가 된다. 이럴 때에는 <head>안의 <link>의 rel과 rev 속성을 통해 prev, next, index등을 지정해줌으로써 혼동을 막는데 도움이 된다.
게다가 이 형식에는 애초부터 시각장애인을 위한 배려가 2%쯤 부족한 아쉬움이 있다.

Good Case 4. "Reverse Path"
그 아쉬움이 뭐냐 하면...
눈을 통해 2차원적으로 동시에 정보를 수용하는 정상인들과 달리, 시각장애인들은 음성이나 점자를 통해 선형적으로 구성된 정보를 시간순으로만 접할 수 있다. 이런 경우 인간의 집중력은 최초에는 매우 강하지만 시간이 흐르면서 계속 정보가 쏟아져 들어올 경우 집중력이 점차 떨어지게 된다.
학교다닐 때 듣기 평가시간을 기억해보면 이해가 될 것이다. 대개 들려주는 지문의 처음부분은 잘 들리지만 뒤로 갈 수록 제대로 듣지 못한다. 비록 시각장애인들의 청각 집중력이 높고, TTS들도 빠르지 않게 읽어주지 않더라도 title이 길어지면 그것을 듣는데 피로해진다.
타이틀에서 중요한 것은 문서의 제목인데, 정작 중요한 제목은 한참뒤에 나온다면 얼마나 불편하겠는가.

따라서 기존의 경로형식 대신 역경로형식을 쓰는 것도 좋은 방법이다.
"올바른 타이틀 작성법 : WebStandard Archive : 블로그 : DNZIN" 이런 식으로 거꾸로 놓으면 가장 중요한 문서제목이 먼저 들리므로 시각장애인들의 어려움을 조금 덜어줄 수 있다.

그러나 좌에서 우로 읽기가 익숙한 사람들에게 저런 형태는 왠지 불편할 수도 있다. 그런 경우에는 두 방식을 혼용해서
"올바른 타이틀 작성법 : DNZIN : 블로그 : WebStandard Archive" 처럼 써주는 방법도 있겠다.

Bonus.
위의 예에서는 언어를 혼용해서 타이틀을 썼는데 실은 언어를 혼용해서 쓰는 건 그다지 좋은 방법이 아니다. 특히 국내용으로 만드는 사이트라면 되도록이면 한글을 써주자. 국내의 TTS들은 외국어 처리가 그다지 매끄럽지 않기 때문에 외국어가 포함되어있을 경우 틀린 발음으로 읽거나 혹은 아예 철자만 불러주곤 한다. 그러니 되도록이면 다른 나라 언어는 사용을 자제하고, 꼭 써야겠다면 한글발음을 병기해주는 것이 좋다. HTML 제작시에 lang 옵션을 일일이 지켜주지 않을 바에야 말이다. (실상 본인도 일일이 lang옵션 주기는 불가능. 게다가 lang옵션을 준다 한들 TTS가 제대로 읽어준다는 보장도 없고.)

웹접근성을 높이는 10가지 방법

1. 의미와 목적에 맞는 HTML을 사용하라.
늘 하는 이야기지만, TABLE 태그가 아무리 편리하다 할 지언정, 그것으로 레이아웃을 잡아선 안된다. IMG는 "비텍스트 컨텐트"를 위한 태그이지 장식을 위한 태그가 아니다. 문단은 P로 나누는 것이지, BR이 아니며, 강조는 B대신 STRONG을 쓴다. 밑줄을 위해 DEL을 쓰지 않는다. 목록은 LI를 사용하며, 제목은 Hx를 사용한다. 기타등등, 기타등등...
당신은 이 중에 얼마나 지키고 있는가?

만약, 당신이 이 계통에서 나름 벌어먹고 사는 것으로 만족한다면, 이런 것들을 무시해도 좋다. 그러나 당신이 엉터리 코드를 만들어놓고 User Interface니 User Experience니 떠드는 것만은 참아달라. 심지어 당신보다 아무것도 모르는 클라이언트 앞이라 해도.
마치 귀모 작가가 외계어남발에 비문투성이인 자칭 소설을 써놓고 소설작법에 대해 논하는 것만큼이나 어리석은 일이다.

2. ActiveX를 사용하지 말라.
반드시 ActiveX를 써야 하는 경우가 있긴 하다. 브라우저를 넘어서 Windows OS단의 무언가를 필요로 할 때, ActiveX외에는 대안이 없다.
그러나 그러한 기능을 추가하는 순간, 당신의 웹사이트는 "웹"이 아니게 된다. 곰곰히 따져보면, 차라리 VB나 델파이같은 것으로 전용어플리케이션을 만드는 게 더 바람직할지도 모른다. "웹"이 아닌 것을 "웹"상에 올려놓지 마라.
고스톱 게임은 웹이 아니다. 인터넷 뱅킹도 웹이 아니다. 당신이 지금 만들고 있는 것도 웹인지 아닌지 차근차근 생각해보라.

3. Frame과 Popup을 사용하지 말라.
모든 팝업은 죄악이며, 그 중에서도 인덱스페이지의 팝업은 더 큰 죄악이다.
새창띄우기를 강제적으로 할당하지 마라. 사용자에게 선택권을 주라. 무지몽매한 사용자들로부터 새 창이 뜨지 않아 불편하다는 클레임을 받는다면, Shift+클릭을 이용하라고 친절하게 답변해줘라. 한 켠에 공지해두는 것도 좋겠다. 사용자들은 금방 배운다. 당신이 생각하는 만큼 멍청하고 게으르지 않다.
프레임을 써야겠다면 타이틀을 정확히 명시해두라. 또, NOFRAMES을 이용해 프레임을 지원하지 않는 브라우저를 고려하라.(당신이 짐작하는 것보다 프레임을 지원하지 않는 브라우저와 그 사용자는 꽤 많다.) 그러나 역시 프레임을 쓰지 않는 것이 가장 훌륭한 대안이다.

4. 마우스에 의존하지 말라.
onmouseover, onmouseout 등의 마우스 이벤트를 사용하지 말라. 최소한, 저 이벤트를 이용한 기능이 빠지더라도 웹사이트 이용에 아무런 지장이 없도록 만들라. 전적으로 마우스에만 의존하는 기능은 접근성에 매우 심각한 문제를 불러온다.
특히, 마우스가 올라가면 서브메뉴가 보이는 방식이라든가, 반드시 마우스로만 작동시킬 수 있는 이미지버튼등을 주의하라.

5. 색상과 그림에 의존하지 말라.
색상에 대해 지킬 것은 두가지이다. 디자인시 같은 명도의 색상들은 되도록이면 피할 것. 링크와 본문의 명도차이를 둘 것.
흑백으로 변환했을 때 구별이 가야 하기 때문이다. 링크의 경우에는 밑줄을 그어주는 것이 매우 바람직하다.
IMG는 "비텍스트 컨텐트"요소에만 사용하도록 한다. 즉, 그 이미지가 없으면 컨텐트 자체의 내용 전달이 힘들 때에만 사용한다.
이미지를 사용할 수 없는 경우들이 있으므로 반드시 대체텍스트를 제공한다.
대체텍스트는, 이미지 파일이름도, 이미지 이름도, 이미지에 대한 설명도 아니라, 바로 이미지가 담고 있는 내용자체를 텍스트로 풀어 제공해야 한다. "기사 이미지"라는 대체텍스트는 잘못된 것이다. "8월 22일 아침 9시, 성산대교앞 혼잡한 교통상황"쯤은 되어야 한다는 소리다.
alt로 대체텍스트를 너무 길게 적지 마라. 길게 적어야 겠다면, 따로 파일로 적어두고, longdesc속성을 이용해 연결한다.
Flash나 Embedding, AJAX등에도 대체텍스트는 필요하다.

6. CSS를 활용하라.
CSS로 깔끔하게 디자인된 페이지는 매우 높은 접근성을 갖게 된다. 덤으로 깔끔하게 CSS를 적용시키기 위해서는 1번에서 말한 의미에 맞는 HTML이 필요충분조건이 된다. 시맨틱한 마크업과 CSS의 조화, 그 자체만으로도 접근성에 50점은 먹고 들어가게 된다.
inline CSS는 쓰나마나이니 이건 제외.

7. JavaScript에 의존하지 말라.
Form Submit을 JavaScript를 이용해 하지 말 것.
ASP.NET의 어떤 케이스, 몇몇 JavaFramework에서는 여러가지 파라미터를 넘기기 위해 페이지 전체를 하나의 폼으로 삼고, 링크를 서브밋버튼처럼 쓰는 경우가 있다. 접근성 면에서 아주 안좋다. 솔루션을 바꿀 것을 추천한다.
그 외에도 Form Validating을 위해 JavaScript로 하는 경우가 있는데, Validating자체는 매우 유용하긴 하나 JavaScript로만 하는 것은 보안상 혹은 데이터 무결성을 저해하는 나쁜 케이스이다.
해결책은 간단하다. JavaScript를 하나도 쓰지 말고 웹사이트를 만들라. JavaScript가 하나도 없이 잘 돌아가는 사이트가 되면 이제 필요한 부분마다 JavaScript를 붙인다. 그러면 JavaScript에 의존하지 않는, 그러면서도 JavaScript의 편리함을 누릴 수 있는 사이트가 될 것이다.

8. 소리, 깜박임등을 이용하지 말라.
"쪽지가 도착했습니다." - 한 때 제X보드 스킨 중에 저런 소리로 쪽지를 알려주는 UI가 있었는데, 절대 사용하지 말 것. 청각장애자가 아니더라도, 브라우저나 디바이스에 따라 소리 이용이 불가능한 경우가 많기 때문이다.
번쩍이는 Animated GIF, 플래시, DHTML은 모두 사용불가다. 사실 촌스럽기도 하다.

9. IE를 피하라.
IE전용 페이지로 만드는 순간, 당신의 웹사이트는 접근성에서 10Km쯤 멀어지게 된다. 개발도, 확인도 모두 비IE 브라우저에서 하라. IE기준으로 만들고나서 다른 브라우저로 보며 접근성을 위해 뜯어고치는 것보다, 비IE브라우저 기준으로 만들고 나서 IE로 보며 수정하는 것이 훨씬 빠르고 쉽다.
물론 당연히 VBScript, JScript(JavaScript와 혼동하지 말것.), ActiveX, 기타 IE전용이라 이름붙은 어떤 것도 피하라.
피할 수 없다면 브라우저 스니핑 기법을 통해 IE로 접속했을 때에만 적용되도록 하며, 다시 말하지만 절대로 IE에서만 이용할 수 있는 페이지가 되어선 안된다.

10. 장애인을 위해 아무것도 하지 마라.
별도의 장애인용 페이지, 별도의 자체 TTS... 모두 버려라. 실제로 이것들은 전혀 장애인들에게 도움되지 않는다. 무익할 뿐만 아니라 오히려 해가 된다. 위에 설명한 9가지만이라도 제대로 지키면 접근성은 90점 이상 획득한 셈이다.

부산시 홈페이지, 접근성 체크

LINK : 부산시 홈페이지
이래놓고 이벤트 페이지를 걸어놓는 용기에 대해서 일종의 경외심마저 품게 된다.

A. 일단, 친절하게 다운로드 받으라고 되어있는 접근성 체크 항목들부터 보자.

1. 대체텍스트의 사용.
충실하게 대체텍스트를 사용.... 이라기보다는, 쓸 데 없는 잡설을 늘어놓는다는 느낌이다. 애초에, IMG 태그란 "비텍스트 컨텐트"를 위해 사용해야 하는 것인데, 대체텍스트를 사용하는 취지자체를 이해하지 못하고 있다.
http://www.busan.go.kr/open_content/busan/general/basic/6260000-arc-2.0-001.jsp?nSelected=1
위 링크에 걸린 페이지 중간에 기상현황 이미지를 예로 들어보자.
이 이미지는 장식용 그림도 아니고, 엄연히 정보를 전달하기 위한 "비텍스트 컨텐트"이다.
물론 이렇게 이미지만 사용하면 접근성에 문제가 생기기 때문에 접근성 제고를 위해 대체텍스트를 사용해야 한다.
그런데 걸려 있는 대체텍스트는 이렇다.

부산의 10년간 년도별 기온, 상대습도, 강수량, 바람을 나타낸 4개의 그래프

시각장애인이 이 대체텍스트를 보고 아아, 그렇구나, 그런 그래프 이미지구나... 라고 고개끄덕거릴거라 생각하려나? 천만에, 제대로 된 대체텍스트라면 다음과 같은 내용이 들어가야 한다.

기온변화 (섭씨, 92년부터 04년까지 13년간의 기온변화)
최고기온 : 35.6도, 30.7도, 35.8도, 32.8도, 34.9도, 34.1도 ...
...

이래야 비텍스트 컨텐트를 대신하는 올바른 대체텍스트가 된다.
물론, 이러면 너무 길다. 따라서 이럴 경우에는 처음처럼 짧게 쓰되, longdesc 속성을 이용하여 그 내용이 담겨있는 별도의 페이지를 기술해줘야 한다. 물론 전혀 그런 면이 고려되어있지 않다.

한편
http://www.busan.go.kr/open_content/busan/cultural_assets/6260000-arc-2.0-001.jsp?nSelected=4&doc_num=90
이 페이지 본문 중간의 사진에는

문화재란?

이란 대체텍스트가 쓰였다. 과연 이 사진이 "문화재란?"이라는 의문을 전달하는 비텍스트컨텐트인가?
실은 이 이미지는 컨텐트도 아니다. 그저 장식적 요소로 사용되었을 뿐, 여기에 대체텍스트를 덧붙이는 건 오히려 낭비라 할 수 있다. TTS로 웹페이지를 읽을 때 저런 비컨텐트 요소가 얼마나 짜증나게 들리고 웹페이지 이용에 방해가 되는지 확인해보길.

홈인덱스야 말로 이런 짜증요소의 집합체라 할 수 있다.
모든 링크마다 "엔터키를 치시면 ~~ 페이지로 연결됩니다."라는 타이틀을 붙여놓았다. 세상에나, 이 페이지를 TTS로 읽을 때 어떻게 들릴지 생각하고 작성한 것일까?

2. 프레임 사용
굳이 프레임을 사용할 이유가 없는 사이트임에도 프레임 사용을 하고 있는데, 그 이유는 아마도, 브라우저의 URL입력창을 깔끔하게 보이고픈 욕구이리라. 덕분에, 해당 페이지의 주소를 알아보기 어려워 링크등을 연결하기 어렵다.
프레임의 사용은 또한 시각장애인들에게 네비게이션의 어려움을 안겨준다.
게다가, 모든 창의 타이틀이 "부산시청 홈페이지에 오신 것을 환영합니다."는 시각장애인들에게는 좌절 그 자체. 시각장애인들은 여러 윈도우들의 구분을 윈도우타이틀을 이용해 구별하고 있는데, 모든 페이지의 타이틀이 똑같기 때문에 시각장애인들의 네비게이션에 혼란을 초래할 수 있다. 기껏 문서별로 타이틀을 부여해도 프레임안에 갇혀버림으로 인해 효과를 전혀 볼 수 없다.
마지막으로 bottom frame은 불필요하다.

3. 키보드 운용성
중간중간에 보이는 플래시메뉴들은 키보드 접근이 아예 불가능하다.
일부 자바스크립트 버튼들은 키보드 네비게이션시 이상한 동작을 보인다. 예를 들어 FF브라우저를 이용할 때, 현재 모든 페이지 하단에 붙어 있는 사용편의성 평가폼의 경우, 버튼으로 포커스를 옮겼다가 나올 경우 "로그인하셔야 사용할 수 있습니다."라는 alert창을 보이고, 로그인 페이지로 이동시킨다. 마우스를 이용할 수 없는 환경도 고려해야 한다.
상단의 메인메뉴의 경우에도, Tab이동시에는 서브메뉴가 표시되지 않는다. 물론 표시로 끝나면 안되고, 각 서브메뉴에도 적합한 순서로 Tab네비게이션이 가능해야 한다.

4. 링크 스킵
이렇게 정형화된 페이지들로 이루어진 사이트에서 특히 "상단"메뉴와 "좌단"메뉴들을 이용할 경우에는 컨텐트 본문으로 바로 포커스를 옮겨주는 "Link Skip" 링크를 제공해야 한다. 물론 부산시 사이트에는 없다.
정상인들은 2차원적으로 페이지를 파악해서 페이지마다 반복되는 상단과 좌단을 무시하고 컨텐트에 바로 집중할 수 있지만, 시각장애인들이 TTS를 이용하는 경우 이런 Link Skip이 없으면 모든 페이지마다 반복해서 상단메뉴와 좌단메뉴를 줄줄이 읽어주는 걸 들어야 한다. 노이로제걸릴 정도로 짜증나는 일이다.
적절한 링크 스킵의 위치는 body태그 바로 밑에서 컨텐트 본문영역을 가리켜주면 된다. 작은 배려가 높은 접근성을 만들어낼 수 있다.

5. 팝업창
MyLink를 반가와하는 사람이 과연 있는지나 궁금하다. RSS를 제공하니 굳이 MyLink는 없어도 되지 않을까? 게다가 첫 화면부터 팝업창을 들이대는 건 매우 짜증나는 일이다.
각 페이지의 메뉴에서도 JavaScript를 이용한 새창띄우기를 하는 곳들이 있다. 이부분들도 문제.

6. 레이아웃
TABLE을 사용한 레이아웃. 더이상 말할 필요도 없다.

7. Form
label을 사용하라는 소리는 잔소리로 들리나보다. label을 무시해주는 대담함이 멋지다.
한편, form의 submit을 JavaScript를 이용한다. onkeypress등의 이벤트를 사용해줌으로써, Tab네비게이션을 방해하는 한 편, JavaScript를 사용할 수 없는 환경을 완벽하게 씹어주신다. JavaScript가 disabled되면 로그인도 못하는 사이트라... JavaScript는 부가요소이지, 필수요소가 아니다. 브라우저에 따라 JavaScript를 쓸 수 없는 브라우저들(음성브라우저, 점자브라우저, 텍스트브라우저, 모바일브라우저)이 있다는 것을 잊지 말자.

B. 다른 부분도 좀 보자.
1. 시맨틱 마크업
전혀 되어있지 않다. 실은 HTML Validator조차 통과하지 못하고 있다.

2. JavaScript
document.getElementById()를 쓰는 것이 그리 어려운가? JavaScript는 Copy&Paste로 끝이라는 발상을 가진 개발자(혹은 코더)의 문제겠지만.
DOM에 관한 공부가 필요한 듯 싶다.

3. CSS
CSS에러가 한다발... IE전용 CSS문법을 쓰고 있는 건 그렇다 치고... CSS를 쓰려면 전부 External로 쓰던가, 군데군데 inline CSS는 코드의 효용을 떨어뜨린다.

4. Java Framework
Java 프레임워크에 과문한 탓으로 VSKIP이라는 태그를 쓰는 프레임워크가 뭔지 잘 모르겠다. 허나, 저런 프레임워크용 템플릿태그가 해석되지 않은 채 소스안에 보이는 것은 문제가 아닌가? 프레임워크 자체의 버그로 보인다. 최소한 프레임워크용 템플릿 태그가 소스중에 노출되어야만 한다면 주석처리라도 해주는 게 옳다.

5. 장애인 홈페이지
장애인 홈페이지에 플래쉬 네비게이션이라는 센스가 멋지다. 물론 새로 나온 플래쉬로 얼마든지 접근성이 높은 무비를 만들 수 있다고 한다. 아르바이트 플래셔에게는 힘든 요구일지도. 어쨌든간에... 접근성 제로다.
장애인을 위한 홈페이지라는데, 정작 장애인에게 이용될 수 없는 홈페이지라니 뭔가 인생의 아이러니를 보여주는 듯 하다.
(솔직히 분석하는게 짜증나서 말투가 아까부터 씨닉해지고 있음.)

6. 품질검사.
http://valet.webthing.com/view=Asis/access/htnorm?url=http%3A%2F%2Fbusan.go.kr%2Fopen_content%2Fmain_page%2F6260000-arc-2.0-001.html&suite=SECTION508&xslt=compact
첫페이지만 따서 webthing의 Section508 검사를 한 결과이다.
몇가지만 짚어보자.
* iframe에 대체텍스트가 빠져있다.
* 플래쉬 무비등의 대체텍스트 사용이 잘못되어있다.
* CSS가 없이도 충분히 정보전달이 가능해야 하는데, 미흡하다.
* textarea안에 flash object라니....
* onmouseover같은 마우스이벤트에 의존하는 스크립트를 사용했다.
기타등등 기타등등...

Watchfire의 WebXact 검사기를 이용해 굿모닝시장실 페이지를 돌려보았다. ()안은 WCAG 1.0기준의 접근성 체크목록의 중요도이다.
* img에 대체텍스트가 없는 경우가 14건. (중요도 1)
* DOCTYPE의 잘못된 사용 (중요도 2)
* 절대사이즈 및 포지셔닝 사용 (중요도 2)
* 마우스 의존적인 이벤트 핸들러 사용 (중요도 2)
* 테이블 레이아웃 사용(중요도 3)
에러건수만 총 5종 81건.
실은 메인인덱스페이지를 대상으로 하려했으나 WebXact 검사기를 뻗게 만들 정도라서 그나마 문제가 적은(?) 시장실 페이지를 대상으로 했다.

이정도라...
흠, 열화와 같은 참여를 위해 일부러 엉망으로 만들고 이벤트를 걸었나...
아니면 딴에는 자신있다고 생각하고 이벤트를 한 것일까...

이벤트... 하고 싶을까?

....

Tag, 반쪽짜리 멍청함

* 이전에 썼던 글을 다시 올림. 조만간 "Tag, 완벽한 멍청함"이라는 제목으로 후속편을 올리기 위해...

어쩌다보니 계속 태그에 대한 부정적인 글만 쓰게 된다. 어쩌랴, 실제로 나 자신은 납득할 수 없는걸.

* 태그, 과연 꿈의 도구인가?

지금은 문을 닫았지만, SF 팬덤내에서는 유명한 홍인기님의 홈페이지를 MovableType을 이용해 만들어드린 적이 있었다. 당시, 그 분의 요구중에, "하나의 글을 다양한 경로로 접근가능할 것"이라는 것이 있었다. 예컨데, "1960년대, 미국작가, 청소년용, 인공지능"이라는 분류를 글에 부여하고, 각각을 통해 해당 글에 접근할 수 있도록 하는 것이었다.
MT는 여전히, 영감을 가득 주는 CMS툴인데, 멋진 기능 중 하나는 바로 멀티카테고리였다. 다단 카테고리와는 달리, 단계별 카테고리를 제공하는 대신, 여러개의 카테고리를 하나의 글에 부여할 수 있고, 각각에 대해 글을 모을 수 있는 기능을 제공했다.
인기님은 각각의 글에 주의깊게 준비된 카테고리 목록을 부여함으로써, 자신의 글에 대한 체계적이면서도 다양한 인덱싱이 가능하게 했다.
껍데기만 보면 완벽한 "태그"이다.

이 말은 뒤집어서 말하자면, "태그"란 결국 멀티카테고리에 지나지 않는다는 뜻도 된다.
WP나 TT, Egloos등에서 멀티카테고리를 지원하지 않으므로, 하나의 카테고리로 담아버리기엔 왠지 엉성해지다보니 태그에 대한 관심이 생기게 된 듯 한데, (추가 : WP에도 멀티 카테고리가 된다.)
이는 전적으로 컨텐츠 생산자의 입장에서 바라본 태그의 효용이다. 컨텐츠 생산자가 붙이는 태그는, 생산자 본인에게는 매우 유용하고 의미있는 분류체계이지만, 그 밖의 사람들에게는 오히려 정보의 노드를 파악하기 어렵게 만드는 불필요한 잉여정보일 뿐이다.
그러니까, WP나 TT등의 블로그툴에서, 작성자 본인을 위해서 사용하는 태그라면 나름대로 쓸만하겠지만, 이것을 집단지성으로 결부시키는 것은 무리하고 멍청한 시도이다.

아주 간단한 비유 하나.
만약 글 작성자들에게 자신이 방금 작성한 글에 대해 스스로 별점을 매기게 한다고 해보자. 자신이 생각하기에 좋은 글은 5점, 그저 그런 글은 1점.. 이런 식으로.
이 점수 매기기는 글 작성자 본인에게는 꽤 유용하다. 예를 들자면 5점짜리 글들만 모아보기. 같은 것, 매우 괜찮은 분류법이다. 혹은 이런 식으로 말할 수도 있다. 내 블로그의 4점 이상 글들만 읽어주세요.. 라든가.
그러나 독자 입장에서 이 별점을 신뢰할 수 있을 것인가. 그건 장담할 수 없는 일이다. 글 쓴이가 5점을 주었다고 해서 독자도 5점을 줄 것인가. 또는 글쓴이는 가치없다고 생각하는 1점짜리 글이라도, 어떤 독자에게는 5점짜리 컨텐츠일 수도 있다. 소위 말하는 longtail의 입장에서는.
이런 것을 감안해 볼 때, "XXX님이 쓴 5점짜리 글모음"이라는 아카이빙은 독자에게는 오히려 객관적인 정보획득을 방해하는 무익한 일이다. 따라서 어떤 메타 서비스에서 "여러 블로거들의 (자칭) 5점짜리 글모음"이라는 섹션을 만들어 두어봤자, 그것이 개개 독자들한테는 아무런 의미를 주지 못한다. 물론, 그 섹션에 글이 등록된 필자 자신에게는 유의미할지는 몰라도.
아마도, 구체적인 대상을 뭉뚱그려버린 "대다수의 블로거"들에게는 그 섹션이 그나마 "읽을만한 것"을 찾는데 도움이 될 수 있다고 반론할 수 있을지도 모른다. 그러나 도대체 그 뭉뚱그려진 "대다수의 블로거"와 세상에서 오직 유일한 "나 자신"이 어떻게 동일시될 수 있는가. 논리의 비약이 심하다. 개인은 모르겠지만, 대다수에게 도움이 될 수 있다는 애매모호한 컨셉이 비즈니스모델이 될 수는 없다.

위 비유에서 "별점"을 "태그"로 바꾸면 무슨 말을 하려는지 이해가 될 것이다.

"태그"는 folksonomy의 한계 이상을 벗어날 수 없다. folksonomy의 본질은 "유희"나 "경험마케팅"을 염두에 둔 것이 아닌, 새로운 정보 분류법-정보분류의 헤게모니 이동-을 목표로 하고 있는데, 정작 그 결과가 컨텐츠 생산자의 자기만족일 뿐이라면 핀트가 어긋나도 한참 어긋나있는 셈이다.
본시, folksonomy란, 생산자의 일방적 분류법에 반대하여 소비자의 의지를 기준으로 하는 분류체계를 말함이 아니던가. 헌데, 막상 여기저기에서 회자되는 태그의 사용법은 고작 컨텐츠 생산자의 또다른 일방적 분류법에 지나지 않았다. 그 뿐이라면 나름대로 생산자 개인에게는 가치있는 분류법일 수도 있겠지만, 그것을 모아서 web2.0이라는 딱지를 슬그머니 붙여놓아봤자 도대체 그것을 무엇에 쓴단 말인가. 일견 무언가 대중참여가 이루어지고 있는 듯 해보이지만, 환상일 뿐이다.
무한개의 쓰레기통을 가져다 놓고 니들 맘대로 담아봐라, 대신 딱지는 멋지게 붙여주마... 라고 한들 분리수거가 제대로 이루어질 리가 없다. 집단지성이 적어도 현재의 생산자중심 태그형태로 발현될 가능성은 0에 수렴한다. (집단감성이 발현될 가능성은 100에 수렴한다.)

이것은 태그 자체의 무정형, 중복가능성, 오류가능성과는 별개의 문제이다. 이런 것들은 태그 자체의 단점이라기보다는 오히려 장점이 될 수 있다. 다만 무리하게 생산자 중심 태그로 적용하려다보니 문제로 보이는 것 뿐이다. 애초에 개인한테만 가치있는 것을 무리하게 다수에게 가치있는 것으로 만들려다 보니 발생하는 것들. 그러니 Tag Suggest란 얼마나 바보같은 짓거리란 말인가. 내 맘대로 태그를 붙이지 못하고, 남들과 같은 태그를 붙이라니 그럴거면 뭐하러 태그를 붙이냐는 거지. 애초에 태그 자체란, 남들과는 다른 나만의 새로운 분류를 위해서가 아니었나?
혹자는 Tag Suggest를 무시하고, 개인적으로 붙이면 되는 문제가 아니겠냐라겠지만, 이 경우에는 소위 Tag를 중심으로한 메타서비스들은 졸지에 자가당착의 문제에 직면하게 된다. 처음부터 핀트를 잘못 맞춘 셈이다.

* 태그는 무용한가?
그렇지 않다.
1) 주의깊게 훈련된 생산자가 역시 주의깊게 작성된 태그를 사용할 경우 정보분류에 엄청난 부가가치를 준다. 이것은 소비자에게도 유의미하다. 그러나 적어도 개인 블로그 정도에서의 생산자 중심 태그는 생산자 자신을 제외한 다른 이들에게는 불필요하다.
2) 역시 전문적으로 훈련된 편집자가 역시 주의깊게 작성된 태그를 생산된 컨텐츠에 붙일 경우 이것도 정보의 가치를 한층 높여준다. 태그는 아니지만 슬래쉬닷컴의 편집시스템을 연상하면 될 것이다.
3) 소비자가 자신만의 태그를 타인의 컨텐츠에 부여할 때 비로소 태그의 진정한 위력이 발생한다.

"개인"을 중심으로 보자면, 그가 붙인 태그가 "웹 2.0"이든, "web 2.0"이든, "webbb 2.0"이든, 혹은 "web 3.0"이든 심지어 "쓰잘데기없는 헛소리"이든 아무 상관이 없다. 오히려 이렇게 자기 맘대로 붙일 수 있을 수록 그 자신에게는 더 유용하다.
실제로, 특정 태그에 어떤 글이 달려 있는 것이 중요한 것이 아니라(이것은 생산자 중심 사고 방식이다. 태그에 글이 종속된다는 것, 이것은 기존 카테고리 중심 분류체계의 이름만 바꾼 셈이다.), 그 글에 어떤 태그가 달려있는가가 더 중요하다. 이것은 소비자가 태그를 붙인다는 전제하에, 개인에서 집단으로 대상을 넓힐 때 의의가 있다. "왕의남자"라는 태그에 어떤 글들이 달려있는가보다는(이것은 해당 키워드로 검색하는 것보다 하등 나은 결과를 낼 이유가 없다), "왕의 남자"라는 영화비평에 어떤 태그가 붙어있는가가 다른 사람들이 그 글에 대해 이해하고 분류하는데 더 가치가 있게 된다.

del.icio.us가 뜨게 된 이유는 개개인이 새롭게 분류가치를 줄 수 있어서이고, 아마존의 태그가 유용한 이유는, 다른 소비자들이 붙인 태그가 나에게 도움이 되어서이다.(절대로, 출판사가 붙이는 태그였다면 그렇지 않았을 것이다.) 집단지성이란 표현을 쓰려면 최소한 그러한 전제는 깔고 들어가야 한다. 그저 태그 클라우드 제공한다고 집단지성이 하늘에서 뚝떨어진다면 박지성이 웃을 일이다. (미안하다. 농담인데 안 웃긴 것 같다.)

3줄 결론.
컨텐츠 생산자가 붙이는 태그는 제한된 효용만 준다.
그렇게 제한된 효용만 주는 생산자 중심의 태그만 모아봤자 의미없는 노이즈의 집합이나 다름없다.
태그는 소비자가 붙이게 하라.