v1.32

Transcription

1 개정일: 2015년 12월 16일 T T A S t a n d a r d 모바일 애플리케이션 콘텐츠 접근성 지침 2.0 Mobile Application Content Accessibility Guidelines 2.0

2 제정일 : 2015년 12월 16일 모바일 애플리케이션 콘텐츠 접근성 지침 2.0 Mobile Application Content Accessibility Guidelines 2.0 본 문서에 대한 저작권은 TTA에 있으며, 이 문서의 전체 또는 일부에 대하여 상업적 이익을 목적으로 하는 무단 복제 및 배포를 금합니다. Copyrightc Telecommunications Technology Associations All Rights Reserved. ii

3 서 문 1. 표준의 목적 본 표준은 장애인, 고령자 등이 비장애인과 동등하게 모바일 애플리케이션 콘텐츠에 접 근할 수 있도록 모바일 애플리케이션 콘텐츠를 제작할 때 준수해야 하는 지침들에 관해 기술하고 있다. 본 표준은 특정 모바일 운영 체제나 기기에 한정을 두고 개발한 것이 아 니며, 다양한 운영 체제에서 활용될 수 있는 지침으로 개발 되었다. 2. 주요 내용 요약 본 표준은 모바일 애플리케이션 콘텐츠의 접근성 확보를 위하여 준수해야 할 19개 항 목으로 구성되었다. 또한 개발자, 서비스 기획자 등이 참고할 수 있도록 모바일 애플리케 이션 접근성 지침을 고려한 사례를 부록으로 제공한다. 3. 표준 적용 산업 분야 및 산업에 미치는 영향 본 표준은 모바일 애플리케이션 콘텐츠서비스 개발자 및 제공자가 장애인, 고령자 등 의 접근성을 보장하기 위해 모바일 애플리케이션 제작 시 지켜야 할 사항을 규정한 것으 로, 국내 모바일 애플리케이션 콘텐츠 관련 산업 및 정책 전반에 영향을 미칠 것이며 장 애인 등 취약계층이 동등하게 모바일 애플리케이션 콘텐츠를 이용할 수 있는 환경 조성 에 기여할 것이다. 4. 참조 표준(권고) 4.1. 국외 표준(권고) - W3C First Public Working Draft, Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile, 국내 표준 - 해당 사항 없음. 5. 참조 표준(권고)과의 비교 5.1. 참조 표준(권고)과의 관련성 iii

4 - 해당 내용 없음 참조한 표준(권고)과 본 표준의 비교표 Mobile Accessibility 비고 2. 1: 인식의 용이성 6. 인식의 용이성 수정 6.1. 대체 텍스트 신설 6.2. 자막, 수화 등의 제공 신설 6.3. 색에 무관한 인식 신설 2.3 명도 대비 6.4. 명도 대비 수정 6.5. 명확한 지시사항 신설 6.6. 알림 기능 신설 3. 2: 운용의 용이성 7. 운용의 용이성 수정 7.1. 초점 신설 3.3 터치스크린 제스처 7.2. 누르기 동작 지원 수정 7.3. 응답시간 조절 신설 7.4. 정지기능 제공 신설 3.2 터치 타겟 사이즈와 간격 7.5. 컨트롤의 크기와 간격 수정 4. 3: 이해의 용이성 8. 이해의 용이성 수정 4.2 일관된 레이아웃 4.4 같은 기능을 구현하는 동작 요소들 그룹핑 8.1. 입력 도움 신설 8.2. 사용자 인터페이스의 일관성 수정 8.3. 깜박거림의 사용 제한 신설 8.4. 자동재생 금지 신설 8.5. 예측가능성 수정 5. 4: 견고성 9. 견고성 수정 2.2 줌 및 확대 9.1. 폰트 관련 기능의 활용 수정 3.1 터치스크린 기기의 키보드 콘트롤 5.3 플랫폼의 특징적 기능 지원 9.2. 보조기술과의 호환성 수정 10. 접근성의 사용자 평가 권고 신설 6. 지식 재산권 관련 사항 본 표준의 지식 재산권 확약서 제출 현황은 TTA 웹사이트에서 확인할 수 있다. 본 표준을 이용하는 자는 이용함에 있어 지식 재산권이 포함되어 있을 수 있으므로, 확인 후 이용한다. iv

5 본 표준과 관련하여 접수된 확약서 이외에도 지식 재산권이 존재할 수 있다. 7. 시험 인증 관련 사항 7.1. 시험 인증 대상 여부 - 해당 사항 없음 시험 표준 제정 현황 - 해당 사항 없음. 8. 표준의 이력 정보 8.1. 표준의 이력 판수 제정 개정일 제정 개정 내역 제 1 판 제 2 판 제정 TTAK.KO 개정 8.2. 주요 개정 사항 TTAK.KO 비고 1. 개요 1. 개요 수정 2. 표준의 구성 및 범위 2. 표준의 구성 및 범위 수정 3. 참조 표준(권고) 3. 참조 표준(권고) 수정 4. 용어 정의 4. 용어 정의 수정 5. 모바일 애플리케이션 접근성 준수 사항 5. 모바일 애플리케이션 콘텐츠 접 근성 준수 사항 수정 v

6 TTAK.KO 비고 - 6. 인식의 용이성 신설 5.1 대체 텍스트 6.1. 대체 텍스트 수정 5.7 자막, 수화 등의 제공 6.2. 자막, 수화 등의 제공 수정 5.5 색에 무관한 인식 6.3. 색에 무관한 인식 수정 5.6 명도 대비 6.4. 명도 대비 수정 명확한 지시사항 신설 6.3 알림 기능 6.6. 알림 기능 수정 - 7. 운용의 용이성 신설 5.2 초점 7.1. 초점 수정 5.4 누르기 동작 지원 7.2. 누르기 동작 지원 수정 응답시간 조절 신설 정지기능 제공 신설 6.2 컨트롤 간 충분한 간격 7.5. 컨트롤의 크기와 간격 수정 - 8. 이해의 용이성 신설 입력 도움 신설 6.5 사용자 인터페이스의 일관성 8.2. 사용자 인터페이스의 일관성 수정 6.6 깜박거림의 사용 제한 8.3. 깜박거림의 사용 제한 수정 6.7 배경음 사용 금지 8.4. 자동재생 금지 수정 8.5. 예측가능성 신설 9. 견고성 신설 6.4 범용 폰트 이용 9.1. 폰트 관련 기능의 활용 수정 6.1 기본 사용자 인터페이스 컴포넌트 9.2. 보조기술과의 호환성 수정 6.8 사용자 평가 10. 접근성의 사용자 평가 권고 수정 vi

7 Preface 1. Purpose of Standard The standard is to describe the methods of developing mobile application which everyone, including persons with disabilities and the elderly, can access. Especially, the standard helps mobile application developers, designers and providers make mobile application accessible. 2. Summary of Contents The standard describes recommendations(18 items) that improve the accessibility of mobile application. Also, the standards provides development methods and actual cases considering accessibility guidelines on the Appendix Ⅰ. 3. Applicable Fields of Industry and its Effect The 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 5. Relationship to Reference Standards(Recommendations) 5.1. Relationship of Reference Standards(Recommendations) - W3C First Public Working Draft, Mobile Accessibility : How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile, vii

8 5.2. Differences between Reference Standard(Recommendation) and this Standard Mobile Accessibility Remarks - 1. Introduction added - 2. Scope of this standard added - 3. Reference Standards added - 4. Terms and Definitions added - 5. Requirements on Mobile Application Accessibility added 2. 1: Perceivable 6. Perceivable Modified Alternative Text added Caption or Sign language added Color added 2.3 Contrast 6.4. Contrast Modified Clear indications added Alert added 3. 2: Operable 7. Operable Modified Focus added 3.3 Touchscreen Gestures 7.2. Touch and Tap Modified Timing adjustable added Pause and Stop added 3.2 Touch Target Size and Spacing 7.5. Control Target Size & spacing Modified 4. 3: Understandable 8. Understandable Modified 8.1. Input assistance added 4.2 Consistent Layout 8.2. User Interface Consistency Modified Flickering added Audio Control added 4.4 Grouping operable elements that perform the same action 8.5. Predictable Modified 5. 4: Robust 9. Robust added 2.2 Zoom/Magnification 9.1. Global Font Setting Modified 3.1 Keyboard Control for Touchscreen Devices 5.3 Support the characteristic properties of the platform 9.2. Interoperability with assistive technology(at) Modified 6. Statement of Intellectual Property Rights IPRs related to the present document may have been declared to TTA. The viii

9 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 Testing and Certification 7.1. Object of Testing and Certification - None 7.2. Standards of Testing and Certification - None 8. History of Standard 8.1. Change History Edition Issued date Outline The 1st edition The 2nd edition Established TTAK.KO Revised 8.2. Revisions ix

10 TTAK.KO Remarks 1. Introduction 1. Introduction Modified 2. Scope of this standard 2. Scope of this standard Modified 3. Reference Standards 3. Reference Standards Modified 4. Terms and Definitions 4. Terms and Definitions Modified 5. Requirements on Mobile Application Accessibility 5. Requirements on Mobile Application Accessibility Modified - 6. Perceivable Added 5.1 Alternative Text 6.1. Alternative Text Modified 5.7 Caption or Sign language 6.2. Caption or Sign language Modified 5.5 Color 6.3. Color Modified 5.6 Contrast 6.4. Contrast Modified Clear indications added 6.3 Alert 6.6. Alert Modified - 7. Operable added 5.2 Focus 7.1. Focus Modified 5.4 Touch and Tap 7.2. Touch and Tap Modified Timing adjustable added Pause and Stop added 6.2 Control Target Size 7.5. Control Target Size & spacing Modified - 8. Understandable added Input assistance added 6.5 User Interface Consistency 8.2. User Interface Consistency Modified 6.6 Flickering 8.3. Flickering Modified 6.7 Audio Control 8.4. Audio Control Modified 8.5. Predictable added 9. Robust added 6.4 Global Font Setting 9.1. Global Font Setting Modified 6.1 Native User Interface Components 9.2. Interoperability with assistive technology(at) Modified 6.8 User Testing 10. User Testing Modified Appendix I. Case Studies on Mobile Application Accessibility Guidelines 5.3 Accessibility Functions of Operating Systems Appendix I. Related documents Appendix Ⅱ. Case Studies on Mobile Application Accessibility Guidelines added Modified - Deleted x

11 목 차 1. 개 요 1 2. 표준의 구성 및 범위 1 3. 참조 표준(권고) 1 4. 용어 정의 및 약어 1 5. 모바일 애플리케이션 콘텐츠 접근성 준수 사항 4 6. 인식의 용이성 대체 텍스트 자막, 수화 등의 제공 색에 무관한 인식 명도 대비 명확한 지시사항 알림 기능 5 7. 운용의 용이성 초점 누르기 동작 지원 응답시간 조절 정지기능 제공 컨트롤의 크기와 간격 6 8. 이해의 용이성 입력 도움 사용자 인터페이스의 일관성 깜박거림의 사용 제한 자동재생 금지 예측가능성 7 9. 견고성 폰트 관련 기능의 활용 보조기술과의 호환성 접근성의 사용자 평가 권고 8 부록 I. 참고문헌 9 부록Ⅱ. 모바일 애플리케이션 콘텐츠 접근성 지침 사례 10 xi

