Ajax 웹표준화에서 어떻게 받아들여야 하나?

[hiphapis]

요즘 한창 뜨거운감자인 Ajax
이 녀석을 웹표준화에선 어떻게 받아들여야 할까요...?
(Ajax - 스크린리더기와의 관계에서 접근하고자 한 글입니다.)

물런, 개발자가 Javascript Disalbe(이하 JS-Dis) 된 상태에서도 돌아가게 만들어 준다면
상관없겠지만...
요즘 돌아다니는 Ajax를 보면, 거의 99% 이런거 없습니다..

그 이유를 따져보면,

• 1) 개발자가, 이런환경(JS-Dis)을 고려하지 않고(무지하기도 하죠) 제작한다.
  2) 개발자가, 이런환경에 대해서 인지하더라도, 귀찮기 때문에..
  3) Ajax으로만 구현 가능한것들 때문 (예를 들면, 포토샵같은 칼라픽커, 슬라이드바조절 등등)

우선, 1,2번 사안에 대해서..

제가, 일전에 Ajax로 만들었던 달력은..
처음에는 JS-Dis 된 상태에선 구동 불가능하다가..
수정을 하여서, JS-Dis 되었을때도 돌아가게 만들었었습니다..

저같은 경우, 약간의 노가다로 JS-Dis 되었을때도 구동 가능하도록 수정했지만..
소스에 따라서 엄청난 노가다로 다가올 수 있습니다.

물런, 이건 "처음부터 오직Ajax만 을 위한 개발"이기 때문이겠죠..
처음에는 HTML 자체적으로만 돌아가도록 만든다음에,
Ajax의 옷을 입히우는 방식으로 한다면, 문제가 없겠죠..
viewtopic.php?t=5657

하지만, 이런식으로 하면, 상사 혹은 회사에서 결과물이 늦게 나오고, 그렇다고 틀려보이는것도 없으니..닥달을 하겠죠...
그러면, 결국 Ajax만을 위한 개발이 되겠죠..

개발자가, 아무리 좋은 마인드가 있더라도..
우리나라 웹성향상, 회사이익구조상,
이런식으로 개발하기는 힘들겠죠..

웹표준화에 대한 의식을 가지고 있는 개발자에게 Order가 떨어지고..
이 개발자는, 의식을 가지고 열심히 코딩을 합니다.
하지만, 이러다보니...표준화를 지키지 않고 코딩하는것보다, 시간이 걸립니다.
회사에선, 결과물이 늦는다고 닥달하고..
결국, 울며 겨자먹기가 되고 맙니다.

부득, 웹표준화 뿐만 아니라, 프로그래머의 이상과 현실의 차이죠...


1,2번 사안은 분명 고칠 수 가 있습니다.
하지만, 위에서 언급한 이유들때문에..너무나 힘이 들겠죠..


3번사안은....어떻게 생각을 해야 할지 모르겠습니다.

어차피 Ajax가 아니면 구현을 못하는거니, Pass를 해야 되는것인지..
Pass하는것은, 웹표준화를 무시하는 행위로 봐야 하는건지..

정상인들만 누리는 특권이 되야지 정상인지.....?
좀 더 나은 서비스를 하기 나왔는데, 어쩔 수 없이 정상인들에게만 혜택을 가게 되는건지..?

어떻게 생각해야 될지..참 어렵네요..



웹에서 절대로 불가능하다고 생각했던 것들을, 가능하게 해주는 Ajax는 정말 대단하고 생각되고, 관심도 많습니다...
하지만, 웹표준화의 입장에서 접근을 한다고 생각한다면..
단순히, 디스플레이가 아닌, 웹표준화로 접근을 한다면..

어떻게 생각을 해야 할지 잘 모르겠네요..

여러분들의 생각은 어떠하신지요..?


PS>정말 두서없이 횡설수설하게 글을 ㅤㅆㅓㅅ네요...
머리속에 있는 구름같은것들을..끄집어내서 글을 쓰다보니..그렇게 되었네요..

[천하귀남]

제경우 AJAX기반 으로 불여우와 익스 양쪽에서 돌아가는 페이지를 구현성공했습니다. 물론 파폭에서는 레이아웃이 깨지는 문제가 있기는합니다만 기능동작에는 문제가 없습니다. 하지만 정말 이거 안되! 저거 안되가 많고 서로 해석도 틀리게 해서 이게 과연얼마나 효용성이 있을지 회의가 들더군요
W3C가 비영리에 강제성이 없는 단체인만큼 이런 문제는 두고두고 계속 등장할거라 봅니다.
하지만 표준은 시장요소가 만들기도 합니다. AJAX의 XMLHttpRequest가 원래 익스 플로러전용이었지만 지금은 대부분의 브라우져에 들어가 있듯이요
시장에서 다수의 유저가 인정하는것이라면 이것을 정리하는것이 표준의 역활이라 봅니다.
여하간 이미 많은 유저들이 사용하고 새로운 가능성을 제시하는 AJAX가 표준안에 추가될날이 멀지 않다고 봅니다.(그러니 빨리좀 추가해 주면 좋을듯...)

[hiphapis]

아, 제가 하나 빼먹은 내용이 있군요...

Ajax와 스크린리더기의 관계입니다..

지금의 스크린리더기로는 Ajax를 읽을 수 없습니다..
물런, 이건 스크린리더기 개발업체의 문제이긴 하지만..
이런거 전혀 고려하지 않고..
막무가내로 만들어 내다가.....
만약에 Ajax를 제대로 읽어내는 스크린리더기가 개발이 안된다면....
(물런 이런일은 없겠지만, 최악의 상황을 고려해봐야죠..)

