• WAI ARIA Live Regions – MDC
• How to use ARIA Live Regions for dynamic content – CodeTalks

이 글을 통해 ARIA 개발의 감각을 끌어올릴 수 있기를 바라며 스펙(Taxonomy of WAI-ARIA States and Properties)에 더 많은 내용이 있으니 참고바란다. 예제들은 ARIA를 지원하는 스크린리더(Korean JAWS for Windows (한글용; 유료), NVDA (영어용; 무료))로 어떻게 동작하는지 테스트해볼 수 있다.

Live Region이란?: 개발자가 웹 문서의 특정 부분을 동적인 컨텐츠라고 명시할 수 있는데 그 영역을 일컬어 Live Region이라고 할 수 있다.

개요

과거에는 웹 페이지 변경은 전체를 읽어주게 하거나 거의 읽어주지 않아서 일부 혹은 전체의 정보에 접근할 수 없도록 만들어 종종 사용자를 짜증나게 했다. 최근까지는 보조기기는 이를 개선할 수 없었다. 왜냐하면 변경에 대응하여 보조기기에 경고해줄 수 있는 마크업 표준이 없었기 때문이다. Live Region은 이 차이를 메우고 보조기기에 DOM 변경을 알려줄 수 있는 설정을 제공하였다. 설정은 언제 어디서 업데이트가 발생하고 얼마나 중요한지를 포함한다. Live Region을 사용하는 목표는 가장 먼저 관련 정보를 제공하고 가능한한 사소한 정보는 제한하는 것이다. 웹 개발자는 Live Region 사용에 익숙해져야 하고 웹 사이트의 사용자 인터페이스를 설계할 때 이것을 고려해야 한다.

Live Region state

페이지를 다시 로드하지 않고 업데이트 되는 동적 컨텐츠는 반드시 Live Region을 표시해야한다. Live Region은 ARIA 가이드라인 상태의 영향을 받으며 많은 사용자 정의 설정들은 가지고 있다. 다음은 각 관련 설정의 목록과 그 설명이다.

aria-live: (aria-live=POLITENESS_SETTING)

보조기기가 live region의 업데이트를 처리하는 우선순위를 설정하는데 사용된다. 가능한 설정들은 “off/polite/assertive“이며 기본값은 off.

설정값

• aria-live="off": live region의 업데이트를 알리지 않음.

  예제: http://accessibleajax.clcworld.net/simple/live_off.htm

• aria-live="polite": live region의 업데이트를 사용자의 현재 동작이 끝날 때 알림.

  예제: http://accessibleajax.clcworld.net/simple/live_polite.htm

• aria-live="assertive": live region의 업데이트를 사용자에게 바로 알림.

  예제: http://accessibleajax.clcworld.net/simple/live_assertive.htm

aria-relevant: (aria-relevant=[LIST_OF_CHANGES])

live region이 변경될 때 보조기기로 하여금 어떤 변경을 주시하도록 할 것인가를 설정한다. 여기서의 변경은 의미있는 변경 – 예를 들어, 온라인 친구목록에서 친구 리스트 한개가 없어졌다면 이는 친구가 오프라인이 되었다는 의미 – 가능한 설정들은 “additions/removals/text/all“이고 기본값은 “additions text“.

설정값

• aria-relevant="additionals": 추가되는 요소를 감시한다.

  예제: http://accessibleajax.clcworld.net/simple/relevant_additions.htm

• aria-relevant="removals": 제거되는 요소를 감시한다.

  예제: http://accessibleajax.clcworld.net/simple/relevant_removals.htm

• aria-relevant="text": 변경되는 요소를 감시한다.

  예제: http://accessibleajax.clcworld.net/simple/relevant_text.htm

• aria-relevant="all": 위의 세가지 변화를 감시한다.

  예제: http://accessibleajax.clcworld.net/simple/relevant_all.htm

aria-atomic: (aria-atomic=BOOLEAN)

