Javascript로 링크 및 AJAX구현시 Fallback Link를 제공해야 하는 이유

f1e4ccf2bb4122e22aba7f35653d5494

Javascript로 행해지는 Action의 결과물이 서버(Server)로 요청(Request)하는 행위라면 Fallback Link를 함께 제공해주는것이 안전하다.

서버로 요청한다는것은, 단순히 UI를 위한 스크립트가 아니라는 말이다.
즉 페이지 이동 하거나, 값을 전송하기 위함인데
필자는 단순히 UI변경하는것보다, 서버로 값을 전송하는게 더 비중있는 일이라고 생각한다.
그 이유는 대다수의 경우 서버로 값을 전송하는것이 Action의 Goal인 경우가 많기 때문이다.
그러므로 난 Fallback Link를 제공해야 한다고 주장하는 것이다.

예를들어
로그인 버튼을 누를시 Javascript를 이용해 서버에 값을 전송하는 환경이라고 하자.
근데 어떠한 이유에 의해서 Javascript가 동작을 안한다면
이 유저는 로그인을 할 수 없게 되는것이다.

자, 그럼 Fallback Link는 무엇이냐?
아주 간단하다. javascript로 동작하는 a태그의 href에 유효한 url을 입력하는 것이다.
그러므로 Click 이벤트가 일어나는 모든것은 Clickable한 객체로 마크업을 하는것이 바람직하다.

Fallback Link는 언제 동작하는것이냐?
이것 또한 간단하다. Javascript가 동작하지 않는 상황을 대비하는것이다.

근데 솔직히 말하면 브라우저가 자바스크립트를 지원하지 않아서, 자바스크립트가 미구동되는 경우는 거의 없다.
하지만 자바스크립트 문법 에러가 나서 동작하지 않는 경우는 꽤 있으므로, 이에 대한 대비로 봐도 된다.
뭐 사실 갖다붙이면 여러가지 이유가 있겠지만..
결론적으로 말하면 자바스크립트 미구동에 대비하는걸로 인해 생기는 부수적인 효과들이다.

돌아와서 Fallback Link제공의 간단한 예를들면

<a onclick="like('comment', 1)" href="#">Like</a>

이렇게 된걸 아래와 같이 수정하는것이다.

<a href="/like" data-action="like" data-content-type="comment" data-content-id="1">Lik</a>

$("a[data-action='like']").click(function(e) {
    # do something
});

단순히 Fallback url을 제공했다고 끝나는게 아닌다.
해당 url이 실제로 동작을 해야 한다.

서버단에서 요청된 Header정보를 보고 Ajax인지 아닌지 판단하고,
여부에 따라서 응답을 달리 해주는 작업을 해줘야 한다.

무슨말인고하니,
보통의 경우 Ajax 응답만 작업했을것이고, 해당 코드는 아래와 같을것이다.

$("a[data-action='like'][data-content-type='comment'][data-content-id='1']").addClass("selected")

하지만, url을 타고 요청이 왔을 경우 유저는 하얀 화면 혹은 위 JS코드가 출력된(?) 화면을 보게 될 것이다.
이럴경우를 대비해야 한다는것이다.

기획단에서 어떤 페이지로 렌딩(Landing)할 것 인지, 먼저 정한 다음
해당 페이지를 렌더링(Rendering) 혹은 리다이렉트(ReDirect)해주면 된다.

Rails에서는 그냥 몇글자 추가해주면 되지만..
보편적인(?) PHP로 예를들면

if(!empty($_SERVER['HTTP_X_REQUESTED_WITH']) && strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest') {
    // Ajax Process
}
else {
    // Page Redirect
}

이 정도?
PHP 코드 출처: http://davidwalsh.name/detect-ajax

사실 이런 내용은
Graceful Degradation, Unobtrusive Javascript
같은 방법론들이 얘기하는것과 일맥상통하기도 한다.

광고

Click Event Binding with Clickable Elements

너무 기초적인 내용인데, 이리 저리 사이트 둘러다니다보면 생각보다 지켜지지 않는 경우가 많아서 포스팅 하기로 했지만..사실 별 내용없다.
요점은 click 이벤트는 clickable한 요소에 등록하자.

내 눈은 Clickable 하지않거든? ㅋㅋ

먼저 아래 코드를 보자.

<img onclick="like('post', 1)" alt="좋아요" src="btn_like.png" />

