상담, 인사, 문서작성 등 여러 업무를 하다 보면 나이를 계산해야 할 경우가 많습니다. 또, 행운석이나 별자리, 띠 등 나이와 생일과 연관되어 알고 싶은 경우도 많습니다.

이런 경우 쉽게 사용할 수 있는 앱을 소개해 드립니다.

사용법은 아주 간단합니다. 생년월일만 입력하면 생활연령, 살아온날수, 나이, 만나이, 띠, 별자리, 행운석 등 다양한 정보를 계산해서 보여줍니다.

기본적으로 오늘을 기준일로 해서 계산되지만, 필요에 따라서 기준일을 바꿔 나이를 계산할 수도 있습니다.

안드로이드와 모바일웹으로 사용할 수 있으니, 아이폰 사용자는 웹으로 접속해서 웹앱 등록하시면 앱처럼 사용하실 수 있습니다.

일부 폰에서는 생년월일 입력후 키패드에 있는 [이동] 버튼을 터치해야 띠, 별자리, 행운석 결과가 나오기도 합니다. (현재 일부 갤럭시노트2에서 발생) 보통은 입력 즉시 계산결과가 표시됩니다.

앱설치 : https://play.google.com/store/apps/details?id=com.k2man.age

웹으로 바로 사용 : http://age.k2man.com




신고
  1. kke 2014.05.29 23:59 신고

    이 앱을 사용하려보니 계산이 잘 맞지 않습니다.
    제 아이 생일 2009.07.17(윤달)을 입력하고 기준일을 2011년 2월 28일이라하면 생활연령 1년 7개월 11일이라고 하는데.... 기준일을 하루 더 해서 2011년 3월 1일이라 하면 생활연령 1년 7개월 14일이라고 나옵니다. 엑셀로 계산해보니 2월 28일의 결과는 맞는 것이며, 3월 1일 결과가 14일이 아닌 12일이라 나와야 맞네요.

    • k2man 2014.06.25 00:34 신고

      계산오류가 있나 봅니다. 빨리 수정해야겠네요... 제보 감사합니다. ^^

웹과 마찬가지로, 모바일 어플리케이션에서도 장애인 등을 위한 접근성 지침이 필요한 실정이였습니다.

행정안저부에서 나름 의미있는 접근성 지침을 내놨군요. 지침을 내놓은 만큼, 최소한 공공기관부터 지침을 준수해주기를 바라는 마음입니다. (여전히 웹접근성은 공공기관이 최악에 가깝죠. 업무용 시스템은 말할나위가 없고, 대국민용 서비스도 글쎄요 입니다.)

그래도 개발 관련 업무를 하시는 분들이 경험적으로 하던 것 말고, 나름 정리된 지침이 있어서 공유해 봅니다.

참고로 한글2010에서 블로그 글올리기(metaWeblogAPI)로 글을 올렸는데, 어떤가요?
한글 파일을 그냥 복사해서 올리는 것보다 훨씬 나아 보입니다. 



제정일자

 2011.  9.  22.

모바일 애플리케이션 접근성 지침

< 행정안전부고시 제2011-38호, 2011. 9. 22. >

2011.  9.


 

목   차

 

 

제1장  총  칙                                                             1

 

  제1조 (목적)                                                                  1

  제2조 (용어 정의)                                                            1

  제3조 (적용 범위)                                                            2

  제4조 (모든 운영체제에서의 접근성 보장)                                  2

  제5조 (모든 모바일 기기에서의 접근성 보장)                              2

  

제2장  모바일 애플리케이션 접근성 준수사항                3

 

  제6조 (대체 텍스트)                                                          3

  제7조 (초점)                                                                  3

  제8조 (운영체제 접근성 기능 지원)                                         3

  제9조 (누르기 동작 지원)                                                    4

  제10조 (색에 무관한 인식)                                                   4

  제11조 (명도 대비)                                                           4

  제12조 (자막, 수화 등의 제공)                                              5

   

제3장  모바일 애플리케이션 접근성 권고사항                5

 

  제13조 (기본 사용자 인터페이스 컴포넌트)                                 5

  제14조 (컨트롤간 충분한 간격)                                              5

  제15조 (알림 기능)                                                           6

  제16조 (범용 폰트 이용)                                                     6

  제17조 (사용자 인터페이스의 일관성)                                       6

  제18조 (깜빡거림의 사용 제한)                                              6

  제19조 (배경음 사용 금지)                                                   7

  제20조 (장애인 등 사용자 평가)                                             7

 

제4장  보 칙                                                               7

 

  제21조 (준수지침 사항)                                                      7

  제22조 (콘텐츠 접근성 범위)                                                7

  제23조 (접근성 진단)                                                         7

 

부  칙                                                                        8

 

[별표] 모바일 애플리케이션 접근성 지침 사례                               9

모바일 애플리케이션 접근성 지침

제1장 총 칙


제1조(목적) 이 지침은「국가정보화기본법」제32조제5항에 따라 모바일 애플리케이션 서비스 제공자가 장애인과 고령자 등의 접근성을 보장하기 위해 애플리케이션 제작 시 지켜야 할 사항을 규정함을 목적으로 한다.


제2조(용어 정의) 이 지침에서 사용하는 용어의 뜻은 다음과 같으며, 정의하지 아니한 용어는 「국가정보화기본법」 및 동법시행령을 따른다.

  1. “접근성”이란 모바일 기기를 사용하여 모바일 애플리케이션을 이용하고자 하는 장애인, 고령자 등을 포함한 모든 사람들에게 이의 활용 가능성이 제공됨을 말한다.

  2. “모바일 기기”란 무선 인터넷 서비스를 제공 받을 때에 사용하는 휴대용 기기를 말한다.

  3. “모바일 애플리케이션”이란 사용자가 특정한 목적을 달성하기 위하여 모바일 기기 상에서 실행되는 소프트웨어를 말한다.

  4. “서비스 제공자”란 모바일 기기를 이용하여 콘텐츠 및 서비스를 제공하는 공공기관 및 사업자를 말한다.

  5. “무리한 부담(Undue Burden)”이란 현재 가능한 기술 수준과 적절한 비용으로 실현시킬 수 있는 정도 이상의 노력을 요구함을 말한다.

  6. “준수사항”이란 모바일 애플리케이션의 접근성 확보를 위하여 무리한 부담이 되지 않는 한 반드시 준수해야 할 사항을 말한다.

  7. “권고사항”이란 모바일 애플리케이션의 접근성 향상을 위하여 무리한 부담이 되지 않는 한 준수할 것을 권장하는 사항을 말한다.

  8. “운영체제”란 모바일 기기 상에서 애플리케이션을 비롯한 소프트웨어를 실행할 수 있는 기반 환경을 말한다.

  9. “보조기기”란 장애인의 신체적․인지적 기능을 증진, 보완, 향상시키기 위하여 사용하는 기기, 장비의 일부분 또는 시스템, 소프트웨어를 말한다. 

  10. 터치(touch) 기반이란 모바일 기기의 기능 및 화면상의 객체를 키나 버튼 같은 물리적인 형태의 컨트롤을 사용하지 않고 화면상에서 직접 만져서 조작 가능한 사용자 인터페이스를 제공하는 운영체제의 특성을 말한다. 


제3조(적용 범위) ① 이 지침은 다른 법령에서 별도로 정한 경우를 제외하고는 국가기관, 지방자치단체 및 공공기관 등(이하 “국가기관 등”이라 한다)이 모바일 애플리케이션을 구축, 운영, 개선 및 유지보수할 경우에 적용한다.

  ② 이 지침이 적용되는 모바일 기기 대상은 다음과 같다.

  1. 운영체제를 갖는 모바일 전화기

  2. 운영체제를 갖는 태블릿 기기

  3. 운영체제를 갖는 전자책 기기


제4조(모든 운영체제에서의 접근성 보장)  ① 국가기관 등의 장은 모바애플리케이션을 신규 구축하는 경우 무리한 부담이 없는 한 해당 애플리케이션이 기반하고 있는 모든 운영체제에서 동등하게 접근성이 보장된 서비스를 제공하도록 하여야 한다.

국가기관 등의 장은 모바일 애플리케이션을 개선, 유지보수 및 운영하는 경우 무리한 부담이 없는 한 모든 운영체제에서 동등하게 접근성이 보장된 서비스를 제공하도록 노력하여야 한다.

제1항 및 제2항에서 무리한 부담이 없는 운영체제의 종류는 해당 애플리케이션을 구축, 운영, 개선 및 유지보수하는 국가기관 등의 장이 정할 수 있다.


5조(모든 모바일 기기에서의 접근성 보장) 국가기관 등의 장은 모바일 애플리케이션을 신규 구축하는 경우 무리한 부담이 없는 한 해당 애플리이션이 사용되는 모든 모바일 기기에서 동등하게 접근성이 보장된 서비스를 제공하도록 하여야 한다.

국가기관 등의 장은 모바일 애플리케이션을 개선, 유지보수 및 운영하는 경우 무리한 부담이 없는 한 모든 모바일 기기에서 동등하게 접근성이 보장된 서비스를 제공하도록 노력하여야 한다.

③ 제1항 및 제2항에서 무리한 부담이 없는 모바일 기기의 종류는 해당 애플리케이션을 구축, 운영, 개선 및 유지보수하는 국가기관 등의 장이 정할 수 있다.

제2장 모바일 애플리케이션 접근성 준수사항


제6조(대체 텍스트) 텍스트 아닌 콘텐츠는 대체 가능한 텍스트와 함께 제공되어야 한다.

  1. 대체 텍스트란 그림 및 이미지, 동영상으로 작성된 멀티미디어 형식의 콘텐츠 내용을 텍스트로 그 의미나 기능을 인식할 수 있도록 제공하는 것을 말한다.

  2. 텍스트 아닌 콘텐츠에 대한 대체 텍스트는 그 의미나 기능을 파악할 수 있도록 짧고 명확하게 제공해야 한다.


