Category Archives: web standard

웹표준

웹 접근성 국제 세미나 후기

국제 웹 접근성 세미나 광경

2010년 10월 6일 서울 소공동 롯데호텔에서 국제 웹 접근성 세미나가 개최되었다.
W3C와 여러 공공 및 민간에서 웹 접근성 분야를 대표하여 발표를 했고 그 중 나는 관심을 가졌던 W3C 웹 접근성 위원회(WAI)의장을 맡고 있는 주디 브루어(Judy Brewer)와 미 재활법 508조를 담당하고 있는 티모시 크리건(Timothy Creagan)의 발표 내용을 정리하려 한다.
이미 팀 블로그인 NULI에 내용을 요약 정리했지만 참여하지 못한 분들에게 최대한 모든 내용을 알려주기 위해 자세하게 정리했다. 때문에 내용이 딱딱하고 길어질 수 있는 점 참고하길 바란다.

W3C 웹 접근성 표준화 동향 및 향후 웹 접근성 방향
Web Accessibility: Progress, Resources and Future Challenges
Judy Brewer / W3C WAI (WAI 의장)

주디 브루어의 발표장면

장애를 가진 사람들도 웹 서비스를 이용할 수 있어야 하는것이 접근성의 기본 원칙이며,
웹 접근성의 가장 중요한 점은 한가지 장애를 가진 사람들이 아니라 다양한 장애를 가진 사람들에게 영향을 미칠 수 있다는 점이다.
장애의 종류는 청력, 전맹, 저시력, 상지, 언어, 기억력, 지적, 발작 장애등 여러가지 다양하다. 중요한 점은 이러한 장애가 장애인들에게만 있는 것이 아니라 일반인들에게도 나이가 들면서 장애가 생길 수 있다는 것이다.
다양한 웹 접근성 문제를 준수하기 위해서는 W3C의 가이드 라인을 준수해야 한다. 웹 접근성의 주요 원칙은 아래와 같이 4가지로 나누어 진다.

  1. 인식의 용이성
    웹 사이트의 정보 콘텐츠가 명확하게 인식되도록 제공되어야 한다. 웹 사이트를 사용하는 사용자가 정보를 보고나 듣거나 어떤 상황에서든 동등하게 제공받을 수 있어야 한다는 것이다. 예를 들어 이미지에 대한 대체텍스트, 미디어라면 캡션이 존재해야 한다. 사용자는 대체텍스트를 이용해서 사용자에 맞게 큰 글씨체로 보고자 할 때 그것을 가능하도록 제작되어야 한다. 사용자들이 쉽게 정보를 식별하도록 고대비로 제공하는것도 인식을 높이는 방법이다.
  2. 운용의 용이성
    웹사이트 사용자가 키보드를 사용하던지 마우스를 사용하던지 머리,눈 등 어떤것을 사용하던지 웹사이트의 정보를 얻을 수 있도록 해야 한다. 온라인 서식에서 무엇을 작성할 경우 충분히 작성할 시간이 주어져야 한다. 번쩍거리는 콘텐츠에 대한 콘텐츠를 제공하지 않는것이 중요하다. 웹사이트 내에서 이동이 용이하도록 네비게이션을 잘 준비하는 것이 중요하다.
  3. 이해의 용이성
    잘 읽을 수 있도록 가독성에 주의해야 한다. 디자인을 할 경우 일반성을 가진 디자인이어야 한다. 서식을 작성할 경우 서식입력에 필요한 도움을 얻을 수 있는 정보를 제공해야 한다.
  4. 견고성
    몇몇 장애인들이 사용하고 있는 보조기술과 웹사이트가 잘 호환이 되어야 한다. 스크린리더, 음성인식소프트웨어, 마우스를 대신해 눈으로 작동하는 소프트웨어, 등(실제 행사장에 오셨던 분중 장애를 가지신 분중에 눈으로 마우스를 대신하는 소프트웨어를 사용하시는 분의 말을 들어보면 국내 웹 사이트 대부분이 잘 호환이 되지 않고 있다고 한다.) 정보화진흥원에는 보조기술에 대한 정보를 1층 에서 잘 체험학습할 수 있도록 되어 있다.

WAI 소개
WAI는 W3C에서 웹을 위해 제작되는 다양한 표준에서 웹 접근성을 지원하기 위한 기술적인 기반을 알리려는 목적을 가지고 있다.

  • Introducing Accessibility
    웹 접근성이 무엇인지, 왜 중요한지, 접근성을 고려한 제작이 중요한지, 장애를 가진 사람들이 어떻게 이용하는지(11월 개정 예정), 접근성 지침이 어떻게 도와줄 수 있는지, 웹 접근성과 고령층에 대한 관계 등을 소개한다.
  • Guidelines & Techniques
    웹 접근성이 있는 코드에 대한 기술을 확인할 수 있고 HOW TO WCAG2.0 에는 어떻게 하면 접근성을 준수할 수 있을지에 대한 내용이 있다. 예를들어 HTML, CSS, Javascript를 이용하여 WCAG2.0의 AA 기준에 준수하게 제작려 한다면 그 기준에 맞는 정확한 지침의 내용을 확인할 수 있다. 플래시나 실버라이트에 대한 정보도 지속적으로 업데이트 시키고 있다.
  • Managing Accessibility
    웹 접근성 관리도구에 대한 내용에는 웹 접근성을 어떻게 지켜야 하는지에 대한 당위성에 대해 다루고 있다. 예를들어 사법적, 기술적, 기업의 사회적 책임에 대한 이유 등을 다루고 있고 다양한 모바일 기기들의 대응을 위한 내용도 다루고 있다.
  • Evaluating Accessibility
    W3C에서 표준을 진행할 때 접근성 관련 문제가 발생하는지에 대해 WAI에서 관리를 하며 그렇게 나온 표준 문서들이 접근성 평가를 하기 위한 용도로 사용된다.
    평가는 비교적 개발하는 도중에 평가툴을 사용하는것이 좋으며, 이것은 웹 개발 초기부터 하는 것이 좋다.