위 코드는 시멘틱(Semantic)하지 않고,
clickable하지 않은 요소에 이벤트를 등록해 키보드로 이용을 할 수 없다는 또 다른 문제점이 있다.
이것은 접근성적인 측면에서 큰 문제가 된다.

너무나 당연해 얘기하는것 조차 민망하지만, click 이벤트가 일어나는것들은 Clickable한 요소를 이용해 마크업을 해야한다.
클릭커블한 요소들은

  • a
  • button
  • input type=”button”
  • input type=”submit”

정도가 있다.

그러므로 위 img태그는 아래와 같이 수정되어야 한다.

<a href="#" onclick="like('post', 1)"><img alt="좋아요" src="btn_like.png" /></a>

href에 알맞은 url까지 적어주면 금상첨화.

<a href="/like?content_type=post&content_id=1" onclick="like('post', 1)"><img alt="좋아요" src="btn_like.png" /></a>

아. 물런 url은 실제로 동작을 해야한다.

이것만으로도 충분하지만, html과 js를 분리시키는게 더 나은 방법(Unobtrusive)임으로 분리를 시켜준다.

<a href="/like?content_type=post&content_id=1" data-content-type="post" data-content-id="1" class="like-button"><img alt="좋아요" src="btn_like.png" /></a>

이런식으로 필요한 정보들은 data 속성(attribute)를 이용해서 제공을 하고

.like-button에 이벤트(event)를 등록(bind)한다.

$(".like-button").click(function(e) {
  e.preventDefault();
  var content_type = $(this).attr("data-content-type");
  var content_id = $(this).attr("data-content-id");

  // ajax ...
});

Accessibility for iOS #2 iOS에서 지원하는 접근성들.

먼저 iOS에서 지원하는 접근성은 어떤것이 있는지 알아보자.
iOS에서 지원하는 접근성 항목은 총 7가지가 있다.

이 항목들은 Settings(설정) -> General(일반) -> Accessibility(손쉬운 사용) 에서 확인할 수 있으며, iOS를 사용하는 Device(장치)인 iPod touch, iPhone, iPad 모두 동일하게 지원을 한다.
 

 

 

VoiceOver

이름이 직관적이라 아마 모두 감 잡았으시리라 생각되지만 Apple에서 만든 Screen Reader 라고 보면 된다.
OS X에 있는 VoiceOver와 동일한 기능을 수행한다.
VoiceOver를 On을 하면, Touch는 선택된 Object(객체)에 대한 설명을 읽어주는것으로 대체되며,
Double-tap을 해야지만 Click과 같은 역활을 수행하게 된다.

기본적인 작동법의 변화 전/후를 정리해보았다.

 VoiceOver Off (Default)  VoiceOver On
 터치(Touch) 실행 항목 읽기
 탭(Double tab) 줌인/줌아웃 실행
 한 손가락 좌우 쓸어넘기기
(Flick left, right)
좌/우로 스크롤링 및 이동 이전/다음 항목 읽기
 두 손가락 아래로 쓸어 넘기기
(Two finger flick down)
선택한 항목에서부터 시작하여 페이지 읽기
두 손가락 위로 쓸어 넘기기
(Two finger flick up)
가장 위에서부터 시작하여 페이지 읽기
세 손가락 좌/우/위/아래로 쓸어 넘기기
(Three finger flick left/right/up/down)
스크롤링
네 손가락 좌/우로 쓸어 넘기기
(Four finger flick left/right)
이전/다음 컨테이너(메뉴 혹은 페이지)로 이동 – iPad만 지원
네 손가락 위/아래로 쓸어 넘기기
(Four finger flick up/down)
처음/마지막 요소로 이동 – iPad만 지원

이 정도만 알아두면 VoiceOver를 사용하는데 지장은 없을듯 하다.

http://www.apple.com/accessibility/iphone/vision.html
http://www.apple.com/accessibility/ipad/vision.html
이곳에 가면 간략한 설명은 나오지만, 디테일한 사용설명서 같은것은 없다.
간단하게 표로 결과물이 나오기까지 저자의 노고를 조금이라도 알아달라는 마음에서;;

하지만 막상 해보면 생각보다 쉽게 되지 않은데 “VoiceOver 연습”이라는 메뉴가 있다.
이곳에 가서 연습을 해보면 된다.

 

 

 

Zoom(확대/축소)

 

 