제7조(초점) 모든 객체에는 초점(focus)이 적용되고, 초점은 순차적으로 이동되어야 한다.

  1. 초점은 화면상의 선택된 객체의 내용을 화면 낭독 프로그램 등의 보조기기를 통해 이용할 수 있도록 도와주는 기능을 말한다. 

  2. 선택된 객체는 초점이 적용되었다고 하고, 초점은 화면상에서 테두리나 하이라이트로 표시하여 제공되는 것이 바람직하다.

  3. 표의 객체에 적용되는 초점은 논리적인 순서로 제공되어야 한다.


제8조(운영체제 접근성 기능 지원) 운영체제가 제공하는 접근성 기능 및 속성이 사용되어야 한다.

  1. 운영체제에서 제공하고 있는 접근성 기능 지원이 활용되어야 하며, 다음과 같은 사항을 고려할 수 있다.

 - 키보드 등 외부 디바이스와의 호환성 제공을 위한 API

 - 정보 제공 방법의 다중성 (redundancy)

 - 음성명령 기능의 포함, 고대비, 폰트 등

2. 애플리케이션이 해당 운영체제에서 제공하고 있는 접근성 기능을 변경할 경우, 애플리케이션의 종료와 함께 접근성 기능을 변경 전의 상태로 복원시켜야 한다.

3. 입력 서식은 운영체제에서 제공하는 접근성 속성을 활용하여 사용자가 이해하기 쉽도록 해야 한다.


제9조(누르기 동작 지원) 터치(touch) 기반 모바일 기기의 모든 컨트롤은 누르기 동작으로 제어할 수 있어야 한다.

  1. 누르기 동작은 화면상의 객체를 손가락 끝으로 접촉하여 만지거나(touch) 가볍게 두드리는(tap) 동작을 말한다.

  2. 두 개의 손가락을 동시에 이용해야 하는 다중 누르기(Multi-touch) 동작은 단순한 누르기 동작으로 대체할 수 있는 방법이 제공되어야 한다.

  3. 슬라이드(Slide), 끌기와 놓기(Drag and drop) 등의 복잡한 누르기 작은 단순한 누르기 동작으로 대체할 수 있는 방법이 제공되어야 한다.


제10조(색에 무관한 인식) 화면에 표시되는 모든 정보는 색에 관계없이 인식할 수 있어야 한다.

  1. 색상으로 정보를 구분할 경우, 색상 이외의 다른 방법으로도 동등한 내용을 전달할 수 있도록 설계한다.

  2. 색상을 사용한 의미의 전달이 흑백 화면에서도 동등하게 이루어질 수 있도록 제공해야 한다.


제11조(명도 대비) 화면에 표시되는 모든 정보는 전경색과 배경색이 구분될 수 있도록 최소 대비 이상으로 제공되어야 한다.

  1. 명도 대비는 화면의 배경색과 객체를 표시하는 데에 사용되는 전경색 사이의 명도 차이의 비율(contrast)을 말한다.

  2. 고대비 제공이 불가능할 경우, 애플리케이션의 설정 기능에 명도 대비 조절 기능을 제공한다.

  3. 화면상의 모든 정보의 최소 대비는 3:1 이상이어야 한다. 저시력인, 고령자 등에게 실효성을 가지기 위해서는 명도 대비가 4.5:1 이상이 되는 것이 바람직하다. 단, 사진과 동영상은 예외로 한다.


제12조(자막, 수화 등의 제공) 멀티미디어 콘텐츠에는 동등한 내용의 자막, 원고 또는 수화가 제공되어야 한다.

  1. 자막, 원고 또는 수화는 화면 상의 콘텐츠와 동기화하여 제공하는 것이 바람직하다.

제3장 모바일 애플리케이션 접근성 권고사항


제13조(기본 사용자 인터페이스 컴포넌트) 운영체제에서 제하는 기본 사용자 인터페이스 컴포넌트(Native UI Component)를 최대한 이용하는 것이 바람직하다.

 1. 운영체제에서 제공하는 접근성 있는 기본 사용자 인터페이스 컴포넌트는 사용자 인터페이스 구성에 사용되는 표준 도구(대화상자, 버튼과 체크 박스, 타이틀 바 등)들을 말한다.

  2. 운영체제에서 제공하는 기본 사용자 인터페이스 컴포넌트를 활용하면 보조기기와의 호환성을 제공하기 용이하므로 접근성의 확보를 위해 적극적으로 활용되어야 한다.


제14조(컨트롤간 충분한 간격) 컨트롤은 충분한 간격으로 배치하는 것이 바람직하다.

  1. 컨트롤은 버튼 또는 위젯과 같이 사용자 인터페이스 화면에서 누르기 동작으로 기능을 활성화시키는 객체를 말한다.

  2. 좁은 화면 공간의 경우, 사용자의 의도와 무관하게 다른 컨트롤을 누르게 되는 문제가 발생할 수 있으므로, 이를 피하기 위해서 컨트롤 사이의 공간을 충분히 확보하여 사용자가 컨트롤 영역을 명확히 구분할 수 있도록 하는 것이 바람직하다.

  3. 모바일 기기의 화면 크기에 관계없이 컨트롤 중심간 간격은 13mm 이상을 권장한다.


제15조(알림 기능) 사용자에게 알림을 제공할 때에는 진동, 시각, 소리 등 최대한 다양한 방법으로 사용자가 선택할 수 있도록 제공하는 것이 바람직하다.

  1. 화면상의 모든 알림 정보는 한 가지 양식으로만 제공되지 않도록 하며, 다양한 감각 양식을 활용한다.

  2. 사용자가 자신에게 가장 편리한 방법을 선택할 수 있도록 한다.


제16조(범용 폰트 이용) 폰트의 크기 조절, 확대 기능을 제공하거나 운영체제에서 제공하는 관련 기능을 활용할 수 있는 방법을 제공하는 것이 바람직하다.

  1. 범용 폰트(Global Font)는 운영체제에 내장되어 확대나 축소, 기울임 등의 변형 형태가 제공되는 글자체를 말한다.

  2. 모든 애플리케이션 화면에서 폰트 크기의 조절이 가능하도록 설계하거나, 최소한 확대 기능을 제공한다.

  3. 폰트 크기 조절을 용이하게 하기 위해서는 텍스트 이미지보다 폰트가 지정되어 있는 텍스트를 사용하는 것이 바람직하다.


제17조(사용자 인터페이스의 일관성) 사용자 인터페이스 요소들의 배치를 일관성 있게 제공하는 것이 바람직하다.

  1. 사용자 인터페이스를 구성하고 있는 요소들은 사용자가 다시 학습할 필요가 없도록 해당 애플리케이션 내에서 일관성 있게 설계한다.

  2. 애플리케이션의 버전이 바뀌어도 중요한 사용자 인터페이스 요소들의 배치는 일관성을 유지한다.


제18조(깜박거림의 사용 제한) 광과민성 발작을 일으킬 수 있는 콘텐츠를 제공하지 않는 것이 바람직하다.

  1. 깜빡이거나 번쩍이는 객체를 사용자 인터페이스에 사용하지 않는다.

  2. 화면상에서 반드시 깜빡임의 효과를 제공해야 하는 콘텐츠는 초당 3 ~ 50 회의 주기는 피해서 설계한다.


제19조(배경음 사용 금지) 자동으로 재생되는 배경음을 사용하지 않는 것이 바람직하다.

  1. 자동으로 재생되는 동영상, 음악, 음성 안내 등을 사용하지 않는다. 단, 3초 미만의 배경음은 예외로 인정한다.

  2. 배경음을 사용할 경우, 사용자가 손쉽게 멈춤, 일시정지, 음량조절 등을 제어할 수 있는 수단을 제공한다.


제20조(장애인 등 사용자 평가) 애플리케이션 개발 시 다양한 모바일 기기에서의 이용 가능 여부를 점검해야 하며, 장애인 사용자 평가를 수행하는 것이 바람직하다.

  1. 애플리케이션의 출시 이전에 장애인, 고령자 등의 사용자를 대상으로 한 평가를 수행하도록 한다.

  2. 사용자 평가는 무리한 부담이 되지 않는 시각 장애, 청각 장애, 뇌병변 장애, 지적 장애, 지체 장애, 고령 등의 사람들을 대상으로 실시한다.

  3. 모바일 애플리케이션 서비스 제공자는 해당 애플리케이션의 장애인 등 사용자 평가의 구체적인 결과를 별도로 공시하는 것이 바람직하다.

제4장 보   칙


제21조(준수지침 사항) 제6조 내지 제20조의 모바일 애플리케이션에 대한 구체적인 준수 지침을 구현하기 위한 방법은 별표 1과 같다.


제22조(콘텐츠 접근성 범위) 애플리케이션이 콘텐츠를 제공하는 경우, 이 지침은 서비스 제공자가 직접 제공하는 콘텐츠에만 적용된다.


제23조(접근성 진단) 행정안전부 장관은 국가기관 등을 대상으로 모바일 애플리케이션의 접근성 준수 여부를 연 1회 이상 진단할 수 있다.

부   칙


제1조(시행일) 이 지침은 고시한 날로부터 시행한다. 

제2조(재검토기한) 「훈령․예규 등의 발령 및 관리에 관한 규정」(대통령훈령 제248호)에 따라 이 고시 발령 후의 법령이나 현실 여건의 변화 등을 검토하여 이 고시의 폐지, 개정 등의 조치를 하여야 하는 기한은 2014년 9월 21일까지로 한다.


