스크롤바가 문제가 되고 있다

• 스크롤바가 점점 작아지거나 숨겨지면서, 스크롤 휠·터치 제스처를 쓰기 어려운 사용자뿐 아니라 문서 안에서 빠르게 위치를 옮기려는 사용자에게도 실제 사용성 문제가 됨
• 미세 운동 제어가 어렵거나 아이트래커처럼 정확도가 제한적인 포인팅 장치를 쓰는 사용자는 8픽셀 폭의 스크롤바를 맞히기 어렵고, 음성 제어 사용자도 반복 스크롤 대신 원하는 위치를 직접 클릭하고 싶어함
• GTK, Qt, Firefox, Chrome, Electron에서는 스크롤바 폭·표시 방식 조정이 가능하더라도 CSS 수정, gsettings, about:config, 테마 재컴파일, 앱별 설정처럼 일반 사용자가 접근하기 어려운 방식에 의존함
• 예전에는 누르고 있으면 조금씩 이동하는 스크롤 버튼이 있었지만 조용히 사라졌고, 화살표 키는 일부 기능을 대신해도 포커스 상태에 따라 동작이 달라짐
• 문서 미니맵처럼 콘텐츠를 보며 큰 클릭 영역으로 이동할 수 있는 UI는 아이트래커와 태블릿 펜 사용자에게도 유용한 대안적 탐색 방식이 될 수 있음

---

작아지고 숨겨지는 스크롤바

• 스크롤바는 클릭하고 드래그해 스크롤 가능한 영역 안에서 현재 위치를 바꾸는 기본 UI임
• 최근 스크롤바가 너무 작아져 스크린샷으로 보여주기조차 어렵고, 더 작게 만들거나 숨기는 흐름이 사용성을 해침
• “스크롤 휠을 쓰면 된다”는 접근은 모든 사용자가 스크롤 휠이나 터치스크린 스와이프를 쓸 수 있다는 전제를 깔고 있음
• 스크롤 휠을 잘 쓰는 사용자도 때로는 특정 위치로 빠르게 점프하고 싶을 수 있음

접근성에 미치는 영향

• 미세 운동 제어에 어려움이 있는 사용자는 얇은 스크롤바를 정확히 잡기 어려움
• 아이트래커 같은 포인팅 장치는 인상적이지만, 8픽셀 폭의 스크롤바를 안정적으로 맞히기에는 부족함
• 음성·소리로 컴퓨터를 제어하는 사용자는 Talon Voice 같은 도구를 쓰더라도 scroll down 반복이나 자동 스크롤보다, 스크롤바에서 원하는 위치를 보고 클릭하는 방식을 선호할 수 있음
• 2015년에도 GTK3 스크롤바 폭 문제가 논의됐으며, 얇은 스크롤바는 비기술 사용자와 손 조작·시각 문제를 가진 사용자에게 부담을 줌

스크롤바가 덜 쓰기 쉬워진 방식

• 일부 경우 스크롤바 폭은 픽셀 기준으로 그대로지만, 모니터 해상도가 높아지면서 실제 조작 대상은 더 작아짐
• 다른 경우에는 스크롤바 자체가 실제로 더 작아짐
• 과거 Ubuntu가 시도했던 매우 얇은 스크롤바 사례도 언급됨
• 스크롤바가 줄어드는 동안, 누르고 있으면 조금씩 이동하는 스크롤 버튼도 사라짐
  • 화살표 키가 일부 기능을 대신하지만, 현재 어떤 콘텐츠에 포커스가 있는지에 의존함
  • 버튼은 포커스 상태와 무관하게 쓸 수 있었음
• 대체로 스크롤바는 덜 쓸 만해졌고, 이를 고칠 사용자 설정은 없거나 일반 사용자가 찾기 어려운 기술 스택 안에 묻혀 있음

GTK 설정의 장벽

