LINE Corporation이 2023년 10월 1일부로 LY Corporation이 되었습니다. LY Corporation의 새로운 기술 블로그를 소개합니다. LY Corporation Tech Blog

Blog


'Tech-Verse 2022' 웹 접근성 향상을 위한 노력

안녕하세요. LINE UIT(User Interface Technology) 팀에서 LINE이 보유한 방대한 데이터를 안전하고 효율적으로 활용할 수 있는 데이터 포털 'IU Web' 디자인과 프런트엔드 개발을 담당하고 있는 Okazaki입니다. 현재 UIT Accessibility TF 소속으로 사내에 접근성에 대해 알리는 활동도 하고 있습니다.

Tech-Verse 2022 소개

Tech-Verse는 LINE과 Yahoo! JAPAN이 합동으로 개최하는 기술 콘퍼런스입니다. 지금까지 각 사에서 LINE DEVELOPER DAYYahoo! JAPAN Tech Conference(일본어)라는 이름으로 각각 개최해 왔던 기술 콘퍼런스가 Tech-Verse라는 이름으로 하나가 됐습니다. Tech-Verse 2022에서는 각 회사가 개발하고 연구하며 쌓아온 지식과 전문성, 현재 활용하고 있는 최첨단 기술과 새로운 도전 등을 전하기 위해 총 88개 세션을 세 개 언어(한국어, 영어, 일본어)로 준비했습니다.

Tech-Verse 2022 웹사이트 첫 화면

이 행사를 진행하기 위해 Tech-Verse 2022 웹사이트를 제작했고, 제작 과정에서 기술적인 도전의 일환으로 접근성을 향상한 웹사이트로 만들기로 결정했습니다. LINE에서 프로덕트 접근성을 향상하기 위한 노력을 시작한 지는 아직 얼마 안 됐지만(참고), 온라인 기술 콘퍼런스를 개최하면서 누구나 장벽 없이 접근할 수 있는 웹사이트를 제공하고 싶었기 때문입니다.

언어 한국어, 영어, 일본어
세션 수 88개 세션
스트리밍 제공 87개 × 3개 언어 = 261개
대상 기기 모바일 기기, 태블릿, 데스크톱
도전 과제 웹사이트 접근성 향상
*세션 수(88개)는 오프닝 세션과 사후 공개된 세션 1개가 포함된 수치

접근성 가이드라인 소개

먼저 사내에서 수립한 접근성 가이드라인과 체크 리스트를 공유해서 기획과 설계, 개발 각 단계에서 합의하고 유의해야 할 점을 전달하는 것으로 출발했습니다. 가이드라인은 WCAG(Web Content Accseeibility Guidelines)를 기반으로 간단하고 알기 쉬운 형태로 구성해서 꾸준히 업데이트하고 있으며, 목차는 다음과 같은 12개 카테고리로 구성했습니다.

  • 마크업 전반
  • 문서 구조와 내비게이션
  • 기기
  • 동적 콘텐츠
  • 텍스트
  • 이미지화한 텍스트
  • 이미지
  • 아이콘
  • 음성과 동영상
  • 링크와 버튼
  • 로그인 또는 세션

체크 리스트는 '디자인과 시각 디자인', '소스 코드', '프로덕트'로 나눴고 각 단계별로 항목을 확인하면 가이드라인 달성 기준을 파악할 수 있게 구성했습니다.

접근성 체크 리스트
접근성 체크 리스트

그럼 기획과 디자인, 프런트엔드 개발, 동영상 자막 지원으로 나눠 각 부분에서 어떻게 접근성 가이드라인을 적용했는지 살펴보겠습니다.

기획과 디자인

색상

접근성 가이드라인: 글자색과 배경색의 명암비를 충분히 확보한다. WCAG 2.1 레벨 AA 명암비가 필수이다.

Tech-Verse 2022 웹사이트 세션 목록 페이지
Tech-Verse 2022 웹사이트 세션 목록 페이지


아래 표를 살펴보겠습니다. 카테고리를 식별하는 색상은 WCAG 2.1 레벨 AA 명암비를 충족하도록 조정했습니다. '큰 글씨'는 18.5px 이상의 굵은 글씨 또는 24px 이상 중 하나로 설정했으며, '그 외'에서는 일부 충족하지 못한 색상이 있었지만 이는 구현 가능한 범위를 디자인 팀과 살펴본 후 찾아낸 타협점이었습니다.

카테고리
배경색
전경색
명암비
큰 글씨
그 외

#144ff0 #ffffff 6.16:1

#db5b4b #ffffff 3.74:1 -