종류별 다양한 지침
그 밖에 웹 접근성을 준수하기 위해 참고하면 좋은 지침들이 있다.

  • 저작 도구 접근성 지침(ATAG)
    웹 사이트를 개발할 경우 제작도구를 활용할 것이다. 저작도구는 HTML제작도구, 블로깅제작도구, 위키소프트웨어 등등 다양하다. 이런 웹 사이트 저작도구에 대한 지침으로 ATAG 이라고 하는 개발도구접근성지침이 있다. ATAG 이라는 것은 소프트웨어제작자(개발자)를 위한 지침이며, 어떻게하면 웹 접근성을 향상시키는 웹사이트를 만들수 있는 저작도구를 만들지에 대한 내용이다. 웹 개발자와 저작도구접근성지침과의 관계 중요성은 만약 사용하는 저작도구가 이 ATAG를 준수하는 저작도구가 아니라면 웹 접근성을 준수하는데 어려움이 있을 수도 있기 때문에 중요하다. 웹사이트를 개발할 때 비용효율을 생각한다면 이런 기준을 지키는 툴은 웹사이트 개발시 시간을 줄여줄 수 있다. 예를 들어 ATAG을 지원하는 저작도구를 사용한다면 웹사이트를 개발하는데 필요한 (접근성)업무를 대신해주는 효과도 얻을 수 있다.
  • 웹 콘텐츠 접근성 지침(WCAG)
    실제로 콘텐츠에 어떻게 웹 접근성을 보장하는가에 대한 지침이 WCAG 이다. 콘텐츠에 대한 지침의 최신 버전은 WCAG2.0이다. 웹사이트를 제작시 WCAG2.0을 활용한다면 1.0버전 보다 웹 접근성에 대한 기술 기준이 훨신 향상되어 있기 때문에 더 웹 접근성을 준수하는 웹사이트를 만들 수 있다. 이 지침은 HTML, CSS 뿐만 아니라 50여개가 넘는 W3C의 표준에 적용을 할 수 있다. WCAG2.0은 유연하고 탄력적으로 사용할 수 있고 쉽고 정확한 테스트가 가능하다.
  • 유저 에이전트 접근성 지침(UAAG)
    방문자와 사용자들을 위한 UserAgent에 대해서도 접근성 가이드 라인이 있다. 주로 웹 브라우저나 비디오플레이어 등이 대상이다.
  • 웹 접근성 RIA(WAI-ARIA)
    ARIA를 사용한다면 스크립트등을 이용할 때 접근성 문제에 도움이 된다. 구축하는 웹사이트에서 자동으로 움직이거나 변화하는 부분에 대해서는 보조기술을 사용하는 사용자들에게는 정보를 제공하기가 어렵다. ARAI에서는 이런 기법에 대해 접근성을 향상시키는데 도움을 얻을수 있다. ARAI는 지침가이드라인이 아니라 테크닉이기 때문에 WCAG2.0을 준수하는 것을 기초로 확인하는 것이 좋다.

웹 사이트가 정말로 장애인들에게 접근성을 제대로 보장하도록 하기 위해서는 이렇게 위 지침을 잘 준수해야 한다.

.
.
.

미국의 웹 접근성 법률 및 정책 동향 – 재활법 508조 중심
Timothy Creagan / U.S Access Board (미국 접근성 위원회)

티모시 크리건의 발표모습

재활법 508조가 하는 역할은 전자제품이나 웹사이트를 미국에 납품(?) 하기위해 필요한 표준을 다루고 있다. 이 표준은 소프트웨어, 웹, 전화(통신기기), 비디오(멀티미디어), 키오스크, 데스크톱 의 총 6가지 제품 군으로 구성되어 있다.

재활법 연대기

  • 1998년 재정( 통신기기 위주)
  • 2001년 508조 재정
  • 2008년 지금 재정중인 508조에 대해 자문위원회의 보고서 받음(제안서)

508조 초안은 과거 1장에서 6장까지에서 1장부터 10장까지로 개정안이 구성된다. 기존 표준에는 어떤 기능들의 변화가 있는지에 대한 내용이 있다. 예로 들어 과거에는 특정 기기가 전화냐 컴퓨터냐 를 구분했었지만 지금은 그런 구분을 하기가 힘들게 되었다. 그래서 이 기기가 전화냐 컴퓨터냐를 구분하기 보다는 어떠한 기능을 가지고 있느냐로 구분하는 것이 좋다고 판단되었다. 복사기를 예로 든다면 휠체어 사용자는 손이 어디까지 닫게 하는지에 대한 기준으로 달라지고 있다. 인터넷 같은경우 어떤 사용자에 따라 쉽게 이동(네비게이트)할 수 있는지에 대한 기준을 가지고 있다.