• GTK2에서는 gtkrc에서 스크롤바 폭을 직접 바꿀 수 있었고, 이를 위한 GUI 프로그램도 있었음
• GTK3에서는 CSS로 조정해야 하며, 테마를 이해하지 못하면 사용자 친화적인 설정 방법이 부족함
• Reddit 스레드에는 GTK3·GTK4의 gtk.css에 slider { min-width: ...; min-height: ...; }를 추가하고 Flatpak 오버라이드와 overlay scrolling 설정까지 처리하는 스크립트가 소개됨
• Flatpak 앱은 별도 오버라이드가 필요해 시스템 테마가 그대로 적용되지 않을 수 있음
• GTK는 기본적으로 스크롤바를 숨겼다가 해당 위치에 마우스를 올리면 보이게 하는 방식도 사용함
  • GTK3에서는 다음 명령으로 항상 보이게 할 수 있음 gsettings set org.gnome.desktop.interface overlay-scrolling false
  • Dconf Editor에서도 찾을 수 있지만, 해당 위치를 알아야 함
• GTK4에서는 이 설정을 전역으로 지정할 수 없다는 GNOME Bugzilla 스레드가 인용됨
  • 논의에서는 앱마다 non-overlay scrollbar 옵션을 요청해야 하는 상황이 문제가 됨

Qt 설정의 장벽

• Qt 스크롤바 폭은 사용하는 Qt 위젯 스타일 플러그인에 의해 결정됨
• /u/cfeck_kde는 r/kde 답변에서 Skulpture 스타일만 크기 설정을 허용하는 것으로 알고 있으며, Breeze 같은 다른 스타일은 C++ 소스를 바꾸고 다시 컴파일해야 한다고 설명함
• Qt 스타일 플러그인은 실제 코드라서 강력한 제어가 가능하지만, 원하는 설정을 제공하는 플러그인을 찾아야 함
• Kvantum은 스크롤바 폭 설정을 찾기 어렵지만, “Transient scrollbars”라는 스크롤바 사라짐 기능은 끌 수 있음
• Skulpture는 시도해볼 만하지만, KDE Plasma 없이 GUI로 설정하는 방법은 확인하지 못함
• 하나의 테마 엔진에 의존해야 한다면 Qt 개발이 계속되는 동안 유지될지 불확실하다는 우려가 남음

Firefox, Chrome, Electron의 상황

• Firefox도 매우 작은 스크롤바를 사용하지만, 현재는 about:config에서 조정할 수 있음
  • 주소창에 about:config 입력
  • widget.non-native-theme.scrollbar.size.override를 원하는 숫자로 수정
  • widget.non-native-theme.scrollbar.style을 수정해 모양 변경 가능
  • 값 4는 두꺼운 직사각형 형태로 설정됨
  • 일반 설정 창 about:preferences에서 “Always show scrollbars”를 켤 수 있음
• 예시로 Firefox 스크롤바 크기를 50으로 설정할 수 있으며, 실제로 그렇게 크게 쓰고 싶지는 않아도 크게 만들 수 있다는 점이 장점임
• Athena Lilith Martin의 Firefox 스크롤바 추가 설정 글은 웹 페이지 CSS 오버라이드 비활성화 등 추가 개선 설정을 다룸
• Chrome은 유용한 설정을 기대하기 어렵다고 평가됨
• Electron 앱도 설정이 어렵고, 커스텀 CSS 주입으로 고칠 수 있을지 모르지만 확실한 해결책은 제시되지 않음

더 나은 탐색 방식: 미니맵

• 미니맵은 콘텐츠를 볼 수 있고, 콘텐츠를 클릭할 수 있으며, 클릭한 콘텐츠 위치로 이동할 수 있음
• 클릭 대상이 매우 커서 아이트래커 사용자와 태블릿 펜 사용자에게도 유용함
• 일반적인 “현대적 디자인 원칙”이 스크롤바와 다양한 컴퓨터 사용 방식을 가진 사람들에게 불리하게 작동하고 있음

[GN⁺]

Hacker News 의견들

