모두가 쓰는 사이트는, 한 사람의 작품이 아닙니다.

저희 팀에서 “접근성 잘 됐어요?”라는 질문은 한 사람에게 던지지 않습니다. 컬러 담당자에게 묻고, 개발자에게 묻고, 마크업을 맡은 사람에게 따로 묻습니다. 한 번은 본문 대비도 완벽하고 키보드로 전부 누를 수 있는 화면을 만들었는데, 스크린리더로 들어보니 메뉴가 그냥 ‘링크 일곱 개’로 읽혔습니다. 시맨틱이 빠졌던 거죠. 그날 배웠습니다. 접근성은 어느 한 곳이 100점이어도, 다른 한 곳이 0점이면 사용자에게는 0점이라는 걸요. 그래서 이 글은 그 합작의 현장을 직접 보여드립니다.

그래서 접근성은 누구의 일인가요?

정답은 ‘전부’입니다. 색을 고르는 사람은 대비를 측정하고, 화면을 짜는 개발자는 키보드로 끝까지 도달하게 만들고, 마크업을 맡은 사람은 div가 아니라 button·nav·main으로 의미를 새깁니다. 여기에 ‘움직임을 끌 수 있게’ 만드는 배려까지 더해져야 비로소 ‘모두가 쓰는 사이트’가 됩니다. 아래에서, 그중 두 축을 직접 만져보세요.

이 색 조합, 정말 읽을 수 있나요?

접근성의 첫 관문은 ‘보이느냐’입니다. 예쁜 조합이 가장 자주 무너지는 지점이 여기예요. 연한 회색 글자에 흰 배경, 파스텔 위의 파스텔. 디자이너 모니터에선 멀쩡해 보여도 햇빛 아래 휴대폰이나 저시력 사용자에겐 글자가 사라집니다. 그래서 색은 ‘감’이 아니라 ‘측정’입니다. 직접 두 색을 골라보세요.

이 검사기는 WCAG의 상대 명도 공식 그대로 계산합니다. 본문 글자라면 4.5:1, 큰 글자라면 3:1을 넘겨야 합니다. 이건 ‘컬러를 맡은 사람’의 일처럼 보이지만, 사실 접근성의 한 축입니다. 색이 읽히지 않으면 그 뒤의 포커스도 시맨틱도 의미가 없으니까요.

포커스 링을 끄면, 무슨 일이 벌어질까요?

두 번째 축은 ‘닿을 수 있느냐’입니다. 마우스 없이 키보드만으로 사이트를 쓰는 사람에게, 포커스 링은 ‘내가 지금 어디에 있는지’ 알려주는 유일한 표시입니다. 말로는 잘 안 와닿으니 직접 써보세요. ‘다음 요소로 포커스’를 누르면 포커스가 한 칸씩 이동합니다. 그다음 ‘링 끄기’를 켜고 다시 눌러보세요. 똑같이 포커스는 움직이는데, 내가 어디 있는지 보이지 않습니다.

링을 끈 상태가 바로 outline:none 한 줄이 만드는 세상입니다. 디자이너는 “파란 테두리가 지저분하다”고 하고, 저도 그 마음을 압니다. 하지만 지우는 대신 :focus-visible로 브랜드 색에 맞춰 다시 그리면, 마우스로 클릭할 때는 안 보이고 키보드로 이동할 때만 깔끔하게 나타납니다. 멋과 배려를 둘 다 가져가는 방법입니다. 이건 ‘개발을 맡은 사람’의 축입니다.

스크린리더는 제 코드를 어떻게 읽을까요?

세 번째 축은 ‘이해되느냐’입니다. 스크린리더는 화면의 ‘모양’이 아니라 HTML의 ‘의미’를 읽습니다. 그래서 <div onclick> 대신 <button>, 메뉴는 <nav>, 본문은 <main>, 제목은 순서대로 h1·h2·h3를 씁니다. 시각적으로 똑같아 보여도, 시맨틱 태그를 쓰면 스크린리더 사용자는 ‘버튼 4개가 있는 내비게이션’이라고 듣고 표제만 훑어 원하는 곳으로 점프할 수 있습니다. div로 쌓은 화면은 그들에게 그냥 ‘텍스트 덩어리’입니다. 위 위젯들도 전부 진짜 <button>으로 만들었습니다.