12 Contents 1. Introduction 1 2. Constitution and Scope 1 3. Reference Standards(Recommendations) 1 4. Terms and Definitions 1 5. Requirements on Mobile Content Application Accessibility 4 6. Perceivable Alternative Text Caption or sign language Color Contrast Clear indications Alert 5 7. Operable Focus Touch and Tap Timing adjustable Pause and Stop Control Target Size and spacing 6 8. Understandable Input assistance User Interface Consistency Flickering Audio control Predictable 7 9. Robust Usage of Font related functions Interoperability with assistive technology (AT) User Testing 8 Appendix I. Related documents 9 Appendix Ⅱ. Case Studies on Mobile Application Accessibility Guideline 10 xii

13 모바일 애플리케이션 콘텐츠 접근성 지침 2.0 (Mobile Application Content Accessibility Guidelines 2.0) 1. 개요 본 표준은 장애인, 고령자 등이 비장애인과 동등하게 모바일 애플리케이션 콘텐츠에 접 근할 수 있도록 모바일 애플리케이션 콘텐츠 제작할 때 준수해야 하는 지침들에 관해 기 술하고 있다. 본 표준은 특정 모바일 운영 체제나 기기에 한정을 두고 개발한 것이 아니 며, 다양한 운영 체제에서 활용될 수 있는 지침으로 개발 되었다. 본 표준은 원칙, 지침의 2 단계로 구성되어 있다. 본 지침을 준수할 경우, 장애인, 노 인 등이 동등하게 모바일 애플리케이션 콘텐츠에서 제공하는 콘텐츠를 인식하고, 이를 운영하고 이해할 수 있다. <표 1-1> 모바일 애플리케이션 콘텐츠 접근성 지침 2.0 개요 원 칙 지 침 4 개 18개 애플리케이션의 모든 컴포넌트는 운영체제에서 제공하는 접근성 기능이 지원 활용될 수 있도록 설계되어야 한다. 만약 현재의 기술 수준으로 본 표준의 적용이 불가능한 경 우, 동등한 대체수단을 제공하거나, 적용 대상의 예외로 할 수 있다. 본 표준은 한국정보화진흥원이 학계, 연구계, 장애인단체, 관련 기업 등의 전문가로 위 원회를 구성하여 개발된 것이다. 2. 표준의 구성 및 범위 본 표준은 모바일 애플리케이션 콘텐츠를 구축, 운영, 개선 및 유지 보수할 경우에 적 용하는 것으로, 본 표준이 적용되는 범위는 모바일 전화기, 태블릿기기 등 모바일 기기에 서 실행되는 모든 애플리케이션 및 콘텐츠이다. 본 표준은 제3자가 제공하는 서비스를 제외하고 모바일 콘텐츠 서비스 제공자가 직접 제공하는 콘텐츠로 한정한다 3. 참조 표준(권고) 1

14 W3C First Public Working Draft, Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile, 용어 정의 및 약어 4.1. 접근성 장애인, 고령자 등을 포함한 모든 사람이 모바일 기기를 사용하여 모바일 애플리케이 션 콘텐츠를 이용할 수 있는 가능성 4.2. 모바일 기기 입력 및 출력기능이 있고 무선 인터넷 서비스를 사용 할 수 있는 휴대용 기기 가. 운영체제를 갖는 모바일 전화기 나. 운영체제를 갖는 태블릿 기기 4.3. 모바일 애플리케이션 콘텐츠 모바일 플랫폼 개발언어로 제작된 응용프로그램 및 콘텐츠 4.4. 서비스 제공자 모바일 기기를 이용하여 콘텐츠 및 서비스를 제공하는 공공기관 및 사업자 4.5. 무리한 부담(Undue Burden) 현재 가능한 기술 수준과 적절한 비용으로 실현시킬 수 있는 정도 이상의 노력을 요 구함 4.6. 보조기술 장애인의 신체적 인지적 기능을 증진, 보완, 향상시키기 위하여 사용하는 기기, 장비 의 일부분, 시스템 또는 소프트웨어 4.7. 대체 텍스트 이미지의 표현 또는 이미지를 설명하는 텍스트 2

15 4.8. 명도 대비 화면의 배경색과 사용자 인터페이스 컴포넌트 및 텍스트를 표시하는 데에 사용되는 전경색 사이의 명도 차이의 비율(contrast) 4.9. 초점 화면상의 선택된 사용자 인터페이스 컴포넌트의 내용을 화면 낭독 프로그램 등의 보 조기술을 통해 이용할 수 있도록 도와주는 기능. 선택된 사용자 인터페이스 컴포넌트 는 초점이 적용되고, 초점은 화면상에서 테두리나 하이라이트로 표시됨 누르기 동작 화면상의 사용자 인터페이스 컴포넌트를 손가락 끝으로 접촉하여 만지거나 (touch) 가볍게 두드리는(tap) 동작 컨트롤(control) 버튼 또는 위젯과 같이 사용자 인터페이스 화면에서 누르기 동작으로 기능을 활성화 시키는 사용자 인터페이스 컴포넌트 폰트 관련 기능 운영체제에 내장되어 확대/축소, 기울임, 색변환, 음영 등의 변형 형태가 제공되어 보 조기술(스크린리더 등)이 처리할 수 있는 기능 기본 사용자 인터페이스 컴포넌트 사용자 인터페이스 구성에 사용되는 표준 도구(대화상자, 버튼과 체크박스, 타이틀바 등) 팝업 사용자의 동작에 의하여 문맥에 따라 나타나는 정보 팬 손가락을 댄 후, 손을 떼지 않고 계속적으로 끄는(Drag) 움직임 3

16 4.16. 지시사항 사용자 인터페이스에서 무엇을 하거나 사용하는데 필요한 자세한 설명 객체 사용자 인터페이스에서 시스템의 구성 요소가 아이콘과 같은 화면상에 표시되는 가시 적 실체에 의해 표현되는 것 5. 모바일 애플리케이션 콘텐츠 접근성 준수 본 표준은 WCAG 2.0(Web Content Accessibility Guidelines 2.0)에서 제시하고 있는 접근성 설계의 4가지 원칙-인식의 용이성, 운용의 용이성, 이해의 용이성, 견고성-을 기 준으로, 접근성 있는 모바일 애플리케이션 콘텐츠의 설계 및 개발을 위한 지침을 제시하 고 있다. 본 표준을 모두 준수한 경우에도 학력, 장애 유형과 정도(장애의 중복 또는 장애의 경 중 등), 모바일 기기 사용 경험, 보조 기술 이용 능력 등에 따라 모바일 애플리케이션 콘 텐츠에 대한 접근이 불가능한 경우가 발생할 수도 있다. 그렇기 때문에 장애인 및 노인 등을 대상으로 하는 모바일 정보화 교육이 필요하며, 장애인에게는 맞춤형 보조 기술을 제공할 필요가 있다. 6. 인식의 용이성 인식의 용이성은 사용자가 장애유무 등에 관계없이 애플리케이션의 모든 콘텐츠를 동 등하게 인식할 수 있도록 제공하는 것을 의미한다 (대체 텍스트) 텍스트 아닌 콘텐츠는 대체 가능한 텍스트와 함께 제공되어야 한다. 1. 텍스트 아닌 콘텐츠에 대한 대체 텍스트는 그 의미나 기능을 동등한 수준으로 짧고 명확하게 제공해야 한다. [참고] 이미지의 대체 텍스트 작성 지침 (TTAK.KO ) 6.2. (자막, 수화 등의 제공) 영상이나 음성 콘텐츠에는 동등한 내용의 자막, 원고 또는 수화가 제공되어야 한다. 1. 영상이나 음성 콘텐츠 내 제공되는 모든 음성정보는 동등한 내용의 자막, 원고, 수 화 중 적어도 하나 이상을 제공해야 한다. 2. 영상이나 음성 콘텐츠에서 화면에 문자정보가 의미를 가지고 있는 경우 이를 설명 4

17 하는 별도의 음성 콘텐츠나 원고를 제공해야 한다. 3. 자막, 원고 또는 수화는 재생되고 있는 영상이나 음성 콘텐츠와 동기화하여 제공한 다. 단, 실시간으로 제공되는 영상이나 음성 콘텐츠의 경우는 실시간 자막 또는 수 화로 제공할 수 있다. 5. 음성이나 문자정보 없이 제공되는 영상이나 음성 콘텐츠는 이를 설명하는 화면해설 을 제공하는 것이 바람직하다 (색에 무관한 인식) 화면에 표시되는 모든 정보는 색에 관계없이 인식될 수 있어야 한다. 1. 콘텐츠에서 제공하는 모든 정보는 특정한 색을 구별할 수 없는 사용자, 흑백 디스플 레이 사용자, 흑백 인쇄물을 보는 사용자 및 고대비 모드 사용자가 인식할 수 있도 록 제공해야 한다 (명도 대비) 화면에 표시되는 모든 사용자 인터페이스 컴포넌트와 텍스트는 전경색 과 배경색이 구분될 수 있도록 제공되어야 한다. 1. 화면에 표시되는 모든 사용자 인터페이스 컴포넌트와 텍스트는 전경색과 배경색이 구분될 수 있도록 명도 대비를 3:1 이상으로 제공해야 한다 (명확한 지시사항) 지시사항은 모양, 크기, 위치, 방향, 색, 소리 등에 관계없이 인식 될 수 있어야 한다. 1. 화면에 표시되는 특정 사용자 인터페이스 컴포넌트를 가리키거나 지시사항을 전달 하는 콘텐츠의 경우 가리키고자 하는 사용자 인터페이스 컴포넌트의 실제 명칭이나 그 사용자 인터페이스 컴포넌트가 포함하고 있는 대체 텍스트를 사용해 지칭하거나, 하나의 감각에 의존하지 않고 여러 감각을 이용하는 정보를 함께 제공해야 한다. 2. 음성이나 음향을 사용해 지시사항을 전달하는 경우 사용자가 소리를 들을 수 없더 라도 지시사항을 인식할 수 있어야 한다 (알림 기능) 알림 정보는 화면 표시, 소리, 진동 등 다양한 방법으로 제공되어야 한 다. 1. 중요한 알림 정보는 시각, 청각, 촉각 등 다양한 감각으로 인식될 수 있어야 한다. 2. 알림정보는 사용자가 자신에게 적합한 방법을 선택할 수 있도록 제공하는 것이 바 람직하다. 7. 운용의 용이성 운용의 용이성은 사용자가 장애유무 등에 관계없이 애플리케이션에서 제공하는 모든 5

18 기능들을 운용할 수 있게 제공하는 것을 의미한다 (초점) 의미나 기능을 갖는 모든 사용자 인터페이스 컴포넌트에는 초점(focus)이 적 용되고, 초점은 논리적인 순서로 이동되어야 한다. 1. 초점은 사용자가 예측할 수 있도록 논리적인 순서로 이동해야 한다. 2. 초점은 화면에서 보이지 않거나 논리적으로 의미를 갖지 않는 사용자 인터페이스 컴포넌트로 이동하지 않도록 해야 한다. 3. 표시되는 초점의 영역은 콘텐츠의 위치와 크기가 맞도록 제공해야 한다 (누르기 동작 지원) 터치(touch) 기반 모바일 기기의 모든 컨트롤은 누르기 동작으 로 제어할 수 있어야 한다. 1. 두 개 이상의 손가락을 동시에 이용해야 하는 다중 누르기(Multi-touch) 동작,, 팬 (Pan), 끌기와 놓기(Drag and drop) 등의 복잡한 누르기 동작은 단순한 누르기 동 작을 함께 제공해야 한다 (응답시간 조절) 시간 제한이 있는 콘텐츠는 응답시간을 조절할 수 있어야 한다. 1. 시간 제한이 있는 경우에는 제한시간 연장 또는 이를 제어할 수 있는 수단을 함께 제공해야 한다. 2. 불가피한 사유로 1항의 기능을 제공할 수 없는 경우에는 사용자에게 시간 제한이 있다는 것을 미리 알려주고, 종료되었을 경우에도 이를 알려주어야 한다. [비고] 불가피한 경우 : 보안, 게임 등 7.4. (정지기능 제공) 자동으로 변경되는 콘텐츠는 움직임을 제어할 수 있어야 한다. 1. 자동으로 변경되는 콘텐츠에는 앞으로 이동, 뒤로 이동, 일시 정지, 정지와 같이 이 를 제어할 수 있는 수단을 제공해야 한다 (컨트롤의 크기와 간격) 컨트롤은 충분한 크기와 간격으로 제공되어야 한다. 1. 컨트롤 간에 외곽선을 표시하지 않는 경우 컨트롤 간의 중심간 간격을 충분히 제 공해야 한다. [비고] 기본 사용자 인터페이스 컴포넌트와 같이 운영체제에게 기본적으로 제공하는 컨트롤의 경우 예외로 한다. 2. 모바일 기기의 화면크기에 관계없이 컨트롤의 가로와 세로 크기는 각각 9mm 이상 으로 제공하는 것이 바람직하다. 6

