웹 접근성을 향상을위한 페이지 검증 도움도구인 pajet이 KWCAG2.0 기반으로 변경이 되었습니다.
예전 버전과 크게 변경된것은 아니지만, 몇몇 기능이 추가되었고 결과에 대한 리포팅을 지침별로 정렬시켜 두었습니다.
http://mydeute.com/was/pajet.html 페이지에서 확인이 가능합니다.
PAJET은 js, CSS를 기반으로 실행되는 툴이기 때문에 웹 사이트에 대해 영향을 많이 받습니다. 때문에 결과가 제대로 보이지 않을 수 있습니다. ㅠ_ㅠ
저도 노력해서 디버깅을 하고 있지만, 사용하시는 분들의 도움이 절실히 필요합니다. 많은 성원 부탁드립니다 
예전부터 만들어논 문서인데.. 그냥 오픈합니다.
지침 1.2 시간에 기반한 미디어(Time-based Media): 시간에 기반한 미디어를 위한 대체물을 제공하라.
멀티미디어 콘텐츠에 대한 정보나 대화 내용, 번역 등을 콘텐츠에 동시에 보여주는 방식
SAMI(사미, Synchronized Accessible Media Interchange; 접근성 미디어 동기화 교환)는 마이크로소프트 사에서 1998년에 발표한 미디어 접근 제안이다. 마크업 언어로 구조화되어 있으며 개인용 컴퓨터에서의 미디어 재생용 자막을 간단히 만들 수 있도록 하는 데 중점을 두고 설계되어 방송용으로는 적합하지 않다.
SAMI 문서를 전문적으로 만들 수 있는 유틸리티도 있지만, SAMI 문서는 문자열로 되어 있기 때문에 어떤 문서 편집기로도 다룰 수 있다. 파일 확장자로 .smi 혹은 .sami를 사용하는데 .smi는 SMIL 파일도 사용하는 확장자이기 때문에 서로 충돌하게 된다. SAMI 문서에 여러 종류의 언어를 담을 수 있다.
대한민국에서는 자막 포맷으로 SAMI가 가장 많이 쓰인다.
youtube는 플래시 기반의 멀티미디어 재생기임에도 불구하고 자막 업로드를 제공하고 있다.
기타 멀티미디어 업로드 사이트에서는 특별한 자막 지원여부를 확인해보지 않았다.
http://mydeute.com/tip/mov/gee.html
<object id="Player" classid="CLSID:6BF52A52-394A-11d3-B153-00C04F79FAA6" width="480" height="272"> <param name="URL" value="gee.wmv"> <param name="autoStart" value="false"> <param name="captioningID" value="captions"> <param name="SAMIFileName" value="gee.smi"> <!--[if !IE]> <--> <object type="application/x-ms-wmp" data="gee.wmv" width="480" height="272"> <param name="pluginspage" value="http://www.microsoft.com/Windows/MediaPlayer/"> <param name="url" value="gee.wmv"> <param name="autoStart" value="false"> <param name="captioningID" value="captions"> <param name="SAMIFileName" value="gee.smi"> </object> <!--> <![endif]--> </object> <div id="captions" style=""> </div>
대부분의 브라우저에서 자막 확인이 가능함
단순한 대화나 말에 대한 자막뿐만 아니라, 상황을 이해 할 수 있는 설명도 포함 하는것이 좋다.
자막을 제작할 수 있는 환경을 구성한다. (동영상 업로드시)
웹 페이지에 정의된 모든 앨리먼트의 배경 이미지를 뽑아올 필요성을 느껴서, 언제나 그렇듯 막무가내로 자바스크립트에 손을 대기 시작했는데요..
처음에는 다음과 같이 했습니다.
element.style.backgroundImage이랬더니 값이 없다고 나오더군요. 그래서 좀 찾아보니… css같이 외부로 스타일을 지정해 준 경우에는 값을 읽어올 수 없다고 합니다.
그래서 이것도 몰랐냐 바보야 이러면서 computedstyle 이라는게 문득 생각나면서 좀 찾아봤더니 역시 우리의 IE는
element.currentStyle.backgroundImage이렇게 써야한다고 하더라구요…
그래서 어쩔 수 없이 분기해서 함수처럼 만들어 쓰기로 했습니다. jQuery같은 훌륭한 라이브러리쓰는 사람들은 알 필요 없겠지만; 혹시나 해서 ^_^ 남겨봅니다.
그리고 언제나 그렇듯 제 코드는 무식 그자체 입니다. 보고 욕하지마세요. 조언은 환영합니다 ㅠ_ㅠ
function getStyle(obj ,sStyle) { var val; if (obj.currentStyle) { val = eval("obj.currentStyle."+sStyle); } else { val = eval("window.getComputedStyle(obj,null)."+sStyle); } return val; }
miname 님의 조언으로 코드가 좋아졌습니다!!! 감사합니다!!! ㅎㅎ
무식하면 삼대가 고생해요 ㅠ_ㅠ 아래 코멘트는 miname님의 언급이십니다*_*
아시겠지만, 보안상으로보나 성능면에서 eval is evil이잖아요.^^
property 값을 얻을 때 bracket notation([])을 쓰면 eval 사용을 피할 수 있습니다.
아래처럼요.
function getStyle(el, sStyle) {
var computedStyle;
if (el.currentStyle) {
computedStyle = el.currentStyle;
} else {
computedStyle = window.getComputedStyle(el, null);
}
return computedStyle[sStyle];
}만약에 위 function이 여러번 반복적으로 실행되는 상황이라면 아래처럼 바꿔서 두 번째부턴 더 빠르게 실행될 수 있도록 할 수 있을 겁니다.
function getStyle(el, sStyle) {
if (el.currentStyle) {
getStyle = function(el, sStyle) {
var computedStyle;
computedStyle = el.currentStyle;
return computedStyle[sStyle];
};
} else {
getStyle = function(el, sStyle) {
var computedStyle;
computedStyle = window.getComputedStyle(el, null);
return computedStyle[sStyle];
};
}
getStyle(el, sStyle);
}p.s 파젯을 KWCAG2.0 버전으로 조금 바꾸고 있습니다 ㅎㅎ 그중에 하나만들다가 이게 나온것이에요.
아시는분들만 안다는 파젯 사용방법을 아시는 분은 새로운 파젯 개발버전인 http://mydeute.com/was/pajet.js 으로 변경해서 확인 가능합니다 ㅋㅋㅋㅋ
2002년말 당시에 저는 모 에이전시에서 초대형 사이트의 리뉴얼 프로젝트 진행 했었습니다. 이 사이트는 그 당시에도 IE6 뿐 아니라 IE5.5, IE5,IE4,NS4.7, MAC IE5.2 등등 그당시의 소위 잘나가던 브라우저들을 모두 맞춰야했었던 프로젝트였습니다. 페이지의 레이아웃을 테이블로 사용하긴 했지만 크로스브라우징은 구현하려고 노력을 많이 했던 프로젝트 였습니다.
그런데 사실 제가 다녔던 그회사는 좀 특이했습니다. 크로스 브라우징은 기본으로 해야한다는 마음가짐을 가진회사였고 제가 첫번째로 다닌 회사가 그 곳이었기 때문에 저는 크로스 브라우징에 대한 생각이 너무 당연 했습니다. 그런데 그다음에 옮긴 두번째 회사에서는 굳이 크로스 브라우징은 클라이언트가 원하지 않으면 신경쓰지 않아도 된다였습니다.
뭐 알았다고 했지만 이미 몸에 밴 습관(라인을 위한 1*1px 빈이미지, padding margin 트릭등)들은 변하지 않았습니다. 오히려 크로스 브라우징이 IE6만 신경쓰는것보다 더 쉬웠을 정도였으니까요. 공수가 많이 드는일도 아니었습니다. 내가 기본이라고 생각하는 범위가 넓으면 넓을수록 내가 얻어가는것과 결과물의 퀄리티는 넓어 질 수 밖에 없다고 생각합니다.
요 몇해사이 웹 접근성 품질마크가 나름 이슈가 되고 있습니다. 웹 접근성 연구소에 온라인 자문 서비스라는 것이 있는데요. 부족하지만 저도 자문을 조금씩 하고 있는데, 자문을 좀 하다보니 웹 접근성 제고와 방법에 대한 자문 요청이 아닌 NIA에서 시행하는 웹 접근성 품질마크의 기준이나 방법에 대한 자문 요청이 많아 지더라구요. 그만큼 웹 접근성 품질마크가 한국 웹 접근성에 큰 영향을 주었다고 생각되기도 하지만, 웹 접근성의 향상을 위한 토론과 문의등을 해야하는 게시판에서 품질마크의 기준에 대해서 문의가 나오는것은 좀 문제가 있다고 봅니다. 이 문제는 자문을 요청하는 사람도, 자문을 하는사람도, 그리고 게시판을 관리하는사람 그리고 품질마크를 담당 하는사람 모두에게 조금씩 문제가 있다고 봅니다.
일단 제가 몇번 얘기했지만 한국의 웹 접근성은 웹 접근성 품질마크가 전부가 아닙니다. 웹 접근성 품질마크는 최소한의 것이라고 생각합니다. 웹 사이트를 만들어서 납품하는 분들은(까놓고 말하겠습니다.) 웹 접근성을 고려해 웹 사이트를 만드는것인지 웹 접근성 품질마크를 고려해서 웹 사이트를 만드는것인지 잘모르겠습니다. 대부분의 업체들은 웹 접근성을 고려해 웹 사이트를 만들다 보니 부가적으로 품질마크 획득도 가능했다 정도겠지요:) 정말 이런것이길 바라겠습니다.
서론에서도 말한것과 같은 느낌으로 내가 항상 웹 접근성을 지켜서 웹사이트를 만들것이고 그것을 위해 노력하겠다라고 한다면 만들어진 웹페이지의 접근성의 퀄리티는 훨신 좋아 질것이고 쉽게 생각이 들것입니다. 웹 접근성을 고려한 사이트를 만들때 “어느부분까지만 지원하면 되”가 아니라 “이부분도 지원하면 더 좋아져”가 항상 드는 생각이기를 바랍니다.
웹 접근성 품질마크는 언제나 최종목적이 아닌 웹 접근성 구현을 위한 작은 한 단계 또는 부가적으로 얻어지는 작은 선물이라고 보시는게 좋을것 같습니다.
또한 웹 접근성 품질마크측에서도 좀더 능동적인 자세를 보여주었으면 하는 바램입니다. 자문게시판에 평가 카테고리가 있긴하지만 제 생각에는 품질마크는 별도의 게시판을 따로 구성하여 관리하는것이 좋을것 같습니다. 너무 영향력이 커져버린 웹 접근성 품질마크이기 때문에, 좀더 능동적이고 개방적인 제도가 되었으면하는 개인적인 바램입니다. 우리나라의 웹 접근성 향상을 위해 노력을 많이 해주셨는데 맨날 불평 불만만 말씀드려서 죄송합니다.
자문을하는 저도 좀더 열심히 공부하고 다각도로 생각의 폭을 넓혀서 항상 더 많은 도움을 드릴수 있도록 노력하겠습니다. 제가 아직은 많이 부족하지만 열심히 하는 모습은 보여드릴려고 노력하겠습니다.
올해는 만들어지는 모든 사이트가 웹 접근성은 기본으로 지켜지는 그런 한해가 되었으면 좋겠습니다.
제가 음주가무를 한계를 뛰어 넘을 정도로 좋아한다는 것은 저를 아는 사람이면 대부분 아는 사실이죠
예전에 웹 표준의날이나 기타등등의 세미나 같은것이 없었을때는 대부분 벙개나 술자리에서 많은 기술 또는 토론이 오갔던것이 사실이었습니다. 저는 밤새 그런이야기에 귀를 기울이며 많은것을 배울 수 있었습니다.
그때의 향수를 잊지 못하고 약간은 허심탄회한 이야기? 또는 즐겁게 모두가 어울려서 놀수있는 분위기를 만들어보기위해서 준비한 자리가 One Web Party 입니다. 이미 신청완료가 되어버린 시점이지만…(사실 이렇게 인기 있을줄 몰랐습니다. 술쟁이들….) 신청하신분들이 모두 와주셔서 즐겁게 하루를 보내며 한해를 마감할 수 있는 자리가 될 수 있으면 좋겠습니다.
또한 저희가 이런 모임을 준비한게 처음이라 많은 부족함이 있을 수 있습니다. 양해 부탁드리며 불만 가지시지 않게 최선을 다하겠습니다.
11일날 봐요~
mydeute.com의 모든 저작물은 크리에이티브 커먼즈 저작자표시 3.0 Unported 라이선스에 따라 이용하실 수 있습니다.
