앱에서 접근성 감사 수행하기

♪ ♪

안녕하세요, 저는 바비야입니다 접근성 팀의 엔지니어죠 오늘 세션에서는 여러분의 앱에 접근성 감사를 수행하는 방법에 초점을 맞추겠습니다 먼저 UI 테스트에서 자동화 접근성 감사를 수행하는 게 얼마나 쉬운지를 다룰 거고요 그리고 훌륭한 테스트 경험과 접근성 경험을 동시에 제공해 요소를 어떻게 노출하는지를 의논하겠습니다 접근성 감사부터 시작하죠 테스트는 앱 개발 과정의 기본적인 구성 요소입니다 테스트를 작성해 코드 출시 전에 버그를 잡아내고 해결하는 것으로 상품의 품질을 보장합니다 그리고 접근성 상품은 고품질 상품이죠 전 세계에서 7명 중 1명 꼴로 장애가 있으며 세상과 기기와 상호작용하는 데 영향을 받습니다 이들은 VoiceOver 같은 도구를 사용해 본인에게 가장 맞는 방법으로 앱과 상호작용하죠 고품질 상품을 제공한다는 의미는 앱에서 고품질 경험을 누릴 수 있도록 누구나 접근 가능한 앱을 제공한다는 뜻입니다 접근성이 깊고 복잡한 주제라는 것은 제 개인적인 경험으로 알고 있습니다 어떻게 하면 접근성 감사가 간단해질지를 탐구해 봅시다 Xcode는 접근성 검사기라는 도구를 탑재하고 있는데요 이 도구는 앱에서 간단하게 접근성 문제를 발견하고 진단해 해결할 방법을 제공하죠 이 도구를 활용하는 강력한 방법으로 앱에서 감사를 수행하는 것이 있습니다 검사기는 앱의 개별 뷰를 대상으로 일반적인 접근성 문제를 감사할 수 있죠

이건 제 예시 앱인데요 2개의 탭이 있습니다 첫 번째 탭은 동기를 부여하는 인용구를 제공하고요 두 번째 탭은 자기 반성을 위한 제 생각을 작성할 수 있습니다 인용구 탭에는 인용구가 표시된 텍스트 뷰가 있는데요 이 텍스트 뷰는 배경 이미지 앞에 위치하고 있죠 인용구를 새로 고침하는 '새 인용구' 버튼도 있습니다 이 앱에 접근성 검사기를 구동해 감사를 수행할 수 있는데요 검사기는 다양한 문제를 확인합니다 요소 설명을 충분히 제공하는지 적절한 대비를 보장하는지 등을요 그리고 발견된 문제는 각각 자세한 설명이 포함된 테이블로 표시되죠 이 강력한 접근성 감사를 이제 자동화할 수도 있습니다 UI 테스트에서 감사를 수행할 수 있죠 performAccessibilityAudit을 XCUIApplication에서 호출하면 현재 뷰의 접근성 문제를 감사합니다 마치 검사기처럼요 표명은 필요하지 않습니다 문제가 발견되면 테스트가 자동으로 실패하니까요 간단한 시연을 통해 실제로 어떤지 살펴보도록 하죠

Xcode에 예시 앱을 열었습니다 앱은 Swift에서 작성되었고 표준 UIKit 뷰를 활용하죠 이미 통과한 테스트가 몇 종류 있는데 화면에 요소가 존재하는지를 검증하는 것들입니다 가령 testQuoteTabView는 이미지 뷰와 텍스트 뷰가 인용구 탭에 존재하는지를 검증합니다 하나 주목해야 할 것은 이들이 접근성 테스트도 돕는다는 점이죠 이들 뷰가 접근성 요소이어야만 XCTest가 이들을 찾을 수 있습니다 이는 여러분의 UI 테스트가 요소를 찾을 수 있다면 보조 기술 역시 그럴 수 있다는 뜻이죠 이런 방법으로 접근성 테스트를 어느 정도 할 수 있는 건 좋지만 테스트에 감사를 조금 더 추가해 모든 종류의 문제를 잡으려고 합니다 testAccessibilityQuoteTab View라는 테스트를 추가하겠습니다 앱을 구동하고 인용구 탭으로 이동하도록 몇 가지를 설정하고요

마지막으로 performAccessibilityAudit을 앱에 호출합니다

감사는 문제를 여러 번 보고할 수 있기에 테스트가 첫 번째 실패 이후에도 문제를 계속 보고할 수 있도록 continueAfterFailure를 참으로 설정하겠습니다

다 됐군요 이제 테스트 마름모를 클릭해 테스트를 실행해 보겠습니다