• 스크롤바만의 문제가 아님. 창 테두리 제거 때문에 배경의 비슷한 색 창과 구분도 안 되고, 가장자리를 잡아 창 크기를 조절하기도 거의 불가능해짐
  제목 표시줄에는 검색창과 불필요한 버튼이 잔뜩 들어가서 창을 옮기려고 잡을 곳이 거의 없고, 텍스트 박스 사이 탭 이동도 기대대로 동작하지 않거나 아예 안 됨
  툴팁은 인터페이스를 방해하고 어지럽히며, 보려는 내용을 가릴 때도 많고, 95%는 중복되거나 쓸모없는 정보임
  지난 10년간 화물 숭배식 UI/UX가 수십 년간 축적된 사용성 원칙을 버리고 보기만 좋고 많은 사람에게는 제대로 동작하지 않는 결과를 만들었음
  Postman, Teams, 요즘 Microsoft 앱 대부분, Chrome, Insomnia 같은 앱은 데스크톱 소프트웨어 UI를 어떻게 만들면 안 되는지 보여주는 사례로 써야 함
  더 큰 죄는 이런 요소들이 윈도 시스템 수준에서 설정 가능하고 앱 개발자가 덮어쓸 수 없게 되어 있었다면 문제가 아니었을 텐데, Windows와 Gnome/GTK는 오히려 기존 옵션을 없애는 방향으로 가고 있다는 점임

  • “멍청이”라는 표현이 맞다고 봄. 괜히 일하는 사람을 욕하고 싶진 않지만, 이제는 창을 옮기려면 제목 표시줄인지 버튼인지 알아내려고 바보처럼 여기저기 클릭해야 함
    “New Teams”를 시작할 때마다 Old Teams로 돌아갈지 묻고, 파일 탐색기에서 New Teams로 PDF를 열면 파일 시스템 위치를 잃지 않고 PDF를 닫는 방법도 명확하지 않음
    게다가 모든 것이 끔찍하게 느림. Microsoft/Apple/Google에서 일하는 꽤 많은 사람이 자기 일을 못하고 있고, 그걸 부끄러워해야 함
  • Windows XP가 사용 가능한 인터페이스의 정점이었고 거기서 멈췄어야 했다는 생각이 듦. 물론 그냥 나이 들어서 애들한테 잔디밭에서 나가라고 하는 걸 수도 있음
    Windows에 대해서는 확실히 그렇고, 이후 모든 Windows 버전은 사용자 경험이 더 나빠졌다고 봄
  • 모욕은 필요 없다고 봄. HN을 좋아하는 이유도 다른 플랫폼의 혐오적인 말투보다 예의 있는 토론이 앞서는 몇 안 되는 곳이기 때문임
    사용성이 미학보다 중요하다는 데는 근본적으로 동의하지만, “화물 숭배식 UI/UX 멍청이”가 정확히 누구를 뜻하는지는 모르겠음
    20년 넘게 UX/UI 리더로 일해 온 입장에서 사용성을 망치는 주범은 디자이너보다 비즈니스 리더와 마케터인 경우가 많았음
    물론 형태가 기능보다 중요하다고 생각하며 작은 스크롤바를 밀어붙이는 디자이너도 있지만, 문제를 설명하면 물러서고 쓸 수 있는 디자인을 만드는 경우가 많음
    C레벨, 마케팅 리더, 관리자들은 UI에 무지하면서도 의견은 강해서 더 위험하고, “이 웹사이트 스크롤바가 좋다”, “디자인이 현대적으로 안 보인다” 같은 요구를 함
    사용성과 접근성을 지키기 위해 싸우는 일이 너무 고통스럽고, 일부 직급은 더 전문적으로 행동하고 전문가를 신뢰해야 함. 디자이너도 사용성을 먼저 생각해야 하는 건 맞음
  • 더 큰 문제는 이제 정보 구조화를 하려는 시도 자체가 거의 없다는 것임
    설정 메뉴는 목록 위에 목록이 쌓인 악몽이고, 앱마다 메뉴 구조가 완전히 랜덤이며, 로컬에서 설정할 수 있는 것마저 외부 사이트 링크로 보내는 경우가 많음
    디자이너의 의도를 이해하기가 정말 어렵고, 설정을 내가 못 찾은 건지 애초에 이 메뉴에 없게 만든 건지 구분이 안 됨
    기본 설정을 바꾸려고 Google을 찾아야 했던 일이 너무 많고, 경험이 제품 가치의 절반인 게임에서도 마찬가지임
    CS2 설정 메뉴는 위쪽의 텍스트 버튼이 탭처럼 보이지만 사실 긴 설정 목록의 임의 지점으로 스크롤시킬 뿐이라, 각 버튼이 무엇을 뜻하는지 머릿속에서 분리하기 어려움
    개념의 의미가 서로 연결되지 않고 구조화도 안 되어 있어서 컴퓨팅을 탐색하는 일이 불필요하게 너무 어려워졌음
    Macromedia Flash의 UI가 그립고, 많이 쓰지는 않았지만 정말 단순하고 쓰기 쉬웠음
    프라이버시와 직접 만든 해결책을 찾게 되는 큰 동기 중 하나도 요즘 보이는 경험과 지식의 오염에서 벗어나고 싶어서임
  • 그게 바로 크기 조절 박스가 있던 이유임. 실제로는 살이 없는 드래그 가능한 가장자리라서, 1픽셀짜리 요소에 역할을 과하게 얹으며 충돌을 만든 셈임
    예전의 크기 조절 박스는 세로 스크롤바 맨 아래, 아래쪽 화살표 버튼 바로 밑에 창 크기 조절 전용 손잡이로 따로 있었음
    초기 화면에 드러나지 않은 내용을 보기 위한 스크롤 버튼 바로 근처라, 뷰포트와 상호작용하는 자연스러운 시작점이자 기준점에 가까웠음
    아이러니하게도 앱 UI에서는 대부분 사라졌지만, 웹 브라우저는 textarea처럼 스크롤바와 resize가 켜진 요소에서 아직 렌더링하기도 함. 다만 대부분 UI에는 관련 스크롤 버튼이 더 이상 없음