live region이 변경될 때 보조기기가 live region 중 변경된 요소만을 알려줄지, live region 전체를 알려줄지 설정한다. 가능한 설정들은 “false/true“이고 기본값은 false.

설정값

• aria-atomic="false": live region 중 변경되는 요소만 알려주도록 설정한다.

  예제: http://accessibleajax.clcworld.net/simple/atomic_false.htm

• aria-atomic="true": live region이 변경되면 영역 전체를 다시 알려주도록 설정한다.

  예제: http://accessibleajax.clcworld.net/simple/atomic_true.htm

aria-controls: (aria-controls=[IDLIST])

사용된 요소가 컨트롤하는 요소들을 나타내는데 사용된다. 값에는 컨트롤하는 요소들의 ID가 공백으로 구분되어 들어갈 수 있다. 예) aria-controls="myRegionID1 myRegionID2"

예제: http://accessibleajax.clcworld.net/simple/controls.htm

aria-labelledby: (aria-labelledby=[IDLIST])

live region에 해당하는 레이블들을 나타내는데 사용된다. live region에 사용하며 값에는 레이블 요소들의 ID가 공백으로 구분되어 들어갈 수 있다.

예제: http://accessibleajax.clcworld.net/simple/labelledby.htm

aria-describedby: (aria-describedby=[IDLIST])

live region에 해당하는 설명들을 나타내는데 사용된다. live region에 사용하며 값에는 설명이 포함된 요소들의 ID가 공백으로 구분되어 들어갈 수 있다.

예제: http://accessibleajax.clcworld.net/simple/describedby.htm

KWAG 12번째 모임 발표자료 WAI-ARIA in Real World(on slideshare.net)입니다.

첫 발표라 긴장되고 어색했다는 느낌이 드네요. 죄송해요. ㅠ_ㅠ

발표에서 빼먹었던 내용들

이렇게 큰 모임에서의 발표는 처음이었던 관계로 긴장이 되어 준비했던 것들을 다 전달해드리지 못했습니다. 아쉬운 마음 글로나마 보충해봅니다. 참가하셨던 분들 중에 몇 분이나 보실지는 모르겠지만 도움이 되셨으면 좋겠네요.

브라우저별 ARIA 지원표에서…

프리젠테이션 10번 슬라이드의 내용입니다. 브라우저별 ARIA 지원표의 마지막 업데이트는 2009년 9월 23일이었고 1년 가까이 지난 관계로 더욱 향상되었을 것입니다. (모든 브라우저들이 적극 ARIA 지원의사를 밝혔으니까요.) 지원표는 Windows Vista의 MSAA role에 대한 지원 정도를 나타냅니다.

Widget Roles의 구현은 자바스크립트로만!

프리젠테이션 17번부터 시작되는 슬라이드의 내용입니다. Tab 같은 Widget Role은 자바스크립트가 비활성화된 경우 선형화된 컨텐츠로 표시되도록 Progressive Enhancement 방식으로 개발하시죠? 따라서 자바스크립트가 비활성화된 경우는 Tab도 일반 컨텐츠이기 때문에 Widget Role은 자바스크립트로 구현합니다. role attribute나 aria-* attribute를 자바스크립트에서 페이지가 로딩된 즉시 부여한다는 이야기입니다.

다만, Landmark Role은 정적인 문서의 영역을 표시해주는 역할을 하기 때문에 HTML에 직접 attribute로 삽입합니다.

Widget Role의 개발 시 추가 참고 문서

Widget Role 개발 시 보여드린 각 Role별 스펙에 추가로 Authoring Practices 스펙의 각 Role별 interaction 구현 방법을 참고하셔야 합니다. 원래 각 Role별 스펙에서 각 Role별 interaction 구현 방법으로 링크가 걸려있어야 할 것 같은데 아직 스펙의 링크들이 정돈되지 않아보이네요.

참고 링크