19 8. 이해의 용이성 이해의 용이성은 사용자가 장애유무 등에 관계없이 애플리케이션에서 제공되는 콘텐츠 를 이해할 수 있도록 제공하는 것을 의미한다 (입력 도움) 입력서식 이용 시, 입력 오류를 방지하거나 정정할 수 있는 방법을 제 공해야 한다. 1. 입력서식에는 용도와 목적을 알 수 있는 대체정보를 제공해야 한다. 2. 별도의 입력 방식이 있는 입력서식에는 입력오류를 방지하기 위하여 입력내용에 대한 설명정보를 제공해야 한다. 3. 사용자 입력 값에 오류가 있는 경우 오류 내용을 이해하고 이를 정정할 수 있도록 해당 오류 내용을 알릴 수 있는 방법을 제공해야 한다. 4. 입력서식의 오류 내용을 수정하기 용이하도록 오류가 발생된 지점으로 초점을 이동 시키는 것이 바람직하다 (사용자 인터페이스의 일관성) 사용자 인터페이스 컴포넌트들은 일관성 있게 배치되 어야 한다. 1. 화면에 표시되는 콘텐츠들의 배치는 일관성 있게 제공되어야 한다. 2. 애플리케이션 내의 유사한 기능을 가지고 있는 컨트롤은 동일하게 제공되어야 한다 (깜박거림의 사용 제한) 깜빡이거나 번쩍이는 콘텐츠를 제공하지 않아야 한다. 1. 화면상에서 깜빡임의 효과를 제공해야 하는 콘텐츠는 초당 3 ~ 50 회의 주기는 피해서 제공하는 것이 바람직하다. 2. 불가피하게 사용할 경우, 깜빡임을 제공하는 콘텐츠는 사전에 알리고, 회피할 수 있 는 방법을 제공해야 한다 (자동재생 금지) 자동으로 재생되는 배경음을 사용하지 않아야 한다. 1. 자동으로 재생되는 배경음은 제공하지 않아야 한다. 단, 3초 미만의 배경음은 예외로 인정한다. 2. 배경음을 사용할 경우, 사용자가 손쉽게 멈춤, 일시정지, 음량조절 등과 같이 이를 제어할 수 있는 수단을 제공해야 한다 (예측가능성) 사용자가 의도하지 않는 화면 전환이나 이벤트 등이 실행되는 경우 사 용자가 이해할 수 있는 방법으로 제공되어야 한다. 7

20 1. 화면이 전환되거나 팝업과 같은 이벤트가 실행되는 경우 이를 예측할 수 있는 방법 을 제공해야 한다. 2. 다른 애플리케이션으로 연결 및 전환되는 경우 이를 예측할 수 있는 방법을 제공해 야 한다. 9. 견고성 견고성은 사용자가 기술에 관계없이 애플리케이션에서 제공하는 콘텐츠를 이용할 수 있도록 제공하는 것을 의미한다 (폰트 관련 기능의 활용) 텍스트 콘텐츠는 운영체제에서 제공하는 폰트 관련 기능을 활용할 수 있는 방법을 제공해야 한다. 1. 텍스트 콘텐츠는 폰트 크기의 조절이 가능하도록 제공되어야 한다. [비고] 폰트 크기 조절 시 화면 레이아웃이 유지될 수 있는 범위 내에서 적용한다. 2. 폰트 관련 기능을 활용할 수 있도록 범용폰트를 활용하는 것이 바람직하다 (보조기술과의 호환성) 사용자 인터페이스 컴포넌트는 보조 기술을 이용하여 사용할 수 있도록 해야 한다. 1. 운영체제에서 제공하는 기본 사용자 인터페이스 컴포넌트를 최대한 이용하는 것이 바람직하다. 2. 부득이하게 기본 사용자 인터페이스 컴포넌트를 사용할 수 없을 시에는 운영체제에 서 제공하는 보조 기술을 사용할 수 있도록 해야 한다. 3. 기본 컴포넌트를 원래의 기능과 다른 기능으로 제공할 경우 사용자가 컨트롤의 기능을 이해할 수 있도록 그 기능에 대한 정보를 제공해야 한다. 10. 접근성의 사용자 평가 권고 접근성 사용자 평가는 장애인 등 당사자가 다양한 모바일 기기에서 실제 모바일 애플 리케이션 콘텐츠를 이용해보고 이용 가능 여부를 점검하는 것을 의미한다. 모바일 애플리케이션의 출시 전에 시각 장애, 청각 장애, 뇌병변 장애, 지적 장애, 지체 장애, 고령자 등의 다양한 접근성 사용자 유형을 대상으로 실시하는 것이 바람직하다. 8

21 부 록 Ⅰ 참고문헌 [1] 장애인 고령자 등의 정보 접근 및 이용 편의 증진을 위한 지침(2013년 8월 19일), 미래창조과학부고시 제 호 [2] Accessibility programming guide for ios, Apple [3] Android Accessibility - Designing for Accessibility, Google [4] Best practice: Designing accessible applications, RIM [5] Making Mobile Phones and services accessible for Persons with disabilities, , ITU-T [6] Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile, , W3C [7] Mobile Accessibility Standards and Guidelines v1.0, BBC [8] Mobile Web Application Best Practices (MWABP), , W3C 9

22 부 록 Ⅱ 모바일 애플리케이션 콘텐츠 접근성 지침 사례 본 모바일 애플리케이션 콘텐츠 접근성 지침 사례는 모바일 애플리케이션 개발자 및 운영자들이 접근성을 고려하여 애플리케이션을 개발할 수 있도록 도움을 주기 위해 제공 하는 것이다. 본 표준에 포함된 인식의 용이성(6개), 운용의 용이성(5개), 이해의 용이성 (5개), 견고성(3개)의 대표적인 기술 구현 방법, 구축 사례를 제공한다. Ⅱ.1. 인식의 용이성 인식의 용이성은 사용자가 장애 유무 등에 관계없이 모바일 애플리케이션 콘테츠에서 제공하는 모든 콘텐츠를 동등하게 인식할 수 있도록 콘텐츠를 제공하는 것을 의미한다 Ⅱ.1.1. 대체 텍스트 텍스트 아닌 콘텐츠는 대체 가능한 텍스트를 함께 제공해야 한다. Ⅱ 준수 필요성 시각장애인의 경우 모바일 기기나 모바일 화면 낭독 프로그램에서 제공하는 음성 읽기 기능(iOS VoiceOver, 안드로이드 Talkback, 윈도 모바일 Narrator 등)을 활용하여 애플리 케이션의 정보를 인식할 수 있다. 하지만, 해당 애플리케이션에서 텍스트 아닌 콘텐츠로 제공하면서 대체 텍스트를 함께 제공하지 않으면 시각장애인은 잘못된 정보를 얻거나 전 혀 정보를 얻을 수 없다. Ⅱ 기술구현 방법 이미지 등 텍스트 아닌 콘텐츠를 제공할 경우에는 반드시 대체 텍스트를 함께 제공해 야 한다. 대체 텍스트는 가능한 짧고 명확(Short & Clear)하게 제공하는 것이 바람직하 며, VoiceOver, Talkback 등 모바일 스크린리더에서 기본적으로 제공해 주는 용어인 버 튼, 이미지, 레이블 등은 중복해서 제공하지 않는 것이 바람직하다(웹 접근성 연구 소 버튼( ), 모바일 접근성 이미지( ), 금융자동화기기 접근성 레이블( ) 웹 접근성 연구소( ), 모바일 접근성( ), 금융자동화기기 접근성( )). 가. 애플의 ios에서 대체 텍스트 제공 방법 대체 텍스트를 제공하는 방법은 크게 2가지 방법이 있다. 첫째, 애플에서 제공하는 Interface Builder를 이용하여 대체 텍스트를 제공한다. 둘째, 대체 텍스트를 10

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

24 < Interface Builder를 활용하여 버튼에 대체 텍스트를 제공하는 방법 > 대체 텍스트 제공 방법 1) Accessibility 속성을 반드시 활성화 (Enabled) 시킨다. 2) Label 속성에 텍스트 아닌 콘텐츠의 의미 와 정보를 동등하게 인식할 수 있도록 대체 텍스트를 짧고 명확하게 제공한다. 3) 부가적인 설명이 필요할 경우에는 Hint 속 성을 활용하여 추가적인 정보를 제공한다. < 참고 > Interface Builder는 Xcode에 포함되어 제공되고 있다. 15년 7월 현재 애플의 최신 개발도구는 Xcode 6이다. 2) UIAccessibility API 등을 활용하여 직접 코드에 삽입하는 경우 애플에서 제공하는 UI 개발자 도구인 Interface Builder를 활용하지 않고 소스코드에서 대체 텍스트를 적용할 경우 UIAccessibility API를 활용하여 Label에 대체 텍스트를 제공 한다. [housebutton setisaccessibilityelement:yes]; [housebutton [housebutton 음악을 멈춥니다."]; 나. 구글의 안드로이드에서 대체 텍스트 제공 방법 안드로이드에서 대체 텍스트를 제공하는 방법은 크게 2가지 방법이 있다. 첫째, 구글에 서 제공하는 GUI 에디터를 이용하여 대체 텍스트를 제공한다. 둘째, 대체 텍스트를 직접 Java 코드에 삽입하여 제공한다. 구글에서 제공하는 GUI 에디터를 이용하는 경우 XML로 정의하는 방법과 애플의 Interface Builder 와 같이 에디터 상에서 수정할 수 있다. 12

25 1) XML을 활용하여 버튼을 제공할 경우 <ImageButton android:contentdescription= 웹 접근성 연구소 /> 2) Java code를 활용하여 버튼을 제공할 경우 Button add_entry_button = new Button(this); add_entry_button.setcontentdescription("웹 접근성 연구소"); Ⅱ 구축 사례 이미지 등 텍스트 아닌 콘텐츠를 활용할 경우에는 반드시 대체 텍스트를 제공해야 한 다. 하지만 아래의 *** 캘린더 앱에서는 주요기능(메뉴, 일정 등)에 대체텍스트를 제공하 지 않았다. 이로인해 시각장애인은 애플리케이션의 기능 및 정보를 인식할 수 없는 상태 이다. 특히 캘린더 앱의 주요기능인 일정 영역에서 대체텍스트가 전혀 제공되지 않아 애 플리케이션의 이용이 불가능한 상태이다. 13