• 최근 웃긴 깨달음이 있었음. 내 시력이 나빠진 게 아니라 UI가 나빠진 것임
  웃길 정도로 대비가 낮은 tiny 스크롤바는 누구에게도 접근 가능하지 않음
  최근 KDE를 Oxygen 테마로 쓰기 시작했는데, 눈의 피로 없이 쓰기 좋아서 즐거움
  이런 스크롤바는 커스터마이즈 여지도 없는 한심한 물건이고, 잠긴 앱에 테마를 적용하려면 행운을 빌어야 함
  UI 디자이너들이 사용자 필요를 신경 쓰지 않는다는 게 너무 노골적이고, FOSS 세계에서도 예외가 아님
  보기 좋고 기능적이며 접근 가능하고 빠른 소프트웨어가 있던 시절에서, 잠겨 있고 테마도 안 되는 Electron 쓰레기로 퇴보한 건 슬픈 일임
  UI에 충분한 대비와 가독성이 있었다면 “다크 모드” 같은 것도 필요 없었을 것임

  • 다크 모드를 대비 때문에 쓰는 게 아니라, 많은 소프트웨어의 라이트 모드가 그냥 순백색이라서 씀. 화면은 점점 더 밝고 강력해졌음
    화이트 모드 없는 소프트웨어를 쓰면 너무 밝아서 근처 벽이 손전등을 켠 것처럼 밝아질 때가 많음
    그래서 화면 밝기를 낮추면 색과 대비가 엉망이 되어 여전히 아무것도 안 보임
    Win 9x 시대의 회색 인터페이스가 그립고, 예쁘지는 않았지만 실제로는 볼 수 있었음
  • 대비도 요인이지만, 평면 UI 유행이 중간 회색과 밝은 회색을 몰아내고 새하얀색과 거의 흰색을 밀어 넣으면서 라이트 모드가 예전보다 훨씬 눈부시게 보이게 됐음
    눈부신 평면 UI가 지배한 뒤 사람들이 다크 모드를 요구한 건 전혀 이상하지 않음
  • 디지털 세계에 아날로그 제어가 더 많았으면 좋겠음. 10단계 위/아래 버튼 대신 회전 노브가 있었으면 함
    메뉴를 나가 버리기 쉽고, 다시 돌아가려다 전혀 다른 걸 조정하게 되는 식의 디지털 수동 제어는 너무 디지털적이고 번거로워졌음
    예전에는 디스플레이의 대비와 밝기, 앰프 볼륨, 아날로그 TV, 온도조절기, 자동차 라디오 등을 조절하기 쉬웠음
    아직 많은 아날로그 제어를 다시 도입하는 흐름은 아니지만, 결국 우리 세계는 아날로그임. 입력은 말, 근육 움직임 등으로 아날로그이고, 출력도 빛과 진동처럼 감각에 닿는 아날로그임
    제어는 왜 더 아날로그적이지 않은지 모르겠고, 아마 비용 문제일 것 같음
    아날로그 컨트롤이 있는 디스플레이나 노트북이라면 바로 살 것 같음. 실제로 1,600만 단계짜리 다이얼이어도 반응이 즉각적이고 진짜 가변저항처럼 느껴지면 충분함
    상황에 따라 강도를 빠르게 바꾸거나 선택지를 순환해 읽기 쉽고 듣기 쉽게 만드는 노브가 있으면 좋겠음
    오늘날 하는 일의 90%는 브라우저 안에서 이뤄지니, 브라우저가 접근성 API를 제공해 블루투스든 뭐든 회전 노브로 제어할 수 있으면 좋겠음. 스크롤 휠의 강화판 같은 것임
  • 특히 새로 나온 “don’t theme my app” 흐름이 안타까움. GTK의 CSS 스타일시트 문제는 CSS를 더 나은 스타일 기술 방식으로 교체해서 해결해야지, 전부 버리고 사용자가 자기 테마를 못 쓰게 해서 해결할 일이 아님
  • 약 20년 전 Windows 2000 시대에 사용성은 정점에 도달했다고 봄. 글의 스크린샷도 사실 그 무렵의 초기 OS X 10.x, 아마 10.3쯤으로 보임