• The Paciello Group Blog: ARIA role support: how the Windows browsers stack up – Update: 브라우저별 ARIA 스펙 준수 테스트 결과 (Windows Vista MSAA 기준)
• Official Google Reader Blog: Reader and ARIA: A new way to read: 구글 리더 제작팀 블로그의 ARIA 지원 알림
• The Roles Model | Accessible Rich Internet Applications (WAI-ARIA) 1.0 » Landmark Roles: 문서의 내비게이션, 메인 영역 지정들을 위한 Landmark Roles 스펙
• The Roles Model | Accessible Rich Internet Applications (WAI-ARIA) 1.0 » Widget Roles: 탭, 다이얼로그 등의 RIA(리치 인터넷 어플리케이션) 위젯 접근성을 위한 Widget Roles 스펙
• The Roles Model | Accessible Rich Internet Applications (WAI-ARIA) 1.0 » tab (role): Widget Roles의 하나인 Tab Role 스펙
• The Paciello Group Blog: WAI-ARIA Implementation in JavaScript UI Libraries – updated: WAI-ARIA가 구현된 자바스크립트 라이브러리 목록
• 3.2.5 Content models — HTML5 (Edition for Web Authors) » 3.2.6 Annotations for assistive technology products (ARIA): HTML 5 스펙의 ARIA에 대한 설명

자바스크립트 속도 때문에 골치를 앓고 있는 이라면 당장 설치하길…

암튼 좀 짱임.

신현석님의 접근성을 해치지 않는 자바스크립트의 사용이라는 글을 읽어보셨는지요? 혹시 어렵고 복잡하다고 생각하실지 모르나 자바스크립트 기술 위에 HTML 표준에 대한 이해가 수반된다면 크게 복잡한 과정이 아닙니다. 웹 사이트 개발에 들어가기 앞서 위의 과정을 이해하고 있다면 접근성을 해치면서(?) 사용하는 자바스크립트와 같은 비용으로 자바스크립트가 불가능한 환경의 접근성, 검색엔진 최적화(SEO) 등의 이득을 챙길 수 있습니다. 접근성을 보장하는 것이 그렇지 않은 것에 비해 추가비용을 필요로 하는 것은 사실이지만 그 추가비용 안에 위의 언급한 이득은 포함되어 있지 않습니다. 즉, 위의 이득들은 꽁짜란 얘기죠. ㅋ 실제로 미투데이라는 서비스의 경우 자바스크립트를 제거한 상태에서도 정확하게 원하는 기능을 사용할 수 있고, 자바스크립트가 이 기능들을 좀 더 편하고 신속하게 이용할 수 있는 보조장치로 쓰인 모습을 볼 수 있습니다.

그 다음엔?

자… 그럼 이렇게 하면 끝일까요? 사실 아닙니다. 그 이유는 말빨이 부족한 제가 설명하는 대신 유명한 웹 접근성 관련 블로그인 456 Berea Street의 Roger Johansson옹의 글 Reading up on WAI-ARIA에서 따왔습니다.

One of the more problematic areas of web accessibility is how to handle the custom widgets and dynamic changes to content used in most web applications and on many content-based websites.

Using JavaScript to add custom behaviour and update content can cause problems for people who rely on assistive technology (AT) such as screen readers. The problems often consist of the AT not being aware that content on the page has changed, the user not noticing that something has changed, or the user being aware that something changed but not what.

웹 접근성에서 상당히 골칫거리인것들 중에 하나가 커스텀 위젯이나 대부분의 웹 어플리케이션이나 많은 컨텐츠 중심 웹 사이트들에서 사용된 컨텐츠의 동적인 변경을 어떻게 다루느냐하는 것이다.

자바스크립트를 사용하여 특정 동작을 추가하고 컨텐츠를 갱신하는 것은 스크린리더와 같은 보조기기에 의지하고 있는 사람들에게 문제를 일으킬 수 있다. 그 문제란 대개 보조기기가 페이지의 컨텐츠가 변경된 것을 감지하지 못하여 사용자가 무엇인가 바뀌었다는 것을 알지 못하거나, 혹은 사용자가 무엇인가 바뀌었다는 것은 알지만 그게 무엇인지는 모르는 문제를 가리킨다.

