부침개 블로그

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

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

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

관련 W3C 자료

• Web Content Accessibility Guidelines(WCAG) 2.0
• Accessible Rich Internet Applications (WAI-ARIA) 1.0

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

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

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

• png요소 : 테스트 결과 중 눈 부분에 사용된 이미지가 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에서는 이제 속성이 지원 되므로 의미는 더 명확하게 정할 수 있고 표현은 더 자유롭게 할 수 있게 되었다.
  
• 여백 : css를 이용한 여백 계산이 얼마나 정확한지 테스트 한다.
• 컨텐츠 생성 : 마크업을 수정하지 않고도 장식이나 주석을 추가할 수 있는지에 대한 테스트 이다. 이 항목은 확실하지 않지만 아마도 before, after, content 속성 지원에 대한 테스트를 말하는 것 같다.
• CSS 파싱 : 알려지지 않은 css에 대해 무시할 수 있는지 테스트를 한다고 나와 있다. 그래서 그런지 이전 IE용 css hack은 더 이상 인식하지 않는다.
• 표현 순서 : 표현에 있어 겹쳐지거나 중복되는 컨텐츠에 대한 표현 순서를 올바르게 지정 할 수 있는지에 대한 테스트 이다.
• Line Height : inline요소의 box model중 일부 속성들의 브라우저 독립적인 속성값에 대한 테스트 이다. 이 테스트에서 일부라는 게 어떤 것 인지 정확하게 알 수 없지만 line-heigh와 vertical-align에 대한 테스트가 아닌가 생각된다.
• 마우스 효과 : Element의 :hover class 속성이 적용 되는지 테스트 한다. 결과 페이지에서 코 부분에 마우스를 대면 색이 변하게 되는 것 인데 아마 이 부분에 대한 테스트가 아닌가 생각된다.
  
  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의 새로운 기능과 내용에 대해 궁금한 부분이 더 있다면 이 세미나에서 더 많은 내용을 얻을 수 있을 것이다.

지난 주 토요일(2월 7일) 한국정보문화진흥원에서는 CDK와 clearboth가 주최한 제 3회 웹 표준의 날 모임이 있었습니다.
이번 모임은 “웹 표준을 넘어서” 라는 부제로 만든 자리였고 많은 분들이 이제는 공감 이상의 몸으로 느끼고 있는 웹 표준에 대해 그 후에 알고 대처해야 할 것들과 웹 접근성과 사용성 대해 발표하고 서로 대화하는 자리였습니다.

너무 오랜만에 생긴 모임이라 어찌나 반가웠던지 모임 안내글을 올리고 신청자를 받기위한 페이지를 등록하자마자 하루만에 선착순 인원이 마감되어 버리는 일이 발생했다고 합니다.

후기는 그날 그날 바로 적어주면 좋겠지만 좀 늦은 관계로 이미 많은 후기가 올라와 있고 워낙에 나름 뿌듯하고 좋았기 때문에 더 적을 말이 생각나지 않지만 발표를 해준 찬명님, 지호님, 성민님, 현진님, KADO(한정기님, 문준기님), 조훈님, 현석님 그리고 사회와 발표와 이 모임을 할 수 있도록 힘써주신 윤표님께 너무 고맙고 아직 선배라고 할 수 없는 저에게 함께 할 수 있는 기회를 줘서 감사하다는 말 전하고 싶습니다.
그리고 스스로 스피커 겸 사진기사 활동을 해준 봄눈님께 감사 드리며(사진은 봄눈님 블로그에서 참고) 아침 일찍부터 해가 떨어질때까지 불만한번 하지 않고 열심히 도와주신 자원봉사 분들도 너무 감사드립니다.

다음 모임을 기다리며 참여했던 모든 분들이 조금이나마 서로를 의지하고 좋은 정보와 만남을 가질 수 있었던 자리였으면 좋겠습니다.
모두 수고하셨습니다.

html, css좀 다룹니다.. 라고 하면 alt 속성 모르는 사람 있을까? 아마.. 없을 거다
시간이 꾀 지났지만 웹 표준이란 말이 나오면서 접근성과 함께 세트 메뉴처럼 딸려 나오는 건 항상 alt 속성으로 대체텍스트만 잘 지켜도 50점은 먹고 들어가는 거라고 할 정도로 언급을 했으니 말이다.