#9329e5 #ffffff 5.38:1

#08aa70 #ffffff 3.00:1 -

#0e9dcb #ffffff 3.13:1 -

UX/Design

#2a26c9 #ffffff 9.46:1

Mobile App

#116954 #ffffff 6.61:1

Web Front-end

#6530d3 #ffffff 7.19:1

Process & Environment

#3a4052 #ffffff 10.31:1

접근성 가이드라인: 색상에 의존해서 표현하지 않는다.

아래 표는 색각 특성에 따라 보이는 상태를 나타낸 것입니다. 

일반적으로 눈에 보이는 상태
제1색각이상(적색맹)
제2색각이상(녹색맹)
제3색각이상(청색맹)

일반적으로 눈에 보이는 상태

제1색각이상(적색맹)

제2색각이상(녹색맹)

제3색각이상(청색맹)

제3색각이상일 때는 녹색('Blockchain')과 하늘색('Server Side') 식별이 어렵다는 것을 알 수 있습니다. 이를 해결하기 위해 아래와 같이 카드 형태의 세션 정보는 배경 카테고리 색상과 함께 텍스트를 추가해서 색상으로 구분할 수 없는 상태에서도 식별할 수 있게 만들었습니다.

카테고리 레이블을 추가한 카드 형태 세션 정보
카테고리 레이블을 추가한 카드 형태 세션 정보

상호작용

접근성 가이드라인: 자동으로 시작해서 5초 이상 움직이는 콘텐츠를 만들지 않는다.

웹사이트 첫 화면 디자인을 다시 보겠습니다.

처음에는 다음과 같이 축의 둘레를 링이 항상 회전하는 콘텐츠를 고려했습니다.

  • 개선 전
    축의 둘레를 링이 항상 회전하는 첫 화면
    축의 둘레를 링이 항상 회전하는 첫 화면
  • 개선 후
    5초 후에 정지하는 첫 화면
    5초 후에 정지하는 첫 화면

프런트엔드 개발

키보드 제어

접근성 가이드라인: 마우스나 터치 조작 등을 이용한 제어를 키보드만으로도 할 수 있게 만든다.

세션 카드가 오른쪽에서 왼쪽으로 흘러가는 첫 화면
세션 카드가 오른쪽에서 왼쪽으로 흘러가는 첫 화면


첫 화면에서는 스크롤에 따른 화면 그리기를 JavaScript로 제어합니다. 따라서 탭 키를 눌렀을 때 페이지 하단 세션 카드로 포커스가 이동하지만, 화면 스크롤 위치는 그에 따라 이동하지 않고 맨 앞 상태에 남아 있는 문제가 발생했습니다. 이 문제는 포커스 이벤트를 감지해서 포커스된 카드가 표시되는 위치까지 스크롤 위치를 이동하게 만드는 것으로 대응할 수 있었지만, 그렇게 하면 이미 화면 안에 카드가 있을 때에도 부자연스럽게 움직이는 부작용이 발생할 우려가 있었습니다.

결국 키보드 방향 키를 이용한다는 대체 수단이 존재했고 이 외에도 대응해야 하는 디자인 조정이나 접근성 향상 작업이 있다는 점을 고려해서 이 문제는 '알려진 문제'로 분류하고 대응하는 데 한계가 있는 것으로 결론짓는 것으로 마무리했습니다.

다크 모드

가이드라인에는 없었지만 다크 모드를 추가했습니다. 예전에 사내에서 근무하는 저시력 사용자분들을 인터뷰했을 때 다크 모드 사용률이 높았던 것으로 나타났기 때문에 수요가 있다고 판단했습니다. 일정에 별로 여유가 없어서 다크 모드 추가는 개발 팀에서 주도했고, 기본적으로 CSS로 표현할 수 있는 범위 내에서 다크 모드를 지원했습니다.

라이트 모드
다크 모드
NEWS 페이지 라이트 모드
NEWS 페이지 라이트 모드
NEWS 페이지 다크 모드
NEWS 페이지 다크 모드
  • 헤더에 마련한 'Light/Dark' 스위치를 전환해 다크 모드로 변경
  • 다크 모드 설정 정보는 로컬에 저장해 이후에도 설정 유지
  • OS에서 다크 모드로 설정(prefers-color-scheme)한 경우에는 자동으로 다크 모드로 실행
  • 적용 우선순위는 1. 스위치 설정 2. OS 설정 순

아쉽게도 다크 모드에 관한 트래킹 이벤트를 설정하지 않았기 때문에 사용률은 알 수 없었습니다.

SEO 최적화