그리고, 잘은 모르겠지만, 스크린리더기의 시장은 별로 활발한 것 같지 않더라구요..
만약, 활발하지 않다면, Ajax를 해석해 나는 스크린리더기가 개발될때까지도,
오래걸릴것이구요...

이걸, 개발단에서 해결 할 수 있는데..
위 글에서 말했다시피..
JS-Dis 된상태에서도, 제대로 돌아가도록 구현한다면..
스크린 리더기에서도 잘 읽히는것 같더군요..


스크린리더기와 Ajax의 관계에 대한 짐을
웹개발자가 질것인지, 스크린리더기개발자들이 질것인지..
이것도 문제겠지만, 아마..스크린리더기 개발자분들께서..
Ajax를 읽는 스크린리더기를 개발하시겠죠..
하지만, 언제 개발이 완료될지...

제경우 AJAX기반 으로 불여우와 익스 양쪽에서 돌아가는 페이지를 구현성공했습니다. 물론 파폭에서는 레이아웃이 깨지는 문제가 있기는합니다만 기능동작에는 문제가 없습니다.

Ajax때문에, 레이아웃이 깨지지는 않죠..
일단 웹페이지와 마찬가지로, HTML Code때문에 레이아웃이 깨지는겁니다.

[hyeonseok]

Ajax중에서도 JS꺼놓고도 잘 작동하는 것들이 많습니다. Ajax만으로 구현 가능한 것 - 표현상 Ajax가 아니라 javascript라고 하는게 더 맞겠지만 - 은 고려할 필요가 없습니다. javascript로 구현된 기능을 javascript 없을때도 되게 하라는 건 말이 안되는 일이지요. 그리고 그건 최소한의 핵심데이터도 아니고 말그대로 RIA니까요.

중요한 것은 HTML로 구현 가능한 것을 Ajax라는 이름으로 javascript없는 환경에서 사용 못해도 된다고 생각하면 안된다는 겁니다.

HTML과 HTTP를 잘 모르면서 Ajax로 삽질하는 거 보다 HTML과 DOM을 잘 아는 상태에서 Ajax를 하면 훨씬 효율적입니다. 웹이라는 것을 기본적으로 이해한 상태에서 개발을 하느냐 마느냐는 큰 차이지만 javascript 없는 상태에서도 작동되게 작업하는게 효율성을 크게 떨어뜨기는 것은 아닙니다.

다른 개발과 마찬가지로, 대충 C&P로 짜집기 하는 거랑 기본을 잘 알고 짜는것의 차이일 뿐입니다.

[사는게상처]

웹 표준화와 동떨어진 얘기지만..

칼라 픽커나 달력등에 ajax를 사용하지는 않습니다.
달력에서 월을 바꿀때마다 서버에 저장된 일정 같은것을 넣어햐 하는 것이 아니라면 말이죠.

참고로 야후에서 UI 라이브러리를 공개 했네요.
http://developer.yahoo.net/yui/index.html
여기에 님께서 말한 달력, 포토ㅤㅅㅑㅍ 에서 쓰이는거 같은 칼라 픽커, 슬라이더가 모두 있습니다.
물론 로컬에서 다운받아 사용 할 수 있으니 절대 ajax는 아닐꺼구요.
(클라이언트(js)에서 쓰는 XMLHttpRequest는 자신의 웹서비스?를 뛰어 넘지 못하니까요.)

제 짧은 소견으로는 ajax는 개발자 입장에서 코딩이 더 번거롭습니다.
예를 들자면 이미지와 테이블 만으로 웹사이트를 개발 하던 개발자가 웹표준이라는 것을 지키기 위해 div와 css등을 쓰는 것과 비슷하다고나 할까요?
물론 익숙해지면 둘다 후자가 좀 더 쉬워 질지도 모르겠습니다

제가 생각하는 ajax의 잇점은 별로 좋아하지 않는 0*0짜리 아이프레임(strict 에서는 아예 쓰질 못하게 되있으니 진정 고마운 일일지도 모르겠군요.)을 이제 안써도 된다는것과 네트웍이나 서버(특히DB)에 부하를 적게 줄 수 있다 정도입니다.

물론 아이프레임 쓸때와 같이 띠꺽띠꺽 하는 소리가 안나서 웹 채팅이나 추천검색어(제시어) 등을 걱정없이 서비스 할 수 있어서 좋기도 합니다만.
(이말은 그럴리는 없겠지만 띠꺽띠꺽 하는 소리가 싫지 않다면 ajax로 만든 모든 스크립트는 아이프레임과 js로 모두 커버 가능하다는 겁니다.)

가끔 ajax 페이지가 이쁘게 장식?되어 있는 걸보구 ajax라서 이렇게 멋진건가 하고 생각하시는 분들이 계신거 같은데 이쁘게 포장된건 단지 dhtml(html+css+js)일 뿐입니다.

제가 생각하는 ajax 사용이 가장 적합한 경우는(참고로 저는 쇼핑몰 비슷한 일에 종사하고있으며 현재 제가 서비스 하고 있는 페이지들 중에서 입니다.)
검색 페이지입니다. 왜냐면 웹 사용자가 서버에 주는 부하의 대부분이 검색페이지니까요.

웹 페이지에 쓰이는 목록들을 보자면

관련검색어
분류(3 depth까지)
네번째 분류
상품
가격대