변화된 기준
변화된 기준으로는 약시, 난청, 신체적접촉없이 활용할 수 있는가 의 3가지로 크게 구분되었다. 약시(시각적 제약)와 전맹은 해결방법이 다르기때문에 약시의 최소 시력이 0.1로 법적 기준(미국)이 되었다.
신체적접촉없이 활용할 수 있는가 의 기준은 마비가 되었을 경우와 블루투스 기능이 확대되면서 추가 되었다.
10년전과 비교하여 두가지의 큰 변화가 있었다면 용어의 변화(전자정보기술 EIT -> 정보통신기술 ICT로 변경)와 적용 콘텐츠(어떤 매체를 이용하는지(이메일, CD) -> 어떤 메체가 관계없이 어떤 콘텐츠인가)의 변화가 있을 것이다.

미국 재활법 소개
현재까지 공개된 재활법 508조의 수정 내용은 다음과 같다.

  • 제 1장
    모든 연방규정에는 제 1장에서 508조의 범위는 전자기기와 통신기기를 다 아우른다는 내용이 가장 처음에 있다. 1장은 두가지로 나눠져있고(255조와 508조)508조는 연방정부 기관이라면 반드시 준수해야 하고 255조는 상대적으로 비교적 쉽게 따를 수 있는 범위이다.
  • 제 2장
    디자인 기준에서 표준에 맞게 디자인이 되었는지에 대한 내용을 다룬다. 예를 들어 WCAG2.0의 기준을 준수했는지에 대한 설명이 있다. 2장은 어떻게 디자인하는지 보다는 결과물을 보는데 예를 들어 하나의 모드에서는 시각장애인, 청각, 난청, 저시력자 등이 이용할 수 있도록 하는지에 대해 갖추고 있는지를 본다. 왜냐하면 각 장애마다 대한 해결책이 다르기 때문이다.
  • 제 3장
    3장에서는 소프트웨어, 하드웨어, 전화, 기기 등에 대한 공통적인 기능에 대해 다루고 있다. 기존에는 개인이 아는것 혹은 가지고 있는것을 인식 기준으로 나누었으나(주로 비밀번호나 보안카드) 개정안은 주로 생체인식(바이오 메트릭스)에 대해 다루고 있다. 이는 9.11 사테 이후 안보(보안)이 강화 되었기 때문이고, 망막스캔, 지문 등 사람이라면 반드시 가지고 있는것에 대한것을 이용할 수 있는 지에 대한 기준을 마련하고 있다.
  • 제 4장, 5장
    4장과 5장은 웹 접근성에 대해 다루고 있다. 4장은 플랫폼 어플리케이션, 인터렉티프 컨텐츠 5장은 전자문서에 대한 내용이다. 4장과 5장을 따로 구분한 이유는 대상으로 하는 사람이 다르기 때문이다. 4장은 웹개발자나 디자이너가 대상이며, 5장은 일상적인 컴퓨터 이용자(메일, 문서제작)가 대상이다.
  • 제 7장
    7장중 704는 제품에 대한 표준을 정의하고 있다. 예를 들어 제품에서 어느 부분에 케이블을 이용할 수 있는지에 대해서 단순히 보고 알 수 있게 되어 있는지 만져봐도 알 수 있는지에 대한 기준을 규정하고 있다.
  • 제 8장, 9장
    8장과 9장은 각각 하드웨어의 오디오 출력, 통신기능 대화의 기능에 대한 규정이다. 8장은 일반적인 모든 소리에 대한 부분, 9장은 실제적인 소통에 대한 부분을 다루고 있다. 예를 들어 핸드폰이 벨소리만 내는지 벨소리와 진동이 함께 되는지에 대한 기준, 그리고 의사소통과 관련된 부분은 듣고 이해하는것인지 문자를 이용해서 소통할 수 있는지에 대한 기준이다.
  • 제 10장
    10장에서 다루고 있는 내용은 ICT에 대한 문서와 ICT 지원 서비스에 대한 내용, 제조업체 측에서 제품에 대해 어떠한 기능과 어떠한 접근성을 지원하는지에 대한 내용을 기관에 요청하도록 하는 내용이다.

이상..

.
.

이밖에도 미래 웹 접근성의 발전을 위해 노력하는 민간업체들의 훌륭한 발표 내용들이 더 많다. 더 많은 내용은 다음 관련 링크에서 참고하기 바란다.

네번째 웹 표준의 날 과 발표 내용 정리

지난주 토요일(5월 29일), 한국정보화진흥원에서는 CDK가 주최하는 제 4회 웹 표준의 날 이 있었다.
제 4회 웹 표준의 날

2006년에 처음 생겨났던 이 모임은 1회, 2회, 3회를 거쳐 올해 4회를 진행하고 있는 CDK 공식 행사이다.

