src.hwp

Transcription

1 제정일: 2012년 12월 21일 T T A S t a n d a r d 모바일 애플리케이션 접근성 지침 Mobile Application Accessibility Guidelines

2 제정일 : 2012년 12월 21일 모바일 애플리케이션 접근성 지침 Mobile Application Accessibility Guidelines 본 문서에 대한 저작권은 TTA 에 있으며, TTA와 사전 협의 없이 이 문서의 전체 또는 일부를 상업적 목적으로 복제 또는 배포해서는 안됩니다. Copyrightc Telecommunications Technology Associations All Rights Reserved.

3 서 문 1. 표준의 목적 이 표준은 모바일 애플리케이션 서비스 제공자가 장애인, 기 위해 애플리케이션 제작 시 지켜야 할 사항을 규정한다. 고령자 등의 접근성을 보장하 2. 주요 내용 요약 모바일 애플리케이션의 접근성 확보를 위하여 반드시 준수해야 할 사항(7 개) 과 준수할 것을 권고하는 사항(8 개) 으로 구성되었다. 또한 개발자, 서비스 기획자 등이 참고할 수 있도록 모바일 애플리케이션 접근성 지침을 고려한 개발 실제 사례 및 방법을 부록으로 제공한다. 3. 표준 적용 산업 분야 및 산업에 미치는 영향 본 표준은 모바일 애플리케이션 서비스 개발자 및 제공자가 장애인, 고령자 등의 접근 성을 보장하기 위해 모바일 애플리케이션 제작 시 지켜야 할 사항을 규정한 것으로, 국 내 모바일 애플리케이션 관련 산업 및 정책 전반에 영향을 미칠 것이며 장애인 등 취약 계층이 동등하게 모바일 애플리케이션을 이용할 수 있는 환경 조성에 기여할 것이다. 4. 참조 표준( 권고) 4.1. 국외 표준( 권고) - 해당 사항 없음 4.2. 국내 표준 - 해당 사항 없음 5. 참조 표준( 권고) 과의 비교 5.1. 참조 표준( 권고) 과의 관련성 - 해당 사항 없음 i

4 5.2. 참조한 표준( 권고) 과 본 표준의 비교표 - 해당 사항 없음 6. 지적 재산권 관련 사항 본 표준의 지적 재산권 확약서 제출 현황은 TTA 웹사이트에서 확인할 수 있다. 본 표준을 이용하는 자는 이용함에 있어 지적 재산권이 포함되어 있을 수 있으므 로, 확인 후 이용한다. 본 표준과 관련하여 접수된 확약서 이외에도 지적 재산권이 존재할 수 있다. 7. 적합 인증 관련 사항 7.1. 적합 인증 대상 여부 - 해당 사항 없음 7.2. 시험 표준 제정 현황 - 해당 사항 없음 8. 표준의 이력 정보 8.1. 표준의 이력 판수 제정 개정일 제정 개정 내역 제1판 제정 8.2. 주요 개정 사항 - 해당 사항 없음 ii

5 Preface 1. Purpose of Standard This standard describes the methods of developing mobile application which everyone, including persons with disabilities and the elderly, can access. Especially, this standard helps mobile application developers, designers and providers make mobile application accessible. 2. Summary of Contents This standard describes requirements(7 items) that should comply with for ensuring accessibility of mobile application. This standard describes recommendations(8 items) that improve the accessibility of mobile application. Also, this standards provides development methods and actual cases considering accessibility guidelines on the Appendix Ⅰ. 3. Applicable Fields of Industry and its Effect This standards will provide mobile application developers, designers, providers with practical accessibility guidelines and help them find new opportunities in domestic and foreign market. 4. Reference Standards(Recommendations) 4.1. International Standards(Recommendations) - None 4.2. Domestic Standards - None iii

6 5. Relationship to Reference Standards(Recommendations) 5.1. Relationship of Reference Standards - None 5.2. Differences between Reference Standard(Recommendation) and this Standard - None 6. Statement of Intellectual Property Rights IPRs related to the present document may have been declared to TTA. The information pertaining to these IPRs, if any, is available on the TTA Website No guarantee can be given as to the existence of other IPRs not referenced on the TTA website. And, please make sure to check before applying the standard. 7. Statement of Conformance Testing and Certification 7.1. Object of Conformance Testing and Certification - None 7.2. Standards of Testing and Certification - None 8. History of Standard 8.1. Change History Edition Issued date Contents The 1st edition Established 8.2. Revisions - None iv

7 목 차 1. 개 요 1 2. 표준의 구성 및 범위 1 3. 참조 표준( 권고) 3 4. 용어 정의 3 5. 모바일 애플리케이션 접근성 준수 사항 대체 텍스트 초점 운영 체제 접근성 기능 지원 누르기 동작 지원 색에 무관한 인식 명도 대비 자막, 수화 등의 제공 6 6. 모바일 애플리케이션 접근성 권고 사항 기본 사용자 인터페이스 컴포넌트 컨트롤 간 충분한 간격 알림 기능 범용 폰트 이용 사용자 인터페이스의 일관성 깜박거림의 사용 제한 배경음 사용 금지 장애인 등 사용자 평가 8 부록 I. 모바일 애플리케이션 접근성 지침 사례 9 v

8 Contents 1. Introduction 1 2. Constitution and Scope 1 3. Reference Standards(Recommendations) 3 4. Terms and Definitions 3 5. Requirements on Mobile Application Accessibility Alternative Text Focus Accessibility Functions of Operating Systems Touch and Tap Color Contrast Caption or sign language 6 6. Recommendations on Mobile Application Accessibility Native User Interface Components Control Target Size Alert Global Font Setting User Interface Consistency Flickering Audio Control User Testing 8 Appendix I. Case Studies on Mobile Application Accessibility Guideline 9 vi

9 모바일 애플리케이션 접근성 지침 (Mobile Application Accessibility Guidelines) 1. 개요 본 표준은 장애인, 고령자 등이 비장애인, 젊은이 등과 동등하게 모바일 애플리케이션 에 접근할 수 있도록 모바일 애플리케이션을 제작할 때 준수해야 하는 지침들에 관해 기 술하고 있다. 본 표준은 특정 모바일 운영 체제나 기기에 한정을 두고 개발한 것이 아니 며, 다양한 운영 체제에서 활용될 수 있는 지침으로 개발 되었다. 본 표준은 한국정보화진흥원이 운영 중인 정보통신 접근성 향상 표준화 포럼 산하 정 보통신 분과위원회가 주축이 되어 학계, 연구계, 장애인단체, 관련 기업 등의 전문가로 위원회를 구성하여 개발된 것이다. 2. 표준의 구성 및 범위 본 표준은 모바일 애플리케이션을 구축, 운영, 개선 및 유지 보수할 경우에 적용하는 것으로, 본 표준이 적용되는 모바일 기기 대상은 다음과 같다. 가. 나. 다. 운영 체제를 갖는 모바일 전화기 운영 체제를 갖는 태블릿 기기 운영 체제를 갖는 전자책 기기 본 표준은 반드시 지켜야 할 사항( 준수 사항) 7 개, 가급적 지켜야 할 사항( 권고 사항) 8 개 항목으로 구성되었으며, 본 표준은 제3 자가 제공하는 서비스를 제외하고, 모바일 애플리케이션 서비스 제공자가 직접 제공하는 콘텐츠로 한정한다. 1

