[SW개발] 코멘토 직무부트캠프: 웹 접근성- 제1주차

 

제1주차 소회

이번 직무부트캠프는 멀티캠퍼스에서 준 제휴 쿠폰을 통하여 진행하게 되었다. 당시 SW 교육과정에서 할 수 있는 것을 찾아 보았는데, 제일 하고 싶었던 백엔드는 마침 자율일정이라(제휴 쿠폰은 자율일정에는 사용이 불가능하다), 다른 커리큘럼을 찾아 보았다.

그 중에서 눈에 들어온 건 웹 접근성이었다. 물론 웹 접근성은 프론트엔드의 영역이지만, 풀스택 지망자 입장에서 프론트 엔드에서 중요한 부분을 그냥 간과할 수는 없었다. 물론 "개발자" 입장에서 웹 접근성은 어쩌면 부차적인 문제일 수도 있다.하지만 내가 하고 싶은 개발은 이용자가 편한 개발이다. 프로그램은 인간을 편리하게 하기 위해서 만들어진 것이니까. 그렇다면 웹 접근성은 내 니즈와 확실히 맞는다고 할 수 있다.

 

그렇게 신청하여 오픈카톡에 들어갔더니, 오픈카톡에는 나와 멘토님밖에 없었다. 세션 당일까지 아무도 오지 않아서 1:1 강의가 되어버렸는데, 이 부분이 오히려 좋았다. 1시간 50분 동안 평소보다 집중해야한다는 게 조금 부담 되었지만, 즐거운 시간을 보냈다.

 

이번 주차는 세션 진행 후 과제를 받아 제출했다.

 

웹 표준/웹 호환성/웹 접근성이란?

멘토님께서는 웹 표준과 웹 호환성, 웹 접근성에 대해서 설명해주셨다. 웹 표준이 전제 되어야 웹 호환이 전제되고 그 위에 웹 접근성이 기본적으로 보증된다는 의미이다.

웹 표준은 정확히 말하면 W3C가 지정한 표준안을 지켜 웹 사이트를 제작하는 것이다. 웹 표준의 장점으로는 빠른 속도와 편의성을 보증할 수 있다는 점이다. 또한 SEO 작업 시에도 웹 표준은 큰 지분을 차지한다. 검색 엔진의 경우 웹 표준을 지키는가를 중점으로 보기 때문이다. 현재 웹 표준상 HTML/CSS/JS는 분리되어 각자의 역할에 맞게 구동되어야 한다.

특히 HTML5의 웹 표준이 나온 뒤에 사라진 대표적인 것은 ActiveX, 그리고 플래시가 있다. 별도의 구동 프로그램을 깔지 않아도 자체 API로도 영상/음악이 돌아갈 수 있게 된 것이다.

 

웹 호환은 운영체제, 그리고 브라우저가 다르더라도 최적화된 방식으로 보이도록 처리하는 것을 의미한다. 한때 IE가 이 웹 호환성에서 혼자 튀었는데(ActiveX 등의 사용이라든가) 최근은 웹 표준과 함께 많은 브라우저가 평준화되면서 사용 가능한 요소가 늘어 웹 호환이 쉬워졌다.

 

웹 접근성은 정보 취약 계층(장애인, 노인 등)에게도 지장이 없도록 해야하는 것인데, 보다시피 표준과 호환이 보증 되지 않으면 이 부분이 어려울 것이다. 이 접근성에 대해서는 단순히 스크린리더 처리만이 아니라, 어려운 사람을 위한 수많은 처리가 필요하다.

 

 

시멘틱 태그에서의 웹 표준

시멘틱 태그가 왜 탄생했는지부터 짚어주셨다. 이것은 스크린 리더기 등에서 읽기 편하도록 존재하기도 한다. <header>, <nav>, <main>, <article>, <section> 등의 존재로서 스크린 리더가 더 편하게 내용을 인지하게 된다. 그렇게 하여 섹션 별로도 이동이 가능하게 됨으로써, 스크린 리더 이용자는 모든 내용을 들을 필요 없이 원하는 섹션으로 갈 수 있게 되었다. 특히 <nav>에는 메뉴가 들어가 있는 것이 표준이 되는데, 웹 사이트에서 중요한 메뉴의 위치가 확실히 잡힘으로써 이용자 입장에서 편하게 되었다.

 

제일 중요한 것은 바로 h1의 사용이다. <section>에는 반드시 h1이 들어 있어야 하며, h1은 하나만 있어야 한다. 만약 h1을 사용할 필요가 없을 경우 <section>을 사용하는 게 아니라 <div>을 사용할 것. 그리고 h1 없는데 h2 등을 사용하는 것도 권장되지 않는다. h1~h6은 글자 크기대로가 아님에 유의하라고 말씀하셨다.

 

html language 관련하여서도 알려주셨는데, 이 부분 또한 스크린리더가 편하게 읽기 위한 부분이 된다(이를 위해 한국어라면 html lang="ko"라고 지정해주는 게 좋다).

 

 