간단하게 화면을 확대/축소하는 기능이다.
이것또한 Touch방식이 변경되는데,  보통 사진이나 Safari에서는 Double tab을 하면 확대/축소가 되었다. 하지만 Zoom기능을 켜게되면 세 손가락이 기준이 된다.

  • 세 손가락으로 Double tab을 하면 확대/축소가 되고
  • 세 손가락으로 Drag(이동)을 하면 화면이 움직이고
  • 세 손가락으로 Double tab한 상태에서 Drag up, down을 하면 줌인/줌아웃이 된다.

Large Text(큰 텍스트)

모든 글자를 크게 해주는것이 아니라 달력, 연락처, 메일, 메세지, 노트의 글자 크기만 키워주는 것이다.

White on Black(검정색 바탕에 흰색)

화면의 배경색을 검정색으로 바꾸고, 글자는 흰색으로 바꾸는 설정이다.
참고로. 이 옵션을 킨 상태에서 캡쳐를 떠도 그냥 일반의 모습으로 캡쳐가 된다. (그래서 포토샵으로 Invert했다는 수고를 알아달라는건 아니다.흠흠)

Mono Audio(모노 오디오)

모노 오디오는 스트레오로 나오는것을 모노로 바꿔서 출력을 해주는 기능

Speak Auto-text(자동 텍스트 말하기)

제목막 보고서,  voiceOver도 있는데.. 이게 무슨 기능인가? 했다.
글자를 입력하다 보면, 자동으로 완성된 문자를 추천해줄때가 있다. 바로 추천된 단어를 읽어주는 기능이다.

Tripe-click Home(홈 삼중 클릭)

Home버튼 (iPod, iPhone, iPad에 외부로 노출된 유일한 제어기능이 있는 버튼)을 세번 눌렀을때 실행되는 기능을 정의하는 메뉴다.
옵션들의 대한 설명은 뻔한것이므로 생략하겠다.
 

 

마치며

iOS에서 제공하는 접근성 기능이 무엇인지 간략하게 알아봤다.
다들 이미 눈치를 챘겠지만, 우리가 신경써서 확인해야 될 부분은 VoiceOver다.
VoiceOver가 제대로 읽어주는지, VoiceOver의 Object간 이동 순서가 논리적인지등
나머지 것들은 시스템에서 제어를 하는 접근성 항목이기 때문이다.

ps.
Xcode3 에서 Xcode4로 넘어오면서 Accessibility 항목이 IB에서 사라져버렸다.
분명 IB에서만 사라진게 아니라 Code에서도 변화가 있을것 같은데..
문제는 아직까지 Xcode4에 맞춘 Guide Document가 아직 릴리즈가 안되었다는 것이다.
일단 Apple에 Xcode4용으로 빨리 릴리즈 해달라고 메일을 보내놓긴 했는데.. 언제 릴리즈가 될지 모르겠다.
결국 헤딩하면서 찾아내야 되는 상황.. 이제 농땡이 칠 시간도 없어져가는데. 큰일이다.

Accessibility for iOS #1 들어가며.

스마트폰 App 제작은 이제 핫이슈가 아니다. 좀 더 정확하게 말하면 이슈거리도 안된다.
스마트폰의 App개발은 홈페이지 만들듯, 이제는 당연한것으로 여겨진다.

그렇다면 App의 접근성은 어떠한가?


우리 솔직해져보자.
개발자중에 ‘접근성’이라는 단어를 들어본적이 있는 사람이 있는가?
만약 있다면 ‘접근성’을 App개발과 연관시켜서 생각해본적이 있는가?
그렇다면 접근성을 준수하는 App을 만들려고 노력이라도 해보았는가?

Apple에서 만드는 제품(Product)들은 대부분 접근성을 잘 지켜진 기기(Device)이다.
그러므로 장비탓을 할 수 도 없다.

과거에는 개발에만 열을 올렸지, 접근성은 철저히 무시되어왔다.
하지만 App을 만드는게 당연해진 지금이라도 접근성을 보장하도록 개발을 해야 하지 않을까?

애초부터 접근성도 함께 관심을 받으며 성장해 나가는것이 최고였겠지만,  지금이라도 접근성을 지켜 App 제작시 접근성도 당연히 신경쓰는날이 오길 기대하며 글을 써본다.