10 < 모바일 애플리케이션 접근성 준수 사항(7 개) 개요 > 지 침 내 용 비 고 대체 텍스트 이미지 등 텍스트 아닌 콘텐츠의 정보나 의미를 동 등하게 인식할 수 있도록 대체 텍스트 제공 시각장애인 등 초점 모든 객체에 초점(focus) 을 적용하고, 초점이 순차적으로 이동될 수 있도록 제공 시각, 지체 장애인 등 운영체제 접근성 기능 지원 각 모바일 운영체제에서 장애인을 위해 제공하는 기능과 호환될 수 있도록 서비스 제공 모든 장애인 누르기 동작 지원 Slide, Drag & Drop 등의 복잡한 동작을 단순 한 방법으로 이용할 수 있도록 제공 시각, 지체 장애인 등 지 침 내 용 비 고 색에 무관한 인식 명도 대비 자막 및 수화 등의 제공 색각 이상자도 정보를 동등하게 접근할 수 있도록 무늬, 패턴 등을 함께 제공 저시력자, 고령자 등을 위해 전경과 배경을 구분할 수 있도록 고대비를 제공 동영상에 대한 내용을 동등하게 인식할 수 있도록 자막, 원고 또는 수화를 제공 색각 이상자 등 저시력인 등 청각 장애인 등 < 모바일 애플리케이션 접근성 권고 사항(8 개) 개요 > 지 침 내 용 비 고 기본 사용자 인터 페이스 컴포넌트 모바일 운영체제에서 제공하는 기본적인 사용자 인터페이스 컴포넌트를 최대한 활용 모든 장애인 컨트롤 간 충분한 간격 사용자 의도와 다른 컨트롤을 누리지 않도록 컨 트롤 간 충분한 간격을 배치 지체, 지적 장애인 등 알림 기능 한 가지 방법이 아닌 진동, 시각, 소리 등 다양 한 방법으로 사용자에게 알림 기능을 제공 시각, 청각 장애인 등 범용 폰트 이용 사용자의 선호에 따라 폰트의 크기의 조절, 확대 등이 가능하도록 기능 제공 저시력인 등 사용자 인터 페이스의 일관성 인터페이스 요소를 사용자가 다시 학습하지 않 아도 되도록 일관성 있는 배치 지적, 시각 장애인 등 깜빡거림의 사용 제한 배경음 사용 금지 장애인 용자 평가 광과민성 발작을 일으킬 수 있는 콘텐츠를 제공 하지 않음 음성에 의존하는 시각장애인 등을 위해 자동으 로 재생되는 배경음을 사용하지 않음 장애인의 이용 보장을 위해 장애인 사용자를 대 상으로 사용자 평가 수행 광과민성 발작 증세 시각장애인 등 모든 장애인 2

11 3. 참조 표준( 권고) 본 표준에서 참고한 표준은 다음과 같다. - 행정안전부 고시( 제 호), 장애인 고령자 등의 정보 접근 및 이용 편의 증진을 위 한 지침(2011년 7월 14 일) - W3C MWABP, Mobile Web Application Best Practices (2010년 12월 14 일) - W3C MWBP, Mobile Web Best Practices 1.0 (2008년 7월 29 일) - Apple, Accessibility programming guide for ios, /iphoneaccessibility/introduction/introduction.html - Google, Android Accessibility - Designing for Accessibility, ers.html - RIM, Best practice: Designing accessible applications, 11.jsp 4. 용어 정의 본 표준에서 사용하는 용어의 뜻은 다음과 같다 접근성 모바일 기기를 사용하여 모바일 애플리케이션을 이용하고자 하는 장애인, 을 포함한 모든 사람들에게 이의 활용 가능성이 제공됨 고령자 등 4.2. 모바일 기기 무선 인터넷 서비스를 제공 받을 때에 사용하는 휴대용 기기를 의미함 4.3. 모바일 애플리케이션 사용자가 특정한 목적을 달성하기 위하여 모바일 기기상에서 실행되는 소프트웨어 를 의미함 4.4. 서비스 제공자 모바일 기기를 이용하여 콘텐츠 및 서비스를 제공하는 공공기관 및 사업자 3

12 4.5. 무리한 부담(Undue Burden) 현재 가능한 기술 수준과 적절한 비용으로 실현시킬 수 있는 정도 이상의 노력을 요구함 4.6. 준수 사항 모바일 애플리케이션의 접근성 확보를 위하여 무리한 부담이 되지 않는 한 반드시 준수해야 할 사항 4.7. 권고 사항 모바일 애플리케이션의 접근성 향상을 위하여 무리한 부담이 되지 않는 한 준수할 것을 권장하는 사항 4.8. 운영 체제 모바일 기기상에서 애플리케이션을 비롯한 소프트웨어를 실행할 수 있는 기반 환경 4.9. 보조 기기 장애인의 신체적 인지적 기능을 증진, 보완, 향상시키기 위하여 사용하는 기기, 장비 의 일부분 또는 시스템, 소프트웨어 터치(touch) 모바일 기기의 기능 및 화면상의 객체를 키나 버튼 같은 물리적인 형태의 컨트롤을 사용하지 않고 화면상에서 직접 만져서 조작 가능한 사용자 인터페이스를 제공하는 운영 체제의 특성 4

13 5. 모바일 애플리케이션 접근성 준수 사항 5.1. ( 대체 텍스트) 텍스트 아닌 콘텐츠는 대체 가능한 텍스트와 함께 제공되어야 한다. 대체 텍스트(Alternative text) 란 그림 및 이미지, 동영상으로 작성된 멀티미디어 형식의 콘텐츠 내용을 텍스트로 그 의미나 기능을 인식할 수 있도록 제공하는 것을 말한다. 텍 스트 아닌 콘텐츠(Non-text contents) 주1) 에 대한 대체 텍스트는 그 의미나 기능을 파악 할 수 있도록 짧고 명확하게 제공해야 한다. 대체 텍스트를 제공하게 되면 시각 장애인 등 시각적으로 정보를 습득하는 데 어려움 을 겪는 사용자들이 모바일 화면 낭독 프로그램( 애플 VoiceOver, 안드로이드 Talkback 등) 과 같은 보조 기술을 사용하면 해당 콘텐츠를 음성을 통해 들을 수 있으므로 최소한 의 접근권을 보장받을 수 있게 된다. 주1) 그림, 이미지 등으로 제작된 텍스트, 애니메이션, 아스키(ASCII) 그림문자, 기호(Bullet) 이미 지, 그래픽 버튼, 이모티콘(Emoticon), 릿스피크(Leetspeak) 등과 같이 표준 문자( 부호) 체계 가 아닌 시각적 또는 청각적 정보가 포함된 콘텐츠를 말한다. 한글 부호의 경우 유니코드, 조합형 또는 완성형 부호 체계를 사용하여 작성된 텍스트 이외의 모든 경우를 포함한다 ( 초점) 모든 객체에는 초점(focus) 이 적용되고, 초점은 순차적으로 이동되어야 한다. 초점은 화면상의 선택된 객체의 내용을 화면 낭독 프로그램 등의 보조기기를 통해 이 용할 수 있도록 도와주는 기능을 말한다. 선택된 객체는 초점이 적용되었다고 하고, 초점 은 화면상에서 테두리나 하이라이트로 표시하여 제공되는 것이 바람직하다. 표의 객체에 적용되는 초점은 논리적인 순서로 제공되어야 한다. 논리적인 순서가 적용 될 경우 인지, 언어, 학습 장애가 있는 사용자들이 표를 이해하는 데 도움을 준다 ( 운영 체제 접근성 기능 지원) 어야 한다. 운영 체제가 제공하는 접근성 기능 및 속성이 사용되 운영 체제에서 제공하고 있는 접근성 기능 지원이 활용되어야 하며, 을 고려할 수 있다. - 키보드 등 외부 디바이스와의 호환성 제공을 위한 API - 정보 제공 방법의 다중성 (redundancy) - 음성 명령 기능의 포함, 고 대비, 폰트 등 다음과 같은 사항 애플리케이션이 해당 운영 체제에서 제공하고 있는 접근성 기능을 변경할 경우, 애플리 케이션의 종료와 함께 접근성 기능을 변경 전의 상태로 복원시켜야 한다. 입력 서식은 운영 체제에서 제공하는 접근성 속성을 활용하여 사용자가 이해하기 쉽도 록 해야 한다. 5

