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

August 28, 2006 at 8:59 pm · Filed under WebPlan

부분공개(?)가 왜 더 바람직한지는 몇가지 이유가 더 있습니다.
일단, 그 전에 “부분공개”라는 용어는 잘못되었음을 지적하고 싶습니다. “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를 이용하려는 이유는 개선된 “광고”를 위해서가 아니었나요?

Comments (7)

RSS에 대해. -4- (창고정리)

August 26, 2006 at 2:34 am · Filed under WebPlan

* 2005년 7월 10일. 이걸로 이 주제는 땡. 역시 앞뒤 context가 빠지니까 이 글만 읽어서는 맹하다.
* 블로그를 옮기면서 RSS 전문공개와 contents:encoded 사용이 되어버렸는데, Wordpress의 기본세팅이 그런지라… 손보는 것도 귀찮아서 그냥 둔다. 뭐, 열낼 거 있나.. 싶기도 하고.

이 주제에 대해 더 이야기하는 것은 동어반복인 감이 없지 않습니다. 그 이유는 일단 몇가지 기본 개념에 대해 오해하시는 부분들이 있어서라고 생각되네요. 자세한 내용들은 앞서 여러차례에 걸쳐 설명했기 때문에 상세 내용은 이전글들을 참조하세요.

1) RSS의 공개/일부공개/비공개.. 라는 개념은 엄밀히 말해 잘못 쓰이는 셈입니다.
앞서 말했듯이, RSS는 제공/제공하지 않음, 두개의 옵션만 있을 뿐입니다. 오히려 “일부공개”라는 개념이 유효하려면, 그 뜻은 “제한된 특정인에게만 특정 아이템을 제공”이라는 뜻이어야겠지요.
그러나 요즘(?) 쓰이는 “일부공개”라는 뜻은, 아마도 “요약제공”을 뜻한다고 봅니다. 왜 이게 중요하냐 하면, 원래 RSS의 규격자체가 “요약(요약이라기보다는 설명이 더 정확한 번역이겠지만. - description)”을 제공하기 위함이기 때문에, “일부공개”라는 용어는 불필요한 오해/선입견을 줄 수도 있겠지요.

2) RSS 2.0까지의 오리지널 포맷에는 <description>만 존재합니다. <content :encoded>는 나중에 마크 필그림등에 의해 확장기능으로 제안되었으며, 많은 리더기가 이 기능을 지원하나 표준은 아닙니다. 그래서 content:encoded를 쓸 때에는 반드시 description을 같이 써서, content:encoded를 지원하지 않는 리더기에서도 읽을 수 있도록 해야한다고 하고 있습니다. (국산 블로그 툴이나 서비스들은 이런 점을 전혀 신경쓰지않고, content:encoded만 쓰거나, 심지어 description안에 HTML코드를 담아 내보내는 만행을 벌이고 있지요.)

3) content:encoded는 문자 그대로, 인코딩된 컨텐트. 즉, HTML코드를 위한 규격입니다. description도 문자 그대로, 요약을 위한 규격이며, 인코딩되지 않은 텍스트를 씁니다.
description이 기본이고, content:encoded가 기본이 아니라는 사실만으로도 RSS에 요약을 쓰는 게 우선함을 알 수 있습니다.

4) hof님의 블로그에서 제공하는 RSS를 보더라도 description으로는 요약(또는 전문의 최초 n개의 글자 - no html)만, 전문은 별도의 content:encoded를 통해 제공하고 있음을 보실 수 있습니다. 또 김중태님의 블로그의 경우에는 description으로 요약(또는 전문의 최초 n개의 글자 - no html)만 제공하고 있구요. 호찬님의 경우에도 처음에는 description만 제공하셨다가 나중에 description에 전문을 담기는 했습니다.(잘못된 포맷입니다.) 그러나 역시 요약만 제공하는 RSS도 별도로 제공하고 있습니다.