그래서 나온게 WAI-ARIA입니다. 자, 그러면 당장 적용을 시키면 되나? 그렇습니…다라고 말씀을 드려야 하지만 좀 상황이 편하지만은 않습니다. WAI-ARIA라는 스펙 자체가 초안(Working Draft) 상태라 아직 표준으로 인정할 수 없는 상태이고 국내에서 유명한 스크린리더인 센스리더는 WAI-ARIA의 W자도 찾아볼 수 없습니다. 구현이 전혀 안되어 있다는 얘기죠.

구글리더는 ARIA 기능을 사용할 수 있는 감춰진 링크를 제공하고 있다.

보조기기들도 지원안하는 WAI-ARIA인지 뭔지 적용하나 마나 쓸모없지 않나?라는 질문을 하실 수 있습니다. 마찬가지로 센스리더 등의 보조기기 제작사에서는 구현된 사이트도 없는데 WAI-ARIA인지 뭔지 적용하나 마나 쓸모없지 않나?라는 질문을 할 수 있고요. -_-;;;

둘 중 누가 먼저라는 걸 서로 주장하는 것도 웃깁니다. 오히려 서로 시급히 도입해야 할 판국이죠. 그렇지 않습니까? ^^

지금 당장은?

우여곡절 끝에 접근성을 해치치 않는 자바스크립트를 사용하고 그 위에 WAI-ARIA까지 적용했다고 합시다. 그런데 보조기기들은 아직이라면? 답은 의외로 간단합니다. 보조기기 사용자들이 자바스크립트를 꺼둔 상태로 사이트를 작동할 수 있는 기능(문서 시작점에 이 기능에 대한 링크를 제공한다던지…)을 주면 됩니다. :)

변경 사항

MiyaValidator 클래스의 add 함수와 addGroup 함수의 리턴값이 변경되었습니다. 특별히 폼 유효성 검사 외에 다른 작업을 하지 않으셨다면 사용상 변화된 점은 없습니다.

add 함수의 리턴값

MiyaCondition의 instance에서 MiyaValidator의 conditions 변수의 해당 index값으로 변경

addGroup 함수의 리턴값

MiyaGroupCondition의 instance에서 MiyaValidator의 groupConditions 변수의 해당 index값으로 변경

추가 기능

fileonly 속성 추가

첨부파일의 확장자를 제한합니다. 이미지파일의 확장자를 검사하는 imageonly 속성과는 별도로 업로드 가능한 첨부파일의 확장자를 직접 선언할 수 있는 속성입니다. 다음과 같은 방식으로 사용하실 수 있도록 구현됩니다.

var v = new MiyaValidator(form);

v.add("somefile", { fileonly: ["hwp", "doc", "xls", "ppt"], message: "아래아 한글 또는 MS 오피스의 문서 파일만 업로드 하실 수 있습니다." });

trim 속성 추가

입력값의 공백을 제거 후 검사할 수 있는 속성입니다. 공백 제거 방법에 따라 다음과 같은 값을 입력할 수 있습니다. 입력값은 trim 속성에 따라 공백이 제거된 후 검사되지만 실제 사용자의 입력값은 그대로 유지되며 전송시에도 공백이 사용자가 입력한 상태대로 전송됩니다.

"trim" 또는 true

입력값의 시작부분과 끝부분의 공백을 제거합니다.

"ltrim"

입력값의 시작부분의 공백을 제거합니다.

"rtrim"

입력값의 끝부분의 공백을 제거합니다.

"compress"

입력값의 모든 공백을 제거합니다.

minlength 속성 추가

HTML4의 maxlength의 반대개념으로 최소 글자수를 설정합니다.

min/max 속성 추가

입력된 값의 최소/최대값을 정의합니다. 값은 반드시 숫자로 입력되어야 합니다.