먼저 밝히고 싶은것은, 사실 필자 또한 접근성을 준수하며 App을 개발해본적이 없다.
하지만 이렇게 글을 써내려가는 이유는, 웹 접근성 전문가들중에 App 개발자는 유일무이한 상태(확인된바는 없다)다보니, 나에게 별로 달갑지 않은 책임감이 생겨버렸다.
내가 무슨 대단한 사람이라고 이런 책임감(?)이 느껴지는지 사실 모르겠다.

아무튼, 관련 문서들을 보며 직접 시도를 해보고 배운것을 하나하나 정리한 후 포스팅하게 될것이며, 기본적인 UI에서의 접근성을 다루게 될 것이다.

수정된(Customized) UI를 다루지 않는 이유는,

  • Customized UI의 방법과 형식은 무한하기 때문에, 이를 다룬다는것 자체가 어폐가 있고
  • 기본 UI의 접근성을 준수하는 방법을 익힌다면, 그 후는 응용이라고 생각하기 때문이다.

iOS에서 접근성을 지키는게 복잡하거나 어려운게 아니기때문에 연재수가 많아지지는 않을것 같다.(사실 무지 간단하다. 포스팅하는게 무안할정도로. 흠흠;;)
짐작키로 많아야 5회정도?

언제 연재가 완료가 될 지 모르겠지만 스스로를 독려해본다.

 

Android와 iOS의 접근성을 비교한 글이 있다. 스마트폰 App개발자라면 한번쯤은 읽어봄직 하다.
Accessibility 서비스로 바라본 안드로이드 vs iOS

[font series 2]폰트사이즈만 상대적으로 하면 된다?

많은 분들이 폰트사이즈만 상대적으로 생각하시는데..
저는 폰트만 상대크기면 반쪽짜리라고 생각합니다.

만약 폰트만 상대크기로 했을경우 줌브라우징하면 글자만 커졌다 작아졌다 하게 된죠. 그렇게 되면 한줄에 10글자씩 보이던게 한줄에 2글자만 보이게 되는 상황이 연출될 수 도 있는데, 이렇게 되면 글자 하나 읽을때마다 엄청난 스크롤의 압박을 견뎌내야 합니다.

그리고 레이아웃도 깨져서 섹션별로 구분하기가 힘들어 집니다.
예를들어, 다음의 메일함 좌측 메뉴에서 글자크기를 크게 해버리면 그리드가 넘어가버리게 됩니다.


이런식으로 정보가 섹션단위로 나뉘어져 있을때, 글자를 크게 해버리면 이 정보가 어느 섹션인지 알 수 없게 되버리는 거죠.
“난 상대크기줘서 글자 켜졌다 작아졌다 하게 해 줫으니깐 책임없어” 라구요?
너무 무책임하시진 않으신가요?

“이렇게 된 사이트가 어딨는데~?” 냐구요?
왜 없겠습니까. 대표적인 예시 사이트가 있습니다. 바로 yahoo.com 이지요.
yahoo.com에 가서 글자크기조절 한번 해보세요. 진정한 줌브라우징에 깜짝(?) 놀라실겁니다. ㅎㅎ

[font series 1]웹에서 Font Size 문제..

스마트에디터오픈하면서 font size 논쟁을 지켜보다가, 과거 제가 겪었던 고민을 공유해보자 글을 써 내려 갑니다.(모두가 한번쯤 생각해볼만한 문제)

폰트 크기를 상대크기로 하면 줌 브라우징을 지원하니 접근성이 향상이 됩니다.
하지만 막상 상대크기로 하고 나면 예상치 못한 문제점들이 발생합니다.

많은 사람들이 브라우져의 글자크기 조절하는 법을 모릅니다.
브라우져 텍스트크기가 보통이 아닌 다른 글자크기로 정의되어 있는데 사이트가 상대크기라면
글자가 갑자기 크게 나오거나, 혹은 작게 나오거나 하겠죠. 이런 상황을 일반적인 사용자가 맞닥뜨리면 기겁을 하며(특히 IE 6) 해킹당한건 아닌지, 바이러스 걸린건 아닌지, 컴퓨터가 고장난건 아닌지 하는 겁이 덜컥 듭니다. 너무 극단적인 예인가요?
하지만 컴퓨터를 조금 아시는 분이라도 당황하기는 마찬가지 입니다.

