[2019.06.25] 널리 세미나 (7차)

  제작년에 갔었던 널리 세미나가 올해도 개최된다 하여 다녀왔다. 다만 올해는 휴가(혹은 공가)가 아닌 계열사 직원 신분으로 근무시간 내에 다녀왔다. 사내 무선랜도 잡혀 사내 사이트 접속도 되는 것은 덤.

 

---

개요

• 행사명: 7th. 2019 NULI SEMINATR : MAKE IT MORE ACCESSIBLE
• 시간: 2019년 6월 25일 화요일 13:00 ~ 18:30
• 장소: 네이버 그린팩토리 2층 커넥트홀
• 구성: 한 장소에서 8개 세션을 발표
• 참가비: 5,000원
• 신청방식: 온오프믹스 선착순 신청
• 링크: https://nuli.navercorp.com/sharing/blog/post/1132980

[세미나 3차 공지] 모두가 함께 누리는! 2019 널리 세미나

 

---

내용

세션1. 모두를 위한 제품 및 서비스 - 구글 웹 프로덕트 및 구글 플레이의 접근성 (박재훈/김민구, 구글)

웹: 박재훈

• 구글의 미션: 세상의 정보를 재구성하여 누구나 접근 가능하고 사용할 수 있도록 만들자
• Accessibility -> 줄여서 A11y
• 구글 검색페이지
  • 제목 (Heading)의 중요성
    • 스크린 리더는 제목 단위로 페이지를 탐색하는 기능이 있음
    • 스크린 리더로 읽을 때 페이지의 전체 구조를 파악하는데 도움이 됨
    • h1, h2 등으로 설정하거나 role="heading", aria level 설정으로 가능
    • ex) h1 검색결과, h2: 어벤저스: 엔드게임, h3: 출연진, h3: 함께 찾은 검색어
    • 구조화 되어 있어 개발자에게도 도움이 됨.
  • 검색 페이지에 숨겨진 접근성 메뉴 (H1)
    • Tab키를 누르거나 스크린 리더를 사용하여 접근할 수 있는 메뉴
    • 세 항목 있음: 주요 콘텐츠로 이동, 접근성 도움말, 접근성 관련 의견 보내기
  • 더 자세한 접근성 레이블 (label)
    • 오전 9:30, 팝업버튼 (X)
    • 오전 9:30 상영 영화 티켓 구매하기, 팝업버튼 (O)
  • 대화상자 (Dialog) UI 구성
    • 대화상자 내에 '닫기', '확인' 버튼이 반드시 있어야 함. 영역 밖을 클릭해서 닫는 것은 스크린 리더로 사용하기 힘듦
  • 대화상자를 열 때의 focus 이동
  • 대화상자를 닫을 때의 focus 이동
    • 이전에 그것을 열리게 했던 element로 focus가 돌아가야함
  • Focus outline - 키보드 접근성 vs 보기 좋은 UI
    • HTML element를 focus하게 되면 해당 상태를 표시하기 위해 테두리가 생김 (색깔 및 굵기는 브라우저마다 다름)
    • outline:none CSS를 적용하여 테두리 없앨 수 있음
    • 하지만 Tab 키를 이용하여 이동할 때 focus여부 확인이 힘들어짐
    • 해결방법
    • 처음엔 없애고, 포커스 되면 테두리가 나오게 설정
  • 키보드 방향키 상호작용
    • Tab / Shift + Tab키 외에도 추가로 방향키나 스페이스 바에 대한 상호작용을 자바스크립트를 통해 지정해 주는 것이 좋다.
    • 포용하고자 하는 사용자는 장애/비장애를 가리지 않음
    • RTL 언어!
    • 아랍어 / 히브리어 등은 오른쪽에서 왼쪽으로 읽는 Right To Left 언어임
    • 웹페이지 또한 좌우가 반대로 되어 그려짐
    • 따라서 RTL의 경우는 JS로 분기해서 반대로 처리해줘야 함
• 컴퓨터 공학 전공 학생들의 접근성에 대한 인식?
  • 대학생 대부분이 장애인의 웹서핑을 하는 것에 대해 생소해 함
  • 스크린 리더를 사용해본 적이 없어, 시각장애인들이 어느 부분에서 어려움이 있을지 알지 못함