접근성 가이드라인: 브라우저와 지원 기술, 크롤러 등이 HTML 구문을 정확히 분석할 수 있게 한다.

Google Search Console 인덱싱 차트
Google Search Console 인덱싱 차트

접근성 향상 대상은 사용자뿐 아니라 크롤러도 포함합니다. 문법적으로 올바르게 구조화한 시맨틱 HTML을 효율적으로 전달하기 위해 sitemap.xml을 작성해서 Google Search Console로 보내 효율적으로 인덱싱하도록 했습니다. 인덱스 커버리지는 초기 단계에서 90%를 넘었고, Tech-Verse 당일에는 100%를 달성할 수 있었습니다. 제목이 중복됐거나 잘못된 캐노니컬(canonical)이 있다면 Google Search Console에서 탐지해 수정할 수 있고, 이는 검색 엔진 접근성 향상으로 이어집니다.

실제 페이지 279
인덱싱된 페이지 279
인덱스 커버리지 100%

동영상 자막 지원

접근성 가이드라인: 음성이 포함된 동영상에는 음성과 동기화한 자막을 제공한다.

키노트 동영상 1 프레임
키노트 동영상 1 프레임

Tech-Verse 2022에서는 87개 세션을 라이브 스트리밍으로 제공했습니다. 동시에 진행하는 6개 트랙을 3개 언어로, 총 18개 채널을 운영하면서 실시간으로 동영상 자막을 지원하기 위해서는 기술 검토가 필요했고, CLOVA Speech API(일본어)를 이용해서 검토를 시작했습니다.

유형 1: 동영상에 텍스트를 포함해서 제공하는 방법
유형 2: 웹에서 텍스트를 표시하는 방법
동영상에 텍스트를 포함해서 제공하는 방법의 흐름도
동영상에 텍스트를 포함해서 제공하는 방법의 흐름도
웹에서 텍스트를 표시하는 방법의 흐름도
웹에서 텍스트를 표시하는 방법의 흐름도

검토해 보니 어떤 방법을 선택하더라도 개발 체제 구축 수준의 개발 공수가 필요하고 구현도 어렵다는 것을 알게 됐습니다. 결국 예상한 것 이상으로 비용과 시간이 필요해 아쉽지만 자막 지원은 구현하지 않았고, 너무 안이하게 예상하고 견적을 산출했던 것을 반성하며 다음을 위해 기록을 남기는 것으로 마무리했습니다.

마치며

이번 글에서는 Tech-Verse 2022 웹사이트 제작 이면에서 접근성을 어떻게 향상했는지 공유했습니다.

웹사이트 https://tech-verse.me/2022/
해낸 일
  • 사내에서 수립한 접근성 가이드라인에 준거한 기획 및 제작, 개발
  • 주어진 기간을 최대한 활용해 설계를 수정하며 지속적으로 개선
  • 개발 팀이 주도한 다크 모드 지원 추가
해내지 못한 일
  • 첫 화면에서 포커스할 때 스크롤 지원
  • 라이브 스트리밍할 때 자막 지원
  • 다크 모드 사용률 조사

아래는 실제로 사용한 체크 리스트로 HTML 구조나 문자 확대 시 작동, 포커스 이동 시 문제점 지적과 수정안, 각 항목의 대응 결과 등이 기재돼 있습니다. 소스 코드 관련해 57건의 이슈를 생성했고, 앞서 언급한 스크롤 1건(노란색 부분)을 제외하고 모두 수정했습니다. 

접근성과 관련해서 이미 완성된 시점에서 개선하는 게 아니라 시작하는 시점부터 제대로 염두에 두고 진행한 경우는 이번이 처음이었습니다. 그 과정에서 기획과 디자인, 개발 팀이 하나가 돼 작업을 진행한 것은 큰 의미가 있었다고 생각합니다.

물론 되돌아봐야 할 점도 있고, 결국 일부 항목은 WCAG 2.1 레벨 A 수준에 이르지 못했지만, 그래도 많은 항목에서 문제점을 발견하고 접근성을 향상할 수 있었습니다. 서로 다른 직종 간에 인식 차이가 발생하기도 했었고 타협이 쉽지 않아서 어려웠던 점도 있었지만, 디자인 단계에서 문제가 될 만한 곳을 짚어내고 개발 환경에서 키보드 조작 및 스크린 리더로 테스트한 것 등 지금까지는 하기 어려웠던 작업을 진행할 수 있었던 것은 좋은 성과라고 생각합니다. 이번 작업이 LINE이 접근성을 지원하는 다음 단계로 나아갈 수 있는 첫걸음이 되길 바라며 글을 마치겠습니다.