그렇다면 일반적인 사용자가 이런 것 들을 알 고 있을까?
모르긴 몰라도 아마 대부분의 사용자들이 이런 속성 따위에는 관심이 없을 거라 생각한다.
그저 본인이 이용하는 환경에서 잘 보이고 이용할 수 있게만 하면 만족할 데니 말이다..
문제는 여기에서 오는 것 이다.

이 글은 사용자의 입장이 아니라 제작자의 입장에서 생각한 내용이다.
alt는 어떤 속성일까? w3c에서는 alt속성에 대해 대상(이미지나 input, applet등)의 요소의 의미나 내용을 텍스트로도 제공할 수 있도록 할 때 쓰인다고 말하고 있다.
이렇게 alt속성을 제공 했을 때의 이점이라고 한다면 요즘과 같이 다양한 플렛폼에서 웹 페이지에 접근을 하더라도 최소한의 동등한 정보를 제공 할 수 있는 방법을 제공할 수 있다는 점과 검색봇이 컨텐츠를 검색 함에 있어도 도움을 줄 수 있다고 말하고 있다.
(물론 이 말은 반은 맞고 반은 이론상 그렇지만 그렇다고 100% 믿어도 나쁠 건 없겠지?)
여하튼 이런 의미와 기능을 가진 alt속성을 기획,개발,디자인에 까지는 바리지 않지만 클라이언트 사이드개발 쪽 사람이라면 제대로 알고 사용을 해야 하지 않겠는가?

작년부터 IE8 beta 씨리즈가 릴리즈 되면서 관련 업무를 진행 하고 있고, 주로 IE8에서 표현되지 못하는 버그나 오류를 테스트 하고 있는데 이런 문의가 온 적이 있다.

“IE8 에서 ooo 부분에 툴팁이 나오지 않고 있습니다. 수정해주세요…”

이미 IE8을 사용해 본 사람들이라면 대부분 다 알겠지만 IE8 부터는(정확히는 브라우저 모드가 IE8 standard mode 여야 한다) alt속성이 더 이상 시스템 툴팁으로 표시되지 않게 되었다.
(그전 까지 IE에서 생각하는 alt는 title속성과 동등하게 title요소가 없을 경우 대신 나타나는 속성정도로 인식되었으니..)
아마도 IE8이 엄격한 표준규칙을 지키려 노력한 브라우저인 만큼 이런 부분까지도 다른 브라우저들과 동등한 기능으로 바꾸려 했을거라 짐작된다.
그럼에도 불구하고 아직까지 10년 15년 전 브라우저를 못 잊은 사용자들의 낡은 습관 때문에 예전과 동일하고 손도 까딱 안 한 코드를 어떻게든 사용자의 입맛을 맞춰서 다시 바꿔줘야 한다고 하면 어떻게 설득 시켜줘야 할까..?
물론 title 속성을 이용해(이건 꼼수도 아닌 그냥 편법이다!) 툴팁이 나타나게 할 수도 있다.
하지만 title 속성의 사용이 alt 를 대체 하기 위한 코드는 아닌데 마냥 아쉽기만 하다.

일모리님 블로그에서는 alt와 title에 대해 정리가 잘 되어 있다.

몇달전 나는 블로그에 “저는 웹 퍼블리셔 입니다.” 라는 제목으로 내가 하고 있는 일에 대해 기록한 적이 있다. 이미 그 전부터 블로거 사이에서 돌고 돌던 말이지만 내가 하고있는 일이 재미있고 적어도 내 블로그를 찾아주는 사람들에게 내가 지금 하고있는 일이 무엇인지 알리고 싶어서 적었던 글이었는데 반응은 의외로 좋았었다. 많은 코멘트가 달리고 자신의 블로그에 글을 남겨 트랙백을 걸어주는 등 여러 분들의 관심을 집중시킨 글이었다고 생각한다.