• 대학생들을 위한 웹 접근성 교육 사례
  • 무엇이 문제인지, 해결방법이 무엇인지 퀴즈로 만들어 진행
  • 스크린 리더 체험 프로그램
  • 글씨 / 배경을 모두 흰색으로 칠한 쇼핑몰 웹사이트 제공하여, 스마트폰 내장된 스크린 리더로만 읽을 수 있게 함
  • 상품의 가격을 구하는 퀴즈를 냄

앱: 김민구

• 1천만명: 장애가 있는 사람의 수
• 구글의 미션
  • 접근성을 개선하면 많은 사람이 함께 혜택을 누릴 수 있음
  • 가족 이야기
    • 유모차가 가지 못하는 것을 느끼며 어려움을 공감함
    • 장애인 길을 사용하여 혜택을 누릴 수 있었음
    • 안드로이드 글자 크기를 키울 수 있는 접근성 기능 사용
• Designing for Accessibility = designing products better for all
• 왜 접근성에 시간과 노력을 들여야 하나?
  • 접근성은 앱 개발사들에게 새로운 사용자들을 유입할 수 있는 기회
• 구글 플레이팀이 가장 많이 들은 피드백
  • 하고는 싶은데 어떻게 해야할 지 모르겠다!
  • 그래서 "안드로이드 접근성 가이드라인" 준비함
• 구글플레이의 접근성 프로젝트
  • 목표: 앱 개발사들과 협력하여 앱의 접근성을 개선
• 구글 플레이의 접근성 리뷰 방법
  • 토크백
  • 선택하면 읽어주기
  • 돋보기
  • 실시간 자막
• 접근성 검사기
  • 검사 영역
    • 터치 타겟 영역의 사이즈
    • 낮은 콘트라스트
    • 콘텐츠 라벨
    • 구현 이슈
• 컨설팅에서 발견된 50% 이상의 문제들은 쉽게 수정 가능
• 구글 플레이 사전 출시 리포트 : 접근성
  • 50여만개 앱으로부터 35만개 이상의 접근성 관련 이슈 피드백 확인 가능
• 사례
  • 문제1: 라벨이 없거나 모호하여 스크린리더 사용자가 내용을 이해하기 어려움
    • 예) 베이징을 입력해보세요.
  • 수정1: 배경을 라벨에 담아 설명하여, 명확하게 해당 요소의 목적과 기능을 전달
    • 예) 여행하고 싶은 도시의 이름을 입력해보세요.
  • 문제2: 텍스트 라벨이 동일하여 다른 요소들을 구분하기 어려움
    • 예) 켜기/끄기
  • 수정2: 각 요소에 맞는 별도의 라벨을 지정
    • 예) 메일 수신 여부 동의/거절
  • 문제3: 복잡한 회원가입 및 권한 동의
  • 수정3: 권한은 꼭 필요한 권한만 요약 정리하여 라벨링. 명확하게, 쉽게, 빠르게
  • 문제4: 스크롤이 너무 빨라 스크린리더가 읽을 수 없거나 적절한 라벨이 없어 콘텐츠를 알기 어려움
  • 수정4: 자동 스크롤이 되지 않도록 수정하거나 스크롤 속도를 충분히 낮추고 적절한 라벨을 설정

세션2. AudioBook! AudioClip (변우식, 네이버)

1. AudioClip
   • 오디오에 적합한 카테고리를 중심으로 DB 확보
   • 동화 동요 콘텐츠는 주로 AI 스피커를 통해 아이들이 활발하게 소비함
   • 어학은 사용자 반응이 가장 잘 나오는 콘텐츠
   • 오리지널 오디오 콘텐츠: 오디오 예능, 웹소설 오디오 드라마 등
   • AudioBook
     • 검증된 '책'을 중심으로 한 오디오 콘텐츠
     • 해외에서 듣는 콘텐츠로 안정적인 성장 중
     • 연극배우 / 셀럽 / 작가 등 다양한 창작자가 제작에 참여
     • 유명 작가 AudioBook 제작
   • AI와 음성합성을 통한 AudioClip
     • 유인나 오디오북
     • 클로바 AI: AI 스피커를 통해 콘텐츠 제공
   • 교육을 위한 AudioClip
     • 설문조사: 대다수의 사람들이 AudioClip이 장애인에게 도움이 된다고 응답