내부적으로 디비에 더 많이 접근 하지만 겉으로 보이는건 이정도 인거 같네요.
여기서 ajax를 도입하면 관련검색어와 분류는 이페이지 내에서 어디로 이동 하든 다시 불러올 필요가 없습니다.(관련검색어 눌렀을때 제외)
그만큼 서버 부하가 줄겠죠.. 만약 상품리스트에서 페이지 이동이라면 상품만 다시 불러오면 됩니다. 서버나 네트웍 측면에서 봤을때 엄청난 절감 효과를 가져 올 수 있는 거죠.

어차피 이런 검색 페이지의 경우 한페이지로 모든게 끝납니다.
ajax를 안쓴다면 무엇을 누르든 다시 이페이지를 호출하게 되어있죠 처음 개발시 페이지 리로딩으로 개발 해놓구(물론 나중에 ajax를 쓴다고 생각을 하시고 말이죠)
끝난 다음 아약스를 부치면 됩니다. 그리고 자바스크립트 디스에이블인게 확인 된다면 폼으로 이페이지를 리로딩 시켜주면 끝납니다.

혹시 ajax로 개발 하실게 있으시면 먼저 예전 방법(페이지이동)대로 개발해 놓으신후 ajax를 부치시면 됩니다.(대부분의 경우는 예전 방법으로도 잘 돌아 갈 것입니다.)
절대 노가다가 아닙니다. 어차피 서버 사이드 스크립트는 카피엔 페이스트에 가까울 것이기 때문입니다.

한가지 덧부치자면 며칠전 부터 고민을 해보는데 스크린리더는 사이트에 버튼을 하나 놓고 쿠키를 이용 자바스크립트를 쓸 수 없는 환경과 같이 페이지 리로딩을 시키는 방법 밖에는 없을거 같네요...

횡설수설...
다시 웹 표준의 세계로 빠져 들어야겠습니다.

[hiphapis]

hyeonseok님 같은 생각을, 모든 웹개발자가 가지면..
무슨 문제가 되겠습니다..
그렇지 않으니 문제죠...

hyeonseok님 말씀에, 전적으로 동의하고..
그렇게 생각하는 개발자와, 상사들이 많아지길 바랍니다.

javascript로 구현된 기능을 javascript 없을때도 되게 하라는 건 말이 안되는 일이지요

하지만, 요즘 다들 Ajax......XMLHttpRequest 에 혹해서..
오로지 Ajax만 코딩하는 모습을 많이 보기에..
이런 생각을 하게 된거죠..
JS-Dis되면, 먹통인 Page...

제가 적었던, 순서대로
현석님이 말씀하셨던, 기반을 가지고...
개발을 하게 된다면, 뭐가 문제가 되겠습니까..ㅠ,.ㅠ


사는게상처님..
요즘 다들 Ajax.....에 대해서, 많은 생각을 하게 되어서..이렇게 다른분들의 의견은 어떠한가..궁금해서 적어본 것입니다.
원래는..이미 오래전부터 있던 XML 기술인데..
갑자기 Ajax란걸로 붕뜬거죠...

그리고, 검색에 Ajax를 이용하면 DB부하를 줄이신다고 하셨는데..
저는, 좀 의아하네요...
Ajax를 이용해서, 검색을 한다면, onKey(~~) 이벤트 핸들러를 이용할텐데..
그러면, 타이핑 할때마다, DB에 쿼리를 날리게 됩니다..
오히려 더 부하가 가지 않을까요..?

(흠, 얘기가 딴대로 샐까요...?)

[eouia]

제 동료중의 한명은
"로그인"을 AJAX로 구현했더군요.

속으로 생각했습니다. "뭐하러?"

AJAX라고 자랑스럽게 떠벌리는 페이지들, "뭐하러?"라는 의문앞에서 얼마나 효용있을지는 모르겠습니다. 어차피 사용자에게는 페이지가 리로딩되건 리로딩되지 않건 원하는게 보이면 그만입니다.
사용자에게 실시간으로 리프레쉬 시켜줘야 하는 경우(채팅? 실시간모니터링?) AJAX남발도 그다지 바람직한 건 아닌 듯 합니다.

[eouia]

앗. 오타...

사용자에게 실시간으로 리프레쉬 시켜줘야 하는 경우(채팅? 실시간모니터링?) AJAX남발도 그다지 바람직한 건 아닌 듯 합니다.

...리프레쉬 시켜줘야 하는 경우가 아닌 때에 AJAX 남발도... ^^;;

[사는게상처]

그리고, 검색에 Ajax를 이용하면 DB부하를 줄이신다고 하셨는데..
저는, 좀 의아하네요...
Ajax를 이용해서, 검색을 한다면, onKey(~~) 이벤트 핸들러를 이용할텐데..
그러면, 타이핑 할때마다, DB에 쿼리를 날리게 됩니다..
오히려 더 부하가 가지 않을까요..?

제가 표현을 잘 못 했나보네요..
hiphpais님이 말씀하시는 부분은 제글에서 찾아보자면 음..

추천검색어(제시어)

이 부분일꺼 같습니다.

검색페이지 -> 검색결과페이지 입니다.
예를 들어 쇼핑몰 검색결과페이지를 보자면 카테고리, 상품, 가격대, 판매자샵, 관련기획전 등을 뿌려주는데 예전 방식대로 하자면 1페이지 2페이지 넘어갈때마다 저 모든걸 다시 불러와야 한다는거죠. 하지만 ajax를 쓰면 페이지 넘어갈때마다 상품만 다시 불러오면 되니까(똑같은 검색어로 페이지만 바꿔서 불러오는데 카테고리나 가격대, 판매자샵, 관련기획전이 변할리는 없으니까요 꽤 오랜시간동안 브라우져를 방치하지 않았다면요.) 부담이 많이 줄어든다는 얘기 였습니다.

