GN⁺: "어머나, 내 앱이 성공했는데 접근성을 고려하지 않았네"

SwiftUI에서 a11y(접근성) 빠르게 적용하기

• SwiftUI 앱에서 접근성을 간과한 경우, 이를 신속하게 해결하는 방법 제시.
• 접근성은 사용자의 16%가 요구하는 중요한 기능임에도 개발 중 종종 무시됨.
• 접근성을 고려하지 않은 앱은 사용자에게 부정적인 인상을 줄 수 있음.

앱의 접근성 검사하기

• 실제 기기에서 접근성을 테스트하는 것이 중요함.
• 제어 센터를 최적화하여 접근성 기능을 빠르게 적용할 수 있도록 설정.

텍스트 크기 검사

• iOS에서는 12가지 텍스트 크기를 제공하며, 이를 테스트하여 앱이 각 크기에 잘 맞는지 확인.
• 가장 큰 텍스트 크기에서도 UI가 잘 작동하는지 검사 필요.

화면 낭독기 검사

• 화면 낭독기를 사용하는 사용자를 위해 VoiceOver와 같은 도구를 사용하여 접근성을 검사.
• 이미지에 접근성 라벨을 추가하는 것과 같은 간단한 수정으로 큰 개선 가능.

접근성 빠르게 적용하기

• 문제를 파악한 후, 하나씩 신속하게 해결.

스크롤 가능한 콘텐츠

• 텍스트 크기가 커질 때 스크롤 뷰로 콘텐츠를 확장하여 문제 해결.
• a11yScrollView()라는 커스텀 뷰 수정자를 사용하여 필요할 때만 콘텐츠를 스크롤 가능하게 함.

공간 확보 코드 냄새

• Spacer() 대신 frame() 수정자를 사용하여 더 신뢰할 수 있는 레이아웃을 구성.

이미지 및 아이콘 크기 조정

• @ScaledMetric 속성 래퍼를 사용하여 사용자의 텍스트 크기에 따라 이미지와 아이콘을 동적으로 조정.

콘텐츠 정렬

• 사용자의 텍스트 크기에 따라 콘텐츠를 정렬할 수 있는 A11yHStack을 사용.

화면 낭독기 개선

• accessibilityLabel, accessibilityElement(children:), accessibilityRepresentation 등을 사용하여 화면 낭독기와의 호환성 향상.

네이티브 컴포넌트 사용

• 가능한 한 네이티브 SwiftUI 컴포넌트를 사용하여 성능과 접근성을 향상.

이해 관계자 설득하기

• 접근성을 중요하게 여기도록 조직 내에서 영향력을 발휘하는 방법.
• 법적 요구사항과 비즈니스 이점을 강조하여 접근성의 중요성을 부각.

결론

• 앱의 접근성 문제를 식별하고 해결하는 방법에 대한 전반적인 과정을 설명.
• 접근성을 향상시키기 위해 SwiftUI에서 제공하는 다양한 도구와 기술을 소개.

GN⁺의 의견

• 이 기사는 앱 개발자들에게 접근성이 중요한 이유와 실제로 접근성을 개선하는 구체적인 방법을 제공함으로써 매우 유익함.
• 접근성을 고려하지 않은 앱은 사용자 경험을 저하시키고 법적 문제를 초래할 수 있어, 개발 초기 단계부터 접근성을 고려하는 것이 중요함.
• SwiftUI와 같은 현대적인 프레임워크를 사용할 때는 네이티브 컴포넌트의 장점을 최대한 활용하여 성능과 접근성을 동시에 향상시킬 수 있음.
• 접근성을 개선하기 위해 커뮤니티에서 제공하는 라이브러리나 도구를 활용하는 것도 좋은 방법이며, 이를 통해 개발 과정을 간소화하고 효율을 높일 수 있음.
• 앱의 접근성을 개선하는 것은 단순히 기술적인 문제를 넘어 사회적 책임과 포용성을 실천하는 것으로, 모든 사용자가 동등하게 서비스를 이용할 수 있도록 하는 것이 중요함.

[aer0700]

접근성을 고려하는 게, 내 서비스에 충성적인 고객을 만드는 방법일 수도 있겠네요
비슷한 경쟁 서비스가 해당 기능을 지원 않는데, 우리 앱만 그걸 지원한다면, 고객은 우리 것을 쓸 테니까요

[godrm]

오호 이건 레츠스위프트에서도 소개해야겠습니다 ㅎㅎ

[neo]

Hacker News 의견

• 첫 번째 댓글 요약:

  개발자는 "앱을 모두가 사용할 때까지 멈추지 않겠다"는 저자의 주장에 동의하지 않음. 개발한 모든 앱은 비즈니스 요구사항이나 앱의 중요/핵심적인 측면을 희생하지 않으면서도 최대한 많은 사용자에게 맞춰 개발됨. 그렇지 않으면 사용할 수 없는 제품이 될 것임.