[ 별 표 ]


모바일 애플리케이션 접근성 지침 사례


 본 모바일 애플리케이션 접근성 지침 사례는 모바일 애플리케이션 개발자 및 운영자들이 접근성을 고려하여 애플리케이션을 개발할 수 있도록 도움을 주기 위해 제공하는 것이다. 본 지침에 포함된 준수사항 7개, 권고사항 8개에 대한 준수 필요성, 대표적인 기술 구현 방법, 구축 사례를 제공한다.


가. 준수사항(7개) : 장애인이 비장애인과 동등하게 모바일 애플리케이션에 접근하여 이용하기 위해서 반드시 준수해야 하는 사항


1. (대체 텍스트) 텍스트 아닌 콘텐츠는 대체 가능한 텍스트를 함께 제공해야 한다.


1) 준수 필요성 : 시각장애인의 경우 모바일 기기나 모바일 화면낭독 프로그램에서 제공하는 음성읽기 기능(iOS VoiceOver, 안드로이드 Talkback, 심비안 및 윈도우 모바일 6.5에서 활용되는 Code Factory사의 Mobile Speak 등)을 활용하여 애플리케이션의 정보를 인식할 수 있다. 하지만, 해당 어플리케이션에서 컨트롤 및 객체를 텍스트 아닌 콘텐츠로 제공하면서 대체 텍스트를 함께 제공하지 않으면 시각장애인은 잘못된 정보를 얻거나 전혀 정보를 얻을 수 없다.


2) 기술구현 방법 : 이미지 등 텍스트 아닌 콘텐츠를 제공할 경우에는 반드시 대체 텍스트를 함께 제공해야 한다. 대체 텍스트는 가능한 짧고 명확(Short & Clear)하게 제공하는 것이 바람직하며, VoiceOver, Talkback 등 모바일 스크린리더에서 기본적으로 제공해 주는 용어인 “버튼”, “이미지”, “레이블” 등은 중복해서 제공하지 않는 것이 바람직하다(웹 접근성 연구소 버튼(×), 모바일 접근성 이미지(×), 금융자동화기기 접근성 레이블(×) → 웹 접근성 연구소(○), 모바일 접근성(○), 금융자동화기기 접근성(○)).


   ① 애플의 iOS에서 대체 텍스트 제공 방법


 대체 텍스트를 제공하는 방법은 크게 2가지 방법이 있다. 첫째, 애플에서 제공하는 Interface Builder를 이용하여 대체 텍스트를 제공한다. 둘째, 대체 텍스트를 UIAccessibility API 등을 활용하여 직접 코드에 삽입하여 제공한다. 이러한 경우 Label과 Hint라는 두 가지의 속성 값을 활용할 수 있는데, Label로 대체 텍스트를 제공하고, Hint는 추가적인 정보가 필요할 경우 제공한다. iPhone에서 사용자가 VoiceOver 옵션에서 Hint를 끌 수(Off) 있으므로 반드시 대체 텍스트는 Label로 제공해야 한다. 예를 들면 뮤직 플레이어의 “멈춤”은 Label에 적고 “뮤직플레이어의 음악을 멈춥니다.”를 Hint에 적는다면 시각장애인 등에게 도움이 될 것이다.


< Interface Builder 화면 >

< UIAccessibility 설정 화면 >


   ⓐ Interface Builder 이용


 Interface Builder는 애플에서 제공하는 것으로 모바일 애플리케이션 개발 시 UI를 손쉽게 만들 수 있도록 도와주는 도구이다. Interface Builder를 실행 시킨 다음 Attribute inspector 창에서 Label 속성에 대체 텍스트를 제공하면 된다. 또한, 애플에서는 접근성 준수여부를 손쉽게 점검할 수 있도록 Accessibility inspector 등을 제공하고 있다.


< Interface Builder를 활용하여 버튼에 대체 텍스트를 제공하는 방법 >

대체 텍스트 제공 방법

 

1) Accessibility 속성을 반드시 활성화(Enabled) 시킨다.

 

2) Label 속성에 텍스트 아닌 콘텐츠의 의미와 정보를 동등하게 인식할 수 있도록 대체 텍스트를 짧고 명확하게 제공한다.

 

3) 부가적인 설명이 필요할 경우에는 Hint 속성을 활용하여 추가적인 정보를 제공한다.

< 참고 > Interface Builder는 Xcode에 포함되어 제공되고 있다. ‘11년 7월말 현재 애플의 최신 개발도구는 Xcode 4이다(http://developer.apple.com/xcode/index.php).


   ⓑ UIAccessibility API 등을 활용하여 직접 코드에 삽입하는 경우


  애플에서 제공하는 개발자 도구인 Interface Builder를 활용하지 않고 UI를 개발할 경우에는 UIAccessibility API를 활용하여 Label에 대체 텍스트를 제공한다.


[houseButton setIsAccessibilityElement:YES];

[houseButton setAccessibilityLabel:@"멈춤"];

[houseButton setAccessibilityHint:@"뮤직플레이어의 음악을 멈춥니다."];


 그러나, 보다 효율적인 개발 및 접근성을 제고하기 위해서는 애플에서 제공하는 Interface Builder를 활용하여 개발하는 것이 바람직하다.


② 구글의 안드로이드에서 대체 텍스트 제공 방법


 안드로이드의 경우에도 UI에 대체 텍스트를 제공하는 방법은 2가지로 XML을 활용하거나 또는 Java code를 활용하는 방법이 있다. 안드로이드의 경우에는 android:contentDescription 속성을 사용하여 대체 텍스트를 제공해야 한다. "웹 접근성 연구소“라는 버튼에 대체 텍스트를 제공하는 방법은 다음과 같다.


   ⓐ XML을 활용하여 버튼을 제공할 경우


<ImageButton

    android:id=”@+id/add_entry_button”

    android:src=”@drawable/plus”

    android:contentDescription=”@string/add_note”/>

layout/main.xml


<xml   version="1.0" encoding="utf-8"?>

<resources>

<string   name="add_note">웹 접근성 연구소</string>

</resources>

values/strings.xml


   ⓑ Java code를 활용하여 버튼을 제공할 경우


Button add_entry_button = new Button(this);

add_entry_button.setContentDescription("웹 접근성 연구소");


3) 구축 사례


 이미지 등 텍스트 아닌 콘텐츠를 활용할 경우에는 반드시 대체 텍스트를 제공해야 한다. 하지만 아래의 ** 은행의 ‘예금조회/이체’ 화면의 사례처럼 대체 텍스트를 제대로 제공하지 않을 경우, 시각장애인 등은 해당 애플리케이션을 이용하기 어렵다. iOS VoiceOver를 설정할 경우, “이전‘, ’전예금조회‘ ’계좌이체‘ 등의 상단 및 주 메뉴와 ’새 소식‘, ’고객센터‘ 등 하단 메뉴를 모두 ”버튼“으로 인식하게 되어 어떤 버튼이 어떤 기능을 수행하는지 알 수 없게 된다. 해당 기능을 제대로 인식할 수 있도록 대체 텍스트를 제공할 필요가 있다.


< ** 은행의 ‘예금조회/이체’ 화면 >

< iOS VoiceOver 설정시 ‘예금조회/이체 화면’  >

대체 텍스트를 미제공하여 ‘예금조회/이체’의 모든 기능을 제대로 활용하기 어려운 실정(모든 것을 ‘버튼’이라고 인식)

 

< 상단 및 주 메뉴 >

- ‘이전’ 버튼

- ‘전예금조회’ 버튼

- ‘계좌이체’ 버튼 등

 

< 하위 메뉴 >

- ‘새 소식’ 버튼

- ‘고객센터’ 버튼 등


 텍스트 아닌 콘텐츠에 대한 대체 텍스트 제공 여부에 대해서는 iOS VoiceOver, 안드로이드의 Talkback 등의 음성 읽기 기능을 활성화해 보면 쉽게 제공 여부를 평가해 볼 수 있다.

 

< 모바일 애플리케이션 접근성 우수 사례 - 청와대 아이폰용 애플리케이션 >

 

 청와대에서는 장애인의 모바일 접근권 보장에 해외 선진사례 분석 및 장애인의 요구에 부응하여, 2011년 8월부터 아이폰 용 애플리케이션의 접근성 제고를 위한 작업을 수행하였다. 청와대에서는 8월 11일과 8월 25일에 2번에 걸친 판올림(update)을 통하여 시각장애인 등의 정보 접근권을 크게 향상시켰다. 국내에서 모바일 애플리케이션 접근성 제고를 위한 우수 사례로 다음과 같은 개선이 이루어졌다.

 

㉮ 청와대 아이폰 용 애플리케이션의 접근성 관련 판올림 현황(2회)

 

< 앱 접근성 제고 판올림 1차(8.11) >

< 앱 접근성 제고 판올림 2차(8.25) >

 

㉯ 청와대 모바일 애플리케이션의 개선 전과 개선 후의 비교

 

 보이스 오버를 활용하여 음성을 출력할 경우 대체 텍스트를 제공하지 않아, 청와대 모바일 애플리케이션의 첫 실행 화면의 정보를 얻을 수 없었으나, 대체 텍스트를 제공하여 동등한 정보를 인식할 수 있게 개선됨.

 

< 공유버튼 안내 페이지 >

< 접근성 개선 전 >

a. 공유버튼 설명문은 “이미지”로 출력

b. 안내문 버튼 설명 “이미지” “입력 창”으로 출력

c. 닫기 버튼은 “버튼”이라고 출력

< 접근성 개선 후 >

a. 공유버튼 설명문의 내용을 동등하게 음성으로 출력 : 청와대 스마트폰 애플리케이션을 ~ (중략)

