개발기초

웹 표준과 웹 접근성 높이기

hyriver(강화영) 2026. 9. 5. 20:14

프론트엔드 채용공고를 여러 개 보면서 우대사항에 계속 같은 문장이 나왔다.

웹 접근성 및 웹 표준에 대한 이해

 

사실 4년 가까이 화면을 만들어오면서 이 두 단어를 진지하게 생각해본 적이 없다.

alt는 넣고 있었고, 시맨틱 태그도 쓴다고 생각했다.

 

근데 왜 필요한지, 안 지키면 정확히 누가 뭘 못 하게 되는지는 설명을 못 하겠는 상태인 것.

그래서 개인 프로젝트를 놓고 직접 확인해보기로 했다.

 

 

웹 접근성 확인하기

* Lighthouse: 웹 페이지 품질 검사 도구로, 성능, 접근성, 권장사항 등의 지표를 점검하고 개선 제안 목록을 알려준다

측정 방법은 개발자도구(F12) → Lighthouse 탭 아래와 같이 체크 후 Analyze page load

측정해보니 88점이 나왔다.

 

 

88점이면 나쁘지 않은 것 같기두..? 근데 그렇게 기능이 많지 않은 화면이라 그럴 수 있다 ^^;

 

결과 화면에서 나타난 문제는

 

 

1. Form elements do not have associated labels (폼 레이블 없음)

입력창에 레이블이 연결되어 있지 않다는 뜻.

화면에 글씨가 보여도, 코드상으로 <label>과 <input>이 연결돼 있지 않으면 스크린리더는 "이게 뭘 입력하는 칸인지" 읽지 못한다.

 

<h3 className="recordCard__title">일자</h3>
<input type="date" value={state.date} name="date" onChange={changeInput} />

 

위와 같이 h3로 되어있는데, h3를 <label>로 바꾸는 대신 input에 aria-label를 붙여줬다. (scss 설정때문에;;)

aria-label은 보조기기 전용으로 스크린리더가 이 입력창에 도착하면 "기록 일자"로 읽어준다.

 

2. Background and foreground colors do not have a sufficient contrast ratio (명도 대비 부족)

배경색과 글자색의 대비가 부족하다는 뜻.

회색 배경에 연회색 글씨 같은 조합이 해당한다(저시력자나 고령자, 밝은 야외에서 보는 사람이 못 읽음)

이건 디자인의 문제이므로 패스

 

 

그리고 이미지에는 안나왔지만 내가 미리 고친 것 중에 아래 문제도 있었다

3. Document does not have a main landmark (main 랜드마크 없음)

페이지에 <main> 태그가 없다는 뜻.

랜드마크는 스크린리더 사용자가 페이지 구조를 파악하고 건너뛰는 데 쓰는 표지판이다.

같은 방식으로 <header>, <nav>, <footer>도 쓰면 랜드마크가 더 갖춰진다.

 

 

 

그 외에 찾아보고 적용한 웹 접근성

4. Tab 키만으로 페이지 통과하기

마우스에서 손 떼고 Tab만 눌러봤다.

내 표는 키보드로 쓸 수가 없었다 기록 목록이 표로 되어 있고 행을 클릭하면 수정 화면으로 간다.

<tr className="healthTr" onClick={() => clickHandler(hid)}>
  <td>{date}</td>
  ...
</tr>

 

Tab을 누르면 아무 일도 안 일어난다.

왜냐면 위와같은 코드로 되어 있었는데 tr은 원래 초점을 받을 수 없는 요소니까.

즉 키보드만 쓰는 사람은 기록을 수정하거나 삭제할 방법이 아예 없었다.

 
<tr className="healthTr">
  <td>
    <Link to={`/list/${hid}`} aria-label={`${date} 기록 수정하기`}>
      {date}
    </Link>
  </td>
  ...
</tr>

 

Link로 바꾸니까 Tab으로 닿고, Enter로 이동하고, 새 탭 열기랑 주소 복사까지 가능했다.

useNavigate랑 클릭 핸들러는 지웠다. 코드가 줄었는데 기능은 늘었다!

또한 aria-label을 붙여 "2026-09-03 기록 수정하기"로 읽히게 했다.

 

 

5. form을 form답게 쓰기

<form className="HealthEditor">
  ...
  <MyButton text={"저장"} onClick={handleSubmit} />
</form>

 

form 태그는 있는데 onSubmit 없이 사용하고 있었다.

이러면 날짜 입력창에서 Enter 눌렀을 때 브라우저 기본 동작으로 폼이 제출되면서 페이지가 새로고침된다.

입력한 게 다 날아간다 ;;

<form className="HealthEditor" onSubmit={handleSubmit}>

 

이렇게 바꾸고 저장 버튼을 type="submit"으로 두니까 Enter로도 저장되고 키보드 사용이 자연스러워졌다.

form을 form답게 쓰기만 하면 되는 일이었다.

 

 

 

마무리

 

 

Lighthouse 점수는 88점에서 96점이 됐다.

사실 이번 작업하면서 점수는 별로 안 중요하다는 걸 알았다.

88점이던 화면도 키보드로는 못 쓰는 화면이었으니까.

 

아직 못 한 것도 있다.

  • NVDA로 실제로 들어보기. 코드는 고쳤는데 자연스럽게 읽히는지는 확인 못 했다
  • 모바일 레이아웃. 여섯 컬럼 표는 작은 화면에서 잘린다. 카드로 바꿔야 함
  • KWCAG 2.2 33개 검사항목이랑 대조. Lighthouse는 국제 표준인 WCAG 기준이라 완전히 겹치진 않는다

 

시작은 채용공고였다.

근데 고친 목록을 다시 보니까 접근성을 위해 추가한 코드보다 잘못 쓰고 있던 걸 바로잡은 게 더 많았다.

tr을 버튼처럼 쓴 것, label 없이 placeholder만 둔 것, form에 onSubmit을 안 붙인 것.

이건 특정 사용자만의 문제가 아니라 그냥 구현이 틀린 거였다.

 

코드가 오히려 단순해진 경우도 있었다.

tr onClick을 Link로 바꾸면서 핸들러 하나가 사라졌고 새 탭 열기가 공짜로 생겼다.

form onSubmit을 붙이니까 Enter 키 동작이 알아서 따라왔다.

브라우저가 이미 잘하는 일을 직접 만들지 않는 것 → 이게 웹 표준의 상당 부분이었다.

다음 프로젝트는 다 만들고 점검하는 게 아니라 처음부터 이렇게 시작해야겠다.