그만큼 “웹퍼블리셔” 라는 UI 개발자들의 새모습에 관심이 많다는 뜻으로 해석된다.
하지만 글을 적고나서 한가지 아쉬웠던 것은 UI 개발자들의 책임감과 사명감에 대해 언급하지 않았다는 점인데 이번 포스팅에 첨언하고자 한다.

수면위로 올라온 웹표준? 이미 모두가 알고있는 웹표준!

우리나라에 웹이라는 부분이 비즈니스적으로 발전하면서 다수의 웹에이전시가 생겨나고 대형 포털 회사들이 생겨나기 시작했다. 그에 발맞춰 웹프로그래머와 웹디자이너가 제자리를 찾아갈쯤 html 코드와 자바스크립트를 사용하는 front 페이지의 제작은 그 위치가 애매해서 웹디자이너나 웹프로그래머 중 여유있는 사람이 부가적으로 하는 일 쯤으로 하찮게 여겼었다.

하지만 몇년전부터 Front end 개발자, client side 개발자, 웹 퍼블리셔 등의 UI 개발자의 또다른 이름으로의 관심이 시작되고 구조와 표현을 분리한 (x)html + css 레이아웃, 웹 표준 개발, 동적인 사용자 인터페이스를 가능케 하는 Ajax 등이 부각되면서 기초적이고 하찮게 여겼던 html 마크업이나 자바스크립트 개발이 매우 중요한 화두에 오르게 됐다. 그러나 이런 기술들을 풀어가기 위해서는 시간이 필요하다. Ajax를 이용한 기술은 아직까지 미개척 분야라고 생각될 정도로 그 이용분야가 무궁무진하고, 웹의 근본적인 구조적 마크업과 css 디자인은 잘못된 교육방식과 잘못 길들여진 사용자경험 때문에 현실에 대입하기 어렵다고 느끼는게 대부분이기 때문이다.

하지만 이러한 기회를 놓치지 않고 UI 개발자들이 그 몫을 잘 해준다면 UI 개발이라는 불확실하고 애매한 위치를 확실한 위치로 바꾸면서 디자이너와 프로그래머 사이에서 정말로 제대로된 조율자 역활을 할 수 있을 것이다. 아울러 자신의 대우나 위치를 상승시킬 수 있는 좋은 기회가 될 수도 있을 것이다.
웹을 만드는데 있어 디자인과 프로그래밍 이 중요하다고 하지만 사용자가 최종적으로(front end) 접하는 건 결국 html 로 구성된 화면이고 앞으로도 그럴것이다. 그러므로 UI 개발자들은 웹을 좀 더 웹답게 만들기 위해 노력할 사명감과 책임감을 가질 필요가 있다.

UI 개발자들의 비전과 지향점

이처럼 앞으로 웹의 미래를 쥐고 있는 분야중 하나로서 UI 개발자들의 몫이 클것이다.
웹 표준의 중요성이 점점 부각되면서 구조와 표현을 분리한 마크업과 css 디자인을 할 줄 아는 “UI 개발자”나 “웹 퍼블리셔”나 “front end Developer”등으로 활동하고 있는 사람들이 점점 대우를 받는 시대로 변화고 있다. 실제로 어느 웹 에이전시나 웹 관련 IT업체에 근무하고 있던 웹 표준에 관심이 있고 이해가 높은 웹종사자들이 여기저기에서 스카웃 제의를 받는것을 보면 정말 피부로 느껴질 정도니까 말이다. 하지만 현재까지는 UI 개발이라는 부분이 앞서 말한 것처럼 애매하고 어중간한 위치임에는 분명하다.

지금처럼 웹 표준에 대한 인식이 높은 상황에서 UI 개발 직군에서 종사하는 여러분들이 한국 웹의 미래를 짊어지고 가는 선구자라고 생각하고, 잘못 된 한국의 웹을 올바른 길로 인도하고 개선하며 웹의 보편성을 지키면서도 현재의 사용자들의 만족을 유지할 수 있는 그런 웹을 만드는 개발자가 되길 바란다.

책임감과 사명감을 가지고 자기개발을 게을리 하지않는 그런 웹 퍼블리셔가 많아지길 기대한다.

위 글은 Standard Magazine 에서 관련글과 함께 보실 수 있습니다.