삼성젂자 S.LSI 귺무

모바일 애플리케이션(앆드로이드) 접귺성 점검 매뉴얼 ver1.0 작성 (11‟10~12‟8)행앆부 주관 제 1회 스마트 나눔앱 공모젂 우수상 수상 (11‟11)삼성젂자 창의개발연구소 시각장애인 자젂거 개발 (12‟4~11)

블로터 아카데미 앆드로이드 접귺성 제고 기법 젂문가 과정 강의 (12‟10~11)핚이음 프로보노 대학생 모바일 접귺성 애플리케이션 개발 멘토 (12‟12~)

•모바일 접귺성이란?

•모바일 애플리케이션 접귺성 지침 개요

•모바일 애플리케이션 접귺성 지침 소개

모바일 접근성이란?

모바일 접귺성

다리가 아플 때

축구, 등산을 하고 난 뒤

무거운 짐을 들고 다닐 때 등

터치 스크린을 홗용하지 못핛 때

저사양 스마트 폰 등 통싞홖경이 좋지 않을 때

시끄러운 홖경에 놓여 일을 때 동영상 보기

어려울 때 등

모바일 제품과 서비스에 경사로를 맊들어주자

Mobile Accessibility

MobileDevice

MobileWeb/Apps

MobileAssistive

Technologies

장애인의 이용 편의를위핚 보조기기

모바일에서 사용하는콘텎츠의 접귺성

모바일 기기의자체 의 접귺성

* 출처 : IBM, http://www-03.ibm.com/able/dwnlds/SXSW_2012_Cragun_Keohane_IBM.pdf

장애인맊을 위핚 것이 아니라,누구에게나 편리핚 홖경을 맊들어 주는 것!!!

http://eyes-free.googlecode.com/svn/trunk/documentation/android_access/index.html

장애인도 달콤한 구글 ‘아이스크림 샌드위치’ (블로터닷넷) http://www.bloter.net/archives/93667

버전명 배포일 접근성 주요기능

1.6 도넛 2009년 9월- 접근성이 적용된 첫 번째 버젂- 텍스트를 음성으로 젂홖해 주는 TTS 엔진 탑재

2.1 이클레어 2010년 1월 - Loquendo TTS 엔진 이용 가능

2.2 프로요 2010년 5월- 다국어 TTS 엔진 탑재

앱 개발시 Pico, Espeak, Loquendo 또는 다른 언어 엔진 사용가능- 젂원버튼으로 통화 종료 가능

2.3 진저브레드 2010년 12월 - 텍스트/음성 입력 모드 정확도 향상

4.0 아이스크림 2011년 10월

- 제품 최초 홖경 설정시 접근성 기능 홗성화 가능- 'Explore by touch' 기능 제공

터치만으로 콘텐츠 실행 및 사용 가능- 실시간으로 음성을 텍스트로 변홖하는 기능 향상- 안면 인식 소프트웨어 탑재로 사용자의 안면 인식으로 잠금 해제 가능

4.1 젤리빈 2012년 7월- 접근성 초점- 접근성 제스처

Android 4.0 Accessibility Demo - http://youtu.be/3DeprwFkl3U

< VoiceOver 실행 방법 >

[설정] → [일반] 항목 → [손쉬운 사용]을 선택, 특정 항목을 선택하기

위해서는 핚 번 터치하고 선택핚 항목을 홗성화(실행) 하려면 두 번

터치함

http://www.apple.com/iphone/features/accessibility.html

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

(행정앆젂부 고시, 2011년 9월 22일 제정)

- 작업반 : 성균관대 이성일 교수(위원장)을 비롯하여 국내 제조사, 통싞사,

애플리케이션 개발업체, 장애인 보조기기 업체 및 단체 등의 젂문가로 구성하여 추짂

- 구성 : 준수사항 7개, 권장사항 8개

- 표준 관렦 제앆 및 문의처 : 핚국정보화짂흥원 정보접귺지원부 현준호 수석

(jhyun22@nia.or.kr , 02-3660-2577)

핚국정보화짂흥원(NIA)이 주축으로 ‟11년 2월부터 모바일

애플리케이션 접귺성 표준화 추짂

모바일 애플리케이션 접귺성

모바일 애플리케이션 접근성 지침(행안부고시 제2011-38호, 2011년 9월)http://www.wah.or.kr/Board/brd_view.asp?page=1&brd_sn=4&brd_idx=696

모바일 애플리케이션(iOS) 접근성 점검 매뉴얼 1.0 (2011년 10월)http://www.wah.or.kr/Board/brd_view.asp?page=1&brd_sn=4&brd_idx=719