14 5.4. ( 누르기 동작 지원) 터치(touch) 기반 모바일 기기의 모든 컨트롤은 누르기 동작으 로 제어할 수 있어야 한다. 누르기 동작은 화면상의 객체를 손가락 끝으로 접촉하여 만지거나(touch) 가볍게 두드 리는(tap) 동작을 말한다. 두 개의 손가락을 동시에 이용해야 하는 다중 누르기(Multi-touch) 동작은 단순한 누르 기 동작으로 대체할 수 있는 방법이 제공되어야 한다. 또한 슬라이드(Slide), 끌기와 놓기 (Drag and drop) 방법이 제공되어야 한다. 등의 복잡한 누르기 동작은 단순한 누르기 동작으로 대체할 수 있는 5.5. ( 색에 무관한 인식) 한다. 화면에 표시되는 모든 정보는 색에 관계없이 인식할 수 있어야 색상으로 정보를 구분할 경우, 색상 이외의 다른 방법으로도 동등한 내용을 전달할 수 있도록 설계한다. 색상을 사용한 의미의 전달이 흑백 화면에서도 동등하게 이루어질 수 있도록 제공해야 한다. 색상 차이를 구분하기 어려운 색각 이상자 등도 정보를 동등하게 인식할 수 있다 ( 명도대비) 화면에 표시되는 모든 정보는 전경색과 배경색이 구분될 수 있도록 최소 대비 이상으로 제공되어야 한다. 명도 대비는 화면의 배경색과 객체를 표시하는 데에 사용되는 전경색 사이의 명도 차 이의 비율(contrast) 을 말한다. 고대비 제공이 불가능할 경우, 애플리케이션의 설정 기능 에 명도 대비 조절 기능을 제공한다. 화면상의 모든 정보의 최소 대비는 3:1 이상이어야 한다. 저시력인, 고령자 등에게 실 효성을 가지기 위해서는 명도 대비가 4.5:1 이상이 되는 것이 바람직하다. 단, 사진과 동 영상은 예외로 한다 ( 자막, 수화 등의 제공) 멀티미디어 콘텐츠에는 동등한 내용의 자막, 원고 또는 수화 가 제공되어야 한다. 멀티미디어 콘텐츠를 장애인이 비장애인과 동등하게 인식할 수 있도록 자막, 원고 또는 수화를 제공해야 한다. 자막, 원고 또는 수화는 화면상의 콘텐츠와 동기화하여 제공하는 것이 바람직하다. 자막, 원고 또는 수화를 제공하면 청각 장애인 등도 음성이나 음향 정보에 접근할 수 있다. 자막이나 원고를 제공하게 되면 청각 장애인뿐만 아니라 소란하거나 조용한 환경, 외국어의 경우에 있어 비장애인들도 도움을 받을 수 있는 장점이 있다. 6

15 6. 모바일 애플리케이션 접근성 권고 사항 6.1. ( 기본 사용자 인터페이스 컴포넌트) 운영 체제에서 제공하는 기본 사용자 인터페이 스 컴포넌트(Native UI Component) 를 최대한 이용하는 것이 바람직하다. 운영 체제에서 제공하는 접근성 있는 기본 사용자 인터페이스 컴포넌트는 사용자 인터 페이스 구성에 사용되는 표준 도구( 대화 상자, 버튼과 체크 박스, 타이틀 바 등) 들을 말 한다. 운영 체제에서 제공하는 기본 사용자 인터페이스 컴포넌트를 활용하면 보조 기기와의 호환성을 제공하기 용이하므로 접근성의 확보를 위해 적극적으로 활용되어야 한다 ( 컨트롤 간 충분한 간격) 컨트롤은 충분한 간격으로 배치하는 것이 바람직하다. 컨트롤은 버튼 또는 위젯과 같이 사용자 인터페이스 화면에서 누르기 동작으로 기능을 활성화시키는 객체를 말한다. 좁은 화면 공간의 경우, 사용자의 의도와 무관하게 다른 컨 트롤을 누르게 되는 문제가 발생할 수 있으므로, 이를 피하기 위해서 컨트롤 사이의 공 간을 충분히 확보하여 사용자가 컨트롤 영역을 명확히 구분할 수 있도록 하는 것이 바람 직하다. 모바일 기기의 화면 크기에 관계없이 컨트롤 중심 간 간격은 13 mm 이상을 권장한다 ( 알림 기능) 사용자에게 알림을 제공할 때에는 진동, 시각, 소리 등 최대한 다양한 방법으로 사용자가 선택할 수 있도록 제공하는 것이 바람직하다. 화면상의 모든 알림 정보는 한 가지 양식으로만 제공되지 않도록 하며, 다양한 감각 양 식을 활용한다. 사용자가 자신에게 가장 편리한 방법을 선택할 수 있도록 제공하는 것이 바람직하다 ( 범용 폰트 이용) 폰트의 크기 조절, 확대 기능을 제공하거나 운영 체제에서 제공하 는 관련 기능을 활용할 수 있는 방법을 제공하는 것이 바람직하다. 범용 폰트(Global Font) 는 운영 체제에 내장되어 확대나 축소, 기울임 등의 변형 형태 가 제공되는 글자체를 말하며, 이를 활용하는 것이 바람직하다. 모든 애플리케이션 화면에서 폰트 크기의 조절이 가능하도록 설계하거나, 최소한 확대 기능을 제공한 것이 바람직하며, 폰트 크기 조절을 용이하게 하기 위해서는 텍스트 이미 지보다 폰트가 지정되어 있는 텍스트를 사용하는 것이 바람직하다. 7

16 6.5 ( 사용자 인터페이스의 일관성) 하는 것이 바람직하다. 사용자 인터페이스 요소들의 배치를 일관성 있게 제공 사용자 인터페이스를 구성하고 있는 요소들은 사용자가 다시 학습할 필요가 없도록 해 당 애플리케이션 내에서 일관성 있게 설계한다. 애플리케이션의 버전이 바뀌어도 중요한 사용자 인터페이스 요소들의 배치는 일관성을 유지하는 것이 바람직하다 ( 깜박거림의 사용 제한) 것이 바람직하다. 광과민성 발작을 일으킬 수 있는 콘텐츠를 제공하지 않는 깜빡이거나 번쩍이는 객체를 사용자 인터페이스에 사용하지 않아야 하며, 화면상에서 반드시 깜빡임의 효과를 제공해야 하는 콘텐츠는 초당 3-50 회의 주기는 피해서 설계 한다 ( 배경음 사용 금지) 자동으로 재생되는 배경음을 사용하지 않는 것이 바람직하다. 자동으로 재생되는 동영상, 음악, 음성 안내 등을 사용하지 않는다. 단, 3 초 미만의 배경음은 예외로 인정한다. 배경음을 사용할 경우, 사용자가 손쉽게 멈춤, 일시 정지, 음량 조절 등을 제어할 수 있는 수단을 제공한다 ( 장애인 등 사용자 평가) 애플리케이션 개발 시 다양한 모바일 기기에서의 이용 가 능 여부를 점검해야 하며, 장애인 사용자 평가를 수행하는 것이 바람직하다. 애플리케이션의 출시 이전에 장애인, 고령자 등의 사용자를 대상으로 한 평가를 수행하 도록 한다. 사용자 평가는 무리한 부담이 되지 않는 시각 장애, 청각 장애, 뇌병변 장애, 지적 장애, 지체 장애, 고령 등의 사람들을 대상으로 실시한다. 모바일 애플리케이션 서비스 제공자는 해당 애플리케이션의 장애인 등 사용자 평가의 구체적인 결과를 별도로 공시하는 것이 바람직하다. 8

17 부 록 Ⅰ 모바일 애플리케이션 접근성 지침 사례 본 모바일 애플리케이션 접근성 지침 사례는 모바일 애플리케이션 개발자 및 운영자들 이 접근성을 고려하여 애플리케이션을 개발할 수 있도록 도움을 주기 위해 제공하는 것 이다. 본 표준에 포함된 준수 사항 7 개, 권고 사항 8 개에 대한 준수 필요성, 대표적인 기술 구현 방법, 구축 사례를 제공한다. Ⅰ.1. 준수 사항(7 개) 장애인이 비장애인과 동등하게 모바일 애플리케이션에 접근하여 이용하기 위해서 반드 시 준수해야 하는 사항 Ⅰ.1.1. 대체 텍스트 텍스트 아닌 콘텐츠는 대체 가능한 텍스트를 함께 제공해야 한다. Ⅰ 준수 필요성 시각장애인의 경우 모바일 기기나 모바일 화면 낭독 프로그램에서 제공하는 음성 읽기 기능(iOS VoiceOver, 안드로이드 Talkback, 심비안 및 윈도 모바일 6.5에서 활용되는 Code Factory사의 Mobile Speak 등) 을 활용하여 애플리케이션의 정보를 인식할 수 있 다. 하지만, 해당 애플리케이션에서 컨트롤 및 객체를 텍스트 아닌 콘텐츠로 제공하면서 대체 텍스트를 함께 제공하지 않으면 시각장애인은 잘못된 정보를 얻거나 전혀 정보를 얻을 수 없다. Ⅰ 기술구현 방법 이미지 등 텍스트 아닌 콘텐츠를 제공할 경우에는 반드시 대체 텍스트를 함께 제공해 야 한다. 대체 텍스트는 가능한 짧고 명확(Short & Clear) 하게 제공하는 것이 바람직하 며, VoiceOver, Talkback 등 모바일 스크린리더에서 기본적으로 제공해 주는 용어인 버 튼, 이미지, 레이블 등은 중복해서 제공하지 않는 것이 바람직하다( 웹 접근성 연구 소 버튼( ), 모바일 접근성 이미지( ), 금융자동화기기 접근성 레이블( ) 웹 접근성 연구소( ), 모바일 접근성( ), 금융자동화기기 접근성( )). 9