5) 외국의 예를 자꾸 드는 이유는, 국내산 툴과 서비스가 “전부” 잘못되어 있기 때문입니다.(블로그를 만들 때 제대로 공부를 안해서… -_-a 제가 개인용 블로그 툴을 만들어봤고 서비스도 두어개 만드는데 참여해봤고 지금도 만들고 있기 때문에 단언할 수 있습니다. 실제로 이런부분에 대해 아무도 모르고 있었습니다. 지금도 아마 모르고들 있을 겁니다. -_-a)
실제로, 외국의 거의 대부분의(사실, 예외를 찾지 못했습니다만, 제가 모르는 것도 있을 수 있기에) 블로그 툴과 서비스에서 제공하는 RSS용 템플릿등을 보면 description을 기본으로 채택하고 있습니다. (최근에 나온 WP등은 description과 content:encoded를 동시 지원하긴 합니다.)
메이저 사이트들이 “유료”라서 description을 사용한다면, 왜 개인용 툴과 서비스들도 하나같이 description을 기본으로 사용할까요? 기술적으로 어려울 일은 하나도 없는데 말이죠.

6) “사이트를 방문하지 않고”라는 뜻은, “갱신된 내용을 알기 위해 일부러 사이트에 일일이 들어가보지 않고”라는 뜻입니다. 사이트(페이지)에 들어가지 않는 것이 목적이 아니라, 들어갈만한 사이트(페이지)만 골라 들어가자는 것이 목적입니다. 사이트를 방문하지 않아도 된다면, 조금 과장되게 말해서 사이트 무용론도 등장할 수 있겠죠. 순수하게 RSS만으로 신디케이트되는 서비스도 있을 법 하지 않겠습니까? (RSS가 아닌 ATOM이 대세가 되면 그런 서비스도 가능해지긴 할 겁니다. 또, podcasting같은 특수한 경우도 있긴 합니다만, description과는 상관없는 이야기죠. - 그런 의미에서 올블로그에서 지원하는 podcasting방법은 상당히 문제가 있습니다. 올블 이야기를 좀 더 하자면, 올블에서 지원하는 나의 추천글 방법도 역시 동일한 문제가… -_-a)

7) 오해를 심화시킨 건 네이버의 몫도 큽니다. 네이버의 변명인 “저작권 운운”은 말도 안되는 소리입니다. “전문의 글자 일부분”이라 하더라도, 저작권에 문제가 있을 수 있습니다. 저작물의 전체가 아닌 부분에도 저작권은 적용됩니다. 따라서 저작권때문에 일부만 제공한다는 소리는 멍청한 소리입니다. (원래, 네이버는 좀 그런 끼가 다분하기 때문에 별로 새삼스럽지도 않습니다만. -_-a)

카트라이더와의 비교는 안들은 걸로 하겠습니다. ^^;

9) 웹표준화와 접근성의 관점에서 가장 고려해야 할 부분은
- 빈곤층/저개발국/인프라부족환경에서도 접근과 사용이 가능할 것.
- 장애인/학습능력이 낮은 사람/저연령/고연령층등에게도 모두 접근과 사용이 가능할 것.
- 비PC기반의 크로스 플랫폼에서도 접근과 사용이 가능할 것.(크로스브라우저는 말할 것도 없고…)
등이 있습니다.
위의 두가지는 논외로 하더라도, 세번째만 보아도 text기반의 description 사용은 자명합니다. 당장 PDA, 모바일, 키오스크, 웹TV, 기타등등 각종 머신피드로 사용되기 위해서는 content:encoded는 많은 문제가 있습니다. 그것이 description을 사용해야 하는 이유입니다. description을 기본으로, 그리고 꼭 전문을 보이고 싶다면 content:encoded를 별도로 지원하는 것이 옳습니다.

10) 따라서 네이버가 description만 지원한다고 해서 그것을 잘못되었다 말할 수는 없습니다. 불편하고 불만일 수는 있어도 말이죠.