[advck1123]

아, 제가 하나 빼먹은 내용이 있군요...

Ajax와 스크린리더기의 관계입니다..

지금의 스크린리더기로는 Ajax를 읽을 수 없습니다..
물런, 이건 스크린리더기 개발업체의 문제이긴 하지만..
이런거 전혀 고려하지 않고..
막무가내로 만들어 내다가.....
만약에 Ajax를 제대로 읽어내는 스크린리더기가 개발이 안된다면....
(물런 이런일은 없겠지만, 최악의 상황을 고려해봐야죠..)

그리고, 잘은 모르겠지만, 스크린리더기의 시장은 별로 활발한 것 같지 않더라구요..
만약, 활발하지 않다면, Ajax를 해석해 나는 스크린리더기가 개발될때까지도,
오래걸릴것이구요...

이걸, 개발단에서 해결 할 수 있는데..
위 글에서 말했다시피..
JS-Dis 된상태에서도, 제대로 돌아가도록 구현한다면..
스크린 리더기에서도 잘 읽히는것 같더군요..


스크린리더기와 Ajax의 관계에 대한 짐을
웹개발자가 질것인지, 스크린리더기개발자들이 질것인지..
이것도 문제겠지만, 아마..스크린리더기 개발자분들께서..
Ajax를 읽는 스크린리더기를 개발하시겠죠..
하지만, 언제 개발이 완료될지...

제경우 AJAX기반 으로 불여우와 익스 양쪽에서 돌아가는 페이지를 구현성공했습니다. 물론 파폭에서는 레이아웃이 깨지는 문제가 있기는합니다만 기능동작에는 문제가 없습니다.

Ajax때문에, 레이아웃이 깨지지는 않죠..
일단 웹페이지와 마찬가지로, HTML Code때문에 레이아웃이 깨지는겁니다.

스크린리더의 시장이 활발하지 않은 것 보다는, 좁다고 하는게 맞는것 같습니다. 사실, 소수 사람들이 쓰는 프로그램이라서....
그리고, 이걸 살려면, 비싼 돈을 주고 사야하니까 가격 부담이 장난이 아니지요. (저의 경우야 가치가 있으니깐 사고, 아니 정확히 말해서 써야하기 때문에.. 사지만, 그렇지 않은 분들은.. 단지, 웹표준 만을 테스트하기 위해 구입해야 한다는게..~~);
그리고, ajax인가요? 잘은 모르지만.. 여튼, 그 기술 관련해선 아직 언급조차 안 된 것으로 압니다. 솔직히 지금의 인터넷의 경우도 버그가 많이 존재합니다. (이를테면, 드림보이스에서 특정 컴에서 h테그 한 줄 때문에 그 이후부터 모두 h테그로 인식해 버리는 등의 여러가지 버그가 존재합니다.) 한국에서 가장 좋다는 센스 리더의 경우에도 이제 해딩 기능이 추가된다고 하네요..
언젠간 누군가에 의해서 언급이 되긴 하겠지요. 하지만, 앞에서도 말했다싶히 스크린리더의 시장은 너무나 좁기 때문에....
그리고, 사실 이런 전문적인 기술들에 대해서 언급하실 분이 몇 안되는 것으로 압니다. 물론, 어딘가에서 공부하고 계신 분도 있긴 하겠지만, 제가 본 바로는.. 몇 개의 응용프로그램 및 인터넷 조금 즐기시는 분들이 대부분인것 같습니다. 스크린리더의 버그 리포팅도 활발해야 할텐데, 몇 분께서 힘을 쏟고 계신듯 한데, 예전보다 훨 낳아진건 사실이지만, 아직까진 너무나 미약한듯 하네요....

[hiphapis]

제 동료중의 한명은
"로그인"을 AJAX로 구현했더군요.

속으로 생각했습니다. "뭐하러?"

AJAX라고 자랑스럽게 떠벌리는 페이지들, "뭐하러?"라는 의문앞에서 얼마나 효용있을지는 모르겠습니다. 어차피 사용자에게는 페이지가 리로딩되건 리로딩되지 않건 원하는게 보이면 그만입니다.
사용자에게 실시간으로 리프레쉬 시켜줘야 하는 경우(채팅? 실시간모니터링?) AJAX남발도 그다지 바람직한 건 아닌 듯 합니다.

eouia님, 동감합니다..ㅎㅎ;
요즘, 다들 너도나도 Ajax...패션에 유행이 있듯이..웹에서 Ajax가 유행을 타고 있죠..
있어도, 그만 없어도 그만......
그리고, 꼭 Ajax가 필요하지도 않는데, Ajax란 유행의 옷을 입혀놓고 말이죠...
어떻해 보면, 낭비라는 표현이 맞겠네요..

아, 그렇다고 Ajax 나쁘다!!, Ajax 공부할 필요가 없다고 말하는게 절대 아닙니다.

검색페이지 -> 검색결과페이지 입니다.
예를 들어 쇼핑몰 검색결과페이지를 보자면 카테고리, 상품, 가격대, 판매자샵, 관련기획전 등을 뿌려주는데 예전 방식대로 하자면 1페이지 2페이지 넘어갈때마다 저 모든걸 다시 불러와야 한다는거죠. 하지만 ajax를 쓰면 페이지 넘어갈때마다 상품만 다시 불러오면 되니까(똑같은 검색어로 페이지만 바꿔서 불러오는데 카테고리나 가격대, 판매자샵, 관련기획전이 변할리는 없으니까요 꽤 오랜시간동안 브라우져를 방치하지 않았다면요.) 부담이 많이 줄어든다는 얘기 였습니다.

