성능 > 접근성..?
웹 개발에서 성능 최적화는 자주 언급되지만, 접근성은 종종 간과됩니다.
"기본적이고 간단한 것"이 "중요하지 않은 것"은 아닙니다.
오히려 기본적인 요소일수록 처음부터 원칙을 지켜 개발해야 합니다.
특히 많은 프론트엔드 개발자들이 사용자 경험(UX)을 중요하게 생각합니다.
여기서 "사용자"는 장애 유무와 관계없이 모든 사람을 의미합니다.
그렇다면 접근성은 선택이 아닌 필수 요소입니다.
이에 충실하고자 이 글을 작성하게 됐습니다.
장애인, 고령자 등이 웹 사이트에서 제공하는 정보에 비장애인과 동등하게 접근하고 이해할 수 있도록 보장하는 것.
비장애인은 웹상에서 제공되는 텍스트, 이미지, 영상 등의 콘텐츠를 쉽게 인식할 수 있지만, 장애인은 그렇지 않을 수 있습니다.
예를 들어, 그림이나 사진이 포함된 콘텐츠를 제공할 때, 눈으로 볼 수 없는 사용자(시각장애인)를 위해 대체 텍스트(alt text)를 제공해야 합니다.
또한, 동영상이나 오디오 콘텐츠에는 청각장애인을 위한 자막 또는 텍스트 대체 정보가 필요합니다.
마우스를 사용할 수 없는 사용자를 위해 키보드만으로도 모든 콘텐츠에 접근 할 수 있도록 설계해야 하며, 움직임이 느린 사용자들을 위해 시간 조절 기능을 제공하는 것도 중요합니다.
네이버에서 만든 [ 접근성 퀴즈 ]를 풀어보면, 조금 더 이해가 쉽다.
접근성은 단순히 장애인을 위한 것이 아니라, 모든 사용자에게 더 편리한 서비스를 제공하는 데 기여한다.
누구에게나 동등한 기회 제공
웹 접근성을 준수하면 장애인과 고령자도 비장애인과 동등하게 웹사이트에서 제공하는 정보와 기능을 이용할 수 있습니다.
예시 1) 스크린 리더를 통해 시각장애인이 웹페이지의 내용을 음성으로 들을 수 있음.
예시 2) 청각장애인이 동영상을 시청할 때, 자막을 통해 내용을 이해할 수 있음.
※ 인터넷이용률 통계 (2013년 한국정보화진흥원 보고서)
여전히 많은 웹사이트가 웹 접근성을 고려하지 않아 장애인 및 고령자의 인터넷 이용률이 낮습니다.
화면에 표시된 정보를 음성으로 변환해 읽어주는 화면 낭독 프로그램입니다.
스크린 리더는 웹페이지 내 HTML 요소를 분석하여, 버튼, 링크, 폼 필드, 이미지(alt text) 등을 사용자에게 안내합니다.
스크린 리더 프로그램은 다양하고,
동작 방식은 사용하는 프로그램과 설정에 따라 다릅니다.
저는 위 프로그램을 사용하였습니다.
대체로 alt 값을 읽을 때 "이미지" 또는 "그래픽" 같은 단어를 자동으로 붙이는 경우가 많습니다.
해당 gif는 "검색 -> 입력 도구 버튼 -> 음성 검색 버튼 -> 이미지로 검색 버튼 -> Google 검색 버튼 -> I'm Feeling Lucky 버튼" 순서로 읽힌다.
Tab 키를 눌러가며 이동시켰습니다.
이미지 alt 태그에 따라 읽히는 방식
<img src="12.jpg" alt=""> -> 아무것도 읽지 않음
<img src="12.jpg" alt="공원에서 뛰어노는 갈색 강아지"> -> "공원에서 뛰어노는 갈색 강아지"
<img src="12.jpg"> -> "12 이미지"
접근성을 개선하다보면 SEO 등 다른 부분과도 연관되지만, 여기서는 접근성에 집중하겠습니다.
div
도배 대신, nav
, main
, article
등 의미 있는 태그 사용.alt
제공<img src="dog.jpg" alt="공원에서 뛰어노는 갈색 강아지">
alt
를 빈 값으로 설정<img src="decorative.png" alt="">
rem
사용 권장.aria-label
aria-label
사용<button aria-label="검색">
<img src="search-icon.png" alt="">
</button>
<button aria-label="삭제">
<i class="fa fa-trash"></i>
</button>
Tab
, Enter
키 등)로 조작할 수 있도록 구현하여 마우스 없이도 웹사이트를 사용할 수 있도록 함."그럼 alt나 aria-label 텍스트만 잘 챙겨서 작성하면 되겠네~"
반은 맞지만, 반은 틀립니다.
텍스트도 그냥이 아니라 "잘" 작성해야 합니다.
어떤게 잘이냐? = 눈을 감고 텍스트를 들으면 이미지가 생생히 떠올리게.
강아지 사진을 예로 들어 보겠습니다.
<img src="dog.jpg" alt="강아지">
alt에 그냥 "강아지"만 적었습니다. 틀린 말은 아니죠.
저희는 눈에 보이니까 "몇마리가", "어디서", "어떤 행동을" 하는지가 무의식적으로 바로 인식됩니다.
하지만, 일부 혹은 아예 보이지 않는 시각장애인 입장에서는 이런 세부사항까지 인식이 될까요?
그래서 이런 부분까지 고려해서 텍스트를 밑처럼 더 자세히 해주는 것이 중요합니다.
<img src="dog.jpg" alt="공원에서 뛰어노는 흰색 강아지 두 마리">
"눈을 감고 들어도 머릿속에 충분히 그려지게 적자!"
접근성 원칙을 적용하면 보조 기술 사용자에게 도움을 주는 것을 넘어, 전반적인 UX도 향상됩니다.
예를 들어:
단순히 “접근성을 개선했다.” 라고 말만 하기보단,
뒷받침할 수 있는 수치 기반 객관적인 지표가 있어야 하고, 이를 측정하는 도구 중 하나가 Lighthouse입니다.
Lighthouse는 웹 사이트의 성능 측정 방법을 수시로 논의하고 개편하고,
모든 사용자가 콘텐츠에 액세스하고 사이트를 효과적으로 탐색하는지 확인합니다.
장점
단점
Lighthouse에서 크게 4가지를 측정할 수 있다.
오늘의 메인 디쉬는 접근성이기 때문에 Lighthouse 접근성 공식 문서를 확인해 보겠습니다.
81점 부터 100점까지 차례대로 점수가 개선되는 과정이다.
문제 설명:
해결 방법
텍스트 추가
버튼 내부에 텍스트를 추가해 역할을 명확히 함.
<button class="btn">삭제</button>
ARIA 속성 사용
텍스트 추가가 어려운 경우 aria-label 또는 aria-labelledby로 역할 설명.
<button class="icon-btn" aria-label="삭제">
<i class="icon-trash"></i>
</button>
실제 적용
aria-lable
을 버튼마다 다 적용해 주었다.개선 후 Lighthouse
ul
태그 안에 값을 li
설정하지 않은 문제.문제 설명
ul
태그 내부에 <li>
가 아닌 다른 요소가 직접적으로 포함되어 접근성 문제가 발생.<li>
)이 아닌 요소가 있으면 제대로 읽지 못함.실제 적용
<ul className="grid-cols-list grid w-[1128px] justify-start gap-x-6 gap-y-8">{children}</ul>
<ul className="grid-cols-list grid w-[1128px] justify-start gap-x-6 gap-y-8">
<li>{children}</li>
</ul>
개선 후 Lighthouse
문제 설명
<h1>
, <h2>
, <h3>
등)가 계층 구조를 따르지 않고 건너뛰거나 순서가 뒤섞여 사용됨.<h1>
다음에 h2, h3를 건너뛰고 바로 <h4>
를 사용해서 문제였음.영향
실제 적용
h4
태그를 순차에 맞게 h2
로 바꿔줌개선 후 Lighthouse
원인
text-gray-200
)과 배경색의 대비 비율이 낮아 텍스트 가독성이 떨어짐.영향:
실제 적용
개선 후 Lighthouse
100점으로 여정 끝
지우 피부가 많이 탔네요ㅋ