b. 안내문 버튼 설명을 동등하게 음성으로 출력 :

   다음부터 이 안내문을 ~ (중략)

c. 닫기 버튼 :

   “닫기 버튼”이라고 음성 출력

 

 

< 모바일 애플리케이션 접근성 우수 사례 - 청와대 아이폰용 애플리케이션(계속) >

 

 보이스 오버를 활용하여 음성을 출력할 경우 하단의 버튼에 대한 대체 텍스트를 제공하지 않았으나, 대체 텍스트를 제공하여 동등한 정보를 인식할 수 있게 개선됨.

 

< 하단 버튼 >

< 접근성 개선 전 >

a. 뉴스/브리핑 : "버튼“이라고 출력

b. 영상/사진 : "버튼“이라고 출력

c. 소셜미디어 : "버튼“이라고 출력

d. 푸른누리 : "버튼“이라고 출력

e. 관람 : "버튼“이라고 출력

< 접근성 개선 후 >

a. 뉴스/브리핑 : "뉴스, 브리핑 버튼“이라고 출력

b. 영상/사진 : "영상, 사진버튼“이라고 출력

c. 소셜미디어 : "소셜 미디어 버튼“이라고 출력

d. 푸른누리 : "푸른누리 버튼“이라고 출력

e. 관람 : "관람 버튼“이라고 출력

 

보이스 오버를 활용하여 음성을 출력할 경우 대체 텍스트를 제공하지 않아, 청와대 관람 정보를 얻을 수 없었으나, 대체 텍스트를 제공하여 동등한 정보를 인식할 수 있게 개선됨.

 

< 이미지 콘텐츠 영역 >

< 접근성 개선 전 >

본문의 내용인 관람운영일, 관람운영일 설명, 신청대상, 신청대상 설명 등을 파악할 수 없음 : “***(파일명) 이미지”라고 출력

< 접근성 개선 후 >

< 이미지에 대한 동등한 내용의 대체 텍스트 제공 >

a. “관람운영일”, “매주 화요일 ~ 금요일 (둘째주 토요일) 토요일은 10인 이하의 개인/가족에 한함”으로 음성 출력

b. "신청대상“, ”초등학생 이상 → 미취학자녀 관람은 가족 동반만 가능“으로 음성 출력

 

2. (초점) 모든 객체에는 초점(focus)이 적용되고, 초점은 순차적으로 이동되어야 한다.


1) 준수 필요성 : 초점이 적용되지 않으면 모바일 기기나 모바일 화면낭독 프로그램에서 제공하는 음성 읽기 기능(iOS VoiceOver, 안드로이드 Talkback, 심비안 및 윈도우 모바일 6.5에서 활용되는 Code Factory사의 Mobile Speak 등) 등을 활용하는 경우의 사용자는 정보를 얻거나 기능을 실행할 수 없는 문제가 발생한다. 또한 순차적으로 이동되지 않을 경우에는 시각장애인, 지적장애인 등이 해당 애플리케이션의 기능과 정보의 이해에 어려움이 발생할 수 있다.


2) 기술구현 방법 : 애플리케이션 개발 시 모든 객체에 초점이 적용되고, 적용된 초점은 순차적으로 이동할 수 있게 개발해야 한다.

 

 ① 애플의 iOS에서 초점 제공 방법


 Accessibility 속성이 활성화(Enabled)될 경우에만 해당 객체에 초점이 적용된다. iOS에서 제공하는 기본 사용자 인터페이스 컴포넌트(Native UI Component)에서는 대부분의 기본 값이 활성화되어 제공된다. 하지만 ImageView UI 컴포넌트의 경우에는 Accessibility 속성이 비활성화(Disabled)되어 있다. 만약 단순한 장식이 아니고 의미를 포함하는 이미지를 ImageView UI 컴포넌트를 활용하여 제공할 경우에는 Accessibility 속성을 활성화 시켜야 하며, 대체 텍스트를 label 속성으로 반드시 제공해야 한다.  iOS 4.1부터 초점의 순서를 제어 할 수 있는 기능을 제공하고 있다.


< Accessibility 속성이 활성화 되지 않은 경우

(초점 미적용) >

< Accessibility 속성이 활성화 된 경우

(초점 적용) >

   ② 구글의 안드로이드에서 초점 제공 방법


 안드로이드에서 제공하는 기본 사용자 인터페이스 컴포넌트(Native UI Component)에서는 iOS와 달리 대부분의 기본 값이 비활성화(false)되어 제공된다. 그러므로 초점 이동이 필요한 UI의 경우에는 반드시 focusable 속성을 활성화(true)시켜 제공해야 한다. 


      <TextView android:id="@+id/text"

                android:focusable=”true”

                android:text="Hello, I am a   focusable TextView"

                android:nextFocusUp=”@id/edit”

                ... />


 안드로이드에서 초점의 이동 순서를 제어하기 위해서는 nextFocusDown, nextFocusUp, nextFocusRight, nextFocusLeft 속성을 이용하면 된다.


3) 구축 사례


 모든 컨트롤에 대하여 초점이 적용되어 있어야 하며, 논리적인 순서로 제공되어야만 시각장애인 등이 활용할 수 있다.


< ** 은행의 로그인 화면 >

< 문제점 및 해결방안 >

o 문제점

 - VoiceOver를 실행할 경우, ‘공인인증서 로그인’, ‘비밀번호 입력창', '로그인’ 등에 초점이 가지 않아 애플리케이션 이용이 불가능한 실정

 * 비밀번호 입력 등이 불가능하여 로그인을 할 수 있는 방법이 없음

 - ‘공인인증서 로그인’, ‘조회회원 가입’, ‘로그인’ 등에 대체 텍스트도 미제공

 * VoiceOver를 사용할 경우, ‘공인인증서 로그인’의 정보가 “dtm into 1 gif"로 출력되는 문제 발생

 

o 해결방안

 - 모든 버튼 및 정보에 초점이 적용될 수 있도록 제공해야 한다.

 - 모든 텍스트 아닌 콘텐츠에는 대체 텍스트를 제공해야 한다.

< ** 은행의 조회 화면 >

< 문제점 및 해결방안 >

o 문제점

 - ‘조회’ 라는 좌우로 스크롤 되는 메뉴가 나타나는데 이 부분에서는 초점이 전혀 생성되지 않는다. 이 메뉴를 통해 ‘조회/이체’ 등을 선택한 후 하단에서 하위메뉴로 진입해야 하는데 메인 메뉴에서 초점이 생성되지 않아 더 이상의 은행업무 수행을 하는 것은 불가능함

 

o 해결방안

 - ‘조회’ 라는 메뉴에 초점이 적용될 수 있도록 제공하고, 하위 메뉴로 초점이 논리적으로 이동할 수 있도록 제공할 필요가 있음


< ** 방송국의 라디오 >

< 문제점 및 해결방안 >

 

o 문제점

 - *** 월드 라디오는 크게 프로그램과 뮤직채널로 나눠져 있다. 이 애플리케이션을 실행하면 두 채널 중 하나를 선택해야 청취가 가능한데, 가운데 있는 이 부분이 VoiceOver를 통해서는 초점이 생성되지도 동작하지도 않는다. 선택하지 않으면 라디오를 들을 수 없는 상황이 되기 때문에 단 하나의 컨트롤의 문제라고 할 수도 있겠지만 VoiceOver 사용자는 이 애플리케이션을 사용할 수 있느냐 사용하지 못하느냐를 가늠하는 중요한 열쇠가 된다. 결과적으로 접근할 수가 없으니 이 애플리케이션의 라디오 기능을 사용할 수 없다.

 

o 해결방안

 - 시각장애인 등이 이용할 수 있도록 “프로그램”과 “뮤직채널”에 초점을 적용해야 한다.


3. (운영체제 접근성 기능 지원) 운영체제가 제공하는 접근성 기능 및 속성이 지원되어야 한다.


1) 준수 필요성 : 장애인 등의 모바일 애플리케이션 접근성을 보장하기 위해서는 각 운영체제에서 제공하는 접근성 기능을 활용해야 한다. 이를 활용하지 않을 경우에는 장애인이 활용하는 다양한 모바일 기기, 모바일 보조기기 등과 호환되지 않아 이용이 불가능할 경우가 발생할 수 있다. 


2) 기술구현 방법 : 애플의 iOS와 구글의 안드로이드 운영체제의 경우 각각 접근성 API를 제공하고 있다. 개발자는 각 운영체제에서 지원하는 운영체제의 접근성 기능을 최대한 지원하도록 노력해야 한다.


 ① 애플의 iOS에서 운영체제 접근성 기능 제공 방법


 iOS에서는 Accessibility API를 제공 하고 있다. 모바일 애플리케이션 개발 시 접근성 준수 여부를 점검할 수 있도록 Accessibility Inspector와 Accessibility Verifier 같은 도구들도 제공하고 있다. 다만, 이러한 기능은 매킨토시 PC 환경에서만 이용이 가능하다.