아, 이해했습니다..!!

[Channy]

하지만, 요즘 다들 Ajax......XMLHttpRequest 에 혹해서..
오로지 Ajax만 코딩하는 모습을 많이 보기에..
이런 생각을 하게 된거죠..
JS-Dis되면, 먹통인 Page...

Ajax라는 정의를 잘 살펴 보면 XMLHttpRequest를 빼고 웹 표준 기술 밖에 없습니다. 그만큼 XMLHttpRequest가 중요하지 않다는 말입니다. DOM 핸들링에서 가장 필요한 것이 구조에서 행동(Behavior)를 분리하는 것이구요. 이러한 방어적 자바스크립트 코딩에 대해서는 실전 웹 표준 가이드의 구조와 행동의 분리 편을 참고하시면 될 듯 합니다.

hiphapis님이 말씀 하신대로 혹해서 만드는 사람 분명히 있습니다만...
주객이 전도되지 않도록 더 많이 알려 주시기 바랍니다. 여기 있는 사람들도 노력할 겁니다. 또한 Ajax 기술이 W3C에서 다루어 지기 시작한 만큼 WAI와 관련해서 앞서 언급한 방어적 코딩외에 좋은 해법이 나올 것입니다.

그리고, 검색에 Ajax를 이용하면 DB부하를 줄이신다고 하셨는데..
저는, 좀 의아하네요...
Ajax를 이용해서, 검색을 한다면, onKey(~~) 이벤트 핸들러를 이용할텐데..
그러면, 타이핑 할때마다, DB에 쿼리를 날리게 됩니다..
오히려 더 부하가 가지 않을까요..?
(흠, 얘기가 딴대로 샐까요...?)

그렇지 않습니다. 비동기적이란게 응답을 받지 않은 상태에서는 호출을 하지 않으니까요. 구글 서제스트 같은것을 http 스니핑 해보시면 onkey할때 다 날리는 것이 아닙니다.

[hiphapis]

이러한 방어적 자바스크립트 코딩에 대해서는 실전 웹 표준 가이드의 구조와 행동의 분리 편을 참고하시면 될 듯 합니다.

http://www.mozilla.or.kr/docs/web-devel ... e-2005.pdf
를 말씀하시는건가요..?

그렇지 않습니다. 비동기적이란게 응답을 받지 않은 상태에서는 호출을 하지 않으니까요. 구글 서제스트 같은것을 http 스니핑 해보시면 onkey할때 다 날리는 것이 아닙니다.

흠..제가 이해를 못한것 같네요...

코드: 모두 선택

<input type="text" name="Search" onKey(.*)="Ajax.Search">

이런식의 구조에서..
만약, 제가 검색어를 "웹표준화" 라고 한다고 가정을 한다면..

• ㅇ, ㅜ, ㅔ, ㅂ,
  ㅍ, ㅛ,
  ㅈ, ㅜ, ㄴ
  ㅎ, ㅗ, ㅏ

이것들이, 입력될때마다, 신호를 날리고 Query 를 날리게 됩니다..
여기서, 응답까지 시간이 걸리면,
응답이 완료될때까지는, 잠시 먹통(?)이 되겠죠.

사는게상처님께서는, 이게 아닌, 다른 처리방식을 말씀하셨던걸 제가 이처럼 오해를 했던거죠..ㅎㅎ;

그리고, 본래, 제가 이글을 쓰게 된 동기가.....
스크린리더기와의 연동이었습니다...
제목을 쓰고, 글을 쓰다보니, 딴 얘기만 잔뜩 쓰게 된거죠..ㅎㅎ;
생각해보면, 제목부터 잘못된것 같네요.
"Ajax와 스크린리더기의 관계...?"
이 정도가 적당했을 것 같네요..ㅎㅎ;

[김준현]

여기 이런 글이 있었네요..
저는 스크린리더 개발자입니다.
시각장애인이고요..
위에서 advc1123님이 드림보이스 센스리더 언급하셨는데..
그게 스크린리더입니다..
스크린리더가 Ajax를 커버할 수 있는가?
전 Ajax는 잘 모르지만..
Ajax가 스크립트 기반 동작 기술이라면..
개발하는 제 입장에선 거의 "불가능"하다고 생각합니다..
그렇지 않았다면 W3C나 KWCAG(Korean Web-Content Accessibility Guidelin, 한국

웹접근성가이드라인)이 나올 필요가 없었겠죠..
홈페이지가 접근성(Accessibility)를 보장하지 않는다면 스크린리더가 그것을 완

전하게 접근하기란 매우 어렵습니다..
즉, 완전하게 접근한다 함은,
스크린리더를 통해 접근성이 보장됨을 의미합니다.
다시 말해, 스크린리더를 사용하는 사용자(대부분 시각장애인이죠..)가 스크린리

더를 통해 얼마나 홈페이지를 접근해낼 수 있는가를 의미합니다.
일예를 들어,이건 Ajax는 아니겠지만..
홈피에보면 그림이 많습니다.
보통 IMG태그로 표현하는데..
시각장애인들은 그림을 볼 수 없죠..
그런데 대부분의 홈피에는 적어도 하나 이상의 이미지가 있죠..
어떤 홈피는 그 특성상 중요한 정보를 이미지로 표현해 놓은 경우도 있습니다.
현재 스크린리더 기술은 그림(이미지)를 만나면 이미지의 파일명을 읽어주도록 되