• 스크롤 가능한 팝오버나 이상한 내부 프레임이 있는 웹사이트를 자주 만나는데, 작은 내부 프레임의 스크롤바가 숨겨져 있어서 콘텐츠가 더 있는지 알 수 없어 사이트가 완전히 망가졌다고 생각하게 됨
  정말 화가 나고, 이 광기를 장려하고 유행시킨 iOS와 macOS를 탓하게 됨. 무엇이 무엇인지 추측하기 어렵게 만든 “평면” UI 유행을 밀어붙인 쪽도 간접적으로 책임이 있음
  UI는 소통인데, UI 디자이너들은 웅얼거리는 게 멋지다고 결정한 셈임

  • 원래 iPhone 맥락에서는 스크롤 중이 아닐 때 스크롤바를 숨기는 게 어느 정도 말이 됨. 화면이 3.5인치이고 데스크톱 수준의 콘텐츠 표시를 목표로 하면 스크롤바를 둘 공간이 많지 않고, 대부분은 스크롤바 자체와 상호작용하지 않을 테니까
    반면 데스크톱 운영체제에서는 쓰이는 가장 작은 화면도 훨씬 크기 때문에, 스크롤바를 숨길 좋은 이유가 별로 없음
  • 이 불만 스레드를 더 불붙는 방향으로 납치할 위험을 감수하자면, 요즘 영화와 TV를 따라 하는 걸지도 모름
    애들이 조용하거나 자거나 학교에 가 있어도, 요즘 많은 영화와 드라마는 자막 없이 보기 어려움
  • 이 평면 UI가 어떻게 유행했는지조차 이해가 안 됨

• 다시 한 번 Firefox가 about:config에서 이런 걸 끌 수 있는 도구를 준 점을 칭찬해야 함. 좋게 봐야 귀여운 장식이고, 나쁘게 보면 짜증나고 악용적임
  브라우저 UI는 웹사이트가 바꿀 수 있는 영역에서 거의 완전히 제외되어야 하고, 스크롤바도 거기에 포함됨

  • 반대로 Chrome은 “Chrome에서 유용한 걸 설정할 수 있다고 상상해 보라”는 지점에서 크게 웃었음
    글 전체는 매우 잘 쓰였고 저자에게 칭찬을 보냄
    나도 Edge가 Bing 검색과 다른 기능을 계속 들이밀고, 탭 복원 프롬프트까지 너무 귀찮게 해서 다시 Firefox로 옮겼음. 그냥 닥치고 그만 좀 했으면 함
  • 2000년대 초 포럼에서 IE6의 스크롤바 스타일링 기능을 완강히 옹호했던 기억이 아주 강하게 남아 있음. 당시 Mozilla 쪽은 그걸 혐오스러운 것이라고 불렀음
    나이 든 지금, 뒤돌아볼 힘과 나빠진 시력이라는 약점을 함께 가진 입장에서 내가 틀렸다고 인정할 수 있음. 너무 쉽게 악용됨
  • 부드러운 스크롤도 그 목록에 넣어야 함. 마우스 휠로 스크롤하든 Ctrl-F로 찾은 단어 사이를 이동하든 마찬가지임
    다행히 uBlock Origin으로 덮어쓸 수 있음
  • 확장 기능 작성자들의 넓은 생태계도 칭찬할 만함. 글쓴이는 마지막에 기존 스크롤바의 업그레이드로 미니맵 사이드바를 칭찬하는데, 실제로 그런 것이 있음
    https://addons.mozilla.org/en-US/firefox/addon/minimap-scrol...
  • 모바일에서도 동작하지만, 이를 덮어쓰는 정확한 주문은 찾아봐야 함
    아마 이게 맞을 것 같음
    <https://www.makeuseof.com/change-firefox-scrollbar-style/>