< 애플의 Accessibility Inspector >


 iOS에서 제공하는 UI Accessibility 속성은 5가지이다. 첫째, Label 속성은 텍스트 아닌 콘텐츠에 대한 동등한 정보를 제공하기 위해 사용할 때 이용한다. HTML에서의 alt="" 속성과 유사한 것으로 이미지 등의 텍스트 아닌 콘텐츠 제공시에는 반드시 제공해야 하는 속성이다. 둘째, Traits 속성은 객체의 형태를 표시하는 속성으로 상태, 액션 등을 설명할 수 있으며 다중으로 선택이 가능하다. 현재 Trait 속성 값은 Button, Link, Search Field, Keyboard Key, Static Text, Image, Plays Sound, Selected, Summary Element, Updates Frequently, Not Enabled, None 등이 포함된다. 셋째, Hint 속성은 부가적인 설명이 필요할 경우에만 사용하는 것으로, Label 등으로 정보가 불충분할 경우 사용하는 속성이다. 넷째, Frame 속성은 화면의 좌표 위치를 나타내 준다. 마지막으로 Value 속성은 각 객체의 속성 값을 말해준다.


   ② 구글의 안드로이드에서 운영체제 접근성 기능 제공 방법 


 안드로이드에서도 iOS와 마찬가지로 Accessibility API를 제공하고 있다. Accessibility Service, Accessibility Event, Accessibility API for Customize, Eyes-free 등이 대표적이다. 특히 Eyes-free API는 오픈 소스로 시각장애인 등이 안드로이드용 모바일 기기를 활용할 수 있도록 Talkback, Soundback, Kickback 등을 제공하고 있다.


3) 구축 사례

     

 운영체제에서의 접근성 기능을 지원한 Twitter의 경우 SNS에서 제공하는 텍스트 정보를 제대로 인식할 수 있으나, 국내의 모 SNS의 경우에는 운영체제의 접근성 기능을 지원하지 않아 VoiceOver 기능 이용시 아무런 텍스트 정보도 얻지 못하는 문제가 발생하고 있다.


< Twitter 애플리케이션(운영체제 접근성 지원) >

< **** 애플리케이션(운영체제 접근성 미지원)>

4. (누르기 동작 지원) 모든 컨트롤은 누르기(touch or tap) 동작으로 제어할 수 있어야 한다.


1) 준수 필요성 : 시각장애인의 경우 모바일 기기에서 가장 어려움을 많이 겪는 부분이 바로 컨트롤의 위치에 대한 부분이다. 특히 컨트롤을 이동해야 하는 경우나 컨트롤 간의 위치를 바꾸어야 하는 경우 더욱 더 어려움에 처하게 된다. 예를 들어 모바일 애플리케이션을 이동하여 폴더를 생성하는 경우나 전화 받기 기능 같은 경우 Drag해야 해당 기능을 활용할 수 있는 경우가 있다. 그러므로 모든 컨트롤이나 Drag 등이 필요한 기능의 경우에는 반드시 이를 대체할 수 있는 수단인 누르기(touch or tap) 동작을 함께 제공해야 한다.


2) 기술구현 방법 : 누르기 동작은 화면 상의 객체를 손가락 끝으로 접촉하여 만지거나(touch) 가볍게 두드리는(tap) 동작을 말하는 것으로, 모든 컨트롤 동작은 누르기 동작만으로도 제어할 수 있어야 한다. 두 개의 손가락을 동시에 이용해야 하는 다중누르기(Multi-touch) 동작이나 Slide, Drag and drop 등의 복잡한 누르기 동작은 단순한 누르기 동작으로 대체할 수 있는 방법이 제공되어야 한다. 


  3) 구축 사례 : 모든 컨트롤은 누르기 동작으로 제어할 수 있도록 제공해야 한다. 사용자 편의성 제고를 위해 다양한 UI를 활용하는 것은 필요하나, 보다 중요한 것은 장애인 등 다양한 사용자가 동등하게 이용할 수 있도록 개발하거나 해당 기능을 대체할 수 있는 수단을 제공하는 등의 보편적 설계(Universal Design)를 적용해야 한다.


< Slide 기능에 대한 대체 수단 제공 사례

(두 번 두드리기(double tap)) >

< Slide 기능에 대한 대체 수단 미제공 사례 >

슬라이드 기능을 활용하지 못할 경우, VoiceOver를 이용할 경우에는 두 번 누르기(double tap)으로 해당 기능 활용 가능

슬라이드 기능을 활용하지 못할 경우 대체 수단을 제공하지 않아, talkback을 이용하는 사용자의 경우에는 전화 받기 기능을 활용할 수 없음

5. (색에 무관한 인식) 화면에 표시되는 모든 정보는 색에 관계없이 인식할 수 있어야 한다.


1) 준수 필요성 : 색맹 사용자의 경우 특정 색을 구별하지 못하는 경우가 있다. 그 대표적인 예로 적녹 색맹의 경우 적색과 녹색을 구분하지 못함으로서 일상 생활에서 신호등을 구분하지 못하고 이로 인하여 운전면허 취득도 어렵다. 이와 마찬가지로 모바일 애플리케이션에서 정보를 색으로만 제공할 경우 색맹이나 색약자의 경우 이를 인지할 수 없다.


2) 기술구현 방법 : 색상으로 정보를 구분할 경우, 색상 이외의 다른 방법으로도 동등한 내용을 전달할 수 있도록 설계한다. 색이외에 명암이나 텍스트, 특수기호 등을 색과 함께 제공하여 해당 정보를 인식할 수 있도록 제공해야 한다.

 

3) 구축 사례


 오른쪽 아래의 그래프에서는 속도 값을 막대그래프로 표현하는데 막대그래프의 위에 의미를 명확히 알 수 있도록 통신사명과 막대그래프의 값을 텍스트로 제공하고 있어서 그 의미를 이해하는데 도움을 주고 있다. 색을 구분하기 어려운 사용자더라도 제공되는 텍스트 정보는 구분할 수 있기 때문에 그래프의 의미를 구분할 수 있다.


< 잘못된 사례 >

< 올바른 사례 >


6. (명도 대비) 화면에 표시되는 모든 정보는 전경색과 배경색이 구분될 수 있도록 최소 대비 이상으로 제공되어야 한다.


1) 준수 필요성 : 시각장애인 등은 모바일 기기를 사용할 경우 화면에 표시되는 전경색과 배경색간의 구분이 잘 되지 않는 문제로 인하여 어려움을 겪는 경우가 많이 발생하고 있다. 특히 전경색과 배경색이 흰색과 회색, 노란색과 오렌지색 등으로 유사한 색으로 되어 있는 경우 이를 인지하기 매우 어렵다. 따라서 전경과 배경을 명확하게 인식할 수 있도록 콘텐츠를 제공해야 한다.


2) 기술구현 방법 : 명도 대비는 화면의 배경색과 객체를 표시하는 데에 사용되는 전경색 사이의 명도 차이의 비율(contrast)을 말한다. 모든 정보의 최소 대비는 3:1 이상이어야 한다. 저시력인에게 실효성을 가지기 위해서는 주 콘텐츠의 경우는 4.5:1 또는 7:1 이상이 되는 것이 바람직하다. 명도 대비를 높게 제공하기 어려운 경우에는 운영체제에서 제공하는 명도 대비를 활용할 수 있도록 제공하거나 애플리케이션 내에서 명도 대비를 높일 수 있는 설정 기능을 제공해야 한다.


※ iOS 4의 경우에는 “설정 → 일반 → 손쉬운 사용 → 검정색 바탕에 흰색”이라는 명도 대비 설정 기능을 제공하고 있다.


< 참고 : 색에 무관한 인식 관련 평가 도구 >

 

Color Doctor

  http://www.fujitsu.com/global/accessibility/assistance/cd/download.html

Visual Impairment Simulator for Microsoft Windows

  http://vis.cita.uiuc.edu/index.php

Colour Contrast Analyser

  http://juicystudio.com/article/colour-contrast-analyser-firefox-extension.php

Colour Checker

  http://www.etre.com/tools/colourcheck/

Color Selector

  http://www.fujitsu.com/global/accessibility/assistance/cs/download.html

aDesigner

  http://www.alphaworks.ibm.com/tech/adesigner

Accessibility Color Wheel

  http://gmazzocato.altervista.org/colorwheel/wheel.php

3) 구축 사례


 **은행 애플리케이션에서 인증서 가져오는 동작을 하면 아래의 왼쪽 그림과 같이 4자리의 숫자를 4번 입력하는 총 16자리의 인증번호가 나온다. 저 인증번호는 PC에서 휴대폰으로 인증서를 전송할 때 반드시 입력해야 하는데 모바일 화면에서 글씨/배경색의 대비가 충분하지 않기 때문에 저시력 시각장애인이 글씨를 읽는 것이 매우 힘들다. 이러한 경우 단순히 글씨를 알아보기 어렵다는 것에 그치는 것이 아니라 동작을 수행할 수 없는 결과를 낳는다. 저시력 사용자는 인증번호를 아예 알아보지 못하거나 잘못 읽어서 인증서를 휴대폰으로 전송하지 못하는 결과를 낳을 수 있다. 저시력 사용자에게 있어서 명도 대비가 없는 이러한 인증번호는 인증번호로서의 목적을 전혀 달성하지 못하고 있는 것이다.

 ** 모바일 고객센터에서 이용량을 보여주는 아래 오른쪽 그림을 살펴보면 그래프를 구분하는 왼쪽 라벨 부분에 문제가 있다. 라벨명인 사용일 수, 음성, 문자 메시지, 문자/멀티 메시지, MMS, 무선 인터넷 부분에서 배경색과 글자색의 대비가 충분하지 않아 저시력 사용자는 글씨를 읽기가 매우 어렵다. 폰트 크기도 작은데다 글자색과 배경색이 대비마저 낮아서 더 읽기가 어려운 상황이다. 라벨을 명확히 알아볼 수 없기 때문에 오른쪽에 나오는 그래프의 의미를 이해하는데 어려움을 겪을 수밖에 없다.


< 잘못된 사례 >

< 잘못된 사례 >

7. (자막, 수화 등의 제공) 멀티미디어 콘텐츠에는 동등한 내용의 자막, 원고 또는 수화가 제공되어야 한다.