테스트가 실패한 모양이네요 문제는 Xcode 소스 편집기에서 인라인으로 보고됩니다 감사가 잡아낸 문제는 2가지인데요 설명이 없는 요소와 사람이 읽을 수 없는 레이블입니다 문제가 되는 요소가 무엇인지 살펴봅시다 이 두 문제를 더 깊이 파헤치려면 Report navigator로 간 다음 Tests를 클릭하고 테스트 옆에 있는 펼치기 삼각형을 클릭합니다 이 뷰는 실행한 테스트와 문제를 상세하게 분석해서 보여 줍니다 첫 번째 문제인 '설명이 없는 요소'를 보려면 요소 스크린샷을 더블 클릭하면 되는데 이미지 뷰에 설명이 없는 게 보이네요 두 번째 문제도 비슷한 방법을 시도할 수 있습니다 텍스트 뷰의 레이블이 사람이 읽을 수 없다고 나오죠 이제 감사에서 발견된 문제를 처리하는 방법을 논해 봅시다 보조 기술에 의존해 앱을 사용하는 사용자가 겪을 수 있는 상호작용 또는 탐색 문제를 개별적으로 조사하고 해결하는 건 중요합니다 어떤 문제는 걸러내고 무시해야 하는 경우도 있다는 점을 인식하는 것도 중요하죠 문제가 거짓 양성이거나 예상대로 동작할 수도 있는데요 접근성 감사를 통해 이런 문제를 쉽게 무시할 수 있죠 문제를 무시하는 예시는 뒤에서 다루겠습니다 접근성의 모범 사례를 더 자세히 알아보고 싶으시면 2018년 세션인 '탁월한 접근성 경험 제공하기'를 확인하세요 감사에서 발견된 첫 문제를 조사해 보겠습니다 사람이 읽을 수 없는 텍스트 뷰의 접근성 레이블인데요 스토리보드에서 텍스트 뷰를 검사했더니 접근성 레이블이 QUOTE_TEXTVIEW로 설정되어 있군요 VoiceOver 같은 보조 기술에 의존하는 사용자는 접근성 레이블을 먼저 듣고 접근성 값을 듣게 될 겁니다 바로 이렇게요 'QUOTE_TEXTVIEW' '하루를 살더라도 최선을 다하라' 레이블은 듣기 좋지 않군요 이상적인 상황에서는 VoiceOver가 레이블을 건너뛰고 인용구만을 말해야 하죠 접근성 레이블을 지울 수는 있지만 그러면 UI 테스트가 망가질 겁니다 텍스트 뷰를 인식하려면 레이블이 있어야 하니까요 이상적으로는 이 문자열을 접근성 식별자로 설정해야 합니다 접근성 식별자를 사용하면 UI 테스트를 작성할 때 접근성이나 UI 경험에 영향 없이 요소를 독자적으로 식별할 수 있죠 스토리보드로 넘어가 보겠습니다

텍스트 뷰를 선택하고요 레이블에서 해당 문자열을 잘라 내어 식별자에 붙여 넣습니다

감사가 발견한 다른 문제는 설명이 없는 이미지 뷰죠 일반적으로 이미지는 설명적이면서도 간결한 레이블로 접근 가능한 것이 중요합니다 하지만 제 앱의 배경 이미지는 장식에 불과하죠 주요 콘텐츠도 아니며 인용구 자체에 의미를 더하지도 않습니다 이상적으로 VoiceOver 같은 기술은 이런 이미지 뷰를 건너뛰어야 하죠 뷰 컨트롤러 뷰에서 접근성 요소를 재정의해 이 동작을 달성할 수 있습니다 접근성 요소를 인용구 텍스트 뷰와 '새 인용구' 버튼으로 설정하면 더 이상 VoiceOver가 이미지 뷰를 건드리지 않죠 Xcode로 넘어가 직접 해 봅시다 뷰 컨트롤러 파일로 가서 accessibilityElements를 설정하죠

멋지군요 다시 감사로 돌아가겠습니다 이제 테스트 케이스를 실행해 문제가 해결됐는지 보죠

좋아요, 감사가 통과됐네요 UI 테스트 중 하나가 실패한 게 보이실 텐데요 그 부분은 나중에 보겠습니다 접근성 감사를 추가하면 걸러내야 할 문제가 있을 수 있는데요 예를 들어 감사에서 특정 레이블의 대비가 너무 낮다는 문제를 발견했다고 가정합시다 조사했더니 대비는 딱 좋았고 문제 부분은 거짓 양성으로 보였죠 이 문제를 무시할 방법을 탐구해 봅시다 performAccessibilityAudit 함수는 추가 매개 변수를 사용합니다 첫 번째 매개 변수를 사용하면 실행하려는 감사 범주의 옵션 묶음을 지정할 수 있는데요 이 범주는 동적 유형과 대비 등 이미 접근성 검사기에서 본 친숙한 범주죠 이 예시에서 감사하는 건 동적 유형 및 대비 문제로 한정하겠습니다 두 번째 매개 변수는 클로저를 지정할 수 있는데요 감사에서 문제가 발견될 때마다 이 클로저가 호출되며 어떤 문제를 무시하고 보고할지를 선택할 수 있게 합니다 우선 shouldIgnore라는 변수를 거짓으로 정의하겠습니다 기본 설정은 문제를 무시하지 않는 것이죠 '나의 레이블'이라는 레이블이 있는 요소의 대비 문제를 무시하겠다고 가정합시다