버튼 사용

버튼은 <button>과 <a> 두 가지로 주로 사용된다. 다른 태그가 사용되기 어려운 것은 태그 자체에서의 동작 문제 때문이다(스페이스 키보드로 동작 안 하는 등). button과 a의 사용은 각 방식에 따라서 다른데, a의 경우 주로 웹페이지를 넘기거나, 내부 페이지 중에 이동 되거나 하는 등에 사용한다. 반면 button은 그 외 다양한 상황에서 사용하게 된다. 네이버가 이런 버튼 사용을 지켜서 사용하는 예제이기도 하다.

 

왼쪽 알림에는 button 태그의 사용을, 오른쪽 쇼핑에는 a 태그의 사용을 하였다. 오른쪽을 누르면 쇼핑 페이지로 넘어간다.

 

 

TAB

이러한 A와 button 같은 경우 탭 키로 넘길 수 있게 되는데 이때 접근성에서 중요한 건 tab의 순서가 된다. 왜냐하면 스크린리더는 이러한 tab키의 순서에 따라서 읽어주기 때문이다. tab의 순서를 지정해주는 tab-index를 함부로 건드리지 않는 게 좋은 이유 또한 이러하다. 사용자가 넘길 때 tab-index가 꼬여 있을 경우 인지가 어려울 수도 있고, 무엇보다 tab-index를 사용하기 시작하면 tab 루프가 불가능하기 때문이다. 이 부분은 새창이 아닌 팝업에서 Yes/No 할 때 등에서 중요하게 보여진다.

 

taba11y라는 확장 프로그램으로 이 순서를 확인할 수 있다. 여기서 a11y는 Accessibility 의 준말인데, 접근성을 다루는데 Accessibility 라는 어려운 단어라 이를 축약하여, A와 Y 사이 11글자, a11y가 되었다.

 

 

색상과 명시성

이 세상에는 전맹은 그다지 없다. 그러나 눈이 각자의 이유로 불편한 사람들이 많다. 적록 색약이나 시력이 좀 저하된 정도는 오히려 흔할 정도이다. 이런 사람들을 편하게 보게 하기 위한 것이 웹 접근성의 이유 중 하나다.

이 중 명도 대비율이라는 것이 있는데, 확인할 수 있는 방법은 다음 블로그에 적혀 있어서 첨부한다.

 

https://gaagaagaa.tistory.com/entry/Chrome-%EA%B0%9C%EB%B0%9C%EC%9E%90-%EB%8F%84%EA%B5%AC-%EC%82%AC%EC%9A%A9%EB%B2%955-%EB%AA%85%EB%8F%84%EB%8C%80%EB%B9%84%EC%9C%A8-%ED%99%95%EC%9D%B8

[Chrome] 개발자 도구 - 명도대비율 확인

 

여기서 명도 대비율이 AA인 것이 필수(최소)이며, AAA가 최고라는 의미이다.네이버가 이런 부분에서 깔끔하게 처리되어 있어 관련 가이드라인을 올려본다.

https://accessibility.naver.com/acc/guide_01

 

 

 

IR 기법

Image Replacement의 준말로, 스크린리더기 등에 읽혀야하지만 화면에는 표기되지 않아야할 때 사용하는 기법이다. 주로 이미지를 대체해서 사용하거나, 스크린 리더기를 사용한 사용자에게 맥락적인 인지를 하기 쉬이 하기 위해서 적는다. 주로 visually-hidden이라는 클래스명을 사용하여 안에 글자를 집어넣는다.

 

 

과제

과제의 내용은 웹표준, 태그 하나 선택해서 웹 표준 분석하는 것이었고, 내가 선택한 것은 바로 IMG 태그이다. IMG 태그는 가질 수 있는 속성 값도 다양한데, 다음과 같다.

 

src, alt, title, width, height, srcset, sizes, loading, decoding, fetchpriority, crossorigin, referrerpolicy, ismap, usemap, elementtiming, attributionsrc, name, align, border, hspace, vspace, longdesc

 

이 중 필수로 사용하는 것은 src로, src만 적는다면 img의 경우 웹표준은 지켜진다. 다만 웹 접근성을 위해서 alt 태그를 사용하는 것이 권장되는데, 스크린리더가 alt 태그가 존재한다면 src 대신 해당 문구를 읽기 때문이다.

 

멘토님의 피드백으로는 title 속성에 대한 설명과, src 속성의 보안적 취약점에 대한 질문이 있었다. src에 이미지가 아닌 .exe 파일 등을 넣는다면 어떻게 처리되냐는 이야기였는데, 이는 기본적으로 브라우저 차원에서 img src는 이미지로 렌더링하고 있다. 다만 검증을 거치지 않는다면 XSS 공격 등에 취약한 경우도 있어(CSRF 공격과 관련하여 내가 TIL에 적은 적이 있다. 링크 참조) 검증을 한 차례 정도는 거치는 것이 좋다.