1) 준수 필요성 : 청각장애인의 경우 동영상이나 음성으로 제공되는 콘텐츠에 대하여는 음성정보를 인지하기 어렵다. 따라서 이들에 대하여는 동기화된 자막을 제공하거나 별도의 원고를 제공하여야 콘텐츠를 인식할 수 있다. 멀티미디어 콘텐츠에 대한 동등한 내용의 자막, 원고 또는 수화는 시끄러운 환경이나 조용한 환경, 해당 언어를 모국어로 사용하지 않는 비장애인에게도 도움이 된다. 또한 동영상 검색시에도 자막이나 원고는 큰 도움을 줄 수 있다.


2) 기술구현 방법 : 멀티미디어 콘텐츠에는 동등한 내용의 자막, 원고 또는 수화를 제공해야 한다. 멀티미디어 콘텐츠를 요약한 자막이나 원고는 불충분하며, 멀티미디어에서 제공하는 음성 정보와 동등한 내용을 자막이나 원고로 제공해야 한다. 음성이 없이 동영상에 포함된 메시지나 자막, 중요 단어에 대한 강조, 홍보 문구 등은 시각장애인이 전혀 확인할 방법이 없으므로, 이러한 경우에는 반드시 화면해설 서비스(음성으로 메시지, 자막, 중요 단어 등을 제공)를 제공해야 한다. 자막, 수화 또는 원고는 화면 상의 콘텐츠와 동기화하여 제공하는 것이 바람직하다.


3) 구축 사례


 왼쪽 아래의 그림은 ‘아이폰 용 복지 TV 애플리케이션’의 사례이다. 본 애플리케이션에서 제공하는 동영상의 경우 자막과 함께 수화를 동시에 제공하여 장애인의 접근성을 확보한 우수 사례이다.

 

< 올바른 사례(복지 TV 애플리케이션) >

< 잘못된 사례 (자막 미제공) >

나. 권고사항(8개) : 모바일 애플리케이션의 접근성 향상을 위하여 무리한 부담이 되지 않는 한 준수할 것을 권장하는 사항을 말한다.


1. (Native UI Component) 운영체제에서 제공하는 기본 사용자 인터페이스 컴포넌트(Native UI Component)를 최대한 이용하는 것이 바람직하다.


1) 준수 필요성 : 대부분의 운영체제에서 제공하는 기본 사용자 인터페이스 컴포넌트(Native UI Component)는 접근성을 고려하여 제공되고 있다. 애플리케이션 개발 시 비용과 시간 등의 제약이 있는 경우 운영체제에서 제공하는 기본 사용자 인터페이스 컴포넌트를 잘 활용하는 것이 좋다. 이에 반해 사용자 변형 UI 컴포넌트(Custom UI Component)를 사용하는 경우에는 운영체제에서 제공하는 VoiceOver 등이 동작하지 않을 수 있다. 그러므로 최대한 기본 사용자 인터페이스를 활용하는 것이 바람직하다.


2) 기술구현 방법 : 모바일 애플리케이션을 개발함에 있어 기본 사용자 인터페이스 컴포넌트를 최대한 활용하는 것이 접근성을 높이는데 도움이 된다. 


   ① 애플의 iOS에서 제공 방법 : Native UI Component에는 UIWindow, UILabel, UIPickerView 등이 있다. 특히 웹 페이지를 내장하는 페이지를 만들 경우에는 UIWebView를 통해 작성을 하게 된다.


   ② 구글의 안드로이드에서 제공 방법 : Native UI Component에는 View, ImageView 등이 있다.


3) 구축 사례 : 대표적인 애플과 구글의 운영체제에서 제공하는 Native UI Component는 아래의 그림과 같다.


< iOS에서의 Natiove UI Component >

< 안드로이드에서의 Natiove UI Componen t>

http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIKit_Framework/_index.html#//apple_ref/doc/uid/TP40006955 

 

http://developer.android.com/reference/android/widget/package-summary.html 

2. (컨트롤간 충분한 간격) 컨트롤은 충분한 간격으로 배치하는 것이 바람직하다.


1) 준수 필요성 : 모바일 기기의 경우 터치를 통하여 컨트롤하기 때문에 터치의 정확성이 매우 중요하다. 터치의 정확성을 담보하기 위해서는 좌표 값도 중요하지만 각 컨트롤간의 간격도 중요하다. 비장애인도 각 버튼간의 터치 간격이 좁게 되어 있고 버튼의 크기가 작으면 매우 불편한데 뇌성마비 장애인의 경우 손 떨림 등이 많이 있고 이로 인하여 정확한 터치 동작을 취하기가 매우 어렵다. 따라서 터치 동작을 원활히 수행할 수 있도록 터치 간격을 적절히 유지하는 것이 매우 중요하다. 저시력인의 경우도 터치 타겟이 작을 경우 많은 어려움을 겪게 되는데 특히 중요한 결제 정보를 입력하거나 은행용 모바일 애플리케이션을 사용하는 경우 실수로 잘못 터치하는 경우 되돌이킬 수 없는 문제가 발생할 수 도 있다.


2) 기술구현 방법 : 좁은 화면 공간의 경우, 사용자의 의도와 무관하게 다른 컨트롤을 누르게 되는 문제가 발생할 수 있으므로, 이를 피하기 위해서 컨트롤 사이의 공간을 충분히 확보하여 사용자가 컨트롤 영역을 명확히 구분할 수 있도록 하는 것이 바람직하다. 컨트롤 중심간 간격은 13mm X 13mm 이상을 권장한다. 선택해야 하는 컨트롤 영역의 크기는 8.5mm X 8.5mm 이상을 권장한다. 컨트롤의 터치 공간을 충분히 확보하여 사용자가 컨트롤 영역을 명확히 구분할 수 있도록 제공하는 것이 좋다. 사용자의 의도에 따라 컨트롤을 확대하여 사용할 경우 상대적인 크기로 커져서 손쉽게 활용할 수 있도록 제공하는 것이 좋다. 쿼티 입력 등 운영체제에서 제공하는 기본 사용자 인터페이스의 경우에는 예외로 한다.


3. (알림 기능) 사용자에게 알림을 제공할 때에는 진동, 시각, 소리 등 최대한 다양한 방법으로 사용자가 선택할 수 있도록 제공하는 것이 바람직하다.


1) 준수 필요성 : 한 가지 감각으로만 정보를 제공하는 경우에는 다양한 사용자가 이를 활용할 수 있다고 보장하기 어렵다. 예를 들어 시력을 요하는 정보를 제공하거나 음성으로만 정보를 제공하는 경우 시각장애인이나 청각장애인들은 이러한 정보를 인지할 수 없다. 따라서 알림 정보 등을 제공하는 경우에는 소리나 화면 진동 등 다양한 방법을 동시에 사용하여 정보를 제공하는 것이 필요하다.


2) 기술구현 방법 : 사용자에게 알림을 제공할 때에는 한 가지 감각에만 의존하지 말고 다양한 감각이나 표현 방법을 통해 사용자가 원하는 알림 기능을 제공하는 것이 바람직하다. 사용자에게 다양한 방법으로 알림을 제공될 수 있도록 시각, 청각, 촉각 등의 피드백을 제공해야 하며, 다양한 알림 기능을 제공할 경우 적절한 방법을 사용자가 선택할 수 있도록 제공하는 것이 더 바람직하다.


3) 구축 사례


 페이스북 애플리케이션에서는 알림이 상당히 세분화 되어있다. 사용자가 자신에게 적합한 방법으로 알림 정보를 진동, 소리 등으로 정보를 얻을 수 있도록 기능을 제공하고 있다. 또한 이러한 알림 정보는 가급적 운영체제에서 제공하는 Native UI를 활용하는 것이 바람직하다.


< 페이스북의 알림 설정 화면 >

< 운영체제에서 제공하는 Native UI 알림기능 사용 예 >

 

4. (범용 폰트 이용) 폰트의 크기 조절, 확대 기능을 제공하거나 운영체제에서 제공하는 관련 기능을 활용할 수 있는 방법을 제공하는 것이 바람직하다.


1) 준수 필요성 : 저시력인, 고령자 등은 일반 PC보다 화면이 적은 모바일 기기를 활용함에 있어 작은 화면으로 인해 정보를 인식하는데 어려움을 겪는다. 저시력인이나 고령자 등도 동등하게 모바일 애플리케이션을 이용할 수 있기 위해서는 폰트를 바꾸거나 폰트의 크기 등을 조절하여 자신에게 적합한 방법으로 애플리케이션을 이용할 수 있어야 한다.


2) 기술구현 방법 : 절대 폰트를 사용하지 말고, 사용자 선택에 따라 폰트의 크기를 변화시킬 수 있도록 제공하는 것이 바람직하다. 시스템이나 사용자가 선택한 환경(Setting)을 그대로 상속(Inherit)할 수 있도록 제공해야 한다. 범용 폰트(Global Font)는 운영체제에 내장되어 확대나 축소, 기울임 등의 변형 형태가 제공되는 글자체를 말한다. 모든 애플리케이션 화면에서 폰트 크기의 조절이 가능하도록 설계하거나, 최소한 확대 기능을 제공한다. 폰트 크기 조절을 용이하게 하기 위해서는 텍스트 이미지보다 폰트가 지정되어 있는 텍스트를 사용하는 것이 바람직하다. 폰트의 확대 시 텍스트의 내용이나 기능의 손실 없이 최소 200%까지 확대될 수 있도록 제공하는 것이 좋다. 또한 별도의 폰트를 사용하는 경우 사용자가 인지하기 어렵게 되는 경우가 발생할 수 있으니 운영체제에서 제공하는 글로벌 폰트를 이용하는 것이 바람직하다.


① 애플의 iOS에서 제공되는 글로벌 폰트 종류(‘11년 7월말 기준)


Font Family: American Typewriter

Font:AmericanTypewriter