• 두 번째 댓글 요약:

  개발자는 자신의 앱을 시각 장애가 있는 사람들도 사용할 수 있도록 최선을 다함. 최근 앱에서는 장애가 없는 사람들도 사용하기 쉽고, 장애가 있는 사람들에게 보상을 제공하는 방법을 찾음. UI의 어떤 요소든 길게 누르면 해당 요소를 설명하는 팝오버가 나타나는 '롱-프레스 도움말' 기능을 추가함. 이 기능은 접근성 레이블과 힌트를 사용하여 잘 작동함.

• 세 번째 댓글 요약:

  실용적인 기사에 대한 긍정적인 평가. 접근성은 중요하지만, 앱을 기본적으로 접근성이 좋게 만들지 않는 개발자들을 게으르다고 비난하는 것은 문제가 있다고 생각함. 배워야 할 개념이 많고, 우선순위가 충돌하며, 익숙해져야 할 도구들이 있으며, 접근성을 위한 비즈니스 케이스를 만드는 것도 필요함. 대부분의 개발자와 디자이너는 WCAG 규칙에 대해 잘 알지 못함. 색상 대비 요구사항을 충족하는 브랜드 색상을 찾는 것도 어려움.

• 네 번째 댓글 요약:

  개발자는 Flutter를 사용하여 접근성을 고려하지 않고 앱을 만들었지만, 앱을 사용한 지 6개월 된 시각 장애인 사용자로부터 불만을 받음. Flutter는 대부분의 접근성을 자동으로 처리해주며, 맞춤형 기능도 시각 장애인 사용자를 위해 크게 수정할 필요 없이 잘 작동함.

• 다섯 번째 댓글 요약:

  왜 접근성 옵션을 시각적으로 우선시하고 정밀하며 터치 밀도가 높은 매체에 주석을 달아야 하는지에 대한 의문 제기. "저시력" 버전이나 "저 터치 정확도" 버전과 같이 접근성을 필요로 하는 사용자에게 맞춤화된 앱을 제공하는 것이 더 나을지도 모름.

• 여섯 번째 댓글 요약:

  새로운 앱이나 스타트업이 예상보다 훨씬 빠르게 성공할 경우 법적 책임이나 유예 기간에 대한 질문. 아이디어가 작동할지 확실하지 않을 때 접근성은 큰 걱정거리가 아닐 수 있으며, 캘리포니아 외의 지역에서는 예상치 못한 성공 후 접근성 문제를 해결하기 위해 자원을 할당하는 경우 법적으로 크게 문제가 되지 않을 것으로 생각함.

• 일곱 번째 댓글 요약:

  개발자의 아버지가 뇌졸중으로 인해 전동 휠체어를 사용한 경험을 공유. ADA 준수의 중요성을 깨닫고, 개발자로서 세상을 접근 가능하게 만드는 데 큰 역할을 할 수 있음을 강조. 개발자들에게 자신의 작업을 가능한 모든 사람에게 접근 가능하게 만들기 위한 노력을 당부함.

• 여덟 번째 댓글 요약:

  iPhone의 '더 큰 텍스트'와 '디스플레이 줌' 옵션을 활성화한 사용자의 경험 공유. 이는 장애가 있는 사람들뿐만 아니라 모든 사용자가 자신의 사용 스타일에 맞게 인터페이스를 조정할 수 있는 유연성과 제어에 관한 것임. 때로는 화면을 보고 싶지 않을 때 화면을 읽어주거나 특정 부분만 읽어주기를 원할 수 있음.

• 아홉 번째 댓글 요약:

  접근성이 필요한 커뮤니티는 일반적으로 먼저 요청하고 나중에 소송을 제기하는 경향이 있음. ADA는 강력한 법이며, 노력을 기울이면 일반적으로 문제가 되지 않음. 2000년경에 변호사의 감독 하에 접근성 가이드를 작성했으며, 이후에도 시각 장애인 사용자와 협력하여 앱에 접근성을 추가함. 누군가 요청하면 도와주고, 그렇게 하면 당신이 하는 일에 대해 강력한 지지자를 얻을 수 있음.

• 열 번째 댓글 요약:

  앱이 성공한 이유는 접근성(a11y)이나 국제화(i18n)와 같은 불필요한 것들에 시간을 낭비하지 않았기 때문임. 역사적으로 모든 성공적인 제품은 처음부터 접근성이나 국제화에 초점을 맞추지 않았음. 이제 앱이 성공적이므로 접근성에 대해 생각하고 자원을 투입할 수 있음.