웹표준의날 후기는 1회부터 작성했던지라 후기를 적기 전에는 항상 지난 모임 후기 글(1회, 2회, 3회)을 한번 씩 읽어보곤 하는데 매번 후기를 볼 때마다 마치 그 글이 어제 일 처럼 떠오르면서 “벌서 이렇게 시간이 흘렀구나..” “몇몇 보이지 않는 분들의 소식도 궁금하네..” 라는 생각이 들곤 한다.

이번 네번째 웹 표준의 날은 “본격! 웹 표준” 이라는 주제로 웹 표준과 UI개발이 이제는 대중적인 단어로 사용될 만큼 웹 서비스 사이에서 자연스럽게 나오는 이야기가 된 것에 대해, 그렇다면 이후에 준비해야 할 것들이 무엇인지에 대해서 알아보고자 했던 자리라고 생각한다.

발표에는 현석님이 다양한 브라우저 이야기와 생각들을, 찬명님이 CSS3에 대해 예제와 생각을 전달해주셨고, 조훈님이 휴대기기와 디바이스 독립적인 환경에서 웹의 무한한 가능성에 대해, 백남중님이 RIA 환경에서의 접근성과 HTML5에서 생각해볼 접근성에 대해서, 그리고 내 발표현준호님이 웹 콘텐츠 접근성 지침 2.0에 대한 소개를 재미있게 해주셨다.

이후 한동안 활동이 없었던 KWAG에 대한 부활과 활동 예고에 대해 장성민님이 해주셨는데 개인적으로도 많이 기대가 되는 부분이여서 다음 KWAG모임이 기대가 되었었다.
모임의 모든 발표가 끝난 후 웹표준경진대회가 있었는데 운영진들과 문제를 출제 하면서 많은 고민을 했었지만 이날 경진대회를 하면서 나름 얻는것도 많았고 생각할 것들이 많았던것 같아 의미있었던 프로그램이였다고 생각이 든다.
항상 모임이 있을때마다 자발적(?)으로 도와주시는 자원봉사자 분들과 사진을 공유해주신 현진님, 그리고 운영에 힘쓰시는 윤표님께 감사드리고 이날 발표하신 모든 분들과 참석하신 분들께도 고맙다는 말 전해드리고싶다.

나는 이번 모임에서 처음으로 발표를 했다.
여러 같은 UI개발자들과 함께하는 자리에서 발표를 해야 하는것이 떨리기도 했지만 평소에 잘 지켜지지 않고 있는 고질적인 문제들을 함께 공유하고 스스로가 고치기로 마음 먹는다는 다짐을 하는 취지에서 발표를 하게 되었다.
미투데이 웹 접근성 발표

처음엔 행사 후기만 기록하려고 했으나 내 발표 내용을 자료로 활용하기에는 이미지 위주이기 때문에 이해하기가 힘들것 같아 간략히 정리해서 공유를 하려고 한다.
이날 내가 준비한 발표는 내가 UI개발을 하고 있는 서비스인 미투데이에 대한 웹 접근성에 대해 다루었고, 미투데이라는 서비스가 얼마나 웹 접근성을 잘 지키고 있으며, 지키지 않는 부분이 있다면 어떤부분이고 왜 지키지 못하고 있는지에 대한 내용이다.

발표 내용 요약

미투데이는 블로그와는 조금 다른 가볍게 한마디 정도의 말을 기록하며 사람들과 소통하는 공간이다.
무조건 공개가 목적이고 누구든지 볼 수 있고 누구라도 사용할 수 있는 공간이기 때문에 어느서비스보다도 접근성과 사용성이 좋아야 할 공간이기도 하다.
W3C의 WCAG2.0에 나와있는 기준대로 접근성을 준수하기란 어려울 수도 있지만 한국에는 K-WAH3.0과 같은 접근성 평가 도구가 있기 때문에 어느정도 최소한의 접근성을 준수 하기 위해 도움을 받을 수 있다.
또한 이전 버전인 KADO-WAH2.0 과 최신 버전인 K-WAH3.0에는 도움말이 포함되어 있는데 WCAG1.0과 2.0 그리고 인터넷 웹 콘텐츠 접근성 지침에 대한 내용을 볼 수 있어 많은 도움이 된다.
실제 실무에서 웹 접근성을 지키자고 하면 많은 부서들과 커뮤니케이션이 필요하다. 왜냐하면 웹 표준과는 또 다르게 웹 접근성은 아직까지 일반인들에게는 생소한 느낌일 것이기 때문이다. 그렇지만 적극적으로 이해를 도와주고 설득해서 주변에 많은 동료를 만든다면 웹 접근성을 잘 준수시키는 사이트를 만드는데 그리 외롭거나 어려움은 없을거라 생각한다.
미투데이는 실제로 K-WAH3.0으로 검사를 하면 그다지 좋은 결과를 확인하지 못한다. 많은 사이트에서 비슷한 문제가 있을거라 생각되지만 일단은 UI개발자들이 조금 더 부지런해야 할 것 같다는 생각이 든다.
다음 세가지는 특히 준수하기 위해서 노력을 하도록 하자.

  1. 이미지의 대체텍스트 준수 같은 경우는 반복되는 이미지가 많기 때문에 자칫 한가지를 못지켜도 마치 준수율이 많이 떨어지는 느낌을 주기 때문에 반드시 지켜야 할 것이다.
  2. 서식과 label의 연결은 사용성과도 연관되기 때문에 개발자에게도 전달이 되어야 하며 서비스가 되기 전까지 점검을 해야 할 필요가 있는 항목이다.
  3. 링크와 form의 action URL은 Javascript를 이용한다고 해도 대체 페이지로 이동할 수 있도록 마련해 줘야 하며, 이것은 기획단계에서부터 먼저 준비가 되어야 하며 그렇지 않으면 서비스에서는 잘 적용하기가 힘들다.