Font:AmericanTypewriter-Bold

Font Family: AppleGothic

Font:AppleGothic

Font Family: Arial

Font:ArialMT

Font:Arial-BoldMT

Font:Arial-BoldItalicMT

Font:Arial-ItalicMT

Font Family: Arial Rounded MT Bold

Font:ArialRoundedMTBold

Font Family: Arial Unicode MS

Font:ArialUnicodeMS

Font Family: Courier

Font:Courier

Font:Courier-BoldOblique

Font:Courier-Oblique

Font:Courier-Bold

Font Family: Courier New

Font:CourierNewPS-BoldMT

Font:CourierNewPS-ItalicMT

Font:CourierNewPS-BoldItalicMT

Font:HiraKakuProN-W6

Font Family: Marker Felt

Font:MarkerFelt-Thin

Font Family: STHeiti J

Font:STHeitiJ-Medium

Font:STHeitiJ-Light

Font Family: STHeiti K

Font:STHeitiK-Medium

Font:STHeitiK-Light

Font Family: STHeiti SC

Font:STHeitiSC-Medium

Font:STHeitiSC-Light

Font Family: STHeiti TC

Font:STHeitiTC-Light

Font:STHeitiTC-Medium

Font Family: Times New Roman

Font:TimesNewRomanPSMT

Font:TimesNewRomanPS-BoldMT

Font:TimesNewRomanPS-BoldItalicMT

Font:TimesNewRomanPS-ItalicMT

Font Family: Trebuchet MS

Font:TrebuchetMS-Italic

Font:TrebuchetMS

Font:CourierNewPSMT

Font Family: DB LCD Temp

Font:DBLCDTempBlack

Font Family: Georgia

Font:Georgia-Bold

Font:Georgia

Font:Georgia-BoldItalic

Font:Georgia-Italic

Font Family: Helvetica

Font:Helvetica-Oblique

Font:Helvetica-BoldOblique

Font:Helvetica

Font:Helvetica-Bold

Font Family: Helvetica Neue

Font:HelveticaNeue

Font:HelveticaNeue-Bold

Font Family: Hiragino Kaku Gothic **** W3

Font:HiraKakuProN-W3

Font Family: Hiragino Kaku Gothic **** W6

Font:Trebuchet-BoldItalic

Font:TrebuchetMS-Bold

Font Family: Verdana

Font:Verdana-Bold

Font:Verdana-BoldItalic

Font:Verdana

Font:Verdana-Italic

Font Family: Zapfino

Font:Zapfino


② 구글의 안드로이드에서 제공되는 글로벌 폰트 종류(‘11년 7월말 기준)

"sans-serif"  

"arial"

"helvetica"

"tahoma"

"verdana"

"serif"

"times"

"times   new roman"

"palatino"

"georgia"

"baskerville"

"goudy"

"fantasy"

"cursive"

"ITC   Stone Serif"

"monospace"

"courier"

"courier   new"

"monaco"


3) 구축 사례 : 트위터, iBooks 애플리케이션에서는 저시력자 등을 위해 폰트의 크기 조절 기능을 설정할 수 있도록 제공하고 있다.


< 트위터의 글자크기 설정 화면 >

< iBooks 폰트 크기 및 서체 설정 화면 >

 

5. (사용자 인터페이스의 일관성) 사용자 인터페이스 요소들의 배치를 일관성 있게 제공하는 것이 바람직하다.


1) 준수 필요성 : 저시력인이나 고령자 등 화면을 확대하는 사용자의 경우에는 전체 화면이 아니라 창의 일부 영역을 화면에 확대하여 이용한다. 따라서 애플리케이션 창마다 내비게이션 컨트롤의 위치와 모양이 다르다면 새로운 애플리케이션 창으로 이동할 때마다 사용법을 익히는 데 많은 어려움이 있을 것이다. 또한 지적 장애인의 경우 방문한 웹 페이지별로 메뉴와 내비게이션 컨트롤의 위치나 모양이 바뀌게 되면 사용자는 이들 웹 페이지를 동일한 웹 사이트가 제공하는 웹 페이지로 인식하기보다는 새로운 웹 사이트가 제공하는 웹 페이지로 인식할 가능성이 높다. 이에 일관성 있는 사용자 인터페이스를 제공하는 것이 바람직하다.


2) 기술구현 방법 : 사용자 경험(User Experience)에 비추어 일관성 있는 사용자 인터페이스(UI) 요소를 제공하는 것이 바람직하다. 사용자 인터페이스를 구성하고 있는 요소들(폰트, 크기, 화면 색상, 링크 제공 방법, 이모티콘 등)을 사용자가 다시 학습하지 않아도 되도록 해당 애플리케이션 내에서 일관성 있게 제공하는 것이 바람직하다.


3) 구축 사례


 *** 영화관 모바일 애플리케이션으로 예약 시간을 선택하는 선택 창과 인원 및 좌석을 선택하는 창이 일관성 없이 제공되어 있어 사용자에게 혼란을 주는 사례이다.


< 일관성 없는 입력 서식 제공 사례 (iOS Native UI Component (좌측), Custom UI Component (우측) >

 

6. (깜빡거림의 사용 제한) 광과민성 발작을 일으킬 수 있는 콘텐츠를 제공하지 않는 것이 바람직하다.


1) 준수 필요성 : 깜빡이거나 번쩍이는 콘텐츠를 제공할 경우 특정 사용자에게 광과민성 발작을 일으킬 우려가 있다. 예를 들어 일본에서 방영된 만화 영화인 포켓몬에서 깜빡임과 번쩍임이 과도하게 제공되어 아동들이 병원에 가서 치료를 받았던 사례가 있다. 그러므로 깜박임과 번쩍임이는 효과로 정보를 제공하기 보다는 효과적인 디자인 등을 통해 모바일 애플리케이션의 정보를 제공하는 것이 바람직하다. 


2) 기술구현 방법 : 깜빡이거나 번쩍이는 콘텐츠를 제공해야만 할 경우 초당 3-50회 주기는 피해서 제공하는 것이 좋다. 깜빡이거나 번쩍이는 콘텐츠를 사용해야 할 경우, 사전에 경고를 하고 깜빡임이나 번쩍임을 회피할 수 있는 수단을 제공하는 것이 바람직하다. 이러한 콘텐츠는 깜빡이는 배경이나 텍스트, 꺼지고 켜짐을 반복적으로 수행하는 그래픽, 또는 다른 여러 이미지를 반복적으로 보여주는 모든 것들을 포함한다.

 

7. (배경음 사용금지) 자동으로 재생되는 배경음을 사용하지 않는 것이 바람직하다.


1) 준수 필요성 : 시각장애인의 경우 모바일 기기나 모바일 화면낭독 프로그램에서 제공하는 음성읽기 기능(iOS VoiceOver, 안드로이드 Talkback, 심비안 및 윈도우 모바일 6.5에서 활용되는 Code Factory사의 Mobile Speak 등)을 활용하여 모바일 애플리케이션을 이용한다. 이러한 기능들은 기본적으로 음성을 통하여 정보를 제공하고 있다. 이에 따라 애플리케이션을 실행하였을 때 배경음이 자동적으로 나오게 되면 음성으로 정보를 정확히 전달받을 수 없다. 따라서 이러한 배경음이 필요한 경우 이에 대한 알림 정보를 제공하고, 사용자가 선택할 경우에만 실행이 되도록 제공하는 것이 바람직하다.


2) 기술구현 방법 : 자동으로 재생되는 배경음(동영상, 음성, 음악 등)을 사용하지 않는 것이 바람직하다. 단, 3초 미만의 배경음은 예외로 한다. 배경음을 사용할 경우, 반드시 배경음을 제어할 수 있는 수단(멈춤, 일시정지, 음량조절 등)이나 배경음 제어로 이동하는 링크를 애플리케이션 첫 부분에 제공하는 것이 좋다. 또한 음량 조절은 운영체제에서 제공하는 음량과 독립적으로 배경음만 조절할 수 있도록 제공하는 것이 더 좋다.

3) 구축 사례


  ** 자동차 회사에서 제공하는 모바일 애플리케이션으로 시작화면부터 사용자가 선택하지 않았음에도 불구하고 배경음이 자동적으로 흘러나오고 있다. 이를 해지하기 위해서는 설정 메뉴로 들어가서 음악과 효과음을 줄여야만 정지되는 형태로 시각 사용자 등에게 혼란을 주는 사례이다.


< 자동 배경음을 사용한 잘못된 사례 >

< 해결 방안 >

동영상을 사용자의 선택에 의해 활성화되도록 제공하는 것이 바람직하다.

 

배경음을 제공할 경우에는 반드시 애플리케이션 첫 부문에 이를 정지할 수 있는 기능을 제공하는 것이 바람직하다.


8. (장애인 사용자 평가) 애플리케이션 개발 시 다양한 모바일 기기에서의 이용 가능여부를 점검해야 하며, 장애인 테스트를 수행하는 것이 바람직하다.


1) 준수 필요성 : 모바일 애플리케이션을 개발함에 있어 앞에서 말한 모든 지침 항목을 준수하여 개발하였다 하더라도 장애인 사용자가 실제로 사용할 수 있는지 점검하는 것이 중요하다. 이는 장애인이 가지고 있는 특성에 대한 이해의 차이 때문에 실제로는 접근성 지침을 지켜도 장애인이 사용하기 어려울 수 있기 때문이다. 또한 사용자는 모바일 애플리케이션을 다양한 모바일 기기를 활용하여 접근할 것이다. 이에 가급적 많은 모바일 기기를 활용하여 애플리케이션의 정보 접근 및 기능 가능여부를 사전에 점검하는 작업을 하는 것이 필요하다.