법인번호(jurino) 형식(MiyaFormat) 추가

오류 수정

requiremax 속성의 메시지 오류 수정

에러 메시지의 오류를 수정하였습니다. 프로그램 동작에 영향을 미치는 부분이 아니기 때문에 0.1 버전에도 수정 반영되었습니다. {requiremax}개 이상이하의 항목이 입력되어야 합니다.

Special Thanks To

0.2 버전의 모든 기능을 제안해주신 RedCat Caravan님께 진심으로 감사드립니다.

웹 접근성 가이드라인과 Ajax

KWCAG 1.0 에는 Flash나 동영상 등의 외부 플러그인에는 적절한 대체 컨텐츠를 제공하여야 한다는 내용이 담겨 있다. 그와 더불어 자체적인 접근성(키보드 조작 가능)이 보장되어야 한다는 내용도 있다. 이는 Ajax 어플리케이션에도 동일하게 적용되는 내용이지만 Drag & Drop이나 위지윅(wysiwig) 에디터 등 키보드 만으로 조작 가능하게 만들기도 불가능한 어플리케이션은 자체적인 접근성을 지니기가 힘들다.

99% 부족한 접근성 보장

앞서 언급한 Drag & Drop이나 위지윅(wysiwig) 에디터 등의 접근성 문제를 해결하는 데에는 여러 가지 방법이 있을 수 있다. 사용성은 떨어지지만 키보드로 구현할 수 있으며 시각장애인을 위해 부가적인 설명을 달아줄 수 있다. 하지만 결과적으로 어떤 이들에게는 사용성의 증대의 좋은 결과를 가져다 준 기능이 어떤 이들에게는 사용성의 저하라는 결과를 가져다 주고 말게 된다. 다양한 환경을 고려하여야 사용성의 저하이지 현재 웹 상의 Ajax는 대부분 키보드만으로, 혹은 스크린리더 등으로 접근할 수 없다.

"자바스크립트 언어로 구현된 Ajax 어플리케이션의 경우 <noscript> 태그를 통해 모든 기능을 구현해 주었다. 무엇이 문제냐?" 하고 묻는다면 "자바스크립트를 사용할 수 있는 경우라도 무조건 마우스를 사용할 수 있는 것이 아니다"라고 얘기하겠다. "자바스크립트 기능을 끄고 사용하면 되지 않느냐?" 하고 묻는다면 "IE6에서 자바스크립트 기능을 한 번 꺼보라"고 얘기하겠다. 매일 인터넷을 이용하는 사람들조차 거의 자바스크립트 기능을 끄는 법을 알아내기가 쉽지 않다. 자바스크립트 기능을 끄는 법을 어플리케이션의 장치 의존적 특성과 함께 해당 어플리케이션이 담긴 페이지 내에서 설명한다면 어느 정도 접근성은 향상시킬 수 있다고 하겠으나, 브라우저의 설정 도구 깊숙히 숨어있는 옵션을 제어하기 위해 설명을 읽고 시간을 허비한다면 결코 접근성이 보장된 어플리케이션이라고 얘기할 수 없다.

대체 기능의 제공

내가 생각하는 최선(最善)은 대체 기능의 제공이다. Ajax 기능은 사용할 수 있지만 장치의 문제 상 단순히 HTML만으로 이루어진 페이지보다 접근성이나 사용성이 떨어지는 경우에는 해당 어플리케이션을 표시하기 전에 분명히 장치 의존적 특성을 설명하고 같은 기능을 다른 방법으로 – 단순한 HTML 등 – 수행할 수 있는 링크를 제공하여야겠다. Drag & Drop 어플리케이션의 대체 기능을 제공한다면 화면의 모양은 다음과 같을 것이다.