2. 접근성 개선을 위한 노력
   • 시스템 접근성 기능의 활용
   • UX의 개선
     • 사례1
       • 자동으로 스크롤 되는 배너의 경우 VoiceOver 모드에서 선택이 어려움
       • VoiceOver 활성화 시 자동 스크롤을 제거해서 쉽게 사용 가능함
     • 사례2
       • 사용자에게 메시지를 잠시 보여주고 닫히는 경우 VoiceOver로 안내하기 어려움
       • VoiceOver 활성화 시 시스템 Alert를 이용한 안내
   • 접근성 개선을 위한 노력
     • 오디오북 체험 부스 (네이버 도서관 2층)
   • 끊임없은 노력이 중요
     • UI 변경 시 기존 접근성 개선을 위한 노력이 사라짐
     • 꾸준한 관심, 프로세스의 변화로 대응 필요
3. 앞으로의 방향
   • Make it More Accessible 모두가 함께 누리는!
   • 모두가 손쉽게 지식을 얻는 세상이 되도록 노력

세션3. WCAG 2.1 Reflow (지훈, UA Lab.)

• WCAG: Web Content Accessibility Guidelines
• 강의에 앞서...
  • 국내 표준에 반영하기 위한 작업이 정보 접근성 포럼을 통해 올 한 해 하반기 진행될 예정
  • 여러분의 의견을 주시면 좋겠음
• 2018.06.05. WCAG 2.1 개정안 발행
• 모바일8, 저시력5, 인지 장애4 개에 대한 내용 추가
• 적합성 레벨: A - 5, AA - 7, AAA - 5개
• 1.4.10 Reflow (AA)
  • 정보나 기능의 손실 없이 양방향으로 스크롤 되지 않도록 제공 되어야 합니다. (CSS 픽셀 기준)
  • CSS 픽셀이 기준인 이유?
    • 오늘날 모바일 기기는 각 장치마다 가진 픽셀 밀도가 다름
    • 비트맵(JPG, PNG) 등 이미지 포맷은 장치 픽셀 밀도에 영향을 받기 때문에 다음과 같이 각 픽셀 밀도에 대응하는 에셋 디자인을 해야 함 (디자인 기준이 1x인 점이 포인트)
    • 반면 CSS, SVG 포맷은 비트맵과 달리 장치의 픽셀 밀도에 전혀 영향을 받지 않음. 장치 독립적으로 적용 가능한 단위(DP)를 제공
  • 400% 확대까지 설정한 이유?
    • 현 시점에서 장치픽셀 배율은 최대 4x까지 고려됨 (Android 4.x, iOS 3.x)
    • 저시력 사용자 이용 실태 보고에 따르면 400% 이하로 화면을 확대하는 사용자가 많음
    • 브라우저 확대/축소 배율이 400%까지 (IE 기준) 지원함
• Reflow의 필요성을 이야기 하는 사용자
  • 각 줄을 읽을 때 좌우로 스크롤 해야 한다면 텍스트를 읽는 것이 거의 불가능합니다.
• Adobe Reader의 Reflow 기능
  • Reflow 기능을 켜면 스크롤바가 상하로만 생겨 읽기 쉬움
• Reflow의 작동 방식
  • 사용자가 콘텐츠 크기를 확대할 때 페이지 공간이 변경되더라도, 화면(Viewport)내에서 모든 정보를 보거나 기능을 사용할 수 있어야 합니다.
  • 반응형 웹 디자인 (RWD)
    • 브라우저 확대/축소 기능을 사용한 경우 또한 포함됨
• Reflow = RWD
• 예시
  • 대한민국국회 국회예산정책처 홈페이지