접근성 준수를 위해 올바른 마크업을 사용해야 하는 것이 기본이겠지만 만약 이미 서비스 되고 있는 것을 마크업 구조까지 변경하기란 쉽지가 않을 것이다. 구조 변경으로 인해 다른 문제가 발생할 수도 있기 때문이다.
그렇기 때문에 접근성 준수를 HTML과 CSS만으로 해결하기보다 최소한이지만 조금이라도 더 배려할 수 있는 방법을 찾는 것도 하나의 방법이라 할 수 있다. 예를들면 입력 폼의 fieldset 제공이나 컨트롤러에 title만이라도 제공한다면 최고는 아니지만 최소한의 접근성은 배려할 수 있기 때문이다.
웹 접근성은 사람이 사람의 생활을 편리하게 하는 행위중에 하나이다. 누구도 쉽게 할 수 없는 일을 할 수 있다는 것에 전문의식과 자부심을 가지고 좋은 사이트가 많아질 수 있도록 모두 힘 내주었으면 좋겠다.

발표 자료 – 미투데이 웹 접근성

객체지향CSS가 무엇인고…?

갑자기 CSS에서 객체지향 이라는 말을 붙이니 뭔가 어색하다.
웹 표준이 대두되고 CSS의 활용 범위가 전에 없던 개발, 디자인 까지 도움을 줄 정도가 되면서 이제는 객체지향적인 기법(?) 내지는 객체지향 이라는 말까지 붙일 수 있게 된 것이라 생각되지만, 아직까지 객체지향CSS가 뭔지 정확히는 잘 모르겠다.
프로그래밍에서 말하는 클래스, 메소드, 상속, 오버로딩, 오버라이딩, 다형성, 추상화 등을 CSS에서도 찾는 것일까? 확실히 알 수 있는 것은 프로그래밍에서 말하는 그 정도의 개념은 아닐 것이라는 거다.
어쩌면 이미 우리가 CSS를 활용하는 방법이 객체지향CSS였을 수도 있고 그러한 방식이 올바른 CSS 사용법으로 적합하다고 알고 있는지도 모르겠지만 stubbornella의 OOCSS(객체지향CSS) 에서 강조하는 몇 가지 사항은 이렇다.

OOCSS를 위해 권장하는 것들

  • 재사용을 위한 component library를 만들어라
  • 스타일을 정의할 때 의미있고 일관되게(모순없이) 정의해라
  • grid를 활용해라
  • 유연하게 만들어라
  • 구조와 표현을 분리해라
  • 박스와 내용을 분리해라
  • 다수의 class를 사용하되 속성의 중복은 피하고 속성의 종류는 확장해라

OOCSS를 하기에 적합하지 않는 것들

  • 위치에 독립적인 스타일은 피해라
  • div.style01과 같이 tag에 class를 지정하는 방식을 피해라
  • 본문안쪽 영역은 ID로 style 하는 것을 피해라
  • 불규칙한 배경(불규칙무늬, 그라데이션)이라면 그림자나 라운드코너 박스를 피해라
  • 높이를 이용한 줄맞춤(간격설정)은 피해라
  • 원본은 언제나 텍스트라는 것을 잊지 말아라(이미지만으로 표현하지 마라)
  • CSS 설정이 중복되지 않게 해야 한다
  • 성급한 최적화는 피해라(충분한 테스트가 필요하다. 장담할 수 있는가?)

이런 내용만 봐도 객체지향CSS가 무엇을 말하려고 하는지 대충 짐작은 된다.
하지만 짐작만으로는 뭔가 시원하게 풀리지 않기에 위 사이트에서 말하는 CSS를 보다 완벽하게 구축하기 위한 상세한 내용을 살펴보면 아래와 같은 내용이 있다.
(사실 내용을 살펴보면 CSS에 대한 그리고 웹 개발에 대한 올바른 인식과 소통법에 대한 충고이거나 격언을 말해주는 부분 이기도 했다.)

CSS에 대한 인식
CSS는 전문적이여야 한다는 것을 말 하고자 한다.
(그렇다고 완벽함을 바라는 것은 아닐 것이다.)
웹 개발 실무자들 사이에서 CSS에 대한 인식이 얼마나 있을까? 현재까지 전문적인 직업으로 여기는 사람들이 그리 많지 않고 개발, 디자인 사이에서 아직까지 애매한 역할을 하고 있는 것이 사실이다.
그렇기 때문에 더욱 명료하고 전문적인 코드가 될 수 있을 법한 CSS가 대충 아무렇게나의 코드가 되는 것은 아닐까? 라는 생각이 든다.