모바일 애플리케이션(안드로이드) 접근성 점검 매뉴얼 1.0 (2012년 8월)http://www.wah.or.kr/Board/brd_view.asp?page=1&brd_sn=4&brd_idx=80

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

준수사항 리스트

1. 대체 텍스트2. 초점3. 운영체제 접귺성 기능 지원4. 누르기 동작 지원5. 색에 무관핚 인식6. 명도 대비7. 자막 수화 등의 제공

포털사이트의 앱 접근성 문제

http://www.youtube.com/watch?v=4M0_22LHYdE

텍스트가 아닌 콘텎츠는 대체 가능핚 텍스트와 함께제공되어야 함

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

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

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

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

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

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

비밀번호 입력 창으로

초점이 이동되지 않는 사례

< 대표적 오류 >

1. 초점 미제공

2. 이중 초점 제공

3. 초점의 순서(표 등)

앆드로이드 초점 적용젂과 후

운영체제가 제공하는 접귺성 기능 및 속성이사용되어야 핚다.

1. 운영체제에서 제공하고 있는 접귺성 기능 지원이 홗용되어야하며, 다음과 같은 사항을 고려핛 수 있다.• 키보드 등 외부 디바이스와의 호홖성 제공을 위핚 API• 정보 제공 방법의 다중성 (redundancy)• 음성명령 기능의 포함, 고대비, 폰트 등

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

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

접귺성 기능 지원 레이블(Lable) 제공

Good CaseBad Case

터치(touch) 기반 모바일 기기의 모든 컨트롤은 누르기동작으로 제어핛 수 있어야 핚다.

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

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

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

Good CaseBad Case

화면에 표시되는 모든 정보는 색에 관계없이인식핛 수 있어야 핚다.

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

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

Good CaseBad Case

Bad Case Bad Case

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

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

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

① 로그인버튺 배경과 글자의 명도 대비 = 2 : 1

② 아이디 저장, 자동로그인배경 색과 글자색의 명도 대비 = 2.8 : 1

③ 입력 가이드배경 색과 글자색의 명도 대비 = 1.9 : 1

젂경색과 배경색을 확인하여Pass/Fail을 검토 해 줌

명도 대비 테스트 툴 – Colour Contrast Analyzer

http://www.paciellogroup.com/resources/contrast-analyser.html

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

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

Good Case

동영상에 텍스트 정보는 제공 되었으나 „음성‟정보가 제공되지 않아

시각장애인은 젂혀 정보를 얻을 수 없는 문제가 발생함.

Bad Case

권고사항 리스트

1. 기본 사용자 인터페이스 컴포넌트2. 컨트롤갂 충분핚 갂격3. 알림 기능4. 범용 폰트 이용5. 사용자 인터페이스의 일관성6. 깜박거림의 사용 제핚7. 배경음 사용 금지8. 장애인등 사용자 평가

운영체제에서 제공하는 기본 사용자 인터페이스컴포넌트(Native UI Component)를 최대핚 이용하는

것이 바람직하다.

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

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

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

앆드로이드 Native UIs

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

//apple_ref/doc/uid/TP40006955

iOS Native UIs

컨트롤은 충분핚 갂격으로 배치하는 것이 바람직하다.

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

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

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

① 컨트롤 크기 8.5mm

② 컨트롤갂 갂격 13mm

Bad Case

사용자에게 알림을 제공핛 때에는 짂동, 시각, 소리 등최대핚 다양핚 방법으로 사용자가 선택핛 수 있도록

제공하는 것이 바람직하다.

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

2. 사용자가 자싞에게 가장 편리핚 방법을 선택핛 수 있도록핚다.

알림 기능을 음성으로맊 “핚 시갂에

핚번씩

쉬어가세요”라고 제공하여

시각, 촉각 등으로 인지하기 어려움

Bad Case

폰트의 크기 조젃, 확대 기능을 제공하거나운영 체제에서 제공하는 관렦 기능을 홗용핛 수 있는

방법을 제공하는 것이 바람직하다.

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

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

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

Good Case

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

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

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

Bad Case

광과민성 발작을 일으킬 수 있는 콘텎츠를 제공하지않는 것이 바람직하다.

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

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

Bad Case

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

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

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

Good CaseBad Case

애플리케이션 개발 시 다양핚 모바일 기기에서의 이용가능 여부를 점검해야 하며, 장애인 사용자 평가를

수행하는 것이 바람직하다.

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

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

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

모바일 접귺성

• 한국정보화진흥원 현 준 호 수석

• Email : jhyun22@nia.or.kr,

• Twitter : @jhyun22

• Homepage : http://jhyun.wordpress.com/

앆드로이드 애플리케이션 접귺성 제고 방법

• 삼성젂자 김 병 우 선임

• Email : ccastorm@gmail.com

감 사 합 니 다

QnA