어 있습니다.
그러나 이럴 경우 파일명만으로는 어떤 그림인지 알 수 없는 경우가 많습니다.
이를테면, "누군가가 컴퓨터 앞에 앉아서 타이핑하고 있는 그림"이 있다고 하면..
그것을 파일명만으로는 추측하기 어렵죠..
그래서 접근성을 보장하고자 하는 페이지는 그림에 "알트(ALT)" 속성을 달아줍니

다.
예를 들어 위와 같은 경우..
IMG src="computer_man.jpg" alt="컴퓨터 앞에 앉아서 타이핑하는 사람"
과 같이 할 수 있죠..
이럴 경우 스크린리더는 파일명을 읽는 대신 알트 속성을 인식하여, "컴퓨터 앞에

앉아서 타이핑 하는 사람"라고 읽습니다.
(백퍼센트는 아니지만..) 접근성이 보장된거죠..
그리고 어떤 페이지에 보면 깜빡이는(블링킹되는) 글자들이 있는 홈페이지가 있습

니다.
이런 경우 저시력인이 사용하기에 매우 어렵습니다.
블링킹으로 인해 눈이 쉽게 피로해 지기 때문이죠..
이런 경우를 대비하여, W3C나 KWCAG에서는 블링킹 횟수를 조절할 수 있도록 하거

나, 블링킹 기능 자체를 On/Off 할 수 있는 기능을 함께 지원하도록 하고 있습니

다.
이미지에 알트 속성을 병행하여 지원하는 것 처럼 말이죠..
이것이 접근성을 보장하는 방법이기 때문입니다.
다들 아시겠지만..
더불어 사는 사회입니다.
함께 사는 사회입니다.
정보화가 우리들에게 끼친 영향력은 굉장하며..
정보화로 인해 삶이 얼마나 좋아지고 풍부해 졌는지 모릅니다.
그러나 일부 사람들은 정보화로 인해 더욱 더 소외감을 느낄 수 있습니다.
다른 사람들이 누리는 모습을 보면서 부럽다..
나도 저렇게 할 수 있다면..
나도 싸이를 자유롭게 사용할 수 있다면..
하고 생각합니다.
같이 만들어 나갔으면 좋겠습니다.
스크립트 사용하지 말라는 거..
사실 어려운 일이죠..
그리고 그렇게 할 수도 없고요..
스크립트가 분명 필요한 부분이 있다고 생각합니다.
ActiveX 콘트롤, Applet도 마찬 가질 것입니다.
Ajax 또한 그럴 것이고요..
그러나..
함께, 더불어 살아가는 것이 바람직하다면..
접근성이 보장될 필요가 있을 것입니다.
제가 W3C나 KWCAG를 언급하는 이유가 여기에 있습니다.
제가 부탁드리고 싶은 것은..
(여기에 이러한 부탁이 가할지는 모르겠으나..)
접근성 지침(W3C나 KWCAG)을 준수해 주십사 하는 것입니다.
접근성 지침의 세부를 보시면 아시겠지만..
접근성 지침이 결코 스크립트나 ActiveX, Ajax를 금지하지 않습니다.
필요하기 때문이죠..
단, 제한하거나 단서 조항을 달 수 있는데..
(이를테면.. 블링킹 기능을 너을 때는 블링킹 횟수를 조절하거나 On/Off할 수 있

는 기능도 같이 넣을 것 등..)
이는 접근성을 위함입니다.
다수 뿐 아니라 소수도 사용할 수 있도록 하기 위함입니다.
접근성 지침을 따랐을 때..
충분히 상업적이고 사용 가능한 홈페이지를 만들 수 있습니다..
그러나 힘들겠죠..
이미지에는 알트 속성을 다라주어야 하고..
여러 가지 단서 조항을 지켜주어야 하니까요..
그래서 부탁드리는 것이죠..
함께 노력해 주실 것을...
사실 지침을 따름으로서 오는 이점도 있습니다.
접근성이 보장된다는 것 외에,
페이지가 명확해 지고 빨라질 수 있으며, 어떤 부분에서는 적은 노력으로 원하는

목적을 달성할 수 있습니다.
그러나 이런 것들과는 별도로..
지침 자체가 부담이 되고 수고스러울 수 있습니다..
힘든 부분이 될 수 있음을 압니다..
그래서 부탁드리는 것이죠...
음.. 길었는데.. 제 생각의 요점은...
"1) 스크립트, ActiveX, Ajax는 필요하다.
2) 이에 아울러 W3C나 KWCAG의 지침을 따른다면 다수가 사용가능한 페이지가 될

것이다..." 입니다.

[hiphapis]

네, 제가 우려하던 바로 그 부분이네요..

좋은글 정말 감사합니다..!!

[hiphapis]

Ajax가 스크립트 기반 동작 기술이라면..
개발하는 제 입장에선 거의 "불가능"하다고 생각합니다..

김준현님, 스크린리더기가
어떤 원리로 구동이 되고 해석이 되는지..
간단한 설명 부탁드려도 될까요..?

스크립트같은것은 어떻게 해석을 하는지 궁금합니다.

[hyeonseok]

KADO에서 스크린리더들의 현황파악을 위해서 테스트 했었던 적이 있습니다. 그때 제가 파악하기로는...

스크린 리더들은 읽는 방식을 몇가지로 변경할 수가 있는데,