• 글쓴이는 문제의 절반을 보고도 해결책의 나쁜 절반을 제안함
  스크롤바는 제어 장치일 뿐 아니라 위치 표시기이기도 함. 긴 목록 같은 더 큰 보기 안에서 현재 뷰포트가 어디에 있는지 보여줌
  macOS 같은 일부 GUI처럼 스크롤바를 숨기는 건, 버튼을 텍스트와 구분 못 하게 만들거나 밝은 회색 배경에 밝은 회색 글자를 올리는 것처럼 매우 무례함
  해결책은 이미 있고 거의 보편적으로 구현되어 있음. 마우스의 스크롤 휠과 트랙패드의 스크롤 제스처임
  스크롤바로 스크롤 가능한데 표준 트랙패드 제스처나 마우스 휠로는 스크롤할 수 없는 보기는 매우 드묾. 내 마우스는 휠로 가로 스크롤도 가능하고, TrackPoint 컨트롤도 마찬가지임
  이런 스크롤은 포인터가 스크롤바 위에 있을 필요도 없고, 원하는 보기/컨트롤/위젯 위에 올라가 있기만 하면 됨
  부정확한 입력 장치, 떨리는 손, 나쁜 시력에도 아주 쉽게 할 수 있음
  하지만 이렇게 자연스럽고 쉬운 스크롤 방식이 있으면, 스크롤바가 표시기 역할을 할 때 오히려 더 그리워짐
  미니맵은 때로 유용하지만 아닐 때도 많고, 개인적으로는 텍스트 편집에서 덩치만 크고 도움이 안 된다고 느낌. 물론 좋아하는 사람을 위한 옵션으로 있는 건 찬성함

  • 스크롤 휠과 제스처는 페이지 이동 장치이고, 스크롤바도 그 역할을 하지만 동시에 “문서의 중간으로 데려가라”는 제어 장치이기도 함
    문서가 제대로 반응한다는 전제가 있으면, 특히 큰 문서에서 스크롤바로 큰 범위를 쉽게 이동할 수 있음. 요즘 웹에서는 그 전제를 믿기 어렵지만
    링크가 없고 “B-29” 같은 섹션 페이지 번호를 쓰는 오래된 큰 PDF에서, 묻힌 페이지를 찾으려고 스크롤바로 사실상 이진 탐색을 한 적이 셀 수 없이 많음
    물론 현대 웹은 지연 로딩과 무한 스크롤의 남발로 스크롤바를 표시기로 쓰는 가능성을 거의 파괴했음
    Mac에서 Cmd-아래 화살표로 문서 끝에 점프해 끝이 있기를 바라고, 형식을 망치는 임베드들이 모두 로드되길 기대한 적이 많음
    하지만 결국 끝이 보이지 않는 기차 위에 올라탄 듯, 얼마나 왔고 얼마나 남았는지도 알 수 없음
    그래서 스크롤바가 사실상 쓸모없어졌기 때문에, 고속 doom scrolling을 위해 설계된 베어링 달린 무게감 있는 마우스 휠을 쓰고 있음
  • 글을 안 읽은 것 같음. 첫 문단부터 “그게 스크롤 휠의 용도라고 하겠지만, 모두가 스크롤 휠이나 터치 화면 스와이프를 쓸 수 있는 건 아니다”라고 함
    바로 다음 문단에서도 작은/숨겨진 스크롤바가 시선 추적기 같은 다른 입력 방식에 주는 어려움을 다룸
  • 맞음. 드디어 스크롤바가 무엇을 위한 것인지 이해하는 사람이 나왔음
    스크롤바의 1차 역할은 문서가 창보다 크다는 것을 사용자에게 보여주는 것이고, 2차 역할은 문서의 어느 부분이 보이는지 보여주는 것임. 사용자가 스크롤하게 하는 건 주된 기능이 아님
    Apple이 macOS에서 기본적으로 스크롤바를 숨기기 시작했을 때 정말 놀랐음. Apple UI 디자이너들은 기본 UI 컨트롤이 실제로 무슨 일을 하는지 모르는 것 같음
  • 스크롤 입력 장치가 보편적으로 제공되는 건 아님
    Wacom/펜 사용자에게는 스크롤 휠이 없음
    많은 트랙볼에도 스크롤 휠이 없고, 일부는 공 주변에 스크롤 링이 있긴 함
    스크롤하는 손가락에 반복사용손상이 생겨서 마우스에서 스크롤 휠을 제거했음. 마우스 쓰는 팔을 과하게 늘려서 몇 주간 반대손으로 트랙볼을 써야 했던 때도 있음
  • 아주 먼 거리를 스크롤해야 하면 마우스 휠은 무너짐