18 가. 애플의 ios에서 대체 텍스트 제공 방법 대체 텍스트를 제공하는 방법은 크게 2 가지 방법이 있다. 첫째, 애플에서 제공하는 Interface Builder 를 이용하여 대체 텍스트를 제공한다. 둘째, 대체 텍스트를 UIAccessibility API 등을 활용하여 직접 코드에 삽입하여 제공한다. 이러한 경우 Label과 Hint 라는 두 가지의 속성 값을 활용할 수 있는데, Label 로 대체 텍스트를 제공하고, Hint 는 추가적인 정보가 필요할 경우 제공한다. iphone에서 사용자가 VoiceOver 옵션에서 Hint 를 끌 수(Off) 있으므로 반드시 대체 텍스트는 Label 로 제공해야 한다. 예를 들면 뮤 직 플레이어의 멈춤 은 Label 에 적고 뮤직플레이어의 음악을 멈춥니다. 를 Hint에 적는 다면 시각장애인 등에게 도움이 될 것이다. < Interface Builder 화면 > < UIAccessibility 설정 화면 > 1) Interface Builder 이용 Interface Builder는 애플에서 제공하는 것으로 모바일 애플리케이션 개발 시 UI를 손 쉽게 만들 수 있도록 도와주는 도구이다. Interface Builder를 실행 시킨 다음 Attribute inspector 창에서 Label 속성에 대체 텍스트를 제공하면 된다. 또한, 애플에서는 접근성 준수여부를 손쉽게 점검할 수 있도록 Accessibility inspector 등을 제공하고 있다. 10

19 < Interface Builder 를 활용하여 버튼에 대체 텍스트를 제공하는 방법 > 대체 텍스트 제공 방법 1) Accessibility 속성을 반드시 활성화(Enabled) 시킨다. 2) Label 속성에 텍스트 아닌 콘텐츠의 의미와 정보를 동등하게 인식할 수 있도록 대체 텍스트 를 짧고 명확하게 제공한다. 3) 부가적인 설명이 필요할 경우에는 Hint 을 활용하여 추가적인 정보를 제공한다. 속성 < 참고 > Interface Builder는 Xcode 에 포함되어 제공되고 있다. 12년 2월말 현재 애플의 최신 개 발도구는 Xcode 4 이다( 2) UIAccessibility API 등을 활용하여 직접 코드에 삽입하는 경우 애플에서 제공하는 개발자 도구인 Interface Builder를 활용하지 않고 UI를 개발할 경 우에는 UIAccessibility API를 활용하여 Label 에 대체 텍스트를 제공한다. [housebutton setisaccessibilityelement:yes]; [housebutton setaccessibilitylabel:@" 멈춤"]; [housebutton setaccessibilityhint:@" 뮤직플레이어의 음악을 멈춥니다."]; 그러나, 보다 효율적인 개발 및 접근성을 제고하기 위해서는 애플에서 제공하는 Interface Builder 를 활용하여 개발하는 것이 바람직하다. 11

20 나. 구글의 안드로이드에서 대체 텍스트 제공 방법 안드로이드의 경우에도 UI에 대체 텍스트를 제공하는 방법은 2가지로 XML을 활용하 거나 또는 Java code 를 활용하는 방법이 있다. 안드로이드의 경우에는 android:contentdescription 속성을 사용하여 대체 텍스트를 제공해야 한다. " 웹 접근성 연구소 라는 버튼에 대체 텍스트를 제공하는 방법은 다음과 같다. 1) XML을 활용하여 버튼을 제공할 경우 <ImageButton /> layout/main.xml <xml <resources> version="1.0" encoding="utf-8"?> <string name="add_note"> 웹 접근성 연구소</string> </resources> values/strings.xml 2) Java code를 활용하여 버튼을 제공할 경우 Button add_entry_button = new Button(this); add_entry_ button.setcontentdescription(" 웹 접근성 연구소"); Ⅰ 구축 사례 이미지 등 텍스트 아닌 콘텐츠를 활용할 경우에는 반드시 대체 텍스트를 제공해야 한 다. 하지만 아래의 ** 은행의 예금조회/ 이체 화면의 사례처럼 대체 텍스트를 제대로 제 공하지 않을 경우, 시각장애인 등은 해당 애플리케이션을 이용하기 어렵다. ios VoiceOver 를 설정할 경우, 이전, 전예금조회 계좌이체 등의 상단 및 주 메뉴와 새 소식, 고객센터 등 하단 메뉴를 모두 버튼 으로 인식하게 되어 어떤 버튼이 어떤 기 능을 수행하는지 알 수 없게 된다. 해당 기능을 제대로 인식할 수 있도록 대체 텍스트를 제공할 필요가 있다. 12

21 <** 은행의 예금조회/ 이체 화면> < ios VoiceOver 설정시 예금조회/ 이체 화면 > 대체 텍스트를 미제공하여 예금조회/ 이체 의 모든 기능 을 제대로 활용하기 어려운 실정( 모든 것을 버튼 이라고 인식) < 상단 및 주 메뉴 > - 이전 버튼 - 전예금조회 버튼 - 계좌이체 버튼 등 < 하위 메뉴 > - 새 소식 버튼 - 고객센터 버튼 등 텍스트 아닌 콘텐츠에 대한 대체 텍스트 제공 여부에 대해서는 ios VoiceOver, 안드 로이드의 Talkback 등의 음성 읽기 기능을 활성화해 보면 쉽게 제공 여부를 평가해 볼 수 있다. 13

22 < 모바일 애플리케이션 접근성 우수 사례 - 청와대 아이폰용 애플리케이션 > 청와대에서는 장애인의 모바일 접근권 보장에 해외 선진사례 분석 및 장애인의 요구에 부응하여, 2011년 8 월부터 아이폰용 애플리케이션의 접근성 제고를 위한 작업을 수행하였다. 청와대에서는 8 월 11일과 8월 25일에 2 번에 걸친 판올림(update) 을 통하여 시각장애인 등의 정보 접근권을 크게 향상시켰다. 국내에서 모바일 애플리케이션 접근성 제고를 위한 우수 사례로 다음과 같은 개선이 이 루어졌다. 가 청와대 아이폰용 애플리케이션의 접근성 관련 판올림 현황(2 회) < 앱 접근성 제고 판올림 1 차(8.11) > < 앱 접근성 제고 판올림 2 차(8.25) > 나 청와대 모바일 애플리케이션의 개선 전과 개선 후의 비교 보이스 오버를 활용하여 음성을 출력할 경우 대체 텍스트를 제공하지 않아, 청와대 모바일 애플리 케이션의 첫 실행 화면의 정보를 얻을 수 없었으나, 대체 텍스트를 제공하여 동등한 정보를 인식할 수 있게 개선됨. < 공유버튼 안내 페이지 > < 접근성 개선 전 > a. 공유버튼 설명문은 이미지 로 출력 b. 안내문 버튼 설명 이미지 입력 창 으로 출력 c. 닫기 버튼은 버튼 이라고 출력 < 접근성 개선 후 > a. 공유버튼 설명문의 내용을 동등하게 음성으로 출력 : 청와대 스마트폰 애플리케이션을 ~ ( 중략) b. 안내문 버튼 설명을 동등하게 음성으로 출력 : 다음부터 이 안내문을 ~ ( 중략) c. 닫기 버튼 : 닫기 버튼 이라고 음성 출력 14