• Reflow 예외 사항
  • 2차원 레이아웃이 요구되는 기능 및 의미를 가진 콘텐츠
    • 지도, 조직도, 게임, 복합한 표, 툴바가 항상 표시되어야 하는 인터페이스 등
• QnA
  • 반드시 반응형 웹 디자인으로 설계해야 할까요?
    • Reflow 성공 기준에 부합하는 방법이 꼭 반응형 웹 디자인만 있는 것은 아닙니다.
    • 모바일 전용 웹 사이트를 대체 수단으로 제공할 수 있습니다. (320px 너비에 대응 되어야 함)
  • 모바일 장치에서도 400% 확대 시 스크롤 바가 양쪽에 생기지 않아야 하나요?
    • 모바일 장치는 예외 사항으로 간주 됨
    • 데스크탑 웹 브라우저에 대한 내용으로 보면 됨
  • 사이트 내에서는 양쪽에 스크롤 바가 생기면 안 되는 건가요?
    • Reflow 성공 기준이 가지는 목적 외 경우라면 세로 축 스크롤 화면의 가로 스크롤 또한 허용 가능함
    • 연속된 읽기 콘텐츠가 아닌 경우, 스크롤 바 예시
    • 스크롤바를 대체 하는 토글 메뉴 예시
• 결론
  • Reflow는 저시력 사용자의 접근성을 향상시키는 WCAG2.1에 추가된 성공 기준(AA)이다
  • ...
• 레퍼런스
  • 유튜브 채널
  • 저시력자를 위한 접근성 요구사항

세션4. 비슷하지만 다른 웹과 모바일 접근성 (이선주, N Tech Service)

• 웹 접근성 항목
  • 24가지
  • 웹 | 키보드 사용 보장
    • 마우스 동작 == 키보드 동작
  • 모바일 | 누르기 동작 지원
  • 웹 | 조작 가능
    • 컨트롤 대각선 길이 6mm 이상
  • 모바일 | 컨트롤의 크기와 간격
    • 컨트롤 가로 9mm, 세로 9mm이상
  • 웹 | 반복 영역 건너뛰기
    • 예시) 메뉴를 건너뛰어 본문으로 바로 감
  • 모바일 | 반복 영역 건너뛰기
    • 굳이 제공할 필요 없음: 햄버거 메뉴 등이 존재
  • 웹 | 제목 제공
    • 페이지 제목 제공 (title)
    • frame과 iframe에도 제공
  • 모바일 | 제목 제공 없음
    • 아직은 제목 제공이 필수가 아님
    • 사용자 편의를 위해 제목 제공하는 것이 좋음
  • 웹 | 표의 구성
    • caption에 제목과 요약정보를 모두 넣어줘야 함
    • 레이아웃 테이블에는 caption, summary, th 미제공
  • 모바일 | 표의 구성 없음
    • 표의 내용을 인식할 수 있도록 제공해야함
• 모바일 앱 접근성 기준
  • 18가지
  • 모바일 | 알림 기능
    • 시각 ,청각, 촉각으로 제공. 두 가지 이상 제공하면 준수
  • 모바일 | 사용자 인터페이스의 일관성
    • 동일 서비스에서는 동일 UI 제공
    • 겨우 적응했는데 달라지면 난감함
  • 모바일 | 폰트 관련 기능의 활용
    • 글자 크기 변경 가능 하도록 제공
  • 웹 | 폰트 관련 기능의 활용 없음
    • 쉽게 폰트 확대/축소가 가능하기 때문
  • 모바일 | 보조 기술과의 호환성
    • 잘 되다가 스크린 리더를 켰을 때 꺼지거나 동작을 안하면 오류
    • 컨트롤의 상태 정보를 제공
    • 컨트롤의 용도나 유형 정보를 제공
• edwith | 웹 접근성의 이해
  • 웹 접근성 이해
• 어떠한 사용자가 어떠한 기술환경에서도 모든 정보에 접근 가능

세션5. 스크린 리더 사용자를 위한, PDF 문서에 접근성 적용하기 (김형섭, 엔비전스)