11) description을 인정하더라도, 두가지 층위의 불만이 존재할 수 있는데, 한가지는 “글의 일부분”을 description으로 인정할 수 있느냐와, “글의 일부분”을 어디까지로 한정짓느냐겠습니다.
전자에 대해서는 그걸로 충분하다고 생각하지만, 불만이신 경우에는 네이버에 “요약-글의 일부가 아닌”을 입력할 수 있는 필드를 제공해달라고 요청해야겠지요. 또 외국의 경우를 들어서 죄송합니다만, de facto 표준 블로그시스템으로 여겨지는 MovableType을 비롯한 대부분의 블로그 툴과 서비스에서는 별도의 “요약”을 입력할 수 있는 방법을 제공합니다. 물론 요약을 입력하지 않은 경우에는 글의 앞부분 일부를 자동으로 요약으로 처리합니다.
국산에는 엔비블로그가 유일할 겁니다. (참고로 국내의 블로그 툴 및 서비스에서 가장 표준에 충실한 것은 엔비블로그입니다. 국내에서 표준은 무시당하고, 비표준이 활개치는게 꼭 블로그계만은 아닙니다만.)
후자에 대해서는 실제로 description자체를 담지 않는 경우도 있습니다. 타이틀만으로 충분히 컨텐츠(링크)에 대한 정보를 제공할 수도 있기 때문이죠. 그래서 description은 필수 엘리먼트가 아닌 선택 엘리먼트입니다. 네이버에서 이 부분의 개선을 위해서라면, 몇글자까지를 description으로 사용할 것인가를 선택할 수 있는 방법을 제공해주는 것이 올바른 해결책이겠죠. 역시 외국의 많은 툴과 서비스에서는 이 description으로 사용할 글자수를 지정할 수 있는 설정을 제공합니다.

12) 네이버가 description으로 본문의 일부만 제공한다 해서 네이버쪽에 득될 일은 하나도 없습니다. 쓰고 계신 분들이 더 잘 아시겠지만, 광고덩어리 네이버에서도 블로그에는 감히 광고를 못붙이고 있습니다. (붙였다가는 난리나겠죠.) 이미 이 부분에 대해서는 김중태님이 여러번 핵심을 잡아 설명하신 적이 있습니다. 그러므로 사용자가 RSS를 읽다가 관심이 가서(혹은, 그 짧은 description때문에 화딱지나서) 실제 해당 페이지에 접속한다 해서 네이버의 수익이 늘어나거나 할 일은 전혀 없습니다. 그러니, 장사속이라고 표현한다면 네이버로서는 억울한 일이겠죠. (평소 행실로 봐서는 뭐 별로 변명해주고 싶지는 않습니다만.)

13) 어쨌거나, 결론은 그겁니다. 국내의 RSS포맷들은 대부분 잘못된 포맷이고, 그 잘못된 포맷에 익숙해져있다보니 불편해졌을 뿐이지만, 표준포맷을 사용했다 해서 비난할 일은 아니라는 겁니다. 더 나은 서비스를 위해 확장을 요구하거나 개선점을 요구할 수는 있어도 말이죠.

14) 어디 잘못된 포맷이 RSS뿐이겠습니까. 트랙백도 그렇고..

헥헥.. 길게 썼네요. 너무 길어서 안 읽으실지도. -_-a

Comments

RSS에 대해. -3- (창고정리)

August 26, 2006 at 2:27 am · Filed under WebPlan

* 2005년 7월 7일, 역시 창고정리중. 옛날에 썼던 거라 context없이 글만 보니 이상…

(오해의 소지가 있다고 판단하여, 제목에서 “네이버”를 빼고 시작합니다.)
폴리스님과의 커멘트대화만으로는 한계가 있어(-_-a 중첩커멘트 템플릿을 이렇게 댓글이 길어질 것을 염두에 두지 않고 썼더니 커멘트 쓰는 영역이 점점 좁아져서…) 따로 포스팅합니다.

제목에서 네이버를 빼긴 했지만, 문제의 시발점이 네이버 RSS 변경이므로 잠깐 언급하겠습니다.

1. 문제의 시발은 네이버가 RSS에 “전문”을 보여주는 대신 “글의 일부”를 보여주는 것으로 바뀌었고, 이에 대해 불만이 많으신 분들이 있으신 듯 하여 그에 대해 적은 글입니다.

2. 제가 폴리스님(그리고 몇몇 분들)께로 트랙백을 걸긴 했지만, 그 불만에 대한 “딴지”를 위해 트랙백을 건 것은 아닙니다.

3. 다만, 네이버가 RSS를 변경한 것이 “불만스러울 지는 몰라도”, “잘못된 것은 아니다.”라는 것을 지적하려는 의도였습니다. 혹시 그 의도가 잘못 전달되었다면 글솜씨 없음으로 생각해주시기 바랍니다.