분리
웹 표준에서 항상 강조하는 것이 구조와 표현을 분리하는 것이라고 말하고 있다. 그러나 객체지향 CSS를 위해서는 내용과 내용을 담는 컨테이너도 분리하는 것이 좋다고 말하고 있다.
내용과 컨테이너를 분리하므로 해서 내용이 특정 위치에 있을 때만 스타일링 되는 것이 아니라 페이지의 어느 곳에서도 표현(위치)하기에 자연스러울 수 있도록 하기 위한 규칙이 아닐까 생각된다.

재사용
디자인에 필요한 component library를 만들어 놓아야 한다.
다양한 페이지를 만들기위해서는 미리 만들어진 구성요소들을 이용해서 조합할 수 있는 것이 가장 중요할 것이다.
어쩌면 이것이 핵심이라 생각된다. YUI를 보자면 객체지향CSS가 무얼 말하는 것인지 단번에 떠오르지 않을까? 일단 모든 구성요소가 정의되면 필요한 디자인은 페이지 마다 필요한 구성요소를 가져다 쓰기만 하면 된다.
(준비된 Lego를 이용해서 다양한 모형을 만드는 것을 비유하고 있는데 꾀나 적절해 보인다. :D)
그러나 재 사용할 수 있는 코드가 있더라도 현실적으로 재 사용이 잘 이루어 지고 있지 않다.
왜냐하면 대부분의 개발자들은 다른 개발자의 코드를 잘 신뢰하지 않기 때문이다.
물론 그로 인해 CSS 코드가 추가되지만 실제로 이런 추가코드는 대부분 별 문제가 없겠지 라고 느끼는게 대부분이다.
하지만 지속적인 CSS의 추가는 그 만큼 파일 사이즈도 증가한 다는 것을 알아야 한다.

곤란할 수 있을 요소를 없애라
만약 h3선언과 h5선언이 똑같은 역할을 하고 있다면? 만약 가변적인 박스에 수직,수평의 변화되는 배경이 깔리거나 라운드 박스 뒤 배경이 변화되는 이미지라면?
웹페이지를 구성하면서 가장 불필요한 시간을 잡아먹는 것이 있다면 이런 곤란한 요소들 때문에 고뇌하고 또 고뇌하는 게 아닐까 생각된다.
정말 필요한 경우가 아니라면 미리 자주 일어날 법한 곤란한 일들은 미리 체크하고 피하는 것이 좋다. 이런 일들은 주로 경험에서 많이 나온다. 그럴때 마다 체크하고 다음 프로젝트를 위해 유용하게 사용될 수 있도록 기록하는 것은 중요한 정보가 될 수 있다.
여기서 말해주는 몇 가지 리스트도 참고할 만 하다.

  • 중복되는 스타일 설정을 피해야 한다.(규칙을 겹쳐쓰지 마라)
  • 표제는 순서대로 선언해야 한다. 잘 못 측정 하면 처음부터 끝까지 계속 잘 못 된다.
  • 어림짐작을 피해라.
  • 일관적인 의미의 스타일을 사용해야한다.
  • 표제가 페이지의 다른곳에 위치하면 안된다.

사실 위 내용을 읽으면서도 어떻게 해야할 지 대략적인 그림이 머리에 그려는 지지만 실현되지 않는 현실때문에 항상 이상으로 남는 것이 대부분이라 생각된다.
하지만 이런 내용들을 CSS를 제작하는 사람들만 알고 있다면 아무것도 해결 되진 않는다.
CSS는 아직 완벽하지 않기 때문에 Grid를 이용하여 레이아웃과 구성요소의 범위 구성을 미리 디자이너, 기획자와 함께 맞춰보고, 디자이너와 개발자에게 CSS에 대한 정보도 공유된다면 유연한 CSS개발에 한걸음 더 올라설 수 있지 않을까 생각해본다.

참고

웹 접근성을 고려한 신기술 콘텐츠 제작기법 공유

한국정보문화진흥원에서 “웹 접근성을 고려한 신기술 콘텐츠 제작기법” 이라는 가이드를 공개 했습니다.

이 가이드는 RIA콘텐츠를 개발하기 위하여 고려해야 하는 규정과 예를 제시하고 있다고 합니다.
HTML과 CSS만으로 표현하던 예전과 달리 콘텐츠의 상호작용을 동적으로 하고 데스크탑 프로그램과 같이 복잡한 기능구현을 가능하게 해주는 RIA기술을 요즘 많이 사용하고 있지만 기존의 콘텐츠 접근성 표준지침은 RIA기술을 이용하여 구축한 동적 콘텐츠에 대하여 표준 기준을 적용할 수 없게 되어 있었지만 이 가이드로 부가어플리케이션의 접근성이 좀 더 좋아 지길 기대해 봅니다.

국내 지침에는 실버라이트 내용이 없어서 실버라이트 개발자나 MS분들은 씁쓸하겠네요…;;
RIA 개발자분이라면 한번쯤 읽어 보시면 좋을 것 같습니다. 🙂

관련 W3C 자료

Acid2 Test 통과한 IE8은 이제 한걸음 걸었을 뿐이고..

