나는 왜 더 이상 동료 시각장애 컴퓨터 사용자들에게 Mac을 추천할 수 없는지
(applevis.com)- Mac에서 VoiceOver로 Safari를 사용할 때 “Safari not responding”이 반복되며 몇 분간 멈추는 문제가 오래 지속돼, 시각장애·저시력 사용자의 일상 작업을 직접 막고 있음
- Safari뿐 아니라 WebKit 기반 애플리케이션에서도 비슷한 응답 없음이 나타날 수 있어, macOS 접근성 전반에 대한 신뢰를 흔듦
- 사용자가 앱 전환이나 VoiceOver 재시작으로 빠져나올 때도 있지만, 전환조차 못 하고 Mac이 다시 반응할 때까지 기다려야 하는 경우가 많음
- 이 문제가 여러 macOS 버전에 걸쳐 해결되지 않으면서, VoiceOver 의존 사용자에게 Mac은 Safari와 관련 앱에서 예측하기 어려운 플랫폼이 됨
- Apple 접근성 팀에 실제 피해를 전달하고, 해결 전까지 새 Mac 구매나 추천을 보류하는 방식의 정중한 압박이 필요함
“Safari not responding”이 만드는 사용 불능 상태
- Mac에서 VoiceOver를 사용할 때 Safari가 응답하지 않는 오래된 문제가 있으며, VoiceOver는 “Safari not responding” 메시지를 반복해서 알림
- 문제가 발생하면 Mac이 한 번에 최대 몇 분 동안 사실상 사용할 수 없는 상태가 될 수 있음
- 일부 상황에서는 Safari에서 다른 앱으로 전환하거나 VoiceOver를 재시작해 빠져나올 수 있음
- 하지만 너무 자주 사용자는 Safari에서 벗어나거나 VoiceOver를 끌 수 없고, Mac이 다시 반응할 때까지 기다려야 함
- 관련 문제는 AppleVis의 Safari/WebKit applications can become unresponsive when using VoiceOver에 정리돼 있음
Safari를 넘어 WebKit 기반 앱까지 이어지는 영향
- “Safari not responding” 동작은 시각장애·저시력 사용자의 생산성과 Mac의 전반적 사용성을 크게 떨어뜨림
- Safari에만 한정되지 않고, Apple의 WebKit 브라우저 엔진을 사용하는 여러 일반 앱도 “not responding” 문제의 영향을 받을 수 있음
- 일상 작업은 물론 중요한 작업 중에도 Safari와 다른 앱에서 버그가 발생해, macOS 경험이 불안정하고 답답해짐
고사양 Mac에서도 피하기 어려운 문제
- 문제는 Mac의 사양 수준과 무관하게 발생함
- 최신 Apple silicon 탑재 Mac과 16GB 이상 RAM을 갖춘 기기에서도 널리 경험됨
- 고급형 최신 Mac 하드웨어를 쓰는 사용자도 이 치명적인 VoiceOver 버그에서 벗어나기 어려움
수년간 누적된 접근성 신뢰 손상
- 이 핵심 문제는 여러 macOS 버전에 걸쳐 수년간 지속됐고, Apple은 영구 수정판을 내놓지 못함
- 지속 기간과 Safari·다른 앱 전반의 방해 수준 때문에, VoiceOver에 의존하는 사용자에게 Mac을 더 이상 선의로 추천하기 어려운 상태가 됨
- 단, Mac만 충족할 수 있는 특정 사용 사례가 있는 경우는 예외로 남음
- Mac은 전통적으로 시각장애 커뮤니티에서 인기가 있었고 좋은 접근성 기능도 제공함
- 그러나 Apple이 이 문제를 오래 방치한 점은 회사가 자주 말해 온 접근성 약속에 심각한 의문을 남김
- 시각 사용자들이 유사한 문제를 겪었다면 상당한 언론 보도와 Apple의 긴급 수정이 있었을 것이라는 비판도 나옴
같은 가격을 내는 고객에게 필요한 기준
- “더 나은 대우”는 시각장애인이거나 접근성 기능을 쓴다는 이유로 특권을 요구한다는 뜻이 아님
- 시각장애·저시력 사용자도 다른 고객과 같은 프리미엄 가격을 지불하고 Mac을 구매함
- 대부분의 Mac 사용자와 달리, VoiceOver 사용자는 하루에도 여러 번 비싼 기기가 몇 분 동안 쓸모없는 물건이 되는 상황을 감수해야 함
- 장애와 VoiceOver 사용은 Apple에 기대해야 할 기준을 낮추지 않음
- 오히려 Apple은 시각 사용자와 동등한 경험을 제공해야 할 책임을 더 크게 짐
재현이 어려운 버그라는 제약
- Apple 엔지니어링 팀이 이 문제를 해결하는 데 어려움을 겪을 수 있다는 점은 인정할 수 있음
- 사용자 보고에 따르면 “Safari not responding” 동작을 일관되게 재현하는 방법이 없어 보임
- 같은 웹페이지가 여러 번 정상 동작하다가 갑자기 멈춤을 유발할 수 있음
- 사용자, 기기, 구성에 따라 차이가 있어 근본 원인을 격리하고 수정하기 어렵게 만듦
- 그럼에도 Apple이 가진 엔지니어링 인재와 자원을 고려하면 이 도전이 극복 불가능해서는 안 됨
Apple에 직접 압박을 높이는 방식
- VoiceOver 사용자를 오래 괴롭힌 “Safari not responding” 버그를 Apple이 우선순위에 두고 영구 해결하도록 요구를 높여야 함
- Mac에서 VoiceOver를 쓰는 사용자는 Apple 접근성 팀에 직접 연락해 자신의 경험과 불만을 공유할 수 있음
- Apple 접근성 팀: accessibility@apple.com
- Apple CEO Tim Cook의 공개 이메일을 참조로 넣는 방식도 제안됨: tcook@apple.com
- 압박은 직접적이되 정중하고 건설적이어야 함
- Tim Cook에게도 지속 중인 버그가 Apple의 시각장애·저시력 고객에게 미치는 직접 영향을 알려야 함
다른 macOS 접근성 문제와 구매 보류 요구
- “Safari not responding”은 Mac의 시각장애·저시력 사용자에게 영향을 주는 유일한 문제가 아님
- macOS Sonoma의 문제와 응답을 다룬 최근 글에도 여러 불만과 실패 사례가 정리돼 있음
- 그럼에도 이 버그는 Apple의 전반적인 접근성 성과와 접근성에 대한 헌신을 재는 척도가 됨
- Apple은 상당한 기간 이 척도에서 실패해 왔음
- 사용자는 이 문제를 공개적으로 말하고, “Safari not responding” 문제가 완전히 해결될 때까지 새 Mac을 구매하거나 추천하지 않는 방식으로 소비자 압박을 가해야 함
- Apple은 시각장애·저시력 고객에게 Mac이 안정적이고 완전히 접근 가능한 경험을 제공한다는 신뢰를 회복해야 함
댓글과 토론
Hacker News 의견들
-
시각장애인 개발자 입장에서 MacOS의 VoiceOver는 누구에게도 추천하기 어렵다. 시력을 잃기 전에는 Apple 팬이었지만, 이후 Windows로 옮길 수밖에 없었고 2016년에 Mac VoiceOver를 배울 때도 너무 답답했다
Terminal 앱의 텍스트 영역 조작은 명령 순서가 비결정적으로 느껴질 만큼 불안정했고, Windows의 평면 탐색보다 Mac의 계층형 탐색은 훨씬 번거로웠다
XCode에서 프로젝트 설정 하나에 접근하려면 패널 안의 하위 패널을 9단계까지 내려가야 했고, 한 번만 실수해도 엉뚱한 곳으로 갔다
외국어 웹페이지 검색도 Command+F가 영어 자판에서만 동작하고 VoiceOver 검색창 안에서는 다른 자판 전환이 안 돼서 막혔다
브라우저에서 링크를 새 탭으로 여는 쉬운 방법도 Windows의 Control+Enter에 비해 부족했고, Fn+Ctrl+Option+Command+Up/Down 같은 5키 단축키는 왼쪽 손목 통증까지 만들었다
Apple은 버그 수정에는 관심이 적고 WWDC에서 접근성을 챙긴다는 번쩍이는 슬라이드를 보여주는 데 더 신경 쓰는 인상이었다
Windows에서는 JAWS가 훨씬 편하고, NVDA는 오픈소스라 문제가 있으면 직접 고칠 수 있어 가장 선호한다. 화면낭독기 시장도 JAWS와 NVDA가 각각 약 45%, VoiceOver는 약 10%라서 Windows 화면낭독기를 배우는 편이 훨씬 낫다고 본다- Fn+Ctrl+Option+Command+Up/Down 같은 5키 단축키는 말도 안 된다. 손가락 제어가 완전하지 않거나 떨림이 있는 사람에게는 사실상 불가능하고, Apple은 쌓아둔 현금 중 몇백만 달러라도 써서 이런 문제를 제대로 고쳐야 한다
- Apple의 접근성은 지속가능성, 환경, 어쩌면 개인정보 보호와도 비슷하게 실제 내용보다 마케팅과 서사 장악에 가까워 보인다
- iOS VoiceOver와 rotor에 대해서는 어떻게 보는지 궁금하다
-
2년 넘게 MacBook Air M1을 주 Mac으로 쓰고 있는데, 이 문제가 글쓴이가 말하는 것만큼 심각하진 않았다. Mac OS 12 무렵에는 훨씬 큰 문제였지만 그때도 Cmd+Option+Q로 “종료하고 창 유지”를 하면 꽤 빨리 해결됐다
VoiceOver에도 문제가 많지만 Windows 화면낭독기도 마찬가지고, Mac에서는 접근성을 깨뜨리는 업데이트를 미룰 수 있다는 점이 좋다. Windows에서는 그게 안 돼서 운영체제를 바꾸게 된 주요 이유 중 하나였다- 이제 그런 문제가 없다니 다행이지만 내 경우는 다르다. 2019 MBP라 M1도 아니고, M2 모델에서도 영향이 있다는 말을 듣고 바로 살 만큼 여유도 없다. 생산성을 크게 멈추는 문제에는 베팅하고 싶지 않다
- 기본값을 바꿔서 Cmd+Q가 창을 유지하며 종료하고, Cmd+Option+Q가 창을 버리고 종료하게 만들 수도 있다. Safari에만 이렇게 설정해 두니 훨씬 낫다
-
시각장애인은 아니고 이 분야 경험도 없지만, Apple Store 직원이 시각장애인에게 VoiceOver 사용법을 안내하는 장면은 꽤 인상적이었다. 적어도 매장 직원 일부는 접근성 기능 교육을 받는다는 뜻으로 보인다
- 때로는 시각장애인을 직접 채용해서 그 일을 맡기기도 한다. 처음 Mac을 알아보러 갔던 Apple Store에도 그런 직원이 있었지만, 몇 년 뒤 다른 분야로 옮겼다고 들었다
- 지금은 일부 매장에서 그럴 수도 있겠다. 10년 전 겪었던 일을 혹평한 글 덕분이라고 믿고 싶기도 하다: https://liam-on-linux.livejournal.com/18605.html
당시 처우는 우리 기준으로 충격적으로 나빴고, 전혀 겸손하게 말할 생각도 없다
-
운영체제 전반의 구조적 문제를 기대했는데, 겉으로는 WebKit의 특정 버그 하나처럼 보인다. 다만 macOS Sonoma 문제 글과 답글도 링크돼 있고, 영향을 받는 사용자에게는 상당히 치명적인 버그이며, 이런 버그가 제품에 들어갔다는 사실 자체가 조직의 구조적 문제 증상일 수도 있다
- 더 넓은 문제를 다룬 글도 따로 있고, 이 글은 그중 최악의 사례를 강조한 것에 가깝다. 시각장애인과 장애 사용자를 지원하려는 웹 개발자로서 이제 깊이 파고드는 중인데, 웹 사용 기준으로는 VoiceOver가 세 주요 화면낭독기 중 최악이다
현대적인 ARIA 속성 표준 지원에서 크게 뒤처졌고, 실제로는 많은 속성을 완전히 무시해서 VoiceOver에서 의도한 화면낭독기 동작을 항상 구현할 수 없다
Safari와 마찬가지로 Apple은 VoiceOver 지원도 말뿐인 것처럼 보이며, 완전 시각장애인들은 다른 선택지가 없을 때만 VoiceOver를 쓰는 듯하다. 많은 온라인 통계는 운영체제 사용과 웹 사용을 섞어 이 사실을 흐린다 - 하루 종일 무작위로 몇 분씩 멈추면서 소리까지 지르는 기계를 참을 수 있겠나
- 결함 하나만으로도 플랫폼이 100% 망가질 수 있다
- 시각장애인에게 이 문제는 정안인에게 모니터가 주기적으로 쉬러 가는 것과 비슷해 보인다. 세 번째쯤 겪으면 정말 지칠 것이다
- 인터넷을 아예 못 쓰게 만드는 버그 하나는 단순히 불편하게 만드는 버그 수백 개보다 훨씬 나쁘다
- 더 넓은 문제를 다룬 글도 따로 있고, 이 글은 그중 최악의 사례를 강조한 것에 가깝다. 시각장애인과 장애 사용자를 지원하려는 웹 개발자로서 이제 깊이 파고드는 중인데, 웹 사용 기준으로는 VoiceOver가 세 주요 화면낭독기 중 최악이다
-
흥미로운 관점이지만 제목은 꽤 자극적이다. 장애인, 그중 시각장애인도 여러 명 대리하는 변호사로서, 내 시각장애 의뢰인들은 모두 Apple 제품에 깊이 의존하고 있고 접근성 기능이 다른 선택지보다 월등하다고 말한다
- 시각장애를 더 잘 보완해 줘서 10년 쓰던 MacOS에서 Linux/Wayland로 옮겼다. 백내장이 있어 화면의 모든 것을 크게 만드는 게 도움이 되는데, MacOS도 가능은 하지만 배율이 정확히 1 또는 2가 아니면 흐릿해지고, 2배는 가로 해상도가 너무 줄어 일부 웹사이트에서 곤란하다
1080p 모니터에서 2배 배율이면 뷰포트가 960픽셀밖에 안 된다
반면 Linux/Wayland는 1.0, 1.25, 1.5, 1.75, 2.0, 2.25 배율을 제공하고, 몇 달째 1.75를 쓰고 있다
Windows도 Linux/Wayland와 비슷하게 동작한다. 최신 OS에 맞게 업데이트되지 않은 앱은 흐릿해지긴 하지만, 이 부분에서 MacOS는 확실히 뒤처져 있다 - iPhone은 정말 좋아한다. 하지만 컴퓨터 운영체제라면 Windows를 쓴다. Logic Pro나 M1 칩 때문에 Apple을 고수하려는 사람도 있지만, 컴퓨터를 가진 시각장애인 중 85% 정도는 Windows를 쓴다고 본다
- 덴마크의 지역 시각장애인 커뮤니티 사람들과 일해 봤는데, iPhone은 많이 보였지만 컴퓨터는 모두 Windows를 썼다
- 장애인을 부를 때는 장애 자체보다 사람을 중심에 두는 표현이 좋다. 예를 들어 “the blind”보다 blind people이 낫다
그리고 여기서 다루는 건 Apple 접근성 전체가 아니라 Mac OS의 VoiceOver라는 특정 영역이다. iPhone의 iOS와 iPad OS는 대체로 Android보다 낫지만 문제는 있다
다만 지금 문제는 실제로 존재하고, 전문가에게는 매우 큰 불편을 준다 - 휴대폰에서는 Apple이 확실히 강하지만, 컴퓨터에서는 아니다. Windows의 NVDA는 훌륭하고 계속 좋아지고 있다
- 시각장애를 더 잘 보완해 줘서 10년 쓰던 MacOS에서 Linux/Wayland로 옮겼다. 백내장이 있어 화면의 모든 것을 크게 만드는 게 도움이 되는데, MacOS도 가능은 하지만 배율이 정확히 1 또는 2가 아니면 흐릿해지고, 2배는 가로 해상도가 너무 줄어 일부 웹사이트에서 곤란하다
-
대안으로 무엇을 추천할지 궁금하다. 내가 알기로는 Mac이 접근성 면에서 꽤 큰 차이로 가장 낫다
- Windows와 JAWS 또는 NVDA가 꽤 주류이고, 접근성 기능도 잘 이해되고 지원된다. VoiceOver는 그보다 덜하다. 접근성의 한 측면만 다루는 이야기지만, 그 분야에서는 대략 80% 점유율을 가진다
- 북미의 시각장애 컴퓨터과학·공학 전공 학생들을 대상으로 한 설문을 마지막으로 봤을 때, 대다수가 화면낭독기로 JAWS를 선호했다. 이는 곧 Windows를 뜻한다
- Microsoft는 실제로 접근성을 꽤 진지하게 다룬다
- 우리 대부분은 Windows를 쓴다
- Mac이 접근성 면에서 최고라고 알았다면, 이제는 다르게 알게 된 셈이다
-
독일어 TTS에는 숫자 앞뒤로 “Homograph”라는 단어를 붙이는 잘 알려진 버그가 반년쯤 이어지고 있다. 그 기술에 의존하는 사람들에게는 부끄러운 일이다
-
글과는 조금 벗어나지만, 시각장애인이 Linux에서 쓸 만한 좋은 도구가 있는지 궁금하다
- 점자 디스플레이와 점자 터미널에는 BRLTTY, 사용자 공간 명령줄 화면낭독기에는 Fenrir, 그래픽 화면낭독기에는 Orca가 있다
Orca는 다른 앱을 시작하기 전에 먼저 실행하는 게 좋다. 접근성 내보내기 변수와 ATSPI 관련 처리를 해 주기 때문이다
정확히 이해하진 못하지만 혹시 몰라 .profile에 export linux-a11y = 1 같은 의식을 아직도 해 둔다. 정확한 변수명은 아니지만 목록은 어딘가에 있다
점자 엠보서와 프린터 출력에는 cups-filters가 있고, 주요 배포판은 거의 엠보서 드라이버를 갖춘 듯하다
Linux는 imagemagick으로 이미지를 점자 그래픽으로 변환할 수도 있다. Windows는 엠보서 드라이버도 기본 제공하지 않고, 그래픽 출력은 더더욱 없다
GUI Linux 접근성이 더 좋았다면 좋겠다. 기반은 이미 꽤 좋고, 거의 어떤 점자 디스플레이도 지원하지만 TTS 엔진은 그리 좋지 않다 - Linux에서 더 눈에 띄는 화면낭독기 중 하나는 Orca다: https://help.gnome.org/users/orca/stable/index.html.en
몇 년 전 테스트로 잠깐 써 봤지만, 전반적으로는 Windows의 NVDA와 JAWS가 더 나은 선택지일 가능성이 크다
- 점자 디스플레이와 점자 터미널에는 BRLTTY, 사용자 공간 명령줄 화면낭독기에는 Fenrir, 그래픽 화면낭독기에는 Orca가 있다
-
개발자 관점에서는 정말 답답하다. 나쁜 사용자 경험을 만드는 문제처럼 보이지만, 적어도 글에는 재현 절차가 없다
가끔만 나타나는 버그는 충분히 드물면 잡아내기가 정말 어렵다. Apple의 지표가 내 것보다 낫겠지만, 그래도 문제를 포착하는 것 자체가 힘들 때가 있다
Apple에서는 WebKit, Safari, VoiceOver/Accessibility처럼 여러 팀이 함께 고쳐야 할 수도 있고, 각자의 방식이 있어 한 팀이 고치는 문제보다 복잡할 수 있다
물론 결국 우선순위 문제일 수도 있다. 몇 년째 남아 있는 버그나 OS 버전이 바뀔 때마다 생겼다가 계속 남는 회귀도 있으니까- 그 “복잡함”은 오히려 Apple에 유리해야 한다. 여러 부품을 완전히 다른 회사들이 책임질 때 문제가 고쳐지기는 더 어려울 수밖에 없다
-
Apple은 예전에는 특히 iPhone에서 좋은 접근성 경험을 만드는 데 뛰어났다. macOS 접근성은 거의 쓰지 않아 많이 말하긴 어렵지만, Android와 Windows에서 각각 Google과 Microsoft가 따라잡고 있다고 본다