기본적으로는 HTML파싱에 의존해서 코드를 읽어줍니다. HTML을 바로 읽는 것은 아니고 IE가 파싱해준 HTML을 읽어주기 때문에 전송된 HTML과는 약간 차이가 았습니다. HTML오류 같은 것을 수정해 주죠. 이 모드에서는 CSS와 이미지와 스크립트를 꺼 놓은 상태와 동일하게 정보를 제공해 줍니다.

다른 모드는 HTML파싱 보다는 화면에 랜더링 된 엘리먼트를 기준으로 읽어 줍니다. 하지만 보통의 스크린리더 사용자들은 이 모드 보다는 위의 HTML파싱을 기본으로 한 모드를 사용한다고 하더군요.

두번째 모드를 이용하면 AJAX를 읽을 수 있지 않을까 라는 생각이 들 수도 있지만 텍스트를 읽어주는 기준 위치를 컨트롤 하기가 힘들고, 컨트롤 해서도 안되기 때문(사용자에게 혼란을 초래할 수있습니다.)에 쉽지는 않을 것 같습니다.

스크립트와 플래시는 해석을 못했습니다.
<object>의 대체 텍스트는 읽을 수 있는 리더도 있었고 없는 리더도 있었습니다.

AJAX를 해석하려면 말 그대로 화면의 변화를 인지해서 이를 알려주는 기능이 필요 한데, (Remote Desktop Connection같이...) 이러한 기능 보다는 페이지를 접근성 높게 만드는 것이 훨씬 효율 적이라고 생각합니다.

[김준현]

예.. 스크린 리더 동작은..
현석님 말씀해 주신 대로입니다..
IE가 주는 HTML을 파싱하여 읽어주는 방식 하나가 있고요..
탭, 쉬프트+탭을 눌러 링크(프레임, 테이블 등)를 랜더링할 때 읽어주는 방식이

있습니다..
이 두 방식을 사용자가 선택하여 읽을 수 있도록 되어 있고요..
좀더 상세히 설명드리면..
1번 방식은.. 웹페이지가 뜨면..
1) IE로부터 HTML을 얻습니다..
2) 얻어온 HTML을 파싱하여 스크린리더 사용자(일반적으로 시각장애인)가 읽을 수

있도록 가상 페이지를 만듭니다..
3) 이 과정이 끝나면 사용자에게 파싱이 끝낫다고 알려줍니다..
4) 사용자는 방향키(상하좌우, Home, End, PgDn, PgUp) 등을 이용하여 페이지를

읽거나 엔터를 눌러 클릭할 수 있습니다..
마치 메모장을 사용하는 것처럼 글자, 단어, 라인 단위로 내용을 확인하도록 해

주고 링크에서는 클릭할 수 있도록 해 줍니다..
일반적으로 이 방식이 사용하기 편하고 많은 정보를 알려주므로 스크린리더 사용

자들이 선호합니다..
그리고 2번 방식은.. 화면 랜더링을 읽어주는 것으로.. 사용자가 이 방식을 선택

하면..
1) 사용자가 탭을 눌러 다음 링크로 이동합니다..
2) 윈도우즈는 이동된 링크 정보를 스크린리더로 알려줍니다..
(이것을 MSAA 이벤트라고 합니다..)
3) 스크린리더는 이벤트를 이용해 링크 객체(object)를 얻고 필요한 정보를 사용

자에게 알려줍니다.. (정확히 말해 음성이나 점자 출력 해 줍니다..)
대략은 이러한 구조로 되어 있습니다.. (모든 스크린리더가 이 구조에서 크게 벗

어나지 않을 거라고 생각합니다..)
구조를 보셔서 아시겠지만.. 상당히 OS 의존적(OS-dependant)입니다..
그것은 스크린리더ㅢ 특성 때문인데..
스크린리더는 독립적 응용프로그램이라기보단..
OS에 상주하면서 OS가 하는 행동들을 사용자에게 알려주어야 하기 때문입니다..
이를테면, 키보드로 입력하는 내용을 읽어주는 것이나..
메모장에서 캐럿을 이동할 때 읽어주는 것이나..
팝업 메뉴의 특정 메뉴 항목 선택 시 읽어주는 것이나..........
OS가 지금 무슨 일을 하고 있는지 알아야 읽어줄 수 있습니다..
이런 이유로 스크린리더 기술 중 널리 쓰이고 있는 기술은 후킹(hooking)입니다..
즉.. 스크린리더가 OS로부터 광범하게 데이타를 가져올 수 있는 체제가 구축되어

야 하는 것이죠..
위의 1번, 2번 방식의 특징을 말씀드리면..
1번 방식:
1) 사용자(일반적으로 시각장애인)가 읽기 쉽게 페이지를 구조화할 수 있습니다..
2) 반면, 상대적으로 Ajax나 스크립트에 약합니다..
2번 방식:
1) Ajax나 스크립트에 강할 수 있습니다.. (단.. OS가 해당되는 부분에 대한 충분

한 이벤트(MSAA 이벤트)를 제공해야 합니다.. 이럴 경우.. 몇초에 한번씩 변경되

는 화면 정보도 읽을 수 있습니다..)
2) 반면, 페이지를 사용자(일반적으로 시각장애인)가 접근하기 쉽게 (구조화하여)

제공하기 어렵습니다..
일반적으로 MSAA 이벤트는 링크나 폼콘트롤에서는 활발하지만.. 단순텍스트를 제

공하는 데는 한계가 있습니다..
예컨대.. 링크의 경우 포커스되면 "포커스 이벤트"를 발생시킬 수 있지만.. 일반