issue.element를 사용해 문제와 관련된 XCUIElement를 가져올 수 있습니다 '나의 레이블' 레이블이 이 요소에 있고 문제 유형이 대비 문제라면 올바른 문제를 잡은 것이므로 shouldIgnore를 참으로 설정합니다 참으로 설정한다는 것은 해당 문제를 무시하겠다는 뜻이죠 마지막으로 shouldIgnore를 반환합니다 위의 조건을 충족하지 못한다면 shouldIgnore는 거짓이 됩니다 이는 문제를 실패라고 보고해야 한다는 의미죠 이게 다예요 이 예시를 확장해 무시 조건을 사용자 지정할 수 있습니다 요소 유형이나 식별자 등 다른 속성을 사용해서요 여러분의 앱에 접근성 감사를 작성하겠다면 다음 고려 사항을 염두에 두시면 도움이 될 겁니다 감사는 화면에 있는 요소에만 한정됩니다 이는 전체 범위를 제공하려면 앱이 표시할 수 있는 모든 보기에 접근성 감사 테스트를 추가해야 한다는 뜻이죠 제 예시 앱의 경우 두 번째 탭으로 이동해 감사를 실행할 테스트를 더 추가해야 합니다 여러 테스트에 감사를 즉시 추가하는 빠른 방법은 teardown에서 감사를 재정의하고 수행하는 것입니다 클래스의 범위에서는 변수를 정의할 수 있는데요 이 방법이면 테스트가 변수를 재정의해 감사를 실행하거나 종료하도록 선택할 수 있으며 문제 무시에 사용하는 클로저를 테스트가 사용자 지정할 수 있죠 테스트 일정은 감사 특화 테스트를 그룹화하는 탁월한 방법인데요 테스트 일정 내 테스트 대상이나 사례 개별 메서드를 선택적으로 활성화할 수 있습니다 끝으로 감사는 보조 기술을 사용한 실제 테스트를 대체하면 안 됩니다 VoiceOver나 Dynamic Type 같은 기술을 활성화해 테스트하는 것이 고품질 경험의 보장에 궁극적으로 가장 좋은 방법이죠 아무 손해 없이 훌륭한 접근성과 테스트를 달성할 수도 있는데요 자동화 요소를 사용하면 해당 요소의 접근성에 영향을 주지 않고 자동화를 목적으로 해당 요소를 지정해 노출할 수 있습니다 이제 UIKit에서 이 API를 활용해 자동화에 필요한 정확한 요소를 노출할 수 있으며 동시에 이러한 요소의 접근성을 사용자 지정할 수 있습니다 조금 전 감사에서 문제를 해결했지만 UI 테스트 하나가 망가진 걸 기억하실 겁니다 해당 이미지 뷰는 더 이상 사용이 불가능해 보였죠 UI 테스트에서 누락된 이유는 접근성에도 누락됐기 때문인데요 이 이미지 뷰는 장식이기에 접근성 요소를 재정의하여 접근성으로부터 뷰를 제외했죠 하지만 그것 때문에 UI 테스트에도 제외된 겁니다 자동화 요소로 UI 테스트에 이미지 뷰를 노출할 방법을 탐구해 봅시다 Xcode에서 뷰 컨트롤러 파일을 열고요

그리고 뷰 컨트롤러 뷰에 automationElements를 이미지 뷰로 설정합니다 automationElements를 재정의할 때 자동화에 노출되어야 할 요소를 모두 지정해야 하는 걸 유념하세요

이는 텍스트 뷰와 버튼을 목록에 추가해야 한다는 뜻이죠 자동화 요소를 재정의하면 기존에 자동화에 노출된 요소도 재정의하게 됩니다 테스트 케이스를 실행해 통과하는지 살펴봅시다

멋지군요 오늘 우리는 훌륭한 UI와 접근성 테스트를 작성했으며 몇몇 접근성 문제도 해결했습니다 접근성 감사는 앱에 자동화 접근성 테스트를 쉽게 추가할 수 있는 환상적인 방법입니다 감사에서 식별된 문제를 해결하는 것은 모두가 앱을 즐기도록 보장하고요 하나를 희생할 필요 없이 훌륭한 접근성과 자동화 경험을 모두 생성하세요 자동화 요소를 사용하면 접근성 경험에 영향을 미치지 않고 UI 테스트로 해당 요소를 지정해 노출할 수 있습니다 performAccessibilityAudit를 위한 간단한 호출을 UI 테스트에서 추가하는 것을 권장합니다 감사합니다