대체 기능 제공을 위하여 대체 기능을 사용할 수 있는 사용자의 범위를 인식하고 그 범위의 사용자들에게 명시적으로 대체 기능의 목적과 이용방법을 제공하여야 할 것이다. 자세한 설명을 별도의 설명 페이지를 통해 할 수 있지만 예제에 표시된 정도의 메시지는 기본적으로 포함되어야 한다. 어떤 사용자는 어플리케이션의 대략적인 성격과 이용가능여부를 다른 페이지를 보고 나서야 알 수 있다면 상당한 사용성의 침해를 받을 것이기 때문이다.

Ajax를 이용할 수 있는 모든 장치를 지닌 사용자라도 무조건 배제할 수는 없다.

대체 기능을 제공할 사용자 범위 산정에 있어 사용자의 이용 환경만을 생각하면 안된다. 예로 마우스 롤오버 시에 작은 이벤트로 또 다른 기능을 제공하는 경우라면 민첩하지 못한 사용자나 인터넷 초심자 – 노인, 어린이, 지체장애인 등 – 에게는 오히려 방해가 될 수 있는 것이 Ajax이다. 이런 사용자에게도 확실하게 어플리케이션의 성격과 이용 시에 야기될 수 있는 문제점들을 알리고 그 대안(대체 기능)을 제공하는 것이 진정한 Ajax의 접근성이라고 하겠다.

키보드로 제어할 수 있는 슬라이더

제목에서도 알 수 있지만 Accessible Unobtrusive Slider는 키보드로 제어할 수 있는 슬라이더 라이브러리이다. 슬라이더 UI는 HTML5에서 지원 예정인데, 현재로서는 표시할 방법이 자바스크립트를 이용한 라이브러리를 통하는 수 밖에 없다. 그래서 많은 관련 라이브러리들이 공개되어 있는데 키보드 제어 가능한 라이브러리는 드문 편이다.

마우스 휠을 활용할 수 있는 슬라이더

Accessible Unobtrusive Slider는 마우스 휠을 통한 제어가 가능하다. 마우스 휠 제어는 상당히 편리한 기능인 것 같다. 현재 마우스 휠 방향과 슬라이드 되는 방향이 잘 맞지 않은 경우가 있어 불편한 느낌이 드는데 이는 어서 수정되었으면 하는 사항이다.

스크린 리더를 사용하는 시각장애인에게는 불편함을 가중시키는 라이브러리

마우스 사용자 뿐 아니라 키보드 사용자에게 까지도 멋지게 제어 가능한 라이브러리이지만 시각장애인에게는 오히려 방해요소가 되고 있다. 라이브러리가 슬라이더로 지정한 폼 컨트롤의 label을 가로채어 <button> 태그로 마크업된 슬라이더 UI에 배정하는데 label의 대상(for 속성)을 왜곡시키고 다른 속성(labelledby 속성)을 통해 슬라이더 UI와 label을 연결시켜주고 있다. <button> 태그에 title 속성을 통한 UI 사용법에 대한 간단한 설명을 넣거나 원래의 폼 컨트롤을 가리키는 label을 가공하지 말아야 할 것이다.

단순히 시각적인 것 이상을 생각한 훌륭한 라이브러리

Accessible Unobtrusive Slider는 시각적인 것 이상을 고려한 것만으로 의미있고 유용한 라이브러리이다. 위에 언급한 단점들을 보완할 수 있으면 모든 사용자에게 훌륭한 UI 개선 도구가 될 것이다.

덧) IE6에서 마우스를 갖다 대었을 때 많이 버벅댄다. 나만 그런가? 사용 전 충분한 테스트는 꼭! :)

DOM Script의 저자 제레미 키스(Jeremy Keith)가 쓴 방탄 Ajax가 출간되었습니다. DOM Script에서 올바른 DOM, 겸손한(unobtrusive) 자바스크립트에 관한 이야기를 했다면 이번엔 올바른 Ajax의 활용, 접근성을 확보하는 Ajax 개발론, 즉 겸손한(unobtrusive) Ajax에 대해 이야기하고 있습니다.