23 < 모바일 애플리케이션 접근성 우수 사례 - 청와대 아이폰용 애플리케이션( 계속) > 보이스 오버를 활용하여 음성을 출력할 경우 하단의 버튼에 대한 대체 텍스트를 제공하지 않았으 나, 대체 텍스트를 제공하여 동등한 정보를 인식할 수 있게 개선됨. < 하단 버튼 > < 접근성 개선 전 > a. 뉴스/ 브리핑 : " 버튼 이라고 출력 b. 영상/ 사진 : " 버튼 이라고 출력 c. 소셜미디어 : " 버튼 이라고 출력 d. 푸른누리 : " 버튼 이라고 출력 e. 관람 : " 버튼 이라고 출력 < 접근성 개선 후 > a. 뉴스/ 브리핑 : "뉴스, 브리핑 버튼 이라고 출력 b. 영상/ 사진 : "영상, 사진버튼 이라고 출력 c. 소셜미디어 : "소셜 미디어 버튼 이라고 출력 d. 푸른누리 : "푸른누리 버튼 이라고 출력 e. 관람 : "관람 버튼 이라고 출력 보이스 오버를 활용하여 음성을 출력할 경우 대체 텍스트를 제공하지 않아, 청와대 관람 정보를 얻 을 수 없었으나, 대체 텍스트를 제공하여 동등한 정보를 인식할 수 있게 개선됨. < 이미지 콘텐츠 영역 > < 접근성 개선 전 > 본문의 내용인 관람운영일, 관람운영일 설명, 신청대상, 신청대상 설명 등을 파악할 수 없음 : ***( 파일명) 이미 지 라고 출력 < 접근성 개선 후 > < 이미지에 대한 동등한 내용의 대체 텍스트 제공 > a. 관람운영일, 매주 화요일 ~ 금요일 ( 둘째주 토요일) 토요일은 10 인 이하의 개인/ 가족에 한함 으로 음성 출력 b. " 신청대상, 초등학생 이상 미취학자녀 관람은 가 족 동반만 가능 으로 음성 출력 15

24 Ⅰ.1.2. 초점 모든 객체에는 초점(focus) 이 적용되고, 초점은 순차적으로 이동되어야 한다. Ⅰ 준수 필요성 초점이 적용되지 않으면 모바일 기기나 모바일 화면낭독 프로그램에서 제공하는 음성 읽기 기능(iOS VoiceOver, 안드로이드 Talkback, 심비안 및 윈도 모바일 6.5에서 활용되 는 Code Factory사의 Mobile Speak 등) 등을 활용하는 경우의 사용자는 정보를 얻거나 기능을 실행할 수 없는 문제가 발생한다. 또한 순차적으로 이동되지 않을 경우에는 시각 장애인, 수 있다. 지적장애인 등이 해당 애플리케이션의 기능과 정보의 이해에 어려움이 발생할 Ⅰ 기술 구현 방법 애플리케이션 개발 시 모든 객체에 초점이 적용되고, 수 있게 개발해야 한다. 적용된 초점은 순차적으로 이동할 가. 애플의 ios에서 초점 제공 방법 Accessibility 속성이 활성화(Enabled) 될 경우에만 해당 객체에 초점이 적용된다. ios 에서 제공하는 기본 사용자 인터페이스 컴포넌트(Native UI Component) 에서는 대부분의 기본 값이 활성화되어 제공된다. 하지만 ImageView UI 컴포넌트의 경우에는 Accessibility 속성이 비활성화(Disabled) 되어 있다. 만약 단순한 장식이 아니고 의미를 포함하는 이미지를 ImageView UI 컴포넌트를 활용하여 제공할 경우에는 Accessibility 속성을 활성화시켜야 하며, 대체 텍스트를 label 속성으로 반드시 제공해야 한다. ios 4.1 부터 초점의 순서를 제어 할 수 있는 기능을 제공하고 있다. 16

25 < 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" 안드로이드에서 초점의 이동 순서를 제어하기 위해서는 nextfocusdown, nextfocusup, nextfocusright, nextfocusleft 속성을 이용하면 된다. 17

26 Ⅰ 구축 사례 모든 컨트롤에 대하여 초점이 적용되어 있어야 하며, 각장애인 등이 활용할 수 있다. 논리적인 순서로 제공되어야만 시 < ** 은행의 로그인 화면 > < 문제점 및 해결 방안 > o 문제점 - VoiceOver 를 실행할 경우, 공인인증서 로그인, 비밀번호 입력창', ' 로그인 등에 초점이 가지 않아 애플리케이션 이용 이 불가능한 실정 * 비밀번호 입력 등이 불가능하여 로그인을 할 수 있는 방법 이 없음 - 공인인증서 로그인, 조회회원 가입, 로그인 등에 대체 텍스트도 미제공 * VoiceOver 를 사용할 경우, 공인인증서 로그인 의 정보가 dtm into 1 gif"로 출력되는 문제 발생 o 해결 방안 - 모든 버튼 및 정보에 초점이 적용될 수 있도록 제공해야 한다. - 모든 텍스트 아닌 콘텐츠에는 대체 텍스트를 제공해야 한 다. < ** 은행의 조회 화면 > < 문제점 및 해결 방안 > o 문제점 - 조회 라는 좌우로 스크롤 되는 메뉴가 나타나는데 이 부분에서는 초점이 전혀 생성되지 않는다. 이 메뉴를 통해 조회/ 이체 등을 선택한 후 하단에서 하위 메뉴로 진입해야 하는데 메인 메뉴에서 초점이 생성되지 않아 더 이상의 은행 업무 수행을 하는 것은 불가능함 o 해결 방안 - 조회 라는 메뉴에 초점이 적용될 수 있도록 제공하고, 하위 메뉴로 초점이 논리적으로 이동할 수 있도록 제공할 필 요가 있음 18

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

28 Ⅰ.1.3. 운영 체제 접근성 기능 지원 운영 체제가 제공하는 접근성 기능 및 속성이 지원되어야 한다. Ⅰ 준수 필요성 장애인 등의 모바일 애플리케이션 접근성을 보장하기 위해서는 각 운영 체제에서 제공 하는 접근성 기능을 활용해야 한다. 이를 활용하지 않을 경우에는 장애인이 활용하는 다 양한 모바일 기기, 모바일 보조 기기 등과 호환되지 않아 이용이 불가능할 경우가 발생 할 수 있다. Ⅰ 기술 구현 방법 애플의 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 20

29 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 등을 제공하고 있다. Ⅰ 구축 사례 운영 체제에서의 접근성 기능을 지원한 Twitter의 경우 SNS에서 제공하는 텍스트 정 보를 제대로 인식할 수 있으나, 국내의 모 SNS의 경우에는 운영 체제의 접근성 기능을 지원하지 않아 하고 있다. VoiceOver 기능 이용 시 아무런 텍스트 정보도 얻지 못하는 문제가 발생 < Twitter 애플리케이션( 운영체제 접근성 지원) > < **** 애플리케이션( 운영체제 접근성 미지원)> 21

30 Ⅰ.1.4. 누르기 동작 지원 모든 컨트롤은 누르기(touch or tap) 동작으로 제어할 수 있어야 한다. Ⅰ 준수 필요성 시각장애인의 경우 모바일 기기에서 가장 어려움을 많이 겪는 부분이 바로 컨트롤의 위치에 대한 부분이다. 특히 컨트롤을 이동해야 하는 경우나 컨트롤 간의 위치를 바꾸어 야 하는 경우 더욱 더 어려움에 처하게 된다. 예를 들어 모바일 애플리케이션을 이동하 여 폴더를 생성하는 경우나 전화 받기 기능 같은 경우 Drag 해야 해당 기능을 활용할 수 있는 경우가 있다. 그러므로 모든 컨트롤이나 Drag 등이 필요한 기능의 경우에는 반드시 이를 대체할 수 있는 수단인 누르기(touch or tap) 동작을 함께 제공해야 한다. Ⅰ 기술구현 방법 누르기 동작은 화면상의 객체를 손가락 끝으로 접촉하여 만지거나(touch) 가볍게 두드 리는(tap) 동작을 말하는 것으로, 모든 컨트롤 동작은 누르기 동작만으로도 제어할 수 있 어야 한다. 두 개의 손가락을 동시에 이용해야 하는 다중 누르기(Multi-touch) 동작이나 Slide, Drag and drop 는 방법이 제공되어야 한다. 등의 복잡한 누르기 동작은 단순한 누르기 동작으로 대체할 수 있 Ⅰ 구축 사례 모든 컨트롤은 누르기 동작으로 제어할 수 있도록 제공해야 한다. 사용자 편의성 제고 를 위해 다양한 UI 를 활용하는 것은 필요하나, 보다 중요한 것은 장애인 등 다양한 사용 자가 동등하게 이용할 수 있도록 개발하거나 해당 기능을 대체할 수 있는 수단을 제공하 는 등의 보편적 설계(Universal Design) 를 적용해야 한다. 22