• 문서의 접근성에 대해서는 많이 고민하지 못하는 실정임
• pdf 시연
  • 헤딩 레벨1, 헤딩 레벨2, 목록 스타일, 테이블 제목을 읽어줌
  • 접근성 적용을 잘 해놓으면 웹 접근성처럼 알기 쉽게 내용 파악 가능
• PDF 접근성, 태그가 중요하다
  • HTML 등과 마찬가지로 태그 사용해서 구조화 가능
  • Adobe acrobat Pro 에서만 태그 수정 가능
• PDF 접근성 태그를 삽입하는 방법
  • Adobe Acrobat Pro의 태그 패널 및 TouchUp reading order 패널에서 수동으로 추가
  • Adobe Acrobat Pro에서 제공하는 자동 태그 삽입 기능을 이용
  • 워드, 파워포인트, 오픈오피스, 인디자인 등에서 접근성에 맞게 문서 제작 후 태그를 포함한 PDF 추출
• 워드
  • 제목은 제목 스타일로 적용을 해야 pdf로 변환 시에 헤딩 레벨로 읽어줌
  • 단순히 글자 크기만 키우면 안되고 의미에 맞게 제목 스타일로 적용하기
  • 표도 속성들을 넣어서 구조화 가능
• 파워포인트
  • 콘텐츠의 순서를 처음으로 설정해주기 (콘텐츠 - 그림 - 제목)
  • 이미지: 대체 텍스트 편집 (워드랑 같음)
  • 어떤게 제목인지 스크린 리더에게 알려줘야함
    • 접근성 검사 체크 후 실행
    • 검사 후 보고서가 나옴
    • 슬라이드에 제목이 없다는 항목이 나옴 -> 권장 작업 -> 슬라이드 제목 설정
• 한글
  • 워드와 같은 포맷으로 작업해서 워드로 변환 -> pdf로 변환...
• 인디자인

세션6. 접근성은 별책 부록 (김혜일, 링키지랩)

• AI 스피커
  • 시각장애인이 비장애인과 동등하게 사용 가능
  • 음성 인터페이스
  • NO 디스플레이
  • 이쁨 (?)
• 콘텐츠 소비 방법
  • 인쇄물 -> 점자로 콘텐츠 소비
  • txt -> TTS
  • image -> alt + TTS
  • VLOG (영상)은 어떻게???
  • AI가 희망의 실마리를 제공
    • 빅데이터: 이미지와 영상을 분석해서 텍스트 생성
• 기계가 세상을 보는 기술 -> 시각 장애인이 세상을 듣는 기술
• 터치인터페이스는 시각장애인에게 너무 어려움
• 음성인터페이스로만 구성하면 청각장애인에게 너무 어려움
• NO UI
  • 달라지는 것일 뿐 사라지지 않음
• 동영상 화면 해설
  • 지금은 수동으로 입힘 (동영상, 영화 등)
• 시각장애인이 사용 가능한 간편결제
  • 카카오페이, 엔페이, 삼성페이, 페이코 딱 4개
• 접근성 있는 서비스를 만들어서 소비자 확보 가능
• 장애인도 소비자로서 대해야 함

세션7. 듣고 말하는 서비스로 발전하는 네이버 어학사전의 접근성 개선 (방설주, 네이버)

• 30대 이상의 사용율: 54%
• TTS 적용
• 자동완성
  • 이 기능이 있다는 것을 시각장애인이 어떻게 알까?
• 음성인식
  • 인식되고 있는건지, 언제 작동하는지 파악하기 어려움
  • 진동 기능을 넣음 + 대체텍스트 제공

 

세션8. 청각장애인 택시 운전기사를 위한 접근성 (송민표, 고요한 택시)

1. 고요한택시 소개
   • 청각장애인이 운행하는 친절한, 고요한택시 서비스를 운영
   • 청각장애인에게 '택시 운전기사'라는 새로운 새로운 취업군을 열어준다.
   • 세가지 소통방식(음성, 태블릿 키보드, 터치패드) 제공
   • 고요한택시 APP이 나오기까지
     • 다양한 관계자와의 만남
       • 기획, Testing, 수정 및 보완, 청각장애인분들과 Field Testing
     • 해외 사례 참고 (Uber의 청각장애인 Driver)