ARIA는 많이 붙일수록 좋은 거 아닌가요?

여기서 많이들 헷갈립니다. ARIA는 최소로, 정확히 써야 합니다. 업계에 “No ARIA is better than bad ARIA(잘못된 ARIA보다 차라리 없는 게 낫다)”는 말이 있을 정도예요. 잘못 붙은 role이나 깨진 aria-label은 스크린리더에 거짓 정보를 줍니다. 그래서 먼저 시맨틱 HTML로 풀고, 네이티브 요소로 표현이 안 되는 경우(커스텀 토글, 라이브 영역 등)에만 ARIA를 보조로 씁니다. 이건 ‘마크업을 맡은 사람’의 축입니다.

움직임이 누군가를 아프게 할 수도 있나요?

네, 의외로 많은 분이 모릅니다. 전정기관이 민감한 사람에게 큰 패럴랙스, 화면을 가로지르는 모션, 자동재생 캐러셀은 어지럼증과 멀미를 유발합니다. 그래서 prefers-reduced-motion을 켠 사용자에게는 큰 움직임을 끄거나 부드러운 페이드로 바꿉니다. 운영체제에서 ‘동작 줄이기’를 켜둔 사람의 의사를 코드가 존중하는 거죠. 접근성은 화려함을 버리는 게 아니라, 끌 수 있게 만드는 일입니다. 이 페이지의 모든 모션도 그 설정을 존중합니다.

접근성을 챙기면 SEO와 전환에도 좋은가요?

같은 뿌리에서 자랍니다. 시맨틱 HTML·이미지 alt·명확한 링크 텍스트·표제 구조는 검색엔진과 AI 크롤러가 페이지를 이해하는 단서와 거의 똑같습니다. 스크린리더가 이해하는 페이지는 크롤러도 이해합니다. 전환도 마찬가지예요. 키보드로 끝까지 못 가는 폼, 안 읽히는 버튼 글자는 그대로 이탈이 됩니다. 접근성을 지킨다는 건 ‘더 많은 사람이 끝까지 전환하게’ 만드는 일이기도 합니다. 그리고 국내외로 웹 접근성에 대한 법적 요구도 점점 커지고 있어, 처음 만들 때 기준을 넣는 편이 나중에 고치는 것보다 훨씬 쌉니다.

이 작품에 들어간 기술

이 한 섹션은 세 명의 손이 같은 기준으로 만났을 때 나옵니다. 각 축을 더 깊이 다룬 실제 글을 함께 보세요.

• 대비(컬러) — 컬러를 맡은 사람의 노트: 명도 대비 검사기와 색 시스템.
• 포커스(개발) — 접근성을 맡은 사람의 노트: 키보드 포커스·스크린리더·ARIA.
• 시맨틱·구조(개발 전반) — 개발은 이렇게 합니다: 웹표준·시맨틱·성능.

이 접근성 섹션을 축별로 분해하면, 누가 무엇을 책임지는지 분명해집니다.

그래서 이 한 화면에 실제로 겹쳐 들어간 기술은 다음과 같습니다.

항목	장식만 신경 쓴 화면	접근성 합작 화면
사용성	마우스로만 가능 → 일부는 막힘	대비·포커스·시맨틱으로 누구나 끝까지
도달	저시력·색약·키보드 사용자 이탈	더 많은 사람이 사이트에 도달·전환
신뢰	안 읽히는 화면 = ‘대충 만든 곳’	읽히고 닿는 화면 = 믿을 수 있는 곳

한 사람이 100점이어도, 합쳐야 100점입니다

접근성은 자랑하려고 챙기는 항목이 아닙니다. 누군가를 사이트 밖으로 밀어내지 않으려는 기본자세입니다. 대비·포커스·시맨틱·모션이 같은 방향을 볼 때, 비로소 ‘모두가 쓰는 사이트’가 됩니다. 당신의 사이트, 어디가 새고 있을까요? 무료 진단으로 함께 확인해 보세요.