4. “요약”과 “전문”중 어느 것이 바람직하냐에 대한 소견은 이미 앞글에서 밝혔으므로 여기에서는 다시 언급하지 않겠습니다. 이 부분에 대해서는 본문중에 RSS라는 단어에 걸린 링크를 눌러보시면 관련 글들이 붙어있으니 참고하시기 바랍니다. Zeldman씨 등이 밝히신 RSS의 정의 등이 포함되어있는 글이므로 읽어보시면 제가 이야기하려던 것이 어떤 것인지 이해하시는데 도움이 되리라 생각됩니다.

5. 다만, “글의 일부”를 요약으로 인정할 수 있느냐하는 부분에서는 입장을 밝혀야겠군요.
결론부터 말하자면, 저는 “글의 일부”를 “요약”으로 인정합니다. 네이버의 80byte짜리라 할지라도요. 심지어는, “글의 일부”조차 없는 - 즉 description이나 excerpt가 전혀 없이 title만 있는 RSS도 인정합니다. (제가 인정하고 자시고 할 문제는 아니지만, 입장은 그렇습니다. ^_^)

물론, 별도의 “요약”을 지원할 수 있는 툴들이 바람직한 것은 사실입니다. 그러나 국내 대부분의 가입형서비스에서는 이 기능을 지원하지 않으며, 제가 아는 한, enbee.com의 엔비블로그에서만 지원하고 있습니다.

대개의 시스템에서 별도의 “요약”을 지원하지 않는 한, RSS의 본래 목표였던, “구독 여부의 가치판단”을 위한 정보로 사용할 수 있는 것은 글과 제목 뿐입니다. 글의 일부라 할지라도 부족하나마 충분히 가치판단 정보로 사용될 수 있습니다. 심지어, 글은 전혀 언급되지 않고, 단지 제목만 가지고도 가치판단 정보로 사용될 수 있습니다. 이를 돕기 위해 “category”등의 보조 수단을 사용할 수도 있습니다.

그러나 “별도의 요약”보다 부족한 것은 사실이지요.

6. 그러므로 네이버의 RSS가 불만스럽다면, 가장 바람직한 해결책은 “다시 전문 표기로 바꿔달라”는 것이 아니라, “별도의 요약을 입력할 수 있도록 해달라.”는 것이 맞다고 생각합니다.

7. 앞에서 말한, 메이저 사이트들에 대해 좀 길게 적겠습니다.

메이저(?)의 선정은 대표적 RSS리더인 Feed Demon 1.5버전의 기본 내장 목록을 기준으로 삼았습니다. 상당히 양이 많아서 일일이 해당 링크를 걸지 못함을 양해바랍니다.

- 요약 혹은 일부, 혹은 캐치카피만 제공하는 사이트
Businessweek, Christian science monitor, CNN, Fast Company, Fortune, Moreover, SmartMoney(기사내용에 따라 제목만 제공하는 경우도 있음), The Motley Fool, Builder.com, CNet, GameSpot, TechRepublic, ZDNet, Digitally Obsessed, Movies.com(본문없이 영화스펙과 메인이미지만 제공), RollingStone, Smart-Popcorn, Variety, Yahoo!News, Ask Yahoo!, Dictionary.com, WiredNews, Kevin,M.D, WebMD, Lockergnome, Reuters, Media Guerrilla, BBC, Guardian, MemoryBlog, The New York Times, The Village Vioce, USNews, Instapundit, PowerLine, Talking Points Memo, Amnesty International, BetaNews, PC Magazine, MajorGeeks, PC World, SnapFiles, ESPN, PR WebSports, SI.com, Extremetech, Gizmodo, Microsoft Watch, The Register, A List Apart, Accessify, Brainstorms and Raves, Digital Web Magazine, Jeffrey Zeldman Report, Meyerweb(에릭 마이어), Sitepoint…

- 아예 제목만 제공하는 사이트
The WallStreet Transcript, The WallStreetJournal, Digital Theater, MedicineNet, Radio Free USA, Mozilla.Org, MozillaZine…

(너무 많아서 대충 생략합니다.)
물론 전문을 거는 사이트들도 있습니다. 그러나 개인 블로그가 아닌, RSS를 제공하는 메이저 사이트(이정도면 메이저 사이트들이라고 생각합니다만.)들은 대부분 요약 혹은 글의 일부, 혹은 제목만 제공하고 있습니다. 물론, 유료서비스 혹은 회원제 서비스때문에 그렇게 사용하는 경우도 있고, 또 아닌 경우도 있습니다. 또, HTML을 일부 허용하거나 완전 금지하거나 하는 등의 차이는 약간 있습니다.