26 <잘못된사례-***캘린더> <ios VOICEOVER 음성> 1. menu icon default 버튼 2. right icon default 버튼 3. 버튼 4. 버튼 5. 버튼 다음은 태그팔로잉 애플리케이션 PHO***의 약관동의 화면이다. 약관에 동의하는 체크 상자에 대체텍스트가 제공되지 않아 화면낭독프로그램을 사용하는 시각장애인은 해당 버 튼의 용도를 알 수 없다. 체크상자와 같은 메타포를 사용했을 때 의미와 기능을 담고 있 으면 반드시 동등한 수준의 대체텍스트가 제공되어야 한다. <잘못된사례 PH****> <ios VOICEOVER 음성> 1. terms off 버튼 2. 선택됨 terms off 버튼 3. terms off 버튼 4. 선택됨 terms off 버튼 다음사례 *** 뮤직 은 주요 기능에 대체텍스트를 제공하지 않았다. 화면낭독프로그램 을 사용하는 시각장애인은 대체텍스트가 없는 버튼은 어떤 기능을 실행하는지 알 수 없 고 결국 애플리케이션을 이용하는 것이 매우 어렵다. 14

27 <잘못된사례-***뮤직 홈화면> <ios VOICE 음성> 1. 버튼 2. 버튼 3. 버튼 4. 버튼 5. main btn add song 버튼 15

28 < 모바일 애플리케이션 콘텐츠 접근성 개선 사례 KB스타뱅킹(iOS) > KB스타뱅킹 앱은 기존 모바일 애플리케이션 콘텐츠 가이드의 구축사례에서 <잘못된사례>로 소 개되었다. 당시 대부분의 사용자 인터페이스 컴포넌트에 대체텍스트가 제공되지 않아 시각장애 인이 애플리케이션을 활용하는 것이 불가능한 상황이었다. 그 이후 KB국민은행에서는 장애인의 모바일 접근권 보장을 위해 2011년 주요 서비스 접근성 준수, 2013년 전체서비스 접근성 준수, 2014년 접근성 품질 고도화 등의 프로젝트를 진행하면서 접근성의 준수 정도가 크게 향상되었다. 접근성 개선 과정에서 장애를 가진 사용자가 참여하는 접근성 평가가 진행된 것으로 알려졌다. 현재는 국내에서 모바일 애플리케이션 콘텐츠 접근성 제고를 이뤄낸 우수 사례로 다음과 같은 개선이 이루어졌다. 2011년 (접근성 개선 전) - 대체 텍스트를 미제공하여 예금조회/이체 의 모든 기능을 제대로 활용할 수 없는 실정이었 다. (모든 사용자 인터페이스 컴포넌트를 버튼 이라고 인식) <개선 전 예금조회/이체 화면> <ios VoiceOver 설정시 예금조회/이체 화면> 16

29 2015년 접근성 개선 후 - 시각적으로 제공되는 콘텐츠와 동등한 수준의 대체텍스트를 제공하하여, 시각장애 인이 모바일 화면낭독프로그램을 활용해서 앱을 이용할 수 있도록 했다. <개선 후 예금조회 화면> <ios VoiceOver 설정시 예금조회 음성출력내용> 1. 뒤로 버튼 2. 조회 머리말 3. 예금/신탁계좌조회 링크 4. 펀드계좌조회 링크 5. 대출계좌조회 링크 6. 외환계좌조회 링크 7. 보험/공제계좌조회 링크 8. 골드계좌조회 링크 9. 퇴직연금계좌조회 링크 10. 전체계좌조회 링크 11. 전체메뉴 버튼 12. 홈 버튼 13. MyKB 버튼 14. 금융센터 버튼 17

30 시계좌목록 화면은 매우 중요한 금융정보를 표시하고 있고, 다양한 정보(계좌명,계좌 정보, 잔액 등)가 표시되는데 그 의미가 혼동될 가능성이 있다. 시각장애인 사용자 평 가과정에서 이런 불편사항이 확인되어 콘텐츠의 의미가 명확해지도록화면에 보이지 않는 대체텍스트를 추가로 제공하고 있다. <개선 후 계좌목록 화면> <ios VoiceOver 설정시 계좌목록 음성출력내용> 1. 계좌명 2. KBStar*t통장저축예금 3. 계좌번호 **** KBStar*t통장저축예금 **** 354 기능 더보기 버튼 6. 계좌명 7. KB종합통장보통예금 8. 계좌번호 **** 계좌별명 11. 입금전용 Ⅱ.1.2. 자막, 수화 등의 제공 멀티미디어 콘텐츠에는 동등한 내용의 자막, 원고 또는 수화가 제공되어야 한다. Ⅱ 준수 필요성 청각장애인의 경우 동영상이나 음성으로 제공되는 콘텐츠에 대하여는 음성 정보를 인 지하기 어렵다. 따라서 이들에 대하여는 동기화된 자막을 제공하거나 별도의 원고를 제 공하여야 콘텐츠를 인식할 수 있다. 멀티미디어 콘텐츠에 대한 동등한 내용의 자막, 원고 또는 수화는 시끄러운 환경이나 조용한 환경, 해당 언어를 모국어로 사용하지 않는 비장 애인에게도 도움이 된다. 또한 동영상 검색 시에도 자막이나 원고는 큰 도움을 줄 수 있 다. 시각장애인은 화면정보를 인식할 수 없으므로 화면으로 제공되는 텍스트를 음성으로 제공하거나 화면해설과 함께 원고로 제공하면 멀티미디어 콘텐츠의 시각정보를 인식할 수 있게 된다. Ⅱ 기술 구현 방법 18

31 멀티미디어 콘텐츠에는 동등한 내용의 자막, 원고 또는 수화를 제공해야 한다. 멀티미 디어 콘텐츠를 요약한 자막이나 원고는 불충분하며, 멀티미디어에서 제공하는 음성 정보 와 동등한 내용을 자막이나 원고로 제공해야 한다. 음성이 없이 동영상에 포함된 메시지 나 자막, 중요 단어에 대한 강조, 홍보 문구 등은 시각장애인이 전혀 확인할 방법이 없으 므로, 이러한 경우에는 반드시 화면 해설 서비스(음성으로 메시지, 자막, 중요 단어 등을 제공)를 제공해야 한다. 자막, 수화 또는 원고는 화면 상의 콘텐츠와 동기화하여 제공하 는 것이 바람직하다. Ⅱ 구축 사례 my K 앱에서는 기존 방송콘텐츠 서비스에 자막 표시 기능을 제공함으로서 청각장애인 도 방송콘텐츠의 음성정보를 동등한 수준으로 인식할 수 있다. 기본적으로 동기화된 자 막을 제공하고 있으며, 사전에 제작된 자막이 없는 경우 실시간 자막입력을 통해서 자막 방송을 제공하고 있다. <올바른사례 - my K 자막제공 화면> 19

32 Ⅱ.1.3. 색에 무관한 인식 화면에 표시되는 모든 정보는 색에 관계없이 인식할 수 있어야 한다. Ⅱ 준수 필요성 색맹 사용자의 경우 특정 색을 구별하지 못하는 경우가 있다. 그 대표적인 예로 적록 색맹의 경우 적색과 녹색을 구분하지 못함으로서 일상 생활에서 신호 등을 구분하지 못 하고 이로 인하여 운전면허 취득도 어렵다. 이와 마찬가지로 모바일 애플리케이션 콘텐 츠에서 정보를 색으로만 제공할 경우 색맹이나 색약자의 경우 이를 인지할 수 없다. Ⅱ 기술 구현 방법 색상으로 정보를 구분할 경우, 색상 이외의 다른 방법으로도 동등한 내용을 전달할 수 있도록 설계한다. 색 이외의 명암이나 텍스트, 특수 기호 등을 색과 함께 제공하여 해당 정보를 인식할 수 있도록 제공해야 한다. Ⅱ 구축 사례 좌하단은 모바일통신 속도를 측정하는 애플리케이션의 통계화면이다. 이 사례에서는 OS, 통신사, 단말기 비율을 그래프로 표시하면서 범례를 함께 제공했지만 각 데이터를 색상으로만 구분하고 있다. 이로인해 색상을 구분하기 어려운 색각이상자나 노안이 있는 사용자는 범례를 보더라도 색상을 명확히 구분할 수 없어서 그래프의 의미를 파악하는 것이 매우 어렵다. 우하단은 은행의 금융상품 현황을 보여주는 화면이다. 금융상품 종류별 비율을 원그래 프로 표시하면서 범례와 구체적인 수치를 함께 제공하고 있다. 금융상품 종류와 구체적 인 수치를 텍스트로 함께 제공함으로서 원그래프와 범례의 색상을 구분하지 못하더라도 데이터를 이해하는데 어려움이 발생하지 않는다. 20

33 < 잘못된 사례 > < 올바른 사례 > 우하단의 올바른 사례에서는 약관 동의 여부를 표시하는 방법으로 체크표시의 유무를 사용하고 있어 선택상태의 구분이 용이한 반면 좌하단의 잘못된 사례에서는 약관 동의여 부를 붉은색 으로 구분하고 있어 색상을 구분하기 어려운 색각이상자는 어느 항목에 동 의를 했는지 구분하기 어렵다. 선택/해제 등 콘텐츠의 상태를 표시할 때는 색상에만 의존 하지 않아야 합니다. 21

34 < 잘못된 사례 > <올바른 사례 > 다음의 잘못된 사례에서 정방향/역방향의 구분을 색상에만 의존하고 있습니다. 좌석의 방향을 색상으로만 구분하고 있기 때문에 색각이상자는 자신이 원하는 좌석을 선택하는 것이 매우 어렵게 됩니다. 좌석의 종류와 같이 콘텐츠를 구분해야할 때는 색상에만 의존 하지 않고, 블릿, 기호, 픽토그램등 다양한 수단을 함께 제공해야 합니다. 22

35 < 잘못된 사례 > 23

36 Ⅱ.1.4. 명도 대비 화면에 표시되는 모든 정보는 전경색과 배경색이 구분될 수 있도록 최소 대비 이상으 로 제공되어야 한다. Ⅱ 준수 필요성 시각장애인 등은 모바일 기기를 사용할 경우 화면에 표시되는 전경색과 배경색간의 구 분이 잘 되지 않는 문제로 인하여 어려움을 겪는 경우가 많이 발생하고 있다. 특히 전경 색과 배경색이 흰색과 회색, 노란색과 오렌지색 등으로 유사한 색으로 되어 있는 경우 이를 인지하기 매우 어렵다. 따라서 전경과 배경을 명확하게 인식할 수 있도록 콘텐츠를 제공해야 한다. Ⅱ 기술 구현 방법 명도 대비는 화면의 배경색과 사용자 인터페이스 컴포넌트를 표시하는 데에 사용되는 전경색 사이의 명도 차이의 비율(contrast)을 말한다. 모든 정보의 최소 대비는 4.5:1 이 상이어야 한다. 운영체제의 화면 확대 기능을 이용할 수 있는 경우 텍스트의 명도 대비 는 3:1 까지 낮출 수 있다. 명도 대비를 높게 제공하기 어려운 경우에는 운영 체제에서 제공하는 명도 대비를 활용할 수 있도록 제공하거나 애플리케이션 내에서 명도 대비를 높일 수 있는 설정 기능을 제공해야 한다. ios 8의 경우에는 설정 일반 손쉬운 사용 검정색 바탕에 흰색 이라는 명 도 대비 설정 기능을 제공하고 있다. < 참고 : 색에 무관한 인식 관련 평가 도구 > Color Doctor Visual Impairment Simulator for Microsoft Windows Colour Contrast Analyser Colour Checker Color Selector adesigner Accessibility Color Wheel 24