• 창 테두리 이야기도 해야 함. 검은 배경과 검은 테두리의 VS Code 창을 여러 개 겹쳐 열어 두었고, 그림자도 없음
  한 창의 프레임/테두리가 다른 창 위에서 어디인지 전혀 보이지 않음. 이건 운영체제 차원의 문제여야 하는데, apparently 앱의 문제임
  게다가 VS Code는 테두리 설정 지원을 “철회”했음: https://github.com/microsoft/vscode/issues/160159

  • 테두리와 제목 표시줄에 대한 더 많은 내용은 여기 있음
    https://news.ycombinator.com/item?id=37865824
    내 이론으로는 디자이너들이 한 번에 전체 화면 창 하나만 보는 사용자를 목표로 삼는 것 같음
    그들의 모델 사용자는 이상적인 조명과 반사 없는 방에서 13인치 노트북 앞에 앉아, 창을 옮기거나 크기 조절하지 않고 하루에 탭/문서도 3개 이상 열지 않음

• 이런 글이나 UX 블로그를 읽을 때마다 우리가 접근성을 얼마나 신경 쓰지 않는지 너무 분명해짐
  접근 가능한 “좋은” 디자인은 현대 웹 앱에 기대되는 것보다 꽤 지루하고 군더더기가 적음
  Adam Silver의 폼 관련 책을 읽고 접근성 관점에서는 우리가 완전히 잘못하고 있다는 걸 깨달았지만, 접근성은 우선순위가 아님

  • 댓글이 접근 가능하려면 독자가 a11y가 “accessibility”라는 뜻이라는 걸 찾아봐야 한다는 점이 아이러니함
  • 비즈니스 관점에서 꼭 틀린 건 아님. 접근 가능한 웹사이트를 만들려면 할 수 없는 일들을 기업이 하면, 계산상 더 잘되는 경우가 많음
    특히 다크 패턴은 접근성과 매우 반대임
    그래서 접근성을 의무화하는 법이 필요함