31 < Slide 기능에 대한 대체 수단 제공 사례 ( 두 번 두드리기(double tap)) > < Slide 기능에 대한 대체 수단 미제공 사례 > 슬라이드 기능을 활 용하지 못할 경우, VoiceOver를 이용 할 경우에는 두 번 누르기(double tap) 으로 해당 기능 활 용 가능 슬라이드 기능을 활 용하지 못할 경우 대 체 수단을 제공하지 않아, talkback을 이 용하는 사용자의 경 우에는 전화 받기 기 능을 활용할 수 없음 Ⅰ.1.5. 색에 무관한 인식 화면에 표시되는 모든 정보는 색에 관계없이 인식할 수 있어야 한다. Ⅰ 준수 필요성 색맹 사용자의 경우 특정 색을 구별하지 못하는 경우가 있다. 그 대표적인 예로 적록 색맹의 경우 적색과 녹색을 구분하지 못함으로서 일상 생활에서 신호 등을 구분하지 못 하고 이로 인하여 운전면허 취득도 어렵다. 이와 마찬가지로 모바일 애플리케이션에서 정보를 색으로만 제공할 경우 색맹이나 색약자의 경우 이를 인지할 수 없다. Ⅰ 기술 구현 방법 색상으로 정보를 구분할 경우, 색상 이외의 다른 방법으로도 동등한 내용을 전달할 수 있도록 설계한다. 색 이외의 명암이나 텍스트, 특수 기호 등을 색과 함께 제공하여 해당 정보를 인식할 수 있도록 제공해야 한다. Ⅰ 구축 사례 오른쪽 아래의 그래프에서는 속도 값을 막대 그래프로 표현하는데 막대 그래프의 위 에 의미를 명확히 알 수 있도록 통신사명과 막대 그래프의 값을 텍스트로 제공하고 있어 서 그 의미를 이해하는데 도움을 주고 있다. 색을 구분하기 어려운 사용자더라도 제공되 는 텍스트 정보는 구분할 수 있기 때문에 그래프의 의미를 구분할 수 있다. 23

32 < 잘못된 사례 > < 올바른 사례 > Ⅰ.1.6. 명도 대비 화면에 표시되는 모든 정보는 전경색과 배경색이 구분될 수 있도록 최소 대비 이상으 로 제공되어야 한다. Ⅰ 준수 필요성 시각장애인 등은 모바일 기기를 사용할 경우 화면에 표시되는 전경색과 배경색간의 구 분이 잘 되지 않는 문제로 인하여 어려움을 겪는 경우가 많이 발생하고 있다. 특히 전경 색과 배경색이 흰색과 회색, 노란색과 오렌지색 등으로 유사한 색으로 되어 있는 경우 이를 인지하기 매우 어렵다. 따라서 전경과 배경을 명확하게 인식할 수 있도록 콘텐츠를 제공해야 한다. Ⅰ 기술 구현 방법 명도 대비는 화면의 배경색과 객체를 표시하는 데에 사용되는 전경색 사이의 명도 차 이의 비율(contrast) 을 말한다. 모든 정보의 최소 대비는 3:1 이상이어야 한다. 저시력인 에게 실효성을 가지기 위해서는 주 콘텐츠의 경우는 4.5:1 또는 7:1 이상이 되는 것이 바람직하다. 명도 대비를 높게 제공하기 어려운 경우에는 운영 체제에서 제공하는 명도 대비를 활용할 수 있도록 제공하거나 애플리케이션 내에서 명도 대비를 높일 수 있는 설 정 기능을 제공해야 한다. ios 4 의 경우에는 설정 일반 손쉬운 사용 검정색 바탕에 흰색 이라는 명도 대비 설정 기능을 제공하고 있다. 24

33 < 참고 : 색에 무관한 인식 관련 평가 도구 > Color Doctor Visual Impairment Simulator for Microsoft Windows Colour Contrast Analyser Colour Checker Color Selector adesigner Accessibility Color Wheel Ⅰ 구축 사례 ** 은행 애플리케이션에서 인증서 가져오는 동작을 하면 아래의 왼쪽 그림과 같이 4자 리의 숫자를 4번 입력하는 총 16 자리의 인증 번호가 나온다. 저 인증 번호는 PC에서 휴 대폰으로 인증서를 전송할 때 반드시 입력해야 하는데 모바일 화면에서 글씨/ 배경색의 대비가 충분하지 않기 때문에 저시력 시각장애인이 글씨를 읽는 것이 매우 힘들다. 이러 한 경우 단순히 글씨를 알아보기 어렵다는 것에 그치는 것이 아니라 동작을 수행할 수 없을 수도 있다. 저시력 사용자는 인증 번호를 아예 알아보지 못하거나 잘못 읽어서 인 증서를 휴대폰으로 전송하지 못하는 경우도 있다. 저시력 사용자에게 있어서 명도 대비 가 없는 이러한 인증 번호는 인증 번호로서의 목적을 전혀 달성하지 못하고 있는 것이 다. ** 모바일 고객센터에서 이용량을 보여주는 아래 오른쪽 그림을 살펴보면 그래프를 구분하는 왼쪽 라벨 부분에 문제가 있다. 라벨명인 사용일 수, 음성, 문자 메시지, 문자/ 멀티 메시지, MMS, 무선 인터넷 부분에서 배경색과 글자색의 대비가 충분하지 않아 저 시력 사용자는 글씨를 읽기가 매우 어렵다. 폰트 크기도 작은데다 글자색과 배경색이 대 비마저 낮아서 더 읽기가 어려운 상황이다. 라벨을 명확히 알아볼 수 없기 때문에 오른 쪽에 나오는 그래프의 의미를 이해하는데 어려움을 겪을 수밖에 없다. 25

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

35 Ⅰ 기술 구현 방법 멀티미디어 콘텐츠에는 동등한 내용의 자막, 원고 또는 수화를 제공해야 한다. 멀티미 디어 콘텐츠를 요약한 자막이나 원고는 불충분하며, 멀티미디어에서 제공하는 음성 정보 와 동등한 내용을 자막이나 원고로 제공해야 한다. 음성이 없이 동영상에 포함된 메시지 나 자막, 중요 단어에 대한 강조, 홍보 문구 등은 시각장애인이 전혀 확인할 방법이 없으 므로, 이러한 경우에는 반드시 화면 해설 서비스( 음성으로 메시지, 자막, 중요 단어 등을 제공) 를 제공해야 한다. 자막, 수화 또는 원고는 화면 상의 콘텐츠와 동기화하여 제공하 는 것이 바람직하다. Ⅰ 구축 사례 왼쪽 아래의 그림은 아이폰용 복지 TV 애플리케이션 의 사례이다. 본 애플리케이션에 서 제공하는 동영상의 경우 자막과 함께 수화를 동시에 제공하여 장애인의 접근성을 확 보한 우수 사례이다. < 올바른 사례( 복지 TV 애플리케이션) > < 잘못된 사례 ( 자막 미제공) > 27

36 Ⅰ.2. 권고 사항(8 개) 모바일 애플리케이션의 접근성 향상을 위하여 무리한 부담이 되지 않는 한 준수할 것 을 권장하는 사항을 말한다. Ⅰ.2.1. (Native UI Component) 운영 체제에서 제공하는 기본 사용자 인터페이스 컴포넌트(Native UI Component) 를 최대한 이용하는 것이 바람직하다. Ⅰ 준수 필요성 대부분의 운영 체제에서 제공하는 기본 사용자 인터페이스 컴포넌트(Native UI Component) 는 접근성을 고려하여 제공되고 있다. 애플리케이션 개발 시 비용과 시간 등 의 제약이 있는 경우 운영 체제에서 제공하는 기본 사용자 인터페이스 컴포넌트를 잘 활 용하는 것이 좋다. 이에 반해 사용자 변형 UI 컴포넌트(Custom UI Component) 를 사용 하는 경우에는 운영 체제에서 제공하는 VoiceOver 등이 동작하지 않을 수 있다. 그러므 로 최대한 기본 사용자 인터페이스를 활용하는 것이 바람직하다. Ⅰ 기술구현 방법 모바일 애플리케이션을 개발함에 있어 기본 사용자 인터페이스 컴포넌트를 최대한 활 용하는 것이 접근성을 높이는 데 도움이 된다. 가. 애플의 ios 에서 제공 방법 : Native UI Component에는 UIWindow, UILabel, UIPickerView 등이 있다. 특히 웹 페이지를 내장하는 페이지를 만들 경우에는 UIWebView 를 통해 작성을 하게 된다. 나. 구글의 안드로이드에서 제공 방법 : Native UI Component에는 View, ImageView 등이 있다. Ⅰ 구축 사례 대표적인 애플과 구글의 운영 체제에서 제공하는 과 같다. Native UI Component는 아래의 그림 28