37 Ⅱ 구축 사례 다음은 ** 메신저 앱의 계정등록 화면이다. 화면내의 대부분 콘텐츠의 명도대비가 매 우 낮은 상태로 계정등록에 대한 안내사항과 비밀번호 입력등 모든 콘텐츠의 내용을 인 식할 수 없는 상태이다. 사례와 같이 명도대미가 매우 낮은 경우 저시력 시각장애인등은 콘텐츠가 있는 것조차 인식할 수 없다. <잘못된사례 계정등록화면> 다음 사례는 *** 앱의 계정로그인 화면으로 편집창의 용도를 표시하는 텍스트 등의 명 도대비가 낮은 상태이다. 저시력 시각장애인 등은 명도대비가 낮아 편집창의 용도와 로 그인 버튼을 명확히 인식할 수 없어 계정로그인이 매우 어렵다. <잘못된사례 계정로그인> 25

38 <잘못된 사례 ***북 탭메뉴> 선택되지 않은 탭메뉴 버튼의 명도대비가 낮 아 색각이상자, 노인 등의 사용자가 탭메뉴의 용도를 인식할 수 없어 탭 전환에 어려움을 겪게 됩니다. <잘못된 사례 ***북 상태업데이트> 사진, 장소, 태그 등을 첨부하는 버튼의 명도 대비가 매우 낮아 색각이상자, 노인 등의 사용 자가 첨부관련 기능이 있다는 것을 인식하기 매우 어렵습니다. 26

39 Ⅱ.1.5. 명확한 지시사항 지시사항은 모양, 크기, 위치, 방향, 색, 소리 등에 관계없이 인식될 수 있어야 한다. Ⅱ 준수 필요성 특정 사용자 인터페이스 컴포넌트를 가리키거나 지시사항을 전달하는 콘텐츠에 한정해 적용하는 것으로, 콘텐츠의 사용에 필요한 지시 사항을 시각이나 청각 등과 같은 특정한 단일 감각에만 의존하는 방법으로 제공해서는 안 된다는 것이다. 즉, 여러 가지 다른 감 각을 통해서도 지시사항을 인식하는 데 문제가 없도록 콘텐츠를 제공해야 한다. 텍스트 콘텐츠(대체 텍스트 포함)는 보조 기술을 통해 다른 감각으로의 변환이 가능하기 때문에 텍스트 지시 사항에는 추가적인 음성 콘텐츠를 제공할 필요는 없다. Ⅱ 기술 구현 방법 색, 크기, 모양 또는 위치와 같은 정보에 대한 인식의 경우 애플리케이션 콘텐츠는 콘 텐츠에 접근하는 사용자들이 색, 크기, 모양 또는 위치에 관한 정보를 인식하지 못하더라 도 원하는 콘텐츠에 접근할 수 있도록 제작되어야 한다. 예를 들어, 특정 사용자 인터페 이스 컴포넌트를 동그란 버튼을 누르시오 또는 오른쪽 버튼을 누르시오 라고 가리킬 때, 그 대상이 되는 버튼이 동그란 버튼 또는 오른쪽 버튼 이라는 대체 텍스트를 포함 하고 있지 않을 경우 시각 장애를 지닌 사용자는 어떤 사용자 인터페이스 컴포넌트를 지 칭하는지 알 수 없다. 따라서 이러한 경우, 가리키고자 하는 사용자 인터페이스 컴포넌트 의 실제 명칭이나 그 사용자 인터페이스 컴포넌트가 포함하고 있는 대체 텍스트를 사용 해 지칭하거나, 불가피하게 색, 크기, 모양, 위치와 같은 정보를 사용해 특정 사용자 인 터페이스 컴포넌트를 가리킬 때는 이를 보완할 수 있는 다른 감각을 이용하는 정보를 제 공해야 한다. 음성이나 음향 정보의 인식의 경우는 사용자에게 음성이나 음향을 사용해 지시사항을 전달하는 경우 사용자가 소리를 들을 수 없더라도 전달하고자 하는 지시사항을 인식할 수 있어야 한다. 예를 들어, 온라인 시험 진행 중 사용자에게 비프 음으로 정답인지 오답 인지를 사용자에게 알려주면, 청각 장애 사용자나 스피커가 설치되어 있지 않은 환경에 있는 사용자는 정답과 오답 여부를 확인할 수 없다. 이 경우에 비프 음과 함께 정답과 오답 여부를 시각적으로 확인할 수 있는 수단을 제공하면 더 많은 사용자가 지시사항을 인지할 수 있게 된다. Ⅱ 구축 사례 다음사례는 *** 동영상 서비스의 튜토리얼 화면이다. 애플리케이션의 주요 기능에 대한 가이드를 제공하고 있는데 잘못된 사례와 바른 사례를 동시에 보여주고 있다. 27

40 1은 잘못된 사례로 사이드 메뉴 버튼에 대한 안내를 제공하면서, 대상을 가리키는 방 법으로 화면상의 위치와 화살표와 같이 시각적인 정보만을 사용하고 있다. 또한 제공된 텍스트에서 버튼을 누르거나.. 와 같이 안내하고 있어서 시각에 장애가 있는 사용자는 사이드 메뉴를 여는 버튼이 무엇이고 어디에 있는지 인식하는 것이 불가능하다. 이런 경 우에는 메뉴버튼에 제공된 대체텍스트를 활용해서 OOO 버튼을 누르거나... 의 형태로 제공하는 것이 바람직하다. 2는 바른 사례로 카테고리 선택 기능을 안내하고 있다. 해당 버튼을 가리키는 방법으 로 화면의 위치, 화살표 뿐 아니라 카테고리 버튼 으로 고유명사를 활용해 안내의 대상 을 명확히 안내하고 있다. 이 경우에는 시각에 장애가 있더라도 지시사항을 인식할 수 있다. <*** 동영상 서비스 앱의 튜토리얼 화면> 다음사례는 ***스토리의 인증화면이다. 자동가입 방지를 위한 인증도구의 하나로 캡챠 를 사용하고 있다. 캡챠의 지시사항이 팝콘이 있는 이미지를 모두 선택하세요 와 같이 시각에만 의존하고 있어 시각에 장애가 있는 사용자는 지시사항을 인식하고 수행하는 것 이 불가능하다. 이런 경우에는 대체할 수 있는 수단을 제공하는 것이 바람직하며, 이 앱 에서는 오디오서비스를 제공하고 있다.) 28

41 < ***스토리 인증화면> Ⅱ.1.6. 알림 기능 사용자에게 알림을 제공할 때에는 진동, 시각, 소리 등 최대한 다양한 방법으로 사용자 가 선택할 수 있도록 제공하는 것이 바람직하다. Ⅱ 준수 필요성 한 가지 감각으로만 정보를 제공하는 경우에는 다양한 사용자가 이를 활용할 수 있다 고 보장하기 어렵다. 예를 들어 시력을 요하는 정보를 제공하거나 음성으로만 정보를 제 공하는 경우 시각장애인이나 청각장애인들은 이러한 정보를 인지할 수 없다. 따라서 알 림 정보 등을 제공하는 경우에는 소리나 화면 진동 등 다양한 방법을 동시에 사용하여 정보를 제공하는 것이 필요하다. Ⅱ 기술 구현 방법 사용자에게 알림을 제공할 때에는 한 가지 감각에만 의존하지 말고 다양한 감각이나 표현 방법을 통해 사용자가 원하는 알림 기능을 제공하는 것이 바람직하다. 사용자에게 29

42 다양한 방법으로 알림을 제공될 수 있도록 시각, 청각, 촉각 등의 피드백을 제공해야 하 며, 다양한 알림 기능을 제공할 경우 적절한 방법을 사용자가 선택할 수 있도록 제공하 는 것이 더 바람직하다. Ⅱ 구축 사례 페이스북 애플리케이션에서는 알림이 상당히 세분화 되어있다. 사용자가 자신에게 적합 한 방법으로 알림 정보를 진동, 소리 등으로 정보를 얻을 수 있도록 기능을 제공하고 있 다. 또한 이러한 알림 정보는 가급적 운영체제에서 제공하는 Native UI를 활용하는 것이 바람직하다. < 페이스북의 알림 설정 화면 > < 운영체제에서 제공하는 Native UI 알림기능 사용 예 > Ⅱ.2. 운용의 용이성 운용의 용이성은 사용자가 장애 유무 등에 관계없이 모바일 애플리케이션 콘텐츠에서 제공하는 모든 기능들을 운용할 수 있게 제공하는 것을 의미한다. Ⅱ.2.1. 초점 모든 사용자 인터페이스 컴포넌트에는 초점(focus)이 적용되고, 초점은 순차적으로 이 동되어야 한다. Ⅱ 준수 필요성 초점이 적용되지 않으면 모바일 기기나 모바일 화면낭독 프로그램에서 제공하는 음성 30

43 읽기 기능(iOS VoiceOver, 안드로이드 Talkback, 윈도우 모바일 Narrator 등) 등을 활용 하는 경우의 사용자는 정보를 얻거나 기능을 실행할 수 없는 문제가 발생한다. 또한 순 차적으로 이동되지 않을 경우에는 시각장애인, 지적장애인 등이 해당 애플리케이션의 기 능과 정보의 이해에 어려움이 발생할 수 있다. Ⅱ 기술 구현 방법 애플리케이션 개발 시 모든 사용자 인터페이스 컴포넌트에 초점이 적용되고, 적용된 초 점은 순차적으로 이동할 수 있게 개발해야 한다. 가. 애플의 ios에서 초점 제공 방법 Accessibility 속성(코드에선 isaccessibilityelement)이 활성화(Enabled)될 경우에만 해 당 사용자 인터페이스 컴포넌트에 초점이 적용된다. ios에서 제공하는 기본 사용자 인터 페이스 컴포넌트(Native UI Component)에서는 이 속성의 기본 값이 활성화(YES)되어 제 공된다. 하지만 이미지나 커스텀 사용자 인터페이스 컴포넌트의 경우에는 Accessibility 속성이 비활성화(Disabled)되어 있다. 만약 의미를 포함하는 이미지를 ImageView UI 컴 포넌트를 활용하여 제공할 경우에는 Accessibility 속성을 활성화(YES)시켜야 하며, 대체 텍스트를 label 속성으로 반드시 제공해야 한다. 또한 커스텀 사용자 인터페이스 컴포넌 트를 사용할 경우에는 UIAccessibilityContainer를 상속받아 구현하면 된다. < Accessibility 속성이 활성화 되지 않은 경우 (초점 미적용) > < Accessibility 속성이 활성화 된 경우 (초점 적용) > 나. 구글의 안드로이드에서 초점 제공 방법 사용자 인터페이스 컴포넌트나. 구글의 안드로이드에서 초점 제공 방법 안드로이드에서 제공하는 기본 사용자 인터페이스 컴포넌트(Native UI Component)에 31

44 서는 ios와 달리 대부분의 기본 값이 비활성화(false)되어 제공된다. 그러므로 초점 이동 이 필요한 UI의 경우에는 반드시 focusable 속성을 활성화(true)시켜 제공해야 한다. <TextView android:focusable= true android:text="hello, I am a focusable TextView" /> 안드로이드에서 초점의 이동 순서를 제어하기 위해서는 nextfocusdown, nextfocusup, nextfocusright, nextfocusleft 속성을 이용하면 된다. - 특정 사용자 인터페이스 컴포넌트 초점 적용 방법 <EditText android:id="@+id/edittext1" android:layout_width="match_parent" android:layout_height="wrap_content"> <requestfocus /> </EditText> - 이벤트를 이용한 초점 이동 방법 sendaccessibilityevent(accessibilityevent.type_view_focused); Ⅱ 구축 사례 모든 컨트롤에 대하여 초점이 적용되어 있어야 하며, 논리적인 순서로 제공되어야만 시 각장애인 등이 활용할 수 있다. 32