곧 정식 버전이 출시될 IE8은 처음 beta 버전이 배포되고 현재 RC1까지 많은 기사와 블로그 글들에서 성능 향상과 Acid2 Test를 통과해 웹 표준을 준수한 브라우저라는 이야기를 많이 실어놓고 있다.
Acid2 Test는 웹 페이지를 웹 표준에 맞게 제작했는지 검증하기 위해 HTML, CSS 검증기를 통과하는 것과 마찬가지로 브라우저가 얼마만큼 웹 표준 규격에 맞춰서 제작되었는지를 알아보는 방법 중에 한 가지라고 할 수 있다.
물론 가장 좋은 방법은 W3C에서 필요한 최소한의 권장사항을 모두 준수한 브라우저라고 하고 그것을 증명할 문서와 브라우저가 출력하는 결과로 증명할 수 있다면 속 시원하겠지만 그렇게 잘 차려진 밥상은 찾을 수 없으니..(사실 잘 못 찾겠다. 누가 좀..;)

그렇다면 Acid2 Test는 어떤 것을 검사를 할까?
acid2 test

이미 Acid2 Test는 작년, 제작 년에 줄기차게 다른 브라우저들이 통과하면서 많이 다뤘던 내용이라 좀 식상하지만..
IE8은 이제 처음 통과 한 것이니 다시 정리 해보면 Web Standards Project에서 제공하고 있는 Acid2 Test는 크게 대략 11가지 항목을 검사한다고 한다.

  • png요소 : 테스트 결과 중 눈 부분에 사용된 이미지가 png이며, 이미지가 제대로 출력 되는지 테스트 한다.
    acid2 test png
  • object요소 : 오브젝트 요소를 인식 하는지 테스트를 하며 오브젝트 안에 대체 컨텐츠(object포함)역시 인식하는 것을 테스트 한다. 이 테스트가 통과되면 IE8에서는 중첩 object와 object 안에 대체 이미지 및 컨텐츠를 표시해 줄 수 있다.
  • absolute, relative, fixed position : 레이아웃에 자주 쓰이는 position속성이 가능한 정확한 위치를 잡을 수 있는지를 테스트 한다. 이 테스트가 통과되면 더 이상 다른 브라우저와 position 위치 차이로 인해 css hack을 사용하지 않아도 된다.
  • box model : 기존 css box model 모델을 기준으로 한 테스트에서 width, height, max-width, min-width, max-height, min-height 항목을 추가한 테스트 이다.
  • css table : 테이블 태그를 이용한 레이아웃은 잘 못 된 표현방법 이기 때문에 css에서는 table처럼 레이아웃을 구성할 수 있도록 속성이 준비되어 있다. 기존 IE에서는 이 속성이 지원되지 않았지만 IE8에서는 이제 속성이 지원 되므로 의미는 더 명확하게 정할 수 있고 표현은 더 자유롭게 할 수 있게 되었다.
    acid2 test diaplay table
  • 여백 : css를 이용한 여백 계산이 얼마나 정확한지 테스트 한다.
  • 컨텐츠 생성 : 마크업을 수정하지 않고도 장식이나 주석을 추가할 수 있는지에 대한 테스트 이다. 이 항목은 확실하지 않지만 아마도 before, after, content 속성 지원에 대한 테스트를 말하는 것 같다.
  • CSS 파싱 : 알려지지 않은 css에 대해 무시할 수 있는지 테스트를 한다고 나와 있다. 그래서 그런지 이전 IE용 css hack은 더 이상 인식하지 않는다.
  • 표현 순서 : 표현에 있어 겹쳐지거나 중복되는 컨텐츠에 대한 표현 순서를 올바르게 지정 할 수 있는지에 대한 테스트 이다.
  • Line Height : inline요소의 box model중 일부 속성들의 브라우저 독립적인 속성값에 대한 테스트 이다. 이 테스트에서 일부라는 게 어떤 것 인지 정확하게 알 수 없지만 line-heigh와 vertical-align에 대한 테스트가 아닌가 생각된다.
  • 마우스 효과 : Element의 :hover class 속성이 적용 되는지 테스트 한다. 결과 페이지에서 코 부분에 마우스를 대면 색이 변하게 되는 것 인데 아마 이 부분에 대한 테스트가 아닌가 생각된다.
    acid2 test :hover
    IE8은 이 속성을 비롯해서 기타 다른 pseudo-class에 대한 지원범위도 넓어 졌다. 더 자세한 내용을 보려면 IE CSS 지원 차트를 확인하면 된다.

IE8이 Acid2 test는 통과 했다고 하지만 Firefox나 safari, opera 보다 사용율이 높은 IE 하위 브라우저들에 대한 대응은 계속 해야 한다는 문제가 남아 있다.
어찌 보면 또 하나에 브라우저가 더 추가되었다는 느낌 밖에 들 수 없을 테고 하위 브라우저 이용 율이 어느 정도 유지되는 동안은 IE8의 개선된 기능에 맞는 속성을 무턱대고 사용하는 것은 컨텐츠 접근이나 사용에 문제가 될 수 있으니 IE conditional comment 와 같은 방법을 사용하거나 충분한 테스트 후 페이지를 제작하는 것이 바람 직하다 할 수 있겠다.