37 < ios에서의 Native UI Component > < 안드로이드에서의 Native UI Component > entation/uikit/reference/uikit_framework/_inde x.html#//apple_ref/doc/uid/tp /widget/package-summary.html Ⅰ.2.2. 컨트롤 간 충분한 간격 컨트롤은 충분한 간격으로 배치하는 것이 바람직하다. Ⅰ.2.1. 준수 필요성 모바일 기기의 경우 터치를 통하여 컨트롤하기 때문에 터치의 정확성이 매우 중요하다. 터치의 정확성을 담보하기 위해서는 좌표값도 중요하지만 각 컨트롤간의 간격도 중요하 다. 비장애인도 각 버튼 간의 터치 간격이 좁게 되어 있고 버튼의 크기가 작으면 매우 불편한데 뇌성마비 장애인의 경우 손 떨림 등이 많이 있고 이로 인하여 정확한 터치 동 작을 취하기가 매우 어렵다. 따라서 터치 동작을 원활히 수행할 수 있도록 터치 간격을 적절히 유지하는 것이 매우 중요하다. 저시력인의 경우도 터치 타겟이 작을 경우 많은 어려움을 겪게 되는데 특히 중요한 결제 정보를 입력하거나 은행용 모바일 애플리케이션 을 사용하는 경우 실수로 잘못 터치하는 경우 되돌릴 수 없는 문제가 발생할 수 도 있 다. Ⅰ.2.2. 기술 구현 방법 좁은 화면 공간의 경우, 사용자의 의도와 무관하게 다른 컨트롤을 누르게 되는 문제가 발생할 수 있으므로, 이를 피하기 위해서 컨트롤 사이의 공간을 충분히 확보하여 사용자 가 컨트롤 영역을 명확히 구분할 수 있도록 하는 것이 바람직하다. 컨트롤 중심 간 간격 은 13 mm X 13 mm 이상을 권장한다. 선택해야 하는 컨트롤 영역의 크기는 8.5 mm X 8.5 mm 이상을 권장한다. 컨트롤의 터치 공간을 충분히 확보하여 사용자가 컨트롤 영역 을 명확히 구분할 수 있도록 제공하는 것이 좋다. 사용자의 의도에 따라 컨트롤을 확대 하여 사용할 경우 상대적인 크기로 커져서 손쉽게 활용할 수 있도록 제공하는 것이 좋 다. 한다. 쿼티 입력 등 운영 체제에서 제공하는 기본 사용자 인터페이스의 경우에는 예외로 29

38 Ⅰ.2.3. 알림 기능 사용자에게 알림을 제공할 때에는 진동, 시각, 소리 등 최대한 다양한 방법으로 사용자 가 선택할 수 있도록 제공하는 것이 바람직하다. Ⅰ 준수 필요성 한 가지 감각으로만 정보를 제공하는 경우에는 다양한 사용자가 이를 활용할 수 있다 고 보장하기 어렵다. 예를 들어 시력을 요하는 정보를 제공하거나 음성으로만 정보를 제 공하는 경우 시각장애인이나 청각장애인들은 이러한 정보를 인지할 수 없다. 따라서 알 림 정보 등을 제공하는 경우에는 소리나 화면 진동 등 다양한 방법을 동시에 사용하여 정보를 제공하는 것이 필요하다. Ⅰ 기술 구현 방법 사용자에게 알림을 제공할 때에는 한 가지 감각에만 의존하지 말고 다양한 감각이나 표현 방법을 통해 사용자가 원하는 알림 기능을 제공하는 것이 바람직하다. 사용자에게 다양한 방법으로 알림을 제공될 수 있도록 시각, 청각, 촉각 등의 피드백을 제공해야 하 며, 다양한 알림 기능을 제공할 경우 적절한 방법을 사용자가 선택할 수 있도록 제공하 는 것이 더 바람직하다. Ⅰ 구축 사례 페이스북 애플리케이션에서는 알림이 상당히 세분화 되어있다. 사용자가 자신에게 적 합한 방법으로 알림 정보를 진동, 소리 등으로 정보를 얻을 수 있도록 기능을 제공하고 있다. 또한 이러한 알림 정보는 가급적 운영 체제에서 제공하는 Native UI를 활용하는 것 이 바람직하다. 30

39 < 페이스북의 알림 설정 화면 > < 운영체제에서 제공하는 Native UI 알림기능 사용 예 > Ⅰ.2.4. 범용 폰트 이용 폰트의 크기 조절, 확대 기능을 제공하거나 운영 체제에서 제공하는 관련 기능을 활용 할 수 있는 방법을 제공하는 것이 바람직하다. Ⅰ 준수 필요성 저시력 인, 고령자 등은 일반 PC보다 화면이 적은 모바일 기기를 활용함에 있어 작은 화면으로 인해 정보를 인식하는데 어려움을 겪는다. 저시력인이나 고령자 등도 동등하게 모바일 애플리케이션을 이용할 수 있기 위해서는 폰트를 바꾸거나 폰트의 크기 등을 조 절하여 자신에게 적합한 방법으로 애플리케이션을 이용할 수 있어야 한다. Ⅰ 기술 구현 방법 절대 폰트를 사용하지 말고, 사용자 선택에 따라 폰트의 크기를 변화시킬 수 있도록 제 공하는 것이 바람직하다. 시스템이나 사용자가 선택한 환경(Setting) 을 그대로 상속 (Inherit) 할 수 있도록 제공해야 한다. 범용 폰트(Global Font) 는 운영 체제에 내장되어 확대나 축소, 기울임 등의 변형 형태가 제공되는 글자체를 말한다. 모든 애플리케이션 화 면에서 폰트 크기의 조절이 가능하도록 설계하거나, 최소한 확대 기능을 제공한다. 폰트 크기 조절을 용이하게 하기 위해서는 텍스트 이미지보다 폰트가 지정되어 있는 텍스트를 사용하는 것이 바람직하다. 폰트의 확대 시 텍스트의 내용이나 기능의 손실 없이 최소 200% 까지 확대될 수 있도록 제공하는 것이 좋다. 또한 별도의 폰트를 사용하는 경우 사 용자가 인지하기 어렵게 되는 경우가 발생할 수 있으니 운영 체제에서 제공하는 글로벌 폰트를 이용하는 것이 바람직하다. 31

40 가. 애플의 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: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: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:Trebuchet-BoldItalic Font:TrebuchetMS-Bold Font Family: Verdana Font:Verdana-Bold Font:Verdana-BoldItalic Font:Verdana Font:Verdana-Italic Font Family: Zapfino Font:Zapfino 32