45 < ** 은행의 가상키보드 화면 > < 문제점 및 해결 방안 > o 문제점 - VoiceOver를 실행할 경우, a, a, s, s, d, d.. 순서로 동일한 콘텐츠에 두 번씩 초점이 적용 - 영문을 다 읽어 준 후 같은 버튼의 한글 입력인 ㅁ, ㄴ, ㅇ... 순서로 동일한 버튼을 한번 더 접근 * VoiceOver를 사용할 경우, 공인인증서 로그인 의 정 보가 dtm into 1 gif"로 출력되는 문제 발생 o 해결 방안 - 모든 버튼 및 정보에 초점이 한번만 적용되도록 해야 한다. 33

46 <잘못된 사례 *** 내정보> 내정보화면에서 초점의 이동순서가 다음과 같 이 비논리적으로 진행되고 있다 만족 3만족 4내공 5채 택답변수 6답변채택률 이로인해 시각장애인은 240 과 만족 이 어 떤 의미를 표시하는 것인지 이해할 수 없는 상황이다. 이처럼 초점의 이동순서는 콘텐츠의 의미를 파악하는데 매우 중요한 역할을 하고 있다. <잘못된 사례 ***스토리 글쓰기> 글쓰기 버튼을 선택해서 하위메뉴를 호출했을 때의 초점이동 순서이다. 탭메뉴 영역을 역순으로 이동한후 하위에 펼 쳐진 메뉴로 이동하기 때문에 화면낭독프로그 램을 사용하는 전맹시각장애인은 콘텐츠의 구 조를 이해하기 어렵고 하위메뉴가 열렸다는 것을 인지할 수도 없다. 하위 메뉴가 호출되었을 때 다음초점 순서가 펼쳐진 하위콘텐츠의 첫부분부터 순차적으로 이동되어야 구조를 명확히 이해하고 사용할 수 있다. 34

47 <잘못된 사례 *** 질문 공유하기> 질문 공유하기 기능을 선택했을 때의 화면이 다. 공유방법을 선택하는 레이어에만 초점이 적용되어야 하지만 뒤에 숨겨진 기존 콘텐츠 영역에 초점이 그대로 적용되고 있어 화면낭 독프로그램을 사용하는 시각장애인은 레이어 콘텐츠를 정상적으로 이용할 수 없다. 기존 콘텐츠가 가려지면서 새로운 콘텐츠가 표시되었을 때는 활성화되어있는 영역에만 초 점이 적용되도록해야 한다. < ** 방송국의 라디오 > < 문제점 및 해결 방안 > o 문제점 - *** 월드 라디오는 크게 프로그램과 뮤직채널로 나눠져 있다. 이 애플리케이션을 실행하면 두 채널 중 하나를 선택해 야 청취가 가능한데, 가운데 있는 이 부분이 VoiceOver를 통 해서는 초점이 생성되지도 동작하지도 않는다. 선택하지 않으 면 라디오를 들을 수 없는 상황이 되기 때문에 단 하나의 컨 트롤의 문제라고 할 수도 있겠지만 VoiceOver 사용자는 이 애플리케이션을 사용할 수 있느냐 사용하지 못하느냐를 가늠 하는 중요한 열쇠가 된다. 결과적으로 접근할 수가 없으니 이 애플리케이션의 라디오 기능을 사용할 수 없다. o 해결 방안 - 시각장애인 등이 이용할 수 있도록 프로그램 과 뮤직채 널 에 초점을 적용해야 한다. 35

48 Ⅱ.2.2. 누르기 동작 지원 다. 터치(touch) 기반 모바일 기기의 모든 컨트롤은 누르기 동작으로 제어할 수 있어야 한 Ⅱ 준수 필요성 상지장애가 있는 사용자는 손가락을 사용하는 조작 즉, 2개 이상의 손가락을 사용하는 벌리기, 끌어다 놓기, 모양 그리기 등 다중 누르기 동작을 수행하는 것이 매우 어렵다. 상지에 장애가 있더라도 동등한 기능을 사용할 수 잇도록 복잡한 제스쳐와 누르기 동작 은 단순한 누르기 동작으로 대신할 수 있어야 한다. 시각에 장애가 있는 경우 기본적으로 시각적인 정보를 얻을 수 없으므로 모양 그리기, 위치바꾸기, 끌어다 놓기 등의 복잡한 동작을 수행하기 어렵다. 이것을 보완하기 위해 단 순한 누르기 동작으로도 동등한 기능을 이용할 수 있도록 해야 한다. 또한 시각장애인은 화면낭독프로그램을 사용하기 때문에 좌/우 쓸어넘기기, 위/아래 쓸 어넘기기, 당겼다 놓기, 버튼 실행 등의 동작에도 제한을 겪게 된다. 모바일 화면낭독 프 로그램을 사용하더라도 동일한 기능을 사용할 수 있도록 모바일 화면낭독프로그램의 제 스쳐(세 손가락 쓸기, 한 손가락 더블탭 등)로 동일한 기능을 이용할 수 있도록 보완하거 나 대체수단을 제공하는 것이 중요하다. Ⅱ 기술구현 방법 누르기 동작은 화면상의 사용자 인터페이스 컴포넌트를 손가락 끝으로 접촉하여 만지 거나(touch) 가볍게 두드리는(tap) 동작을 말하는 것으로, 모든 컨트롤 동작은 누르기 동 작만으로도 제어할 수 있어야 한다. 두 개의 손가락을 동시에 이용해야 하는 다중 누르 기(Multi-touch) 동작이나 Slide, Drag and drop 등의 복잡한 누르기 동작은 단순한 누 르기 동작 또는 버튼 등으로 대체할 수 있는 방법이 제공되어야 한다. 가. 애플의 ios에서 누르기동작 제공 방법 UIButton 과 같이 단순 누르기 동작을 지원하는 컨트롤을 함께 제공해야 합니다. ss/index.html#//apple_ref/occ/cl/uibutton Ⅱ 구축 사례 모든 컨트롤은 누르기 동작으로 제어할 수 있도록 제공해야 한다. 사용자 편의성 제고 를 위해 다양한 UI를 활용하는 것은 필요하나, 보다 중요한 것은 장애인 등 다양한 사용 자가 동등하게 이용할 수 있도록 개발하거나 해당 기능을 대체할 수 있는 수단을 제공하 36

49 는 등의 보편적 설계(Universal Design)를 적용해야 한다. <바른 사례 - 다음지도 확대/축소 기능> 상지에 장애가 있는 사용자는 두 손가락을 활용한 확대/축소 기능을 이용하기 어렵다. 장애가 있더라도 단순 누르기 동작으로 동등 한 기능을 이용할 수 있도록 +/- 버튼을 사용할 수 있는 설정을 제공하고 있다. <잘못된 사례 - ***VOD 서비스> 콘텐츠 목록 갱신하는 기능을 아래로 당겼다 놓는 제스쳐로 이용하도록 구현되어있다. 하지만 모바일 화면낭독프로그램을 위한 제 스쳐(세 손가락 쓸기)를 구현하지 않어서 시 각장애인은 지정한 제스쳐를 수행할 수 없어 목록을 갱신하는 것이 불가능하다. 참고 페이스북 ios앱은 동일한 기능에 보이스오버 의 제스쳐(세손가락 아래로 쓸기)를 구현해서 피드목록 갱신을 원활하게 이용할 수 있다. <잘못된 사례 PHO***튜토리얼 화면> 애플리케이션 초기 실행시 나오는 튜토리 얼 화면이다. 페이지네비게이션을 제공하 고 있지만, 페이지네비게이션을 탭했을 때 다음페이지로 이동하는 동작이 실행되지 않아 상지장애인이 다음 화면으로 전환하 는 것이 쉽지 않다. 또한 시각장애인은 보이스오버의 페이지 이동 제스쳐(세손가락쓸기)를 사용해 다음 페이지로 이동하는 것이 불가능하다. 37

50 <잘못된 사례 **사전 내 단어장 화면> 목록항목을 좌에서 우로 한 손가락으로 쓸면 삭제, 이름변경과 같은 내단어장 편집기능을 호출해서 사용할 수 있다. 하지만 보이스오버 사용자는 편집 기능호출 및 버튼실행 기능에 대한 대체수단이 제 공되지 않아 내단어장 편집기능을 이용하는 것이 불가능하다. <바른 사례 카카오톡 친구목록> 화면낭독프로그램 사용자는 목록에서 한손가락 쓸 기로 활성화되는 기능의 대체수단이 없으면 이용 이 불가능하다. 하지만 ios 카카오톡은 보이스오 버로 동등한 기능을 사용할 수 있도록 대체수단이 제공되어 있다. 사용방법 1. 로터 활성화 한후 동작을 선택 2. 한손가락 위/아래 쓸기로 원하는 항목 선택 3. 한손가락 더블탭으로 실행 < Slide 기능에 대한 대체 수단 제공 사례 (두 번 두드리기(double tap)) > < Slide 기능에 대한 대체 수단 미제공 사례 > 슬라이드 기능 을 활용하지 못 할 경우, VoiceOver를 이 용할 경우에는 두 번 누르기 (double tap)으 로 해당 기능 활용 가능 슬라이드 기능을 활용하지 못할 경 우 대체 수단을 제공하지 않아, talkback을 이용하 는 사용자의 경우 에는 전화 받기 기능을 활용할 수 없음 38

51 <볼륨조절 기능에 대한 대체 수단 미제공 사례 > <볼륨조절 기능에 대한 대체수단 제공 가이드 > 화면의 원형 모양대로 화 면을 슬라이드 하여 터치하지 못할 경우 볼 륨조절 기능을 활용할 수 없 음 talkback을 이용하 는 경우에도 볼륨 기능을 조절할 수 있는 추가적인 버 튼 또는 누르기 컨 트롤 등의 대체수 단을 제공하여야 함 Ⅱ.2.3. 응답시간 조절 시간제한이 있는 콘텐츠는 응답시간을 조절할 수 있어야 한다. Ⅱ 준수 필요성 애플리케이션 콘텐츠 제작 시 시간제한이 있는 콘텐츠는 가급적 포함하지 않는 것이 바람직하며, 보안 등의 사유로 시간제한이 반드시 필요할 경우에는 이를 회피할 수 있는 수단을 제공해야 한다. Ⅱ 기술구현 방법 시간제한이 있는 콘텐츠는 제공하지 않아야 한다. 시간제한이 있더라도 온라인 경매, 실시간 게임 등과 같이 반응 시간의 조절이 원천적으로 허용되지 않는 경우에는 이 검사 항목이 적용되지 않는다. 다만, 이 경우에도 사용자에게 시간제한이 있다는 것을 미리 알 려주고, 종료되었을 경우에도 이를 알려주어야 한다. 세션 시간이 20시간 이상인 콘텐츠 의 경우에도 예외로 간주한다. 반응 시간 조절이 필요한 콘텐츠의 경우에는 반응 시간이 정해진 애플리케이션 콘텐츠를 사용자가 이용할 수 있도록 하기 위해서는 반응 시간이 완료되기 전에 사용자가 다음 중 한 가지 방법을 선택하여 반응 시간을 조절할 수 있는 수단을 제공해야 한다. 또한 반응 시간 조절 기능은 충분한 시간(최소 20초 이상)을 두고 사전에 알려 주어야 한다. Ⅱ 구축 사례 다음 사례는 보안상의 이유로 세션 시간에 제한이 있는 애플리케이션이다. 시간제한으 39