이 책에서의 Ajax는 Asynchronous JavaScript and XML가 아닌 미국과 영국 등에서 과거에 쓰였던 Ajax라는 단어의 뜻으로서 정의하고 있습니다. 쉽게 말해 Flex, Silverlight 등의 RIA을 포괄하는 의미라는 것입니다.

모든 웹 사이트, 웹 어플리케이션의 기본은 문서이다. 라고 이야기하는 이 책에서는 기본적인 문서((X)HTML)로 부터 출발하여 점층적으로 CSS, Ajax를 덧붙여 나아가는 개발 방식을 이야기하고 있습니다. 기본적으로 하위 호환성과 접근성이 보장된 문서((X)HTML)의 틀에서 점층적으로 새로운 기술들을 적용해 나아간다면 겸손한(unobtrusive) Ajax의 제작이 어렵지 않을 것이라는 이야기입니다.

Ajax 기술들은 아직 충분히 접근성이 검증되어 있지 않은 새로운 기술들입니다. 방탄 Ajax는 그에 대해 지적하며 Ajax 기술 적용 시에 잃을 수 있는 것들에 대해 경고하고 있습니다. 저는 이것이 이 책이 얘기하는 주제라고 생각합니다. 눈 앞에 펼쳐질 화려한 효과에 앞서 고려하지 않으면 잃게 될 것이 무엇인지, 잃게 될 것들을 지키려면 어떻게 해야 할지가 명확하지 않다면 이 책을 볼 충분한 이유가 될 것 같습니다.

덧) 항상 좋은 책을 볼 수 있게 해주시는 명수씨, 감사합니다! :)

Java의 Interface와 Ruby의 Mixin 개념을 도입한 OO 방식의 프레임워크인 QOOXDOO는 또한 기본적인 UI를 자체 제공하며 관련 아이콘들이 SDK에 포함되어 있다.

한글로 된 QOOXDOO에 관한 정보가 거의 없는 관계로 개발에 조금은 어려움이 있지만, 앞으로 중·소 사이트 제작 간 관리자 툴로서 활용할 목적으로 여러 프레임워크 중 QOOXDOO를 선택하게 되었는데 아직은 목적 달성까지 남은 일이 많은 관계로 구체적인 적용사례나 노하우는 기회가 되면 다시 소개하기로 하겠다. (써보시거나 관련 정보를 보신 적 있으신 분들, 알려줘용!! ㅠㅠ)

QOOXDOO 관련 링크

• QOOXDOO 공식 홈페이지
• 데모 페이지 – showcase에서 전반적인 UI를 볼 수 있다.
• 메일링 리스트

웹 개발 간 브라우저의 어떤 개체(element)의 상세정보를 알고 싶다면 X-Ray를 이용 해 보자. 단순히 북마크에 X-Ray 스크립트를 넣고 원하는 페이지에서 북마크를 호출하여 주는 것만으로 준비는 끝이다!

<

p>X-Ray (북마크 해 주세요!)

XRAY라는 타이틀을 가진 조그마한 레이어가 나타난다. 이제 상세정보를 알고 싶은 어떤 개체(element)를 클릭하면, id, class, position, border, margin, padding 등의 정보를 얻을 수 있다. 그리고 개체(element)가 속한 HTML의 구조가 표시되는데 부모 개체(element) 태그명을 클릭하면 해당 상세정보를 얻을 수 있다.

X-Ray 예제

X-Ray를 끄고 싶다면 x 버튼을 클릭하거나 브라우저를 새로고침하면 끝이다.

웹디자이너나 퍼블리셔, 자바스크립트 개발자들에게 상당히 유용한 툴이 될 듯 하다. 이번 버전에서 IE6 이상에 대한 지원이 추가되었다고 하니 IE의 렌더링 오류 수정에도 크게 도움이 될 것 같다. 스크린샷을 찍고 그래픽 툴에서 붙여서 확대해서 픽셀 재는 수고를 좀 덜어주지 않을까? :)