이와 더불어 IE8에서 개선(?) 달라지는 사항들을 정리해 보면.. 아래와 같은 내용도 있다.

Haslayout 삭제
CSS2.1을 모두 지원하고 Acid2 Test를 통과 함으로 IE 자체 레이아웃 방식인 Haslayout기능은 더 이상 사용 하지 않는다고 한다.
이로 인해 IE8에서는 float으로 발생되는 버그나 박스 모델에서 width, height 값 인식 버그, margin 겹침 문제, position 위치가 다른 문제 등이 더 이상 발생 하지 않게 되었다.

Charset에 따라 글 간격 달라지는 문제 해결
IE(5,6,7)에서는 charset의 종류에 따라 글 간격(행간)이 달라지는 문제가 발생한다.
이 경우 가장 대표적인 문제는 텍스트 언더라인 문제와 상하 여백 문제인데 IE8에서는 Charset에 따라 텍스트 간격 차이가 없어 졌다.
하지만 텍스트 언더라인과 텍스트가 붙는 문제는 여전히 발생을 하는데 이 부분은 폰트 고유의 문제이며 중대한 문제가 아니라고 판단되는지 개선하지는 않고 있다.

브라우저 모드, 문서 모드 설정
표준을 준수한 IE8은 하위 브라우저와의 여러가지 차이가 발생 할 가능성이 있다.
이로 인해 개발자들과 사용자들에게 혼란을 줄 수 있기 때문에 하위 브라우저 호환성을 유지할 수 있는 설정 방법이 있다.
하지만 사용자 역시 브라우저에서 기본으로 제공되는 개발도구를 열어 브라우저 모드나 문서 모드를 마음대로 조작 할 수 있기 때문에 하위브라우저와 IE8을 모두 대응하기 위한 방법을 찾는 것이 더 좋을 것 같다.
(물론 사용자 조작으로 인한 변화의 책임은 사용자의 몫 이겠지?)

form 컨트롤러 자체 여백 문제 해결
모든 요소의 자체 여백은 해당 브라우저에 종속적이고 form 컨트롤러는 OS와 브라우저의 영향을 받는 부분이다.
하위 IE 브라우저에서는 다른 브라우저와 달리 form컨트롤러들이 css초기화를 하였음에도 불구하고 보이지 않는 자체 여백을 계속 지니고 있었지만(1px 테두리라고 해야 할까..) IE8에서는 이 부분이 개선되어 더 이상 자체 여백은 가지지 않는다.

Printing css 지원
기존 IE 브라우저는 프린트 페이지 여백 설정이 화면과 다른 결과로 출력 되었다.
이 때문에 미리보기나 출력을 하면 원하는 결과를 볼 수 없었는데 IE8에서는 이런 여백 문제가 개선되었을 뿐만 아니라 CSS2.1을 지원하기 때문에 print style 속성을 지원한다. 이 기능으로 인해 IE8브라우저에서는 프린트 페이지의 여백 설정이나 페이지를 나누어서 표현하는 다단기능과 같은 기능도 사용 할 수 있다.

IE8 확장 CSS 지원
IE8에서 자체적인 css 확장 속성을 제공하고 있다.
이 속성들은 현재 IE에서만 지원하는 css속성과 css3에서 지원될 속성 들을 IE8에서 사용할 수 있도록 하는 속성들이며, IE8만을 위한 전용 css로 사용 된다고 생각 할 수 있다.
아직 완전히 지원되고 있지는 않지만 내용 확인은 가능하다.
microsoft css vendor extensions
IE CSS Extension?

링크 url 값에 따라 :visited 인식안됨 문제
이 문제는 IE7부터 발생하던 문제였지만 IE8에서도 개선되지는 않고 있다.
방문한 url에 따라 :visited 인식이 되어야 하는 것은 당연하다고 생각하지만 IE7과 8은 url의 값이 스크립트로 구성되어 있거나 #이 들어가 있을 경우 디자인보안 문제로 인해 고의로 막았다고 하니 조금 힘이 빠지네..
링크의 :link와 :visited에 대한 구분 기준은 있지만 url의 어떤 값에 대한 정의는 특별히 없기 때문에 이 문제에 대한 정확한 정의를 내릴 수는 없어서 이런 문제가 생기는게 아닌가 싶고, 그다지 보편적으로 큰 이슈가 될 만한 문제가 아니라 생각되어서 그런지 이 부분도 역시 바뀔 것 같지는 않다.
하지만 방문 했다는 기준에 대한 :visited는 정의 내려야 하는 게 맞지 않나 생각된다.

여전히 하위 IE 브라우저 때문에 고생하고 있을 분들에게는 IE8의 출시가 어떤 영향을 줄지 궁금하지만 조금씩 더 나아지고 있는 IE와 점점 사용층이 IE6 에서 IE7 로 바뀌고 있으니 곧 IE8도 대중화 되길 바라는건 내 바램만은 아닐 것이다.
웹 표준 뿐만 아니라 기능향상과 IE8의 새로운 기능과 내용에 대해 궁금한 부분이 더 있다면 이 세미나에서 더 많은 내용을 얻을 수 있을 것이다.