텍스트는 발생시킬 이벤트가 없습니다..
따라서.. 스크린리더에서 Ajax가 지원되기 위해서는.. 2번 방식을 사용한다고 했

을 때..
1) Ajax로 인해 (화면 상에) 변경된 상황을 알려주는 이벤트가 제공되어야 하며..
2) 그 이벤트는 충분하고 스크린리더 사용자가 만족스러울만큼의 접근성 있는 정

보이어야 합니다..
정말.. 정말 기술이 발전하여..
이벤트 의존 없이.. 스크린리더 자체적으로 이런 모든 상황을 커버하기 위해서

는..
스크린리더가 Ajax를 분석해야 합니다..
즉.. OS의 내부를 파악해야 하며..
IE의 동작 원리를 알고 있어야 합니다..
뿐만 아니라.. OS로 침투하여 필요한 정보를 얻어올 수 있어야 합니다..
사실 이것이 전혀 불가능한 것은 아닙니다..
실제로 외국의 스크린리더는 화면 정보 데이타베이스를 구성할 때.. 이러한 OS 침

투 방식을 사용합니다..
그러나 그러기 위해서는 상당한 기술력을 갖추고 있어야 합니다..
스크린리더 개발자가 OS를 설계하고 제작한 것이 아니므로..
사실 이러한 작업들은 매우 어려운 작업에 속한답니다..
실제로 외국에서도 화면 정보 데이타베이스를 구성하는 것 외에는 OS의 low-level

접근은 이루어지지 않는 것으로 알고 있습니다..
따라서.. 정리하자면..
스크린리더들은 OS-dependant 하게 개발되어 왔으며..
앞으로의 방향성 또한.. 이 체제를 유지하되..
스크린리더 자체 기술을 보완하여 보다 세밀하고 정확하게 읽어줄 수 있도록 할

것 같습니다..
어떻든.. 스크린리더의 완벽 스크립트 지원이나 완벽 Ajax의 지원은..
현재 스크린리더 자체 기술로는 어려우며..
(스크립트 파서의 구비는 물론, OS 및 IE 파악과 더불어 OS 침투 기술 등이 필요

합니다.. OS침투 기술은 OS에서 정보를 가져와야 하기 때문..)
OS 의존적인 현재의 수준에서는..
OS가 제공해 주는 정보를 크게 벗어나지 않는 범위(스크린리더가 자체 기능을 보

강하여 조금 더 읽어줄 수는 있겠지만..) 내에서 지원 가능합니다..
전에.. 접근성을 언급하면서..
함께 살아감.. 더불어 살아감에 대해 말씀드렸었는데..
사실.. 스크린리더 개발에도 유사한 것을 느낍니다..
우선.. (자의든 타의든) OS 의존적이라는 것..
그리고.. 일반 개발자들의 협조가 필요하다는 것을 느낍니다..
장애인이 일반 사회에 통합되기 위해서는..
장애인들의 노력이 첫째로 중요할 것이요..
그와 아울러 사회의 장애에 대한 인식 개선과..
장애를 수용할 수 있는 시스템이 갖추어져야 할 것입니다..
장애인들만의 힘으로는 부족하며..
서로 의존하고.. 더불어 가야 할 것입니다..
소프트웨어에 있어서도 마찬 가지입니다..
접근성에 대한 인식.. 필요성들이 일깨워져야 한다고 생각하고요..
아직 왜 접근성 지침이 필요하며..
그것을 지켜야 할 이유를 모르는 분들도 많은 현실.. t_t;;..;;
아울러 필요성의 인식에서 그치는 것이 아니라..
실제로 그러한 노력들이 이루어져..
접근 가능한 시스템이 갖추어 진다면..
지금보다 더 낳은 세상.. 더 나은 공간이 되지 않을까 하는.. ^_^..
장애인인 제가 드릴 수 있는 말씀은..
여러분들께 이러한 부탁을 드리는 것 정도지만........
그리고 실제 개발하면서 이러한 필요성을 느낍니다..
스크린리더의 힘만으론 어렵겠구나..
함께 함이 없으면 힘들겠구나............
하나의 예를 들자면..
만약 스크린리더가 정말 진보하여서 ActiveX나 스크립트, Ajax를 완벽하게 지원할

수 있는 날이 와도..
시각의 장애로 인해 오는 불편함은 여전히 남습니다..
(일부 정말 천재들이 있긴 하지만..) 스타크래프트를 하는 시각장애인은 거의 없

으니까요..
스타크래프트가 음성 지원 되어야 한다는 말이 아니라..
그만큼 접근성이 고려되지 않는다면..
정보 접근에 대한 사각 지대는 여전히 남을 수 밖에 없을 것입니다..
음.. 쓰다 보니 또 긴 연설문이 되어 버렸다는 t_t;; 그래도 잘 읽으시고 잘 이해

해 주실거라고 믿고요...... 안녕히.......

[hiphapis]

현석님, 준현님
좋은 글 정말 감사합니다

[hiphapis]

문득 생각이 난것이 있는데..

만약 말씀하신대로의 방식이라면..
CSS 같은경우는 어떻게 되는지 궁금합니다.

CSS가 입혀진 상태에서 출력되는 그대로를
스크린리더기가 읽어서 처리한다면..
CSS규칙만 지켜서 코딩하면 될 것 같은데....


CSS Disalbe 된 상태까지 감안해서 제작해야 되는지..
만약, 감안해야 한다면 어떤 상황을 대비해서 감안해야 하는지..
이게 궁금합니다..