위의 사이트들은 글의 일부(길이는 각 사이트별로 차이가 있습니다만.) 혹은 제목만 제공하지만 그것으로도 충분히(물론 사람에 따라서는 아닐 수도 있겠군요.) 구독 여부에 대한 가치판단이 가능하다고 생각합니다.

8. 이런 점등으로 미루어, 네이버의 RSS변경은 익숙한 사용자에게 불편을 줄 지언정, 크게 잘못된 점은 없다고 할 수 있습니다. 또한 그 불편은, 어떻게 보자면 잘못된 관습에 익숙해져있던 것에 기인한다고도 할 수 있습니다. (다시 말씀드리지만, 전문 대신 요약-글의 일부 혹은 제목만 포함한 것이라도-을 사용하기를 권장하는 건 그냥 제 개인적인 희망사항만은 아니며, 이미 국내외 많은 블로고스피어에서 이에 관해 논의되어왔습니다. 물론 어느 한쪽이 절대 옳다는 것은 아니며, “전문”을 쓰는 것에 대한 장점은 저도 잘 인지하고 있습니다. 게다가 “전문”을 쓰는게 RSS 규약에 위배(오리지널 포맷에는 없지만 확장을 통해 가능하므로)되는 것이 아니므로 “전문”을 쓴다는 것이 잘못되었다는 것은 아닙니다. 그러므로 “권장”이라는 표현을 쓰고 있음을 살펴주세요.

Comments (1)

RSS에 대해. -2- (창고정리)

August 26, 2006 at 2:24 am · Filed under WebPlan

* 2005년 7월 7일

… 앞부분은 생략하고 …

일단, RSS 2.0에 대해 잘 정리된 스펙을 보고 싶으시다면, http://blogs.law.harvard.edu/tech/rss를 참조하시기 바랍니다.

이하, RSS 2.0을 바탕으로 설명합니다.

RSS는 Really Simple Syndication의 약자입니다.
RSS란 컨텐츠에 대한 정보입니다. 컨텐츠 그 자체가 아닙니다.

일단, 각 항목들을 설명드리겠습니다. 이부분이 필요없으신 부분은 스크롤바를 내려서 결론부분부터 읽으셔도 됩니다.

* Channel 엘리먼트 - 개별 RSS 채널(rss 파일 단위)에 대한 설명입니다.

-필수항목-

title - 채널의 이름입니다. 블로그라면 해당 블로그 혹은 블로그의 하위 항목 이름이겠죠.

link - 채널이 다루는 컨텐츠의 HTML 웹사이트 주소를 가리킵니다.

descriptin - 간단한 채널에 대한 설명.

-선택항목-

language - 채널이 쓰여진 언어를 말합니다. 인코딩 문제나 번역기를 위해 제대로 명기해주는 것이 좋습니다.

copylight - 채널의 저작권 표기입니다.

managingEditor - 채널 편집자의 메일 주소입니다.

webMaster - 채널이 다루는 컨텐츠 웹컨텐츠 사이트의 웹마스터 메일 주소입니다.

pubDate - 채널 출판 시각입니다.

lastBuildDate - 마지막으로 이 RSS채널이 갱신된 시각을 나타냅니다.

category - 이 채널이 속하는 하나 이상의 카테고리를 표시합니다.

generator - 채널 생성에 이용된 프로그램을 표시합니다.

docs - 이 채널 RSS 파일의 주소를 가리킵니다. (자기자신)

cloud - SOAP이나 XMLRPC등을 이용한 RSS 머신 피딩을 하기 위해 쓰입니다. (모르셔도 됩니다. ^_^)

ttl - 이 채널 RSS파일의 유효기간을 표시합니다. (분단위)

image - 이 채널 자체에 대한 이미지 아이콘을 표시합니다.

rating - 이 채널의 PICS 등급을 표시합니다. (예를 들어.. 아동 사용가.. 같은 등급이라든가.. 그외에도 여러가지. ^_^ 꼭 성인구분을 위한 등급은 아닙니다.)

textinput - 거의 안쓰이므로 패스. 추후, 이를 이용한 개별 사용자 인증이 가능할지도. 단, 현재의 RSS수집기들이 대부분 무시해버리므로…

skipHours - RSS 수집기들의 수집주기를 지시합니다.

skipDays - 역시 RSS 수집기들의 수집주기를 지시합니다.

* Item 엘리먼트 - 이 RSS 채널에 포함된 각각의 개별 컨텐츠에 대한 설명입니다.

title - 컨텐츠의 제목입니다.

link - 컨텐츠의 URL입니다.

description - 컨텐츠의 대략본 / 요약 / 일부 / 설명입니다. “전문”이 아닙니다.

author - 컨텐츠 작성자입니다.

category - 컨텐츠가 속한 하나 이상의 카테고리를 표시합니다.

comments - 이 컨텐츠와 관련된 커멘트 페이지의 URL입니다.

enclosure - 이 컨텐츠와 관련된 “첨부파일”(포함된 이미지, 플래쉬, 각종 파일들)의 설명입니다.

guid - 이 컨텐츠만의 유일한 id입니다.

pubDate - 컨텐츠 출판 시각입니다.

source - 이 컨텐츠가 포함된 소스URL을 가리킵니다. (대개의 경우 위의 title및 link와 동일합니다.)

이 정도가 RSS 2.0의 공식 스펙입니다.

문제가 되는 부분은 바로,
description을 쓸 것이냐 content:encoded(확장 RSS by Mark Pilgrim)를 쓸 것이냐 하는 부분인데요,
잘 모르시는 분들을 위해 두가지의 차이에 대해 잠시 설명해보자면,
description은 컨텐츠에 대한 설명 / 요약 / 정보 / 일부이며, HTML을 사용하지 않는 순수한 Text입니다.
content:encoded는 컨텐츠 자체 혹은 일부를 표시할 수 있으며, HTML을 사용합니다.

물론 대부분의 RSS 리더는 두가지를 모두 지원합니다.

제 개인적인 입장으로는, description을 권장합니다. 그 이유로는,

RSS의 본래 의도는 간편히 컨텐츠의 구독 가치를 판단할 수 있는 정보의 제공이었기 때문입니다. (물론, 그 의도가 변해서는 안된다고 생각하지는 않습니다만…)

접근성의 관점에서 보았을 때, html이 포함된 RSS는 순수 Text에 비해 접근성이 떨어집니다. (Text Only 운동과 연관지어 생각해주세요.)

웹 RSS 수집기나, 데스크탑용 RSS 수집기만 있는 것이 아닙니다. HTML을 사용할 수 없는 RSS 수집기도 많습니다. (후진 프로그램이라서가 아니라, 그런 환경일 수 밖에 없는 경우들 - 예를 들어 장애인용 리더라든가, 비 PC기반 수집기들도 있습니다.)

훈련되지 못한 author들이 작성한 비표준 HTML코드들로 이루어진 컨텐츠는 순수 Text에 비해 의미론적 웹에서 활용의 걸림돌이 되기 때문입니다.

트래픽 및 RSS 수집기에서의 리소스 점유율이 낮기 때문입니다. 몇백개의 RSS를 등록하고 사용하는 경우, 제 컴퓨터는 죽어버립니다. -_-a

특히, RSS안에 embed로 미디어파일이라도 걸려있으면… -_-a 홈페이지에 강제로 BGM걸어놓는 것이 불편한 사람들에게는 RSS역시 마찬가지입니다.

RSS는 컨텐츠 재활용에 대한 일종의 허가증이라고 생각합니다만, 이에 대해 잘 모르시는 분들께는 본의아닌 저작권 피해가 발생할 수도 있기 때문입니다.

실제로 외국의 메이저 사이트들의 RSS는 모두 “전문”이 아닌 “텍스트 요약”만 표시하고 있으며, 꼭 필요한 첨부 미디어-파일의 경우에는 enclosure를 이용해 제공하고 있음을 주의해주세요. 뭐, 외국이 한다고 따라해야한다는 법은 없지만, 그들이 그렇게 하는 데는 그럴만한 이유들이 있지 않을까요?

Comments

RSS에 대해. -1- (창고정리)

August 26, 2006 at 2:19 am · Filed under WebPlan

* 옛날 블로그 옮기는 중. 2005년 1월 27일

뭐하러 새삼스레 이런 것에 대해 글을 쓰는지 나도 모르겠네…

1. What is RSS?
Really Simple Syndication.

RSS는 원문이 아니다. RSS는 “단순히” 그것이 가리키는 원본에 대한 description일 뿐이다.
Zeldman은 이렇게 말했다.

“How you feel about the limitations of RSS probably depends on what you use it for. If you want a simple format that lets you notify subscribers when your site’s content is updated, and makes it easy to include a few lines of that content so they can decide whether or not it interests them, RSS 2.0 fits the bill perfectly. Its genius is its simplicity – and simplicity, whether in furniture design or software design, is a high virtue.”

RSS와 RSS 리더기를 사용하는 이유는,
1) 내가 관심있는 사이트의 정보 갱신을 쉽게 확인하기 위해.
2) 과연 그 갱신된 정보가 읽을만한 가치가 있는지 쉽게 확인하기 위해.