41 나. 구글의 안드로이드에서 제공되는 글로벌 폰트 종류( 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" Ⅰ 구축 사례 트위터, ibooks 애플리케이션에서는 저 시력자 등을 위해 폰트의 크기 조절 기능을 설 정할 수 있도록 제공하고 있다. < 트위터의 글자크기 설정 화면 > < ibooks 폰트 크기 및 서체 설정 화면 > Ⅰ.2.5. 사용자 인터페이스의 일관성 사용자 인터페이스 요소들의 배치를 일관성 있게 제공하는 것이 바람직하다. Ⅰ 준수 필요성 저 시력 인이나 고령자 등 화면을 확대하는 사용자의 경우에는 전체 화면이 아니라 창 의 일부 영역을 화면에 확대하여 이용한다. 따라서 애플리케이션 창마다 내비게이션 컨 트롤의 위치와 모양이 다르다면 새로운 애플리케이션 창으로 이동할 때마다 사용법을 익 히는 데 많은 어려움이 있을 것이다. 또한 지적 장애인의 경우 방문한 웹 페이지별로 메 뉴와 내비게이션 컨트롤의 위치나 모양이 바뀌게 되면 사용자는 이들 웹 페이지를 동일 한 웹 사이트가 제공하는 웹 페이지로 인식하기보다는 새로운 웹 사이트가 제공하는 웹 페이지로 인식할 가능성이 높다. 이에 일관성 있는 사용자 인터페이스를 제공하는 것이 바람직하다. 33

42 Ⅰ 기술 구현 방법 사용자 경험(User Experience) 에 비추어 일관성 있는 사용자 인터페이스(UI) 요소를 제 공하는 것이 바람직하다. 사용자 인터페이스를 구성하고 있는 요소들( 폰트, 크기, 화면 색상, 링크 제공 방법, 이모티콘 등) 을 사용자가 다시 학습하지 않아도 되도록 해당 애플 리케이션 내에서 일관성 있게 제공하는 것이 바람직하다. Ⅰ 구축 사례 *** 영화관 모바일 애플리케이션으로 예약 시간을 선택하는 선택 창과 인원 및 좌석 을 선택하는 창이 일관성 없이 제공되어 있어 사용자에게 혼란을 주는 사례이다. < 일관성 없는 입력 서식 제공 사례 (ios Native UI Component ( 좌측), Custom UI Component ( 우측) > 34

43 Ⅰ.2.6. 깜빡거림의 사용 제한 광과민성 발작을 일으킬 수 있는 콘텐츠를 제공하지 않는 것이 바람직하다. Ⅰ 준수 필요성 깜빡이거나 번쩍이는 콘텐츠를 제공할 경우 특정 사용자에게 광과민성 발작을 일으킬 우려가 있다. 예를 들어 일본에서 방영된 만화 영화인 포켓몬에서 깜빡임과 번쩍임이 과 도하게 제공되어 아동들이 병원에 가서 치료를 받았던 사례가 있다. 그러므로 깜박임과 번쩍임이는 효과로 정보를 제공하기 보다는 효과적인 디자인 등을 통해 모바일 애플리케 이션의 정보를 제공하는 것이 바람직하다. Ⅰ 기술 구현 방법 깜빡이거나 번쩍이는 콘텐츠를 제공해야만 할 경우 초당 3-50회 주기는 피해서 제공 하는 것이 좋다. 깜빡이거나 번쩍이는 콘텐츠를 사용해야 할 경우, 사전에 경고를 하고 깜빡임이나 번쩍임을 회피할 수 있는 수단을 제공하는 것이 바람직하다. 이러한 콘텐츠 는 깜빡이는 배경이나 텍스트, 꺼지고 켜짐을 반복적으로 수행하는 그래픽, 또는 다른 여 러 이미지를 반복적으로 보여주는 모든 것들을 포함한다. Ⅰ.2.7. 배경음 사용 금지 자동으로 재생되는 배경음을 사용하지 않는 것이 바람직하다. Ⅰ 준수 필요성 시각장애인의 경우 모바일 기기나 모바일 화면 낭독 프로그램에서 제공하는 음성 읽기 기능(iOS VoiceOver, 안드로이드 Talkback, 심비안 및 윈도우 모바일 6.5에서 활용되는 Code Factory사의 Mobile Speak 등) 을 활용하여 모바일 애플리케이션을 이용한다. 이러 한 기능들은 기본적으로 음성을 통하여 정보를 제공하고 있다. 이에 따라 애플리케이션 을 실행하였을 때 배경음이 자동적으로 나오게 되면 음성으로 정보를 정확히 전달받을 수 없다. 따라서 이러한 배경음이 필요한 경우 이에 대한 알림 정보를 제공하고, 사용자 가 선택할 경우에만 실행이 되도록 제공하는 것이 바람직하다. 35

44 Ⅰ 기술 구현 방법 자동으로 재생되는 배경음( 동영상, 음성, 음악 등) 을 사용하지 않는 것이 바람직하다. 단, 3 초 미만의 배경음은 예외로 한다. 배경음을 사용할 경우, 반드시 배경음을 제어할 수 있는 수단( 멈춤, 일시 정지, 음량 조절 등) 이나 배경음 제어로 이동하는 링크를 애플 리케이션 첫 부분에 제공하는 것이 좋다. 또한 음량 조절은 운영 체제에서 제공하는 음 량과 독립적으로 배경음만 조절할 수 있도록 제공하는 것이 더 좋다. Ⅰ 구축 사례 ** 자동차 회사에서 제공하는 모바일 애플리케이션으로 시작화면부터 사용자가 선택 하지 않았음에도 불구하고 배경음이 자동적으로 흘러나오고 있다. 이를 해지하기 위해서 는 설정 메뉴로 들어가서 음악과 효과음을 줄여야만 정지되는 형태로 시각 사용자 등에 게 혼란을 주는 사례이다. < 자동 배경음을 사용한 잘못된 사례 > < 해결 방안 > 동영상을 사용자의 선택에 의해 활성화되도록 제 공하는 것이 바람직하다. 배경음을 제공할 경우에는 반드시 애플리케이션 첫 부문에 이를 정지할 수 있는 기능을 제공하는 것이 바람직하다. 36

45 Ⅰ.2.8. 장애인 사용자 평가 애플리케이션 개발 시 다양한 모바일 기기에서의 이용 가능 여부를 점검해야 하며, 애인 테스트를 수행하는 것이 바람직하다. 장 Ⅰ 준수 필요성 모바일 애플리케이션을 개발함에 있어 앞에서 말한 모든 표준 항목을 준수하여 개발하 였다 하더라도 장애인 사용자가 실제로 사용할 수 있는지 점검하는 것이 중요하다. 이는 장애인이 가지고 있는 특성에 대한 이해의 차이 때문에 실제로는 접근성 표준을 지켜도 장애인이 사용하기 어려울 수 있기 때문이다. 또한 사용자는 모바일 애플리케이션을 다 양한 모바일 기기를 활용하여 접근할 것이다. 이에 가급적 많은 모바일 기기를 활용하여 애플리케이션의 정보 접근 및 기능 가능여부를 사전에 점검하는 작업을 하는 것이 필요 하다. Ⅰ 준수 방법 기획 단계부터 해당 애플리케이션에 대해 장애인 사용자 평가를 수행하는 것이 바람직 하다. 시각, 청각, 상지 장애 등의 다양한 장애인 사용자를 대상으로 하는 것이 좋으며, 고령자도 포함하는 것이 좋다. 또한 모바일 애플리케이션 개발자, 운영자 등도 운영 체제 에서 제공하는 애플의 VoiceOver, 구글의 TalkBalk 등을 활용하여 지속적으로 점검하는 것이 바람직하다. 37

46 표준 작성 공헌자 표준 번호 : 이 표준의 제정 개정 및 발간을 위해 아래와 같이 여러분들이 공헌하였습니다. 구 분 성 명 위원회 및 직위 연락처 (Tel, ) 소속사 과제 제안 현준호 웹 프로젝트그룹 부의장 표준 초안 제출 현준호 이성일 권오채 이순호 이건복 조용규 김요한 강완식 김정호 홍경순 웹 프로젝트그룹 부의장 교수 수석연구원 매니저 대표이사 대표이사 과장 센터장 이사 부장 표준초안 에디터 현준호 웹 프로젝트그룹 부의장 표준 초안 검토 jhyun22@nia.or.kr jhyun22@nia.or.kr silee@skku.edu ochae.kwon@samsung.com soonho@sktelecom.com keon@dotnetxpert.com 한국정보화진흥원 한국정보화진흥원 성균관대학교 삼성전자 SK 플래닛 닷넷엑스퍼트 choco@conoz.com 코노즈 hiphapis@gmail.com 옥시젠컴퓨팅 indra77@hitel.net 한국시각장애인연합회 jeffree@xvtech.com 엑스비전테크놀러지 kshong@nia.or.kr 한국정보화진흥원 jhyun22@nia.or.kr 한국정보화진흥원 이승윤 웹 프로젝트그룹 의장 syl@etri.re.kr 한국전자통신연구원 외 프로젝트그룹 위원 표준안 심의 사무국 담당 박승민 기반SW 기술위원회 의장 minpark@etri.re.kr 한국전자통신연구원 외 기술위원회 위원 김영화 - ykim@tta.or.kr TTA 김영재 - yjkim@tta.or.kr TTA 38

47 정보통신단체표준( 국문표준) 모바일 애플리케이션 접근성 지침 (Mobile Application Accessibility Guidelines) 발행인 발행처 : : 한국정보통신기술협회 회장 한국정보통신기술협회 , 경기도 성남시 분당구 서현동 발행일 : Tel : , Fax :