52 로 인해 콘텐츠 이용에 많은 시간이 소요되는 장애인, 노인 등은 정해진 시간안에 원하 는 기능을 이용하기 어렵지만, 제한시간이 만료되기 전에 사용자에게 알리고 로그인시간 을 연장할 수 있는 기능을 제공해서 서비스 이용에 문제가 없도록 하고 있다. <바른사례 KB스타뱅킹 자동로그아웃안내> < 개선 전 > < 개선 후 > 응답시간을 조절할 수 있는 기능이 제 공되지 않음 인증번호의 재전송 기능 및 남은 시간을 연장할 수 있도록 시 간 연장 버튼을 추가 Ⅱ.2.4. 정지기능 제공 자동으로 변경되는 콘텐츠는 움직임을 제어할 수 있어야 한다. Ⅱ 준수 필요성 모바일 애플리케이션 콘텐츠에서 제공되는 스크롤 및 자동 갱신되는 콘텐츠를 장애인 사용자가 이용할 수 있도록 일시 정지할 수 있는 수단을 제공해야 한다. Ⅱ 기술구현 방법 40

53 이동하거나 스크롤 되는 콘텐츠 사용을 배제하는 경우 스크롤 및 자동 갱신되는 콘텐 츠를 사용하지 않는다. 이동하거나 스크롤되는 콘텐츠는 저시력 장애인이나 지적 장애인 등은 이동하거나 스크롤되는 콘텐츠를 사용하기 어려우므로, 애플리케이션 콘텐츠는 사 용자가 이동이나 스크롤을 일시 정지시키고, 지나간 콘텐츠 또는 앞으로 나타날 콘텐츠 를 선택할 수 있는 컨트롤(예: 앞으로 이동', 뒤로 이동, 정지 등)을 제공해야 한다. Ⅱ 구축 사례 < ** 예술관 사례 > < 문제점 및 해결방안 > o 문제점 - 좌에서 우로 자동으로 스크롤되는 연극 배너 콘텐츠 를 제공하고 있으나, 정지 기능을 제공하지 않음 o 해결방안 - 콘텐츠를 제어할 수 있도록 제어 기능을 제공 < 성남시장애인편의시설 제공 사례 > < 미 제공 사례 > 자동으로 변경되는 콘텐츠의 움직임을 제어할 수 있도록 정지/재생, 이전, 다음 버튼을 제공 포털 사이트의 자동 갱신 콘텐츠에 정지기능을 제공하지 않아 스크린리더의 오동작을 일으킴 Ⅱ.2.5. 컨트롤의 크기와 간격 41

54 컨트롤은 크기와 간격을 충분히 제공해야 한다. Ⅱ 준수 필요성 모바일 기기의 경우 터치를 통하여 컨트롤하기 때문에 터치의 정확성이 매우 중요하다. 터치의 정확성을 담보하기 위해서는 좌표 값도 중요하지만 각 컨트롤간의 간격도 중요하 다. 비장애인도 각 버튼간의 터치 간격이 좁게 되어 있고 버튼의 크기가 작으면 매우 불 편한데 뇌성마비 장애인의 경우 손 떨림 등이 많이 있고 이로 인하여 정확한 터치 동작 을 취하기가 매우 어렵다. 따라서 터치 동작을 원활히 수행할 수 있도록 터치 간격을 적 절히 유지하는 것이 매우 중요하다. 저시력인의 경우도 터치 타겟이 작을 경우 많은 어 려움을 겪게 되는데 특히 중요한 결제 정보를 입력하거나 은행용 모바일 애플리케이션 콘텐츠를 사용하는 경우 실수로 잘못 터치하는 경우 되돌이킬 수 없는 문제가 발생할 수 도 있다. Ⅱ 기술구현 방법 좁은 화면 공간의 경우, 사용자의 의도와 무관하게 다른 컨트롤을 누르게 되는 문제가 발생할 수 있으므로, 이를 피하기 위해서 컨트롤 사이의 공간을 충분히 확보하여 사용자 가 컨트롤 영역을 명확히 구분할 수 있도록 하는 것이 바람직하다. 모바일 기기의 화면 크기에 관계없이 가로 X 세로 크기는 각각 9mm 이상으로 제공하는 것이 바람직하다. 컨트롤의 터치 공간을 충분히 확보하여 사용자가 컨트롤 영역을 명확히 구분할 수 있도 록 제공하는 것이 좋다. 사용자의 의도에 따라 컨트롤을 확대하여 사용할 경우 상대적인 크기로 커져서 손쉽게 활용할 수 있도록 제공하는 것이 좋다. 쿼티 입력 등 운영체제에 서 제공하는 기본 사용자 인터페이스의 경우에는 예외로 한다. 42

55 < 컨트롤 크기 > o 필요성 및 해결방안 - 사용자가 컨트롤 영역을 명확히 구분하고 컨트롤의 충분한 터치 공간을 확보하기 위해 가로 x 크기 크기는 각각 9mm (48dpi(Dots per Inch)) 이상 제공 ng_accessibility.html Ⅱ.3. 이해의 용이성 이해의 용이성은 사용자가 장애 유무 등에 관계없이 애플리케이션에서 제공하는 콘텐 츠를 이해할 수 있도록 제공하는 것을 의미한다. Ⅱ.3.1. 입력 도움 입력 서식에는 입력을 위한 제목 또는 설명을 제공하고, 입력 오류가 있을 경우 이를 정정할 수 있는 방법을 제공해야 한다. Ⅱ 준수 필요성 사용자가 입력을 할 때에 용도나 목적을 이해할 수 있도록 입력 정보에 관한 제목이나 설명을 통해 오류 없이 입력할 수 있도록 하고 입력 도중 오류가 발생한 경우에 이를 쉽 게 정정할 수 있도록 하여 사용자의 입력을 돕는다. Ⅱ 기술 구현 방법 입력 서식은 운영체제에서 제공하는 접근성 속성을 활용하여 사용자가 이해하기 쉽도 록 해야 한다. 오류가 발생하면 오류 원인을 알리고, 오류 위치에서 바로 입력할 수 있도 록 초점을 이동 시킨다. 가. 안드로이드에서 입력서식 도움말 제공 방법 43

56 입력서식의 제목 제공 사례 소스코드상의 제목 제공 예제 <TextView android:layout_width="wrap_content" android:layout_height="wrap_content" /> <EditText android:layout_width="wrap_content" android:layout_height="wrap_content" /> <EditText <EditText 입력서식의 설명정보 제공 예제 android:layout_width="wrap_content" android:layout_height="wrap_content" /> android:layout_width="wrap_content" android:layout_height="wrap_content" /> 44

57 Ⅱ 구축 사례 < 입력서식 예시 > < 접근성 개선 전 > 제공된 입력서식은 라디오버튼, 콤보상자, 피커 컨트롤 의 용도를 구분할 수 있도록 적절한 입력도움말을 제 공해야 하나 대부분의 입력서식에서 제공되지 않음 < 접근성 개선 후 > 모든 서식에 대한 서식도움말이 적절하게 제공되어 인 식이 용이함 < 로그인 예시 > < 문제점 및 해결방안 > o 문제점 - 아이디, 비밀번호를 입력하는 서식 접근 시 해당 서 식을 단순히 에디터 테스트 로 출력 o 해결방안 - 입력서식을 이해할 수 있도록 입력도움말을 추가 아이디 입력 비밀번호 입력 45

58 <잘못된 사례 **** 가입화면> 블로그 서비스의 가입화면에서 필명 관련 오 류사항을 안내하고 있지만 보이스오버에서 접근할 수 없는 방식으로 알림이 제공되어 있다. ios환경에서 알림을 앱 개발사 맞춤형으로 제작했기 때문에 보이스오버는 알림내용을 음성으로 전달하지 못한다. 또한 메시지가 나타났다가 바로 사라지기 때문에 화면낭독 프로그램을 사용하는 시각장애인과 확대기능 을 사용하는 저시력 사용자는 알림메시지의 내용을 인식할 수 없다. 결국 알림은 제공했지만 장애인 사용자에게 제대로 전달되지 않는다. <준수 사례> < 미 준수 사례 > apple ID입력 창은 hint로 입 력도움말을 제 공하여 누구나 입력서식을 이 해할 수 있음 텍스트 이미지로 아이디와 비밀번 호를 서식 옆에 제공하고 있으나 실제 서식 접근 시 편집창 으 로만 인식되어 로그인 기능 이 용이 불가능 46

59 <바른 사례 비밀번호 변경> 비밀번호 변경기능에서 비밀번호 오류에 대한 안내에 시스템 알림을 사용하고 있어 보이스 오버를 사용하는 경우에도 명확하게 오류정보 를 인식할 수 있다. Ⅱ.3.2. 사용자 인터페이스의 일관성 다. 사용자 인터페이스 사용자 인터페이스 컴포넌트들의 배치를 일관성 있게 제공해야 한 Ⅱ 준수 필요성 저 시력 인이나 고령자 등 화면을 확대하는 사용자의 경우에는 전체 화면이 아니라 창 의 일부 영역을 화면에 확대하여 이용한다. 따라서 애플리케이션 창마다 내비게이션 컨 트롤의 위치와 모양이 다르다면 새로운 애플리케이션 창으로 이동할 때마다 사용법을 익 히는 데 많은 어려움이 있을 것이다. 또한 지적 장애인의 경우 이용한 애플리케이션 별 로 메뉴와 내비게이션 컨트롤의 위치나 모양이 바뀌게 되면 사용자는 페이지를 동일한 애플리케이션이 제공하는 페이지로 인식하기보다는 새로운 애플리케이션이 제공하는 페 이지로 인식할 가능성이 높다. 이에 일관성 있는 사용자 인터페이스를 제공하는 것이 바 람직하다. 47

60 Ⅱ 기술 구현 방법 사용자 경험(User Experience)에 비추어 일관성 있는 사용자 인터페이스(UI) 사용자 인 터페이스 컴포넌트를 제공하는 것이 바람직하다. 사용자 인터페이스를 구성하고 있는 사 용자 인터페이스 컴포넌트들(폰트, 크기, 화면 색상, 링크 제공 방법, 이모티콘 등)을 사 용자가 다시 학습하지 않아도 되도록 해당 애플리케이션 내에서 일관성 있게 제공하는 것이 바람직하다. 가. 애플의 ios에서 사용자 인터페이스의 일관성 제공 방법 예를 들면 "선택" 기능의 구현에 있어 어느 부분은 라디오버튼으로 하고 어느 부분에선 Custom Menu로 한다면 사용자에게 많은 혼란을 주게 됩니다. 이와 같이 유사한 기능 및 동작 관련해선 일관성 있는 사용자 컴포넌트를 사용하도록 기획단계 부터 적용할 수 있도록 합니다. 참고 : 라디오 버튼 /Button/Concepts/RadioButtons.html Custom Menu nus/introduction/intro.html Ⅱ 구축 사례 *** 영화관 모바일 애플리케이션 콘텐츠로 예약 시간을 선택하는 선택 창과 인원 및 좌석을 선택하는 창이 일관성 없이 제공되어 있어 사용자에게 혼란을 주는 사례이다. < 일관성 없는 입력 서식 제공 사례 (ios Native UI Component (좌측), Custom UI Component (우측) > 48

61 팝업창의 확인, 취소 버튼의 위치가 일관성 없이 제공되어 사용자에게 혼란을 주는 사 례이다. <일관성 없는 사용자 인터페이스 컴포넌트 배치 사례> 다음 사례는 메신저앱으로 이전단계로 이동하는 이전/닫기 버튼의 위치가 일관성있게 제공되어있다. <올바른 사례 카카오톡> Ⅱ.3.3. 깜빡거림의 사용 제한 광과민성 발작을 일으킬 수 있는 콘텐츠를 제공하지 않는 것이 바람직하며, 부득이 사 용할 경우 그 깜빡임을 제어할 수 있어야 한다. Ⅱ 준수 필요성 깜빡이거나 번쩍이는 콘텐츠를 제공할 경우 특정 사용자에게 광과민성 발작을 일으킬 우려가 있다. 예를 들어 일본에서 방영된 만화 영화인 포켓몬에서 깜빡임과 번쩍임이 과 도하게 제공되어 아동들이 병원에 가서 치료를 받았던 사례가 있다. 그러므로 깜박임과 번쩍임이는 효과로 정보를 제공하기 보다는 효과적인 디자인 등을 통해 모바일 애플리케 이션 콘텐츠의 정보를 제공하는 것이 바람직하다. 49

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

63 Ⅱ.3.4. 자동재생 금지 자동으로 재생되는 배경음을 사용하지 않는 것이 바람직하다. Ⅱ 준수 필요성 시각장애인의 경우 모바일 기기나 모바일 화면 낭독 프로그램에서 제공하는 음성 읽기 기능(iOS VoiceOver, 안드로이드 Talkback, 심비안 및 윈도우 모바일 6.5에서 활용되는 Code Factory사의 Mobile Speak 등)을 활용하여 모바일 애플리케이션 콘텐츠를 이용한 다. 이러한 기능들은 기본적으로 음성을 통하여 정보를 제공하고 있다. 이에 따라 애플리 케이션을 실행하였을 때 배경음이 자동적으로 나오게 되면 음성으로 정보를 정확히 전달 받을 수 없다. 따라서 이러한 배경음이 필요한 경우 이에 대한 알림 정보를 제공하고, 사 용자가 선택할 경우에만 실행이 되도록 제공하는 것이 바람직하다. Ⅱ 기술 구현 방법 자동으로 재생되는 배경음(동영상, 음성, 음악 등)을 사용하지 않는 것이 바람직하다. 단, 3 초 미만의 배경음은 예외로 한다. 배경음을 사용할 경우, 반드시 배경음을 제어할 수 있는 수단(멈춤, 일시 정지, 음량 조절 등)이나 배경음 제어로 이동하는 링크를 애플 리케이션 첫 부분에 제공하는 것이 좋다. 또한 음량 조절은 운영 체제에서 제공하는 음 량과 독립적으로 배경음만 조절할 수 있도록 제공하는 것이 더 좋다. Ⅱ 구축 사례 ** 자동차 회사에서 제공하는 모바일 애플리케이션 콘텐츠로 시작화면부터 사용자가 선택하지 않았음에도 불구하고 배경음이 자동적으로 흘러나오고 있다. 이를 해지하기 위 해서는 설정 메뉴로 들어가서 음악과 효과음을 줄여야만 정지되는 형태로 시각 사용자 등에게 혼란을 주는 사례이다. 51

64 < 자동 배경음을 사용한 잘못된 사례 > < 해결 방안 > 동영상을 사용자의 선택에 의해 활성화되도 록 제공하는 것이 바람직하다. 배경음을 제공할 경우에는 반드시 애플리케 이션 첫 부문에 이를 정지할 수 있는 기능을 제공하는 것이 바람직하다. Ⅱ.3.5. 예측가능성 화면전환이나 팝업과 같은 이벤트 등을 실행하는 경우 사용자가 이해할 수 있도록 해 당 실행 정보를 제공하여 다음 화면의 내용이나 동작을 예측할 수 있도록 해야 한다. Ⅱ 준수 필요성 사용자 인터페이스 컴포넌트애플리케이션의 기능을 실행했을 때 사용자가 예상할 수 없는 동작이 일어나면 장애가 있는 사용자는 이것을 원래의 상태로 바로잡기 위해 많은 노력이 필요하게 된다. 특히 시각장애인은 화면의 변화를 감지할 수 없기 때문에 더욱 어려움을 겪게 된다. 특정 버튼을 실행했을 때 만약 다른 앱으로 이동된다면 시각장애인은 앱이 전환된 것 을 깨닫지 못하고 이전의 앱 기능을 사용하기 위해 많은 노력을 기울이면서 혼란에 빠지 게 된다. 이것을 방지하기 위해 사용자가 예측할 수 없는 기능이 실행되거나 다른 앱으 로 전환이 발생하는 경우 사용자가 사전에 이것을 예측할 수 있는 정보를 제공해서 해당 기능의 이용여부를 선택할 수 있도록 해야 한다. Ⅱ 기술 구현 방법 화면전환이나 버튼 변화, 이미지 변환 등이 일어나는 다양한 이벤트에 대한 알림 정보 를 제공하여, 해당 액션을 이해하고 다음 동작을 미리 예측할 수 있도록 제공한다. 52

65 Ⅱ 구축 사례 <잘못된 사례 ***북 채팅탭> 사용자가 하단 탭메뉴에서 메신저탭을 선택하 면 별도의 메신저앱으로 연결된다. 하지만 단 순히 메신저 버튼 으로 음성출력되기 때문에 시각장애인 사용자는 다른 앱으로 전환된 것 을 알지 못한다. 결국 채팅기능을 이용 후 다 시 원래의 SNS 콘텐츠를 이용하려다가 혼란 에 빠지게 된다. <잘못된 사례 ***톡 그룹만들기> 그룹채팅방에서 그룹만들기 기능을 이용하기 위해 버튼을 누르면 별도의 ***그룹앱으로 이 동된다. 하지만 시각장애인 사용자는 다른 앱 으로 전환된 것을 알지 못한다. 53

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

67 < 트위터의 글자크기 설정 화면 > < ibooks 폰트 크기 및 서체 설정 화면 > Ⅱ.4.2. 보조기술 호환성 보조기술을 통하여 사용자 인터페이스 컴포넌트를 인지할 수 있도록 해야 한다. Ⅱ 준수 필요성 시각장애인등의 사용자는 모바일기기에서 제공하는 장애인 보조기술을 사용하여 애플 리케이션을 이용하게 된다. 만약 애플리케이션의 사용자 인터페이스 컴포넌트가 보조기 술의 사용을 지원하지 않는다면 보조기술을 사용하는 장애인은 애플리케이션을 이용할 수 없는 상황에 처하게 된다. 애플리케이션에서 보조기술을 지원하는 가장 효과적인 방법은 기본사용자인터페이스 컴포넌트를 사용하는 것이나 부득이 사용자정의 컴포넌트를 사용할 경우 보조기술로도 접근할 수 있는 속성들을 반드시 제공해야 한다. 기본적으로는 사용자 인터페이스 컴포넌트가 어떤 유형(버튼, 슬라이더 등)인지 정보를 제공해야 한다. 시각장애인의 경우 디자인을 인지할 수 없으므로 컴포넌트의 종류에 따 라 조작하는 방법을 선택하게 되므로 사용자 인터페이스 컴포넌트의 유형을 명확히 제공 하는 것이 중요하다. Ⅱ 기술 구현 방법 모바일 애플리케이션 콘텐츠를 개발함에 있어 기본 사용자 인터페이스 컴포넌트를 최 대한 활용하는 것이 접근성을 높이는데 도움이 된다. 가. 애플의 ios에서 제공 방법 : Native UI Component에는 UIWindow, UILabel, UIPickerView 등이 있다. 특히 웹 페이지를 내장하는 페이지를 만들 경우에는 UIWebView를 통해 작성을 하게 된다. 부득이 커스텀 사용자 인터페이스 컴포넌트를 사 용할 경우 UIAccessibilityContainer protocol을 상속 받아 구현해야 한다. 나. 구글의 안드로이드에서 제공 방법 : Native UI Component에는 ImageView, Button 등이 있다. 부득이 커스텀 사용자 인터페이스 컴포넌트를 사용할 경우 관련 55

68 Accessibility 속성을 Enable 한 후 사용해야 한다. Ⅱ 구축 사례 대표적인 애플과 구글의 운영체제에서 제공하는 Native UI Component는 아래의 그림 과 같다. < ios에서의 Native UI Component > < 안드로이드에서의 Native UI Component > umentation/uikit/reference/uikit_framewor k/_index.html#//apple_ref/doc/uid/tp oid/widget/package-summary.html < 속성 정보를 제공하지 않은 잘못된 사례 > < 문제점 및 해결 방안 > o 문제점 - 해당 콘텐츠는 실행 시 답변을 볼 수 있는 기능이 제공되고 있으나 단순히 텍스 트 정보만 읽어주게 되어 기능의 유무를 인 식할 수 없음 o 해결방안 - 특정 기능이 실행되는 콘텐츠의 경우 해당 기능이 실행되는 것을 알 수 있도록 속성정보(버튼, 링크)를 대체 텍스트에 함 께 제공 56

69 <잘못된 사례 - ***톡 설정> 1. 개인정보 2. 카카오계정 3. 친구관리 4. 알림메세지 5. 알림설정 ON 설정목록에서 항목을 구분하는 텍스트와 하 위메뉴로 진입하느 버튼이 구분되지 않고 모두 일반텍스트인 것처럼 음성출력되고 있 다. 이로 인해 talkback 사용자는 어느 항목 을 실행할 수 있는지 어디에서 더블탭을 해 야할지 알 수 없는 상태이다. <바른사례 라인 메신저 설정화면 > 1. 알림 전환버튼 켬 2. 알림일시정지 off 버튼 3. 알림음 삼중음 버튼 설정 목록에서 기능이 있는 사용자 인 터페이스 컴포넌트를 보이스오버에서 전환버튼 혹은 버튼 으로 음성출력 하고 있다. <바른사례 nplayer 재생화면 동영상을 탐색하는 기능을 보이스오버 로 접근했을 때 다음과 같이 음성출력 한다. 트랙 위치 38 분12 초 조절 가능 값을 조절하려면 한 손가락으로 쓸어올리거 나 쓸어내리십시오 콘트롤의 종류, 현재값, 조작방법이 음 성으로 안내되고 있어 시각장애인이더 라도 보이스오버를 통해 영상을 탐색하 는 것이 가능하다. 57

70 표준 작성 공헌자 표준 번호 : 이 표준의 제정 개정 및 발간을 위해 아래와 같이 여러분들이 공헌하였습니다. 구분 성명 소속 및 직위 연락처 ( 등) 소속사 표준(과제) 제안 송재일 웹 프로젝트그룹 위원 jaeil@nia.or.kr 한국정보화진흥원 이성일 - silee@skku.edu 성균관대학교 문현주 웹 프로젝트그룹 위원 semulset@gmail.com 충북대학교 안동한 - hany92@nate.com 시각장애인연합회 표준 초안 작성자 김명운 - 삼성전자 서효진 - j22n22@gmail.com ( 前 )LG전자 조용규 - choco@conoz.ne 코노즈 윤성영 - 김혜일 - 캠프모바일 디케이테크인 표준 초안 검토 이승윤 웹 프로젝트그룹 의장 syl@etri.re.kr ETRI 외 프로젝트그룹 위원 표준안 심의 박승민 소프트웨어/콘텐츠 기술위원회 의장 외 기술위원회 위원 minpark@etri.re.kr ETRI 사무국 담당 김영화 - ykim@tta.or.kr TTA 이혜진 - hjlee@tta.or.kr TTA 58

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