프론트엔드 채용공고를 여러 개 보면서 우대사항에 계속 같은 문장이 나왔다.
웹 접근성 및 웹 표준에 대한 이해
사실 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 키 동작이 알아서 따라왔다.
브라우저가 이미 잘하는 일을 직접 만들지 않는 것 → 이게 웹 표준의 상당 부분이었다.
다음 프로젝트는 다 만들고 점검하는 게 아니라 처음부터 이렇게 시작해야겠다.
'개발기초' 카테고리의 다른 글
| CORS는 서버를 보호하는 장치가 아니라 사용자를 보호하는 장치다 (0) | 2026.08.14 |
|---|---|
| REST API에서 Path parameters와 Query parameters 그리고 requestbody (0) | 2023.06.19 |
| 브라우저 렌더링 과정 (0) | 2023.06.05 |