2) 준수 방법 : 기획 단계부터 해당 애플리케이션에 대해 장애인 사용자 평가를 수행하는 것이 바람직하다. 시각, 청각, 상지 장애 등의 다양한 장애인 사용자를 대상으로 하는 것이 좋으며, 고령자도 포함하는 것이 좋다. 또한 모바일 애플리케이션 개발자, 운영자 등도 운영체제에서 제공하는 애플의 VoiceOver, 구글의 TalkBalk 등을 활용하여 지속적으로 점검하는 것이 바람직하다.


신고
  1. 신호등 2011.10.02 23:02 신고

    드디어 나라에서 움직이기 시작(?)하네요.
    슬슬 이런 것도 표준이 필요한 시점이기도 했구요.

HelloAndroid 만들기

이제 안드로이드 개발환경이 제대로 되었는지, “HelloAndroid”를 만들어 보겠습니다. 안드로이드 프로젝트를 생성하는 방법을 간단히 익힐 수 있으니, 처음 하시는 분은 꼭 해보시길 바랍니다.

지금부터는 모두 eclipse에서 작업이 이루어집니다.

1. [File] - [New] - [Project..] 메뉴를 선택합니다.

2. New Project창이 뜨면 [Android] – [Android Project] 를 선택합니다.

 

3. 아래와 같이 입력하고, [Finish] 버튼을 클릭합니다.

 

4. [Run] – [Run] 메뉴나 [Ctrl+F11] 단축키를 이용해서 실행합니다. 아래처럼 나오면, [Android Application]을 선택합니다.

 

5. 에뮬레이터가 실행되면 “HelloAndroid”가 실행됩니다.

 

Eclipse의 좌측에 나타나는 각종 리소스들을 하나씩 살펴보시면, 안드로이드 어플리케이션이 어떤 구조로 만들어지는지 대략적으로 짐작할 수 있을 겁니다.

위에 나타난 문구를 바꾸시려면, 아래 그림에 있는 strings.xml을 열어서 고치시면 됩니다.

신고

1. AVD (Android Virtual Device) 만들기

가. Eclipse에서 [Window] - [Android SDK and AVD Manager] 메뉴로 들어간다.

나. 왼쪽 목록에서 [Virtual Devices]를 선택하고, [New]버튼을 클릭한다.


다. [Name]에 “AVD1.6”, [Target]에 “Google APIs (Google Inc.) – API Level 4”를 선택하고, [Size]는 ‘128’을 입력한다. 다음 [Create AVD]버튼을 클릭하면, AVD가 생성된다.


Target에는 설치된 SDK버전이 모두 나타나는데, 보통 “Android 1.6 – API Level 4”와 “Google APIs (Google Inc.) – API Level 4”처럼, 두 개가 있다. 둘 다 같은 버전이지만, Google APIs라고 된 것은 Google서비스가 포함되어 있다.

여기서 1.6버전으로 선택한 것은, 국내에 출시되는 안드로이드폰이 1.6과 2.1버전으로 주로 출시되는 상황이라서 선택했다. 자신이 원하는 버전을 선택하면 된다.

128은 SD Card용량을 의미하고, Skin에서는 화면 해상도를 선택할 수 있다.

 

2. PATH설정

PATH설정은 안해도 무방하지만, 설정해 두면 가끔 android SDK 폴더에 있는 tools 폴더 명령을 사용해야 할 때 유용하다.

윈도우XP 기준으로 [내 컴퓨터] - [시스템 등록 정보] – [고급] - [환경 변수] - [PATH] - [편집]에서 압축을 풀었던, android-sdk-window폴더의 tools 폴더 경로를 입력하면 된다. (이미 입력된 내용을 참고해 보면, 세미콜론 ; 를 이용해서 구분한 것을 알 수 있다. 즉, 여기서는 ;C:\Program Files\eclipse\android-sdk-windows\tools 를 가장 끝에 입력하면 된다.)

 

3. 한글키보드 설치

안드로이드 SDK에는 한글키보드가 없기 때문에 한글 입력을 테스트할 수 없다. 따라서 가상 한글키보드를 설치해야 하는데, 여기서는 “접촉식 한글 자판”을 설치한다.

가. http://www.androidpub.com/keyboard 에서 가장 최신 버전의 “HangulKeyboard.apk” 파일을 다운로드 받는다.

나. 다운로드 받은 파일을 android-sdk-windows의 tools 폴더에 복사한다. (여기서는 C:\Program Files\eclipse\android-sdk-windows\tools 폴더이다. 자신이 압축푼 위치를 찾으면 된다.)

다. 윈도우 XP기준으로 [시작] - [실행]에서 “cmd”를 입력해서 커맨트창을 연다.

라. “cd C:\Program Files\eclipse\android-sdk-windows\tools” 명령을 입력해서 tools폴더로 이동한다.

마. “start emulator –avd AVD1.6” 명령을 입력하면, 에뮬레이터가 실행된다. (“AVD1.6”은 앞서 만들었던 AVD이름이다.)

라. 에뮬레이터가 실행되면, “adb install hangulkeyboard.apk” 명령을 실행해서 한글 키보드를 설치한다.

 

4. AVD 한글 설정

아래 설정 방법은 안드로이드 1.6 기준이며, 다른 버전으로 실행하면 조금씩 다를 수 있다. 휴대폰 사용법과 유사하니 어렵지 않게 설정할 수 있을 것이다.

가. 아래 순서대로 설정하면 모든 메뉴가 한글로 나올 것이다.


나. “한글 접촉식 키보드”만 체크하고, 다른 것은 모두 체크를 해제한다.

 

이제 개발을 위한 기본 설치는 마쳤다. 아래 이미지처럼 eclipse에서 [Window] - [Android SDK and AVD Manager]에 들어가서도 에뮬레이터를 실행할 수 있다.

에뮬레이터에서 안드로이드 운영체제를 함 사용해 보시길… 나름 재밌습니다. ^^;

신고

1. JDK 설치

http://java.sun.com/javase/downloads 에서 JDK를 다운로드 받아 설치한다.

JDK는 Java Development Kit 의 약어로 Java개발을 위한 필수 프로그램이다. 개발을 위한 것이 아니라면 JRE를 설치하는데, JRE는 Java로 개발된 프로그램을 실행하기 위한 것으로 차이가 있다.

 

2. Eclipse 설치

http://www.eclipse.org/downloads 에서 Eclipse IDE for Java Developers 를 클릭해서 다운로드 받는다.

받은 파일은 C:\Program Files\eclipse (반드시 이 경로가 아니라도 된다.)에 압축을 푼다. Eclipse는 별도의 설치 프로그램을 제공하지 않으므로 원하는 경로에 압축을 풀어도 무방하다.

압축을 풀었으면, eclipse 실행파일을 바탕화면에 바로 가기로 등록해 두면 좋다.

 

3. Android SDK 설치

http://developer.android.com/sdk 에서 다운로드 받는다.

받은 파일은 C:\Program Files\eclipse\android-sdk-windows (eclipse 하위가 아닌 다른 경로도 상관없다.)에 압축을 푼다.

 

4. Eclipse ADT플러그인 설치

가. Eclipse를 실행한다. (Vista나 Windows7에서는 관리자권한으로 실행하기를 권장한다. 설치 시에만 해당하며, 만약 위에서 압축 풀 때 개인 폴더에 풀었다면 관리자권한이 아니라도 상관없다.)

나. [Help] – [Install New Software] 선택하고, Install 창이 나오면 [Add]를 클릭한다.


다. Add Site창이 나오면, [Name]에 “Android Plugin” 입력, [Location]은 “https://dl-ssl.google.com/android/eclipse” 입력하고(https 오타 주의), [OK]를 클릭한다.


라. Work with 에 방금 입력한 Android Plugin 이 맞는지 확인하고, [Developer Tools]에 체크한 후, [Next]를 클릭한다. (Developer Tools는 조금 기다려야 나타날 수 있다. 나타나지 않는다면, Work with에서 Android Plugin을 다시 선택해 보자.)


마. 조금 기다리면 아래 화면처럼 나온다. “Android DDMS”와 “Android Development Tools”가 있는지 확인 후, [Next]를 클릭한다.


바. “I accept the terms of the license agreements”를 선택하고, [Finish]를 눌러 마친다.


사. 아래 그림처럼 설치가 되고, Eclipse 를 재시작한다. (중간에 메시지가 나오더라도 [OK]를 눌러 진행시킨다.)

 

5. Android SDK 경로 지정 설치

가. Eclipse의 [Window] – [Preferences] 메뉴를 선택한다.

나. 좌측 목록에서 “Android”를 선택하고, 오른쪽에서 [Browse…]를 클릭해서, Android SDK 압축푼 위치를 지정한다. 다음 [OK] 버튼을 클릭한다. (중간에 몇 개의 메시지가 뜨면 [OK]를 클릭해서 넘긴다.)


다. 이번에는 [Window] – [Android SDK and AVD Manager] 메뉴를 선택한다.


라. [Accept All] 선택 후 [Install] 버튼을 클릭해서 설치한다. (자신에게 필요한 버전만 선택해서 설치할 수 있지만, 편의상 모든 버전을 설치하였다.)


마. 아래 화면처럼 선택한 SDK를 모두 다운로드 받아 설치한다. (약 30분 정도 걸렸다.)

신고
  1. vvipbum 2010.05.23 16:56 신고

    보고 많은 안드로이드 개발환경구축하는데 많은 도움이 되었습니다 ^ㅡ^;; 좋은 정보 감사합니다.

  2. jinyeo 2010.05.26 22:49 신고

    많은 도움 되었습니다. 감사합니다.

  3. 2010.07.05 09:19

    비밀댓글입니다

+ Recent posts