그래서 RSS에 들어가는 description은 엔트리의 전체 내용이 아닌 “요약”이 되기를 규정하고 있다.

2. What’s the problem?
국내 사이트의 RSS들의 문제는,
“너무 많은 것을 RSS를 통해 배포하려한다.”
는 점인것 같다.
RSS에 엔트리 전체 내용을 담아 배포하는 것은 벌써 2년전에 그 문제점을 지적한 바 있었는데, 결국 다음RSS넷같은 문제를 불러일으키게 된 듯.
결국, 악화가 양화를 구축한다는 것은 어디에나 통용되는 진리인 듯 하다.

초심으로 돌아가기. 귤이 회수를 건너 탱자가 되는 것에 당위성 따위가 들어가서는 안된다.

ps. contents:encoded 와 description 둘 중에 어느 것을 써야 하는가. 아무리 생각해봐도 후자를 쓰는 것이 옳다고 본다.

Comments (4)

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

August 26, 2006 at 1:59 am · Filed under WebDevelopment, WebPlan, WebStandard

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

나쁜 예부터 보자.

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가 제대로 읽어준다는 보장도 없고.)

Comments (1)

IE7, CSS버그 대거 수정

August 24, 2006 at 5:09 pm · Filed under WebDevelopment, WebStandard

Details on our CSS changes for IE7 via Channy’s Weblog