• 40대 이상의 많은 사람에게 접근성 문제가 되는 게 뭔지 아는가? 어두운 배경의 흰 글자임
  내 나이대 사람들이 웹 페이지를 읽을 수 있게 만들자고 주장하는 이야기는 아무리 들어도 질리지 않을 것 같음
  개발자 도구를 열어 작성자의 CSS를 수정하면 읽을 수는 있었지만, 셸 스크립트는 읽을 수 없게 됐음

  • 40세 미만인데도 이 조합은 눈에 엄청난 부담을 줌. 몇 문단을 읽고 벽을 보면 30초 이상 시야에 잔상 글자가 남음
    너무 불편해서, 전체 텍스트를 선택해도 어두운 배경/흰 글자 대비가 완화되지 않으면 그 페이지는 아예 읽지 않음
  • 안타깝게도 접근성 요구는 서로 충돌하는 경우가 많고, 웹 페이지를 만드는 사람에게 모두를 위한 옵션을 보장할 무한한 시간이 있는 것도 아님
    CSS를 아예 끄는 것도 고려할 수 있음
  • 아직 40은 아니지만 내 경우는 반대임. 심한 비문증이 있어서 흰 배경에서는 그것들이 도드라짐
    지난 5년간 정말 좋았던 점은 주요 사용자 인터페이스 대부분이 이제 다크 모드와 라이트 모드를 모두 제공한다는 것임
  • 브라우저에서는 Dark Reader 확장을 만져보면 좋음. 보통은 전역 다크 모드에 쓰지만, 사이트별 또는 전역으로 화이트 모드도 설정할 수 있음
  • 정확히 같은 문제는 아니지만, 밝거나 중간 회색 배경에 어둡거나 중간 회색 글자가 올라간 경우를 자주 봄
    내 해결책은 이것임
    https://addons.mozilla.org/en-US/firefox/addon/font-contrast...
    최소한 텍스트를 검은색으로 강제해 줌. 꽤 안정적이고, 가끔 필요한 예외 설정도 쉽게 할 수 있음

• 스크롤바가 죽어 가고 있고 쓸 수 없게 된다는 데 동의함. 스크롤바는 넓고, 명확히 보이며, 맞히기 쉬워야 함
  문서 중 현재 보이는 비율을 나타내도록 비례 크기여야 하고, 움직이는 부분은 미끄러움이 아니라 마찰감을 암시하는 특징이 있어야 함
  화살표 버튼은 서로 반대쪽 끝이 아니라 함께 배치되어야 하며, 호버와 마우스 누름 상태를 색으로 알려야 함
  여기 나온 고전 스크롤바 중에서는 https://scrollbars.matoseb.com/ Nextstep이 가장 조건에 가깝고, Mac OS 8이 전체적으로 가장 예쁘다고 봄

  • 여기에 더해 문서가 지원한다면 단일 툴바 위젯에서 양방향으로 패닝할 수 있는 옵션도 있어야 함. 그런 구현을 본 적은 있지만, 화살표 버튼이 양끝이 아니라 함께 있는 형태는 본 적이 없음
    예전에는 인간-컴퓨터 상호작용이라는 연구 분야가 있어서 Fitts의 법칙이나 화면 가장자리가 사실상 무한한 크기를 가져 특히 가치 있다는 사실을 배웠음
    OS X에서 벌로 MS Teams를 열어 두고 있는데, 창은 화면 오른쪽에 딱 붙어 있고 오른쪽 가장자리에 스크롤바가 있음
    마우스를 오른쪽으로 밀고, 마우스오버로 확장되어 가장자리 픽셀까지 닿은 스크롤바를 잡으려고 클릭하면, 전체 창이 끌려감
    어떻게 여기까지 왔는지 모르겠음. 좋은 사용자 인터페이스가 무엇인지 적극적으로 연구하던 시기가 있었고, 그 연구가 실제 사용자 경험에 반영됐으며, 결과로 드러났음
  • 화살표 버튼을 반대쪽 끝이 아니라 나란히 배치해야 한다는 건 생각해 본 적이 없지만 말이 됨
    “항상 그래 왔으니까” 말고는 왜 그렇게 드문지 궁금함

• “디자이너들이 비기술 사용자와 함께 사용성 테스트를 하지 않는다”고 하지만, 해도 별 차이 없을 것임
  거의 25년간 웹 개발자로 일했고 많은 디자이너와 협업했는데, 그들이 신경 쓰는 건 자기 “비전”과 일치하는 픽셀 퍼펙트 레이아웃임. UX는 스쳐 지나가는 생각조차 아님

  • 모든 디자이너가 그렇지는 않지만 많은 디자이너가 그렇긴 함. 실제 사용자와 진행한 UX 연구에서 나온 뒤 “이건 하나의 데이터 포인트일 뿐이고, 우리는 그 사용자들이 틀렸다고 본다”고 말하는 디자이너를 본 적이 있음
    이런 경우에는 설득이 통하지 않음