사용자가 많을 수 록 이러한 문제의 비율은 극격히 높아질 것 이고, 고객센터에 엄청난 질문과 항의가 올라올 것 입니다.(때때론 전화가 올 수 있구요..ㅎㅎ;)
FAQ에 올려 있다고 하더라도, 이걸 보는 사용자가 얼마나 될까요..?

대다수의 고객들이 절대크기를 경험에 의한 학습으로 사용해 왔고, 사용하고 있습니다.
회사 입장에서는 모험을 하기보다는, 안정적인 운영을 위해 절대크기로 갈것입니다. (안정적인 운영은 곧 수익창출을 할 수 있는 기반이니깐요)

그럼 결국 줌브라우징이 필요한 소수의 사용자들은 또 배척되는 딜레마 상황이 되어버리죠..
양쪽 모두를 아우를 수 있는 방법은 없는 걸까요?

IE 6 이 패치되는 방법은 어떨까요? (IE 7 부터는 줌브라우징이 지원됩니다)
패치됬을때 불러올 혼란을 생각하면 끔찍하지만, 가장 확실한 방법이죠.
하지만 MS가 그 무리수를 감당하려 할까요?
애시당초 IE 6 이 줌브라우징을 지원했었더라면..(덤으로 표준도 준수했더라면;;)

고니님과 대화를 하면서 외국계 회사들은 상대크기를 많이 쓰는거에 대해 얘기를 하게 되었는데
고니님은 그 이유를 서체에 있다고 보셨습니다. 영어는 줌브라우징으로 작게해도 알아볼 수 있는 마지막단계가 한글보다 높다는 의견이었는데,
즉 무슨말인고 하니(숫자가 작을수록 글씨크기는 작아진다면) 영어로 사이즈를 2으로 하면 더 이상 알아보기 힘들다고 한다면 한글은 5로 하면 더 이상 알아보기 힘든 사이즈가 되는 것이죠.

상대폰트 쓰면 좋은데, 막상 쓰고나면 이러저러한 문제점들이 생기니…

ps > 이것 말고도 많은 고민들과 문제점이 있을 수 있습니다.
그런것들을 서로 공유를 하면 좋겠습니다. (트랙백 혹은 코멘트로)
이러한 고민들을 서로 공유해 나가는것이 해결책을 찾아 나가는 길이니깐요.

 

서울시의 장기전세주택 ‘시프트’ 홈페이지..인덱스화면;;

제가 10월 6일이 식날이어서..
집구한다고 이리저리 둘러보다가, 신문에서 무대리가 홍보하던 시프트가 생각나서 홈페이지 접속을 해 봤습니다.


첫 화면을 보고, “오, 유치하지만 괜찮은데?” 라고 생각을 했습니다.
하지만 Shift를 누르자 바뀌어야 할 브라우져화면은 안바뀌고, JS Error 라고 뜨더군요..(아 물런 FireFox로 접근했습니다.)

그리고


이미지에 대체텍스트 또한 없더군요..

시프트에 관심있어 하는 분들중 장애인이거나 컴퓨터를 잘 모르시는 분들도 계실텐데..
대체 텍스트도 없고, index.jsp로 바로가기 링크 또한 없고..
컴퓨터를 잘 모르시는 분들은, 컴퓨터 자판의 Shift를 찾기 위해 불필요한 시간을 소모해야 하고.
어찌어찌해서 페이지로 들어가도, 상단 탑메뉴들은 작동을 안해서 메뉴이동 자체를 할 수 없습니다.

시프트 홈페이지에서 가장 많이 보는 페이지중 하나는 분명 시프트라는 정책에 대한 설명일것입니다. 이 페이지를 가면


이런 식으로 대체텍스트 없이 텍스트를 이미지로 만들어 버리는 엄청난 과오를 만행하고 있습니다.

컴퓨터 자판의 Shift키를 눌러서 이동하는것은 재미있는 아이디어이긴 하지만,

  • 바로 인덱스로 갈 수 있는 바로가기 링크 제공
  • 텍스트이미지 같은경우 대체텍스트를 제공
  • 탑메뉴 이동이 자유롭도록

등등의 방법을 취하여 접근성을 높인다면 아래의 문구처럼


웹업계의 잘못된 관행을 바로 잡은 사이트로 멋진 발돋음 하지 않을까요?

ps > http://www.shift.or.kr/index.jsp 로 가시면 shite 안누르셔도 메인페이지로 이동합니다. ㅎㅎ