자세한 내용은 링크를 참조하도록 하시고…

약 200여종의 버그(!!! - 이런 버그를 갖고 있는 브라우저를 마치 표준인양 사용해왔다니.)를 수정해서 CSS 2.1 준수를 상당한 수준까지 끌어올렸다.

대표적인 몇가지를 보자면,

• 더이상 * HTML 등의 셀렉터 버그를 이용한 hack을 쓸 수 없게 되었다.
• overflow가 제대로 동작한다.
• select 태그가 더이상 가장 최상위 레이어에 위치하지 않는다. 플래쉬나 DHTML로 레이어작업을 하던 이들에게는 희소식
• float시 3px버그가 고쳐졌다. 만세!
• 역시 float시 마진이 따블로 붙던 버그가 사라졌다. 만만세!
• <?xml> 를 쓰면 qurik모드가 되던 바보같던 버그가 해결되었다.
• HTML엘리먼트가 BODY엘리먼트와 분리되었다.
• 클래스 셀렉터들이 정상적으로 동작한다. (지켜봐야 할 문제.)
• A 태그외에도 :hover 사용이 가능해졌다. Goooood!
• OBJECT 엘리먼트의 fallback이 개선되었다. Gooood 2!
• min/max-width/height의 지원. Goooood 3!
• 1px dotted border가 예뻐진다.
• 투명 border 지원
• fixed position 지원 Cooool!
• 알파채널 PNG 가 제대로 된다!!!!!!!!

이정도면 충분히 기존의 버그들은 거의 잡혔다고 볼 수 있겠다.

물론 그러나 나는… CSS3를 원한다…

Comments (1)

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

August 24, 2006 at 12:18 am · Filed under WebDevelopment, WebPlan, WebStandard

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점 이상 획득한 셈이다.

Comments (2)

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

August 22, 2006 at 6:20 pm · Filed under WebDevelopment, WebPlan, WebStandard

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 검사기를 뻗게 만들 정도라서 그나마 문제가 적은(?) 시장실 페이지를 대상으로 했다.

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

이벤트… 하고 싶을까?

….

Comments (4)