2. 해외사례(Uber의 청각장애인 Driver)
   • 미국, Uber 청각장애인 드라이버 약 6천명 활동 (16.9)
   • 미국, 청각장애인 택시 콜 100만건 이상 달성 (17.9)
   • 캐나다, 싱가폴 등 운행
3. 고요한택시 기사님을 위한 접근성
   1. ...
   2. 버튼 식 소통방식 제공
   3. 손으로 쓰는 방식
4. 승객을 위한 UI/UX
   1. 기사님의 메시지를 음성으로 읽어주는 방식
   2. 음성, 키보드, 손으로 쓰기 제공
5. T map 택시 내 기능 추가
   1. 콜 알림 깜빡이
   2. 콜잡이 버튼 제공
   3. 고요한택시 배차 알림 팝업
   4. 메시지 기능 (전화 기능 제거)
   • 택시의 사고율이 높음
     • 콜을 잡기 위해 손을 뻗을 때 사고가 많이 남
     • 콜잡이 버튼 자체 제작

 

---

 

현장 사진

<세션1 중, 구글의 미션에 접근성이라는 것이 언급되어 있는 것을 알 수 있음>

<세션1 중, 안드로이드 앱 컨설팅 시 발견되는 문제점들의 통계>

 

<세션3 중, 네이버 웹사이트를 예시로 든 Reflow 설명>

 

<세션3 중, Reflow에 대한 결론>

 

<세션4 중, 네이버 서비스에 드러나는 웹과 앱의 접근성 준수 차이>

 

<세션5 중, 스크린 리더 사용자가 어떻게 PDF를 쉽게 읽을 수 있을까?>

 

<세션5 중, PPT 문서를 PDF로 변환할 때 의미에 맞는 태그가 달리게 하는 방법을 설명. 문서 내용이 심상치 않다>

 

<세션7 중, 초창기 네이버 사전의 모습>

 

<중간에 간식으로 제공된 샌드위치 박스>

 

<참석자 명찰>

 

---

느낀점

  회사에서 서버쪽을 개발하기 때문에 업무적으로는 접근성과 상관이 없다고 할 수 있다. 하지만 사회적으로도 많이 이슈가 되고 있는 접근성에 대해 잘 알고 있어야 나중에 프론트 쪽을 개발하게 된다거나 혹은 프론트와 협업을 할 때에 이해하는데 도움도 될 것이다. 구글 검색과 안드로이드 플랫폼에서도 충분히 웹 & 앱 접근성을 고려하여 개발 및 가이드 하고 있는 것을 보고 정말 남얘기가 아니구나 라는 생각이 들었다. 우리 서비스도 웹접근성과 앱접근성을 고려했는지는 잘... 모르겠다(그렇지 않다는 것이 아니라 안뜯어 봐서 정말 모르겠음).

  청각장애인 택시기사를 위한 앱은 얼마전에 유튜브인지 어디서 광고로 보았었는데 마지막 세션에서 발표를 하니 친근했다. 히즈빈즈나 베어베터처럼 장애인들이 적재적소 필요한 곳들에서 노동하며 댓가를 얻을 수 있게 해주는 플랫폼이라 마음이 갔다. 이런 서비스들이 많이 나와 장애인도 자립하여 살아가기 좋은 세상이 되면 좋겠다. SKT와 협업하여 T map에 기능이 추가되고 있다고 하니 앞으로 크게 발전하지 않을까 싶다. 우리 회사도 사회적 기업들과 협업하여 사회에 기여하면 좋겠다.

  접근성이 나와는 관련없는 혹은 일을 더 귀찮게 하는 시각으로 볼 것이 아니라 더 많은 잠재 고객들을 끌어올 수 있는 기회로 여겨도 좋을 것이다. 하지만 근본적으로는 모두가 평등한 세상, 웹(& 앱)이 되는 것이 공평하고 정의로운 것 아니겠는가. 이번 주제가 Make it more accessible 이었던 만큼, 많은 기업들과 사이트, 앱들이 접근성에 더 관심을 갖고 준수하면 좋겠다.