접근성(Accessibility)은 종종 개발자에게 '지켜야 할 규제'처럼 무겁게 다가온다. 하지만 접근성의 본질은 단순히 특정 계층을 지원하는 데 그치지 않는다. 모든 사용자의 경험(UX)을 개선하고, 개발 효율(DX)을 높이며, 브라우저(MX)가 코드를 더 정확하게 해석하도록 돕는 기술적 투자다.

Lighthouse 점수를 확보함과 동시에 서비스의 기초 체력을 다질 수 있는 5가지 전략을 정리했다.

---

🏗️ 시맨틱 마크업: 브라우저와 대화하는 가장 효율적인 방법

상호작용 요소에는 의미 있는 태그 사용하기

스타일링의 편의를 위해 div나 span에 onClick을 부여하는 것은 브라우저에게 요소의 역할을 판단하도록 방치하는 것과 같다.

• 현실적인 타협: button 태그의 기본 스타일(배경, 테두리)을 초기화하는 것이 번거로워 div에 cursor: pointer만 주고 마무리하는 경우가 많다.
• 코드로 보는 대비:

  <div onClick={handleSearch} style={{ cursor: 'pointer' }}>검색</div>
   
  <button type="button" onClick={handleSearch} className="btn-reset">검색</button>

• 접근성을 고려했을 때의 이점:
  • 네이티브 기능 활용: 별도의 JS 로직 없이 Tab 키 이동과 Enter 실행이 가능해진다.
  • Lighthouse 지표 개선: '버튼에 접근 가능한 이름이 있는가?' 항목에서 즉각적인 점수를 확보한다.
  • SEO 최적화: 검색 엔진 봇이 페이지 내 핵심 상호작용 요소를 정확히 파악하여 페이지 랭킹에 긍정적인 영향을 준다.

---

📝 폼(Form) 디자인: 사용자 편의와 데이터의 정확성

레이블(Label)과 입력창의 유기적인 연결

placeholder는 입력을 시작하면 사라지는 휘발성 정보인 점을 간과해선 안 된다. 레이블이 없는 폼은 사용자의 인지 부하를 높이고 오입력을 유발한다.

• 현실적인 타협: 레이블을 만들고 ID를 생성해 htmlFor로 연결하는 과정이 번거로워 input만 단독으로 배치하곤 한다.
• 코드로 보는 대비 (React useId 활용):

  const emailId = useId();
  return (
    <div className="flex-col">
      <label htmlFor={emailId}>이메일 주소 <span className="text-red-500">*</span></label>
      <input id=
  
  

---

👁️ 시각적 피드백: 디자인과 기능의 절충안

:focus-visible로 포커스 상태 명시하기

디자인상 거슬린다는 이유로 outline: none;을 선언하는 것은 키보드 사용자에게 길잡이 없이 웹사이트를 탐색하게 하는 것과 같다.

• 현실적인 타협: 마우스 클릭 시 발생하는 테두리가 심미적으로 좋지 않다는 피드백을 받고 고민 없이 포커스 스타일을 제거해버린다.
• 코드로 보는 해결책:

  /* ❌ 최악의 접근성: 현재 어디를 조작하는지 알 수 없음 */
  button:focus { outline: none; }
   
  /* ✅ 영리한 해결책: 마우스 클릭 시엔 숨기고, 키보드 탐색 시에만 강조 */
  button:focus:not(:focus-visible) { outline: none; }
  button:focus-visible { 
    outline: 2px solid #3b82f6; 
    outline-offset: 4px; 
  

---

🧊 복잡한 UI: 네이티브 기능을 통한 복잡도 관리

모달(Modal)의 표준,

태그 활용

팝업이 떴을 때 포커스를 모달 내부에 가두고 배경 상호작용을 막는 로직은 직접 구현하기 꽤 까다롭다.

• 현실적인 타협: 직접 구현이 복잡하여 z-index만 높인 div를 띄우고 배경 클릭 정도만 막는 선에서 타협한다.
• 네이티브 활용 코드:

  const modal = document.querySelector('dialog');
   
  // ✅ 네이티브 방식: showModal() 호출로 배경 차단(Backdrop)과 Focus Trap 해결
  modal.showModal();

• 접근성을 고려했을 때의 이점:
  • 개발 생산성 향상: showModal() 호출 하나로 포커스 트랩, Esc 키 닫기, 배경 차단이 네이티브로 처리된다.
  • 스크린 리더 최적화: 브라우저가 직접 관리하는 모달은 보조 공학 기기에서 현재 대화상자 상태임을 가장 정확하게 공지한다.

---

📢 ARIA 속성: 시각 정보와 음성 정보의 간극 보완

아이콘 버튼에 명확한 역할 부여하기

이미지로만 구성된 버튼은 스크린 리더에게 그저 '버튼'이라고만 읽힌다. 사용자는 이 버튼이 삭제인지, 저장인지 알 수 없다.

• 현실적인 타협: 아이콘 모양만으로 충분히 의미가 전달될 것이라 짐작하고 aria-label 작성을 생략한다.
• 코드로 보는 대비:

  <button><SearchIcon /></button>
   
  <button aria-label="검색"><SearchIcon aria-hidden="true" /></button>

• 접근성을 고려했을 때의 이점:
  • 정보 불균형 해소: 시각 정보를 음성 정보로 명확히 변환하여 모든 사용자가 동일한 정보를 얻게 한다.
  • 정확한 데이터 전달: aria-label은 브라우저가 사용자에게 정보를 전달할 때 가장 우선시하는 데이터가 되어 접근성 점수 향상에 기여한다.

---

🏁 결론: UX, DX를 넘어 MX(Machine Experience)로

우리는 그동안 사용자 경험(UX)과 개발자 경험(DX)에 대해 고민해 왔다. 하지만 이제는 **브라우저가 코드를 읽어주는 경험(MX)**에 대해서도 고민이 필요하다.

시맨틱 태그를 쓰고 접근성을 챙기는 것은 단순히 규약을 지키는 작업이 아니다. 브라우저가 코드를 명확히 이해하고, 그것을 다시 사람의 목소리로 전달하는 과정을 설계하는 일이다.

사용자는 편안하고, 개발자는 불필요한 로직을 덜어내며, 브라우저는 막힘없이 코드를 해석하는 경험. 이 조화가 이루어질 때 진정으로 견고한 서비스가 만들어진다.

오늘 여러분의 Lighthouse 점수는 몇 점인가?