제 15회 보아즈(BOAZ) 빅데이터 컨퍼런스 - [개미야 뭐하니?팀] : 투자자의 반응을 이용한 실시간 등락 예측(feat. 카프카)BOAZ Bigdata
데이터 엔지니어링 프로젝트를 진행한 개미야 뭐하니? 팀에서는 아래와 같은 프로젝트를 진행했습니다.
[Web 발신] 5분 후, 당신이 투자한 주식이 떨어집니다!
실시간으로 내 주식의 등락을 알려주는 ai가 있다?
이것만 있으면 나도 주린이 탈출
개미와 함께하는 최적의 매도 매수 타이밍
지금 이 순간, 내 주식의 미래를 볼 수 있다
(신청: https://github.com/jayleenym/AYOA)
16기 강지수 동덕여자대학교 정보통계학과
16기 김서민 숙명여자대학교 컴퓨터과학과
16기 김윤기 한양대학교 대학원 컴퓨터소프트웨어학과
16기 문예진 서강대학교 경제학과 / 빅데이터 사이언스
CNA(Cloud Native Architecture)
MSA(Micro Service Architecture)
Service Mesh
MDA(Micro Data Architecture)
Data Mesh
MIA(Micro Inference Architecture)
Inference Mesh
제 15회 보아즈(BOAZ) 빅데이터 컨퍼런스 - [YouPlace 팀] : 카프카와 스파크를 활용한 유튜브 영상 속 제주 명소 검색 BOAZ Bigdata
데이터 엔지니어링 프로젝트를 진행한 YouPlace팀에서는 아래와 같은 프로젝트를 진행했습니다.
<aside>
이젠 검색도 유튜브 시대
제주여행을 계획할 때 브이로그 영상을 많이 참고하실텐데요
수많은 영상들과 영상 속 분산된 명소들을 하나 하나 찾으려 생각하면 막막하지 않으셨나요?
이러한 고민을 갖고 계신 분들을 위해, 유튜브 브이로거들이 찾아간 여행 명소들을 지도에서 한 눈에 파악할 수 있도록 만들었어요
(github : https://github.com/Boaz-Youplace)
16기 엔지니어링 고은서 | 중앙대학교 소프트웨어학부
16기 엔지니어링 류정화 | 성신여자대학교 융합보안공학과
16기 엔지니어링 송경민 | 국민대학교 소프트웨어학과
운영하는 서비스의 전체 또는 일부분을 클라우드의 이점을 100% 얻으며 옮겨가기 위해 서버리스는 가장 좋은 선택입니다. 서버리스 환경은 개발자가 애플리케이션을 개발하고 배포하는 방식을 바꾸고 있습니다. 본 세션에서는 서버리스 개발자가 애플리케이션 수명주기 관리, CI/CD, 모니터링 및 진단에 사용할 수 있는 모범 사례를 살펴 봅니다. AWS CodePipeline, AWS CodeBuild 및 AWS CloudFormation을 사용하여 서버리스 애플리케이션을 자동으로 구축, 테스트 및 배포하는 CI/CD 파이프 라인을 구축하는 방법에 대해 설명합니다. 또한 기능 및 API의 여러 버전, 단계 및 환경을 만들기 위해 Lambda 및 API Gateway의 기본 제공 기능에 대해 설명합니다. 마지막으로, Amazon CloudWatch 및 AWS X-Ray로 람다 기능의 모니터링 및 진단에 대해 소개합니다.
제 15회 보아즈(BOAZ) 빅데이터 컨퍼런스 - [개미야 뭐하니?팀] : 투자자의 반응을 이용한 실시간 등락 예측(feat. 카프카)BOAZ Bigdata
데이터 엔지니어링 프로젝트를 진행한 개미야 뭐하니? 팀에서는 아래와 같은 프로젝트를 진행했습니다.
[Web 발신] 5분 후, 당신이 투자한 주식이 떨어집니다!
실시간으로 내 주식의 등락을 알려주는 ai가 있다?
이것만 있으면 나도 주린이 탈출
개미와 함께하는 최적의 매도 매수 타이밍
지금 이 순간, 내 주식의 미래를 볼 수 있다
(신청: https://github.com/jayleenym/AYOA)
16기 강지수 동덕여자대학교 정보통계학과
16기 김서민 숙명여자대학교 컴퓨터과학과
16기 김윤기 한양대학교 대학원 컴퓨터소프트웨어학과
16기 문예진 서강대학교 경제학과 / 빅데이터 사이언스
CNA(Cloud Native Architecture)
MSA(Micro Service Architecture)
Service Mesh
MDA(Micro Data Architecture)
Data Mesh
MIA(Micro Inference Architecture)
Inference Mesh
제 15회 보아즈(BOAZ) 빅데이터 컨퍼런스 - [YouPlace 팀] : 카프카와 스파크를 활용한 유튜브 영상 속 제주 명소 검색 BOAZ Bigdata
데이터 엔지니어링 프로젝트를 진행한 YouPlace팀에서는 아래와 같은 프로젝트를 진행했습니다.
<aside>
이젠 검색도 유튜브 시대
제주여행을 계획할 때 브이로그 영상을 많이 참고하실텐데요
수많은 영상들과 영상 속 분산된 명소들을 하나 하나 찾으려 생각하면 막막하지 않으셨나요?
이러한 고민을 갖고 계신 분들을 위해, 유튜브 브이로거들이 찾아간 여행 명소들을 지도에서 한 눈에 파악할 수 있도록 만들었어요
(github : https://github.com/Boaz-Youplace)
16기 엔지니어링 고은서 | 중앙대학교 소프트웨어학부
16기 엔지니어링 류정화 | 성신여자대학교 융합보안공학과
16기 엔지니어링 송경민 | 국민대학교 소프트웨어학과
운영하는 서비스의 전체 또는 일부분을 클라우드의 이점을 100% 얻으며 옮겨가기 위해 서버리스는 가장 좋은 선택입니다. 서버리스 환경은 개발자가 애플리케이션을 개발하고 배포하는 방식을 바꾸고 있습니다. 본 세션에서는 서버리스 개발자가 애플리케이션 수명주기 관리, CI/CD, 모니터링 및 진단에 사용할 수 있는 모범 사례를 살펴 봅니다. AWS CodePipeline, AWS CodeBuild 및 AWS CloudFormation을 사용하여 서버리스 애플리케이션을 자동으로 구축, 테스트 및 배포하는 CI/CD 파이프 라인을 구축하는 방법에 대해 설명합니다. 또한 기능 및 API의 여러 버전, 단계 및 환경을 만들기 위해 Lambda 및 API Gateway의 기본 제공 기능에 대해 설명합니다. 마지막으로, Amazon CloudWatch 및 AWS X-Ray로 람다 기능의 모니터링 및 진단에 대해 소개합니다.
알아봅시다, Polymer: Web Components & Web AnimationsChang W. Doh
GDG Korea WebTech : 시작하세요, Polymer, Oct, 11, 2014.
Let's learn about specifications before diving into Polymer:
- Web Components
- Web Animations
This slide includes resources from HTML5Rocks, Polymer and PolyTechnic.
안녕하십니까 청각장애인이 운행하는 친절한 고요한택시 서비스를 운행하는 코액터스 송민표입니다. 저희는 택시 내 의사소통 도구를 개발해서 청각장애인에게 택시 운전기사라는 직업을 열어주고 있습니다. 오늘 해당 의사소통 도구를 개발할 시 청각장애인 택시 운전기사님들을 위해서 고려했던 접근성 이슈를 이야기함과 더불어 접근성에 대한 범주를 좀 더 넓혀, 최대한 모두가 사용할 수 있는 유니버셜 디자인적인 접근으로 승객을 위한 기능들도 함께 소개를 해보겠습니다.
좀 가볍게 편안한 마음으로 저희가 기획할 때 했던 고민들을 들어주셨으면 좋겠습니다. 여러분 Uber 아시나요? 대부분 아실 거라 생각이 듭니다. 모빌리티 공유에 씨앗을 발아시킨 기업이죠. 그렇다면 놀랍게도 미국 Uber에 등록되어 있는 청각장애인 드라이버가 약 6천명 정도인 사실도 아시나요? 6천명 정도가 되니 Uber에서도 청각장애인 기사분들을 위해 여러 고민을 했겠죠? 따라서 저희는 제품을 만들 시 Uber에서 고안한 접근성 부분도 함께 고민을 했었고, 최근에 SK T map 택시와 업무협약을 맺으면서 고요한택시 기사님들을 위해 기능을 추가하기도 했습니다. 이를 사례를 중심으로 말씀드리겠습니다.
먼저 고요한택시가 생소한 분들이 많으실 것 같아서 간략히 소개를 드리자면, 17년 8월 '청각장애인에게 택시 운전기사라는 새로운 취업군을 열어주자'라는 미션으로 시작했습니다. 이후 이 어려운 미션을 해결하기 위해 여러 지자체와 협력도 하고, 해외 전시회에서 발명상도 수상하며 제품을 검증받기도 했습니다. 그리고 기획 및 개발과정을 거쳐 작년 6월부터 1년간 고요한택시 서비스를 운행했습니다. 마지막 세션이기도 하고, 제가 낮은 톤의 목소리라 졸리실 것 같아서 제가 영상을 많이 준비했는데요. 저희 서비스에 관한 내용. 영상을 통해 만나보시죠.
[2019널리세미나] 듣고 말하는 서비스로 발전하는 네이버 어학사전의 접근성 개선Nts Nuli
안녕하세요. 저는 네이버 어학 사전에서 접근성을 담당하고 있는 방설주입니다. 저는 중국인이고, 베이징 오피스에서 근무하고 있습니다.네이버 어학 사전은 중국과 한국이 함께 만들어 가는 서비스입니다. 어학 사전은 워낙 다양한 언어를 다뤄야 하므로 양국에 나누어서 운영되고 있습니다. 저는 듣고 말하는 서비스로 발전하는 네이버 사전의 접근성 개선 사례를 설명하고자 이 자리에 섰습니다.
먼저 네이버 어학 사전의 간단한 소개를 드리겠습니다. 1999년에 네이버 어학 사전은 한 개의 사전 영한사전으로 출발하여 5년 뒤에 4개 언어 사전을 추가하여 서비스하게 되었습니다. 그 이후에는 2010년까지 추가된 사전은 없었지만 2009년 스마트폰 보급이 급속히 확대되면서 네이버 어학 사전의 분야도 PC 웹에서부터 모바일 웹과 모바일 앱으로 확장되었습니다. 확장과 동시에 편의성과 접근성을 강화하고 멀티미디어 콘텐츠를 추가하며 단어장 등 학습 기능도 같이 제공하게 되었습니다.
그런 노력 끝에 20년 전 1개 사전으로부터 시작했던 네이버 사전은 현재 41종 사전으로 늘어났습니다. 그리고 외국인을 위한 한국어 학습 사전도 제공하고 있고 각 사전에는 대부분 단어장 기능을 제공하고 있습니다.
네이버 사전을 어떻게 이용하고 있는지 간략히 설명을 좀 드리겠습니다. 지금은 앱으로 많이 접속하시죠? 앱으로 설명해 드릴게요. 2019년 5월 27일 기준으로 네이버 어학 사전 누적 다운로드 수는 1천 7백20만 건이며 78%는 안드로이드 사용자입니다. 이렇게 안드로이드랑 IOS를 나눈 이유는 OS별로 지원하는 분야가 조금 차이가 있어 따로 설명해 드립니다.
사용자 연령대별 지표를 한번 볼게요. 대부분의 서비스는 20대 초반에 포커싱 되어 있는데요. 저의 같은 경우 30대 이상인 사용자가 더 많은 비중을 가지고 있습니다. 심지어 60세 이상의 사용자가 6% 이상입니다. 100만명 정도 되세요. 그래서 저희는 남녀노소 모두 고루고루 사용하는 서비스라는 생각으로 제공하고 있습니다. 아쉽게도 청각과 시각에 불편하신 분의 수량은 정확한 수치로 추출하기 어렵지만, 현재 이 지표에 보이는 수량 중 어느 정도 비중을 가지고 있지 않냐는 생각에 저희는 항상 접근성을 고려하고 있습니다.
이렇게 다양한 연령층 사용자가 저희 사전을 사용한다는 것은 저희 서비스가 다양한 사용자의 요구사항을 어느 정도 만족할 수 있기 때문이라고 생각합니다. 그 요구사항 중의 중요한 하나가 콘텐츠라고 생각합니다.
네이버 어학 사전의 콘텐츠는 대부분 4개 분야로 그룹핑 되어 있습니다. 학습하기 위한 아주 기본적인 기초 사전이 있고. 그다음 전문용어 사전이 있습니다. 그리고 웹 수집 콘텐츠가 있고 참여 사전이 있습니다. 위에 2종류는 출판사가 출판한 콘텐츠라서 신뢰도가 높지만, 단점이 하나 있습니다. 업데이트 주기가 길고 복잡합니다. 우리가 사용하고 있는 언어들은 사실 끝없이 성장하고 있어요. 많은 유행어, 신조어, 인테넷용어들이 새로 생성되거나 다른 뜻으로 사용하고 있는 경우가 있는데요. 이런 내용을 대응하기 위해 저희는 인터넷에 있는 논문, 뉴스 등 신빙성이 높은 내용을 네이버 기술에 의해 추출하고 가공하여 사전에 도입하였습니다. 이게 바로 웹수집 콘텐츠입니다.
인류에게 지식의 저장수단은 책으로 표현되는 텍스트에서 이미지로 발전하고 점점 동영상으로 그 형태를 달리해왔습니다. 그에 따라 시각장애인에게 지식을 전달하는 수단도 변화해왔지요. 점자책, 녹음도서에서 홈페이지의 alt text로 그리고 화면해설까지 세상의 변화에 따라가고 있습니다. 하지만 데이터의 폭발이라고 표현할만큼 현대 사회는 엄청난 양의 이미지와 동영상 콘텐츠를 만들어내기 시작햇고 시각장애인은 도저히 따라갈 수 없는 격차를 경험하게 됩니다. 이런 격차는 최근 들어 점점 좁혀지기 시작했는데요 그것은 바로 이 방해단 멀티미디어 콘텐츠를 효율적으로 활용하고자 하는 비장애인들의 노력에서 출발했습니다.
2015년 공개된 기술 이미지에서 사람을 구분하고 그들의 감정을 분석하는 기술이 가능해졌습니다.
MS에서도 사진을 분석해 여러 키워드를 생성하는 분석기술이 있습니다. 설명과 키워드를 보면 단어 형태지만 사진의 내용을 담고 있구요 주요 색상정보와 성인콘텐츠 여부까지 판단할 수 있습니다.
이런 이미지 분석 서비스는 여러 회사에서 다양한 플랫폼으로 소개됩니다. Microsoft Azure Google Cloud vision Google Video Intelligence AWS Amezon Rekognition Nvidia Intelligence Video Analytics
이미지 분석 뿐 아니라 동영상을 실시간으로 분석하는 기술까지 등장하고 있습니다. 거리의 사람들, 차량의 흐름 등을 분석하는 기술이 등장했고 지역의 빈 주차공간이나, 법률의 집행이 정상적으로 이루어졌는지 확인하는 것까지 활용범위가 넓어지고 있습니다. 이러한 영상 분석 기술은 스마트시티의 시스템을 구성하는 기초가 되고 있습니다.
[영상자동재생됨] 영상의 내용을 보면 각 사람을 따라다니는 숫자가 보입니다. 이것은 시간 정보입니다. 영상 속에서 각 사람을 구분하고 그들의 이동을 추적하는 시스템입니다. 특정 공간의 체류시간을 분석하고 사람들의 흐름을 확인할 수 있는 기술이죠. 이렇게 유동인구를 분석하면 지역상권이나 매장의 인기상품 분석, 이상행동을 하는 범죄패턴가지 분석해낼 수 있는 아주 다양한 효과를 거둘 수 있습니다. 영상원본 : https://youtu.be/rY1qmXda0Oo
안녕하세요 비슷하지만 다른 웹과 모바일 접근성에 대해 발표하게 된 NTS 접근성팀 이선주입니다.
연사 초청을 받고 나서 아 주제를 뭐로 해야 할까 고민을 무지 많이 했어요. 항상 무슨 세미나가 있다 그러면 무조건 신청하고 보지 않나요? 회사안가니까, 뭐라도 도움이 되지 않을까, 아니면 경품에 혹해서? 그런데 막상 하루 종일 세미나를 듣고 와도 머리에 남는 건 많지 않나요? 접근성 세미나에서는 보통 웹에는 이런 것들이 있습니다 또는 모바일에서는 이런 것들이 있습니다. 라고 쭉 설명을 하는 경우가 많아서 무엇을 주제로 해야 할까 고민해보다가 세부적인 지침을 다 다루기보다는 웹에만 있거나 모바일에만 있거나 또는 웹과 모바일에 동시에 있어서 헷갈리는 부분들을 다뤄 봐야겠다 라는 생각이 들었습니다. 지금부터 웹과 모바일 접근성 차이에 대해 살펴보도록 하겠습니다. 웹에는 24가지의 접근성 항목이 있는데요, 다들 기본적으로 알고 계시죠..?? 알고 계시죠?? 그래서 이렇게 몇 가지만 모바일과 비교하여 살펴보도록 하겠습니다.
웹에는 키보드 사용 보장 항목이 있는데요 말 그대로 키보드 사용을 보장한다 입니다. 마우스를 사용하기 힘든 사용자들은 키보드로 웹을 탐색하기 때문에 모든 기능은 키보드만으로도 사용할 수 있어야 합니다. 그러려면 마우스로 동작할 수 있는 기능들은 모두 키보드로도 동작할 수 있도록 구현해주셔야 겠죠? 그럼 모바일은 어떨까요? 모바일은 키보드가 없습니다.
모바일은 터치 기반 입니다. 모바일에는 키보드 사용 보장이라는 항목 대신 누르기 동작 지원 항목이 존재하는데요, 모바일에서는 모든 기능이 누르기 동작으로 조작 가능해야 합니다. 이게 무슨말이냐, 통상적인 예로 지도 앱이 있는데요, 지도를 확대시키려면 두 손가락을 이용해야 하죠? 그럼 두 손가락을 이용하지 못하는 사용자는 이 기능을 어떻게 사용해야 할까요? 또한 스크린 리더 사용시 두 손가락 사용은 다르게 탐색하는 기능이기 때문에 다중 누르기, 펜, 끌기와 놓기 등의 복잡한 동작은 단순한 누르기 동작을 함께 제공되어야 합니다.
이렇게 끌어다 놓기로 이동이 가능한 경우 우측과 같이 누르기 동작만으로도 이동이 가능하도록 구현해야 합니다. 다음은 웹에서의 조작 가능 항목인데요, 저만해도 버튼이 너무 작으면 마우스로 클릭하기 힘들거든요, 손 떨림 현상을 가진 사용자와 같이 정교한 마우스 조작이 어려운 사용자들은 작은 컨트롤을 조작하는 것이 더~어 힘들겠죠? 따라서 컨트롤의 크기는 대각선 길이가 6mm이상이 되도록 구현해야 합니다. 가로, 세로가 아니라 대각선 길이 입니다.
모바일에도 비슷하게 컨트롤의 크기와 간격 항목이 있는데요 모바일에서는 컨트롤의 가로, 세로 길이가 각각 9mm 이상이 되도록 구현해주셔야 합니다. 컨트롤 크기는 아무래도 디자이너분들이 신경 써 주셔야 할 영역인 것 같은데요, 즉, 컨트롤을 큼직큼직하게, 클릭하기 쉽게 제공해주시면 됩니다. 웹에는 반복 영역 건너뛰기 항목이 있는데요, 저는 처음에 이게 반복되는 영역으로 건너뛰는 기능 인줄 알았어요. 그래서 메뉴로 바로 가기 이렇게 제공해야 하는 줄 알았는데 그게 아니라 반복되는 영역을 건너뛰는 기능이었습니다. 페이지마다 보통 메뉴가 반복되어 있는데요, 웹 페이지를 들으면서 탐색하는 분들은 다른 페이지에 갈 때마다 이 메뉴를 처음부터 다시 읽어주게 되어 불편합니다. 따라서 페이지마다 반복되는 콘텐츠를 건너뛸 수 있는 기능을 제공해야 합니다.
반복 영역 건너뛰기는 마크업 상 최 상단에 위치해야 하고 당연히 링크는 페이지 내에 존재해야 하며 키보드 접근 시 화면에 노출되어야 합니다. 또한 하단 메뉴로 바로가기 와 같은 위치 정보는 시각장애인의 경우 하단이 어디인지 알 수 없기 때문에 본문으로 바로 가기와 같이 명확하게 제공해야 합니다.
그럼 모바일은 어떨까요? 모바일은 반복 영역 건너뛰기 항목이 없습니다. 모바일은 화면 공간이 협소하기도 하지만 보통 반복되는 콘텐츠인 메뉴를 이렇게 아이콘으로 제공하여 선택 시 메뉴가 노출되기 때문에 굳이 반복 영역 건너뛰기를 제공할 필요가 없습니다. 웹에서는 제목 제공 항목이 있는데요, 이렇게 페이지를 여러 개 띄워 놓은 경우 페이지 제목이 모두 네이버네이버네이버 이면 직관적으로 어떤 페이지인지 인지하기 어려워 불편합니다. 청각으로 웹을 탐색하는 분들 또한 페이지 내용을 다 들어야 어떤 페이지인지 알 수 있기 때문에 페이지에는 페이지를 유추할 수 있는 제목을 제공해야 합니다. 프레임이나 아이프레임에도 제목을 제공해야 하며 콘텐츠 블록에도 제목을 제공해야 하는데요 이렇게 헤딩 태그로 콘텐츠 제목을 제공해주면 스크린리더 사용시 헤딩 태그만 건너뛰는 기능이 있기 때문에 본인이 원하는 콘텐츠를 선택해서 탐색할 수 있습니다.
모바일은 어떨까요? 모바일에는 제목 제공 항목이 없는데요 왜 없을까요? 소스를 볼 수 없으니까요.. 뿐만 아니라 모바일 네이티브 앱에서는 title태그와 같이 페이지 제목을 제공하는 기능이 없습니다. 다만 모바일 웹의 경우에는 “웹뷰 네이버”와 같이 title태그로 제목 제공 시 해당 제목을 읽어줍니다. 또한 모바일은 터치 기반으로 터치하면 내용을 들을 수 있기 떄문에 제목 제공이 아직은 필수는 아니지만 제목 제공 해주는 것을 권장합니다. 콘텐츠 제목을 예로 들면 비장애인분들은 아 이 부분들이 다 메뉴이구나라고 인식할 수 있지만 스크린 리더 사용자는 이 부분이 어떤 영역인지 알 수 없어 사용에 혼란을 줄 수 있습니다.
따라서 이렇게 디자인상으로 콘텐츠에 대한 제목을 제공하거나 다른 방법으로 제목을 제공해 주는 것이 좋습니다. 웹에서는 데이터 테이블을 제공하는 경우 표의 제목과 내용 셀을 구분해야 하며, 제목과 요약 정보를 제공해야 합니다. HTML5부터는 summary속성이 없어져서 많이들 헷갈려 하시는데요, Summary 속성이 없어졌다고 해서 요약 정보를 제공하지 않는 것이 아니라, caption에 제목과 요약 정보를 모두 제공해야 합니다.
[2019널리세미나] 모두를 위한 제품 및 서비스 - 구글 웹 프로덕트 및 구글 플레이의 접근성Nts Nuli
안녕하세요, 구글 검색팀 소프트웨어 엔지니어 박재훈입니다.
접근성 향상을 위한 모두의 노력이 한 군데에 모이는 매우 의미있는 ‘널리 세미나'에 연사로 참여하게 되어 무척 영광입니다. 저는 검색팀 내에서 영화 검색의 프론트엔드를 담당하고 있습니다. 오늘 저는 여러분들께 구글 검색에서 지원하는 접근성을 위한 기능들 및 고려사항들을 소개드리고, 추가로 제가 소프트웨어 엔지니어를 꿈꾸는 대학생 대상으로 진행했던 웹 접근성 교육에 대해서도 공유를 드리도록 하겠습니다. 구글이 ‘접근성'이라는 주제를 대하는 방식을 이해하시는 데에 도움이 되기를 바랍니다.
구글의 미션은 "Organize the world’s information and make it universally accessible and useful" 입니다. 해석하면, "세상의 정보를 재구성하여 누구나 접근 가능하고 사용할 수 있도록 만들자" 입니다. 여기서 제가 "universally accessible", 즉 "누구나 접근 가능하고" 라는 부분을 진하게 처리해 놓았는데요, 이렇게 저희는 회사의 mission statement에도 접근성이 들어갈 정도로 접근성을 중요하게 생각하고 있고, 모든 제품과 서비스를 출시하고 운영할 때 이 접근성을 아주 중요한 요소 중 하나로 고려하고 있습니다.
영어권에서는 접근성이라는 단어를 줄여서 "a11y” 라고 부르는데요, 접근성을 영어로 쓰면 accessibility가 되는데 이 때 첫글자인 a와 마지막 글자인 y 사이에 11개의 알파벳이 있다고 해서 a-11-y의 형태로 줄여 쓰는 것입니다. 실제로 제가 업무를 할 때에도 이런 줄임말을 사용합니다.
그러면 본격적으로 구글 검색 페이지의 접근성에 대해 소개를 드리겠습니다. 웹사이트를 만들 때, "헤딩" 혹은 "h1, h2" 같은 단어를 들어보셨을 거예요. 현재 페이지의 제목을 나타내는 html 태그인데요, 이렇게 웹사이트에 제목 태그를 적절히 사용하게 되면, 시각장애인들이 스크린 리더를 사용하여 페이지를 탐색할 때에 전체적인 구조를 파악하는데 큰 도움이 됩니다. 또한, 스크린 리더로 순차적으로 페이지를 탐색할 때 제목 단위로도 포커스를 이동시키는 것이 가능하기 때문에, 원하는 섹션으로 빠르게 이동할 수 있습니다. 제목 설정은 <h1>, <h2>등의 태그를 사용하거나, <div>같은 일반 element에 role=”heading” 및 aria-level=”1"을 주는 방식으로도 가능합니다.
구글의 접근성 도움말 페이지를 보면, 구글 검색 페이지가 제목 수준, 즉 heading level별로 어떠한 구조로 나뉘어 있는지를 데스크탑 / 모바일 별로 볼 수 있습니다. 예를들어 데스크탑의 구글 검색 페이지에서는 검색결과, 광고 등 페이지의 중요 영역이 제목 수준 1로, '스포츠 결과', '동영상' 등 그룹 결과 섹션이 제목 수준 2로 표시되는 식입니다.
좀더 구체적인 예로 "어벤져스: 엔드게임"을 검색했다고 할 때, "검색결과" 라는 타이틀이 제목 수준 1이 되고, "어벤져스: 엔드게임" 이라고 나와있는 지식 패널의 제목이 제목 수준 2가 되고, 하위 구조에 있는 "출연진", "함께 찾은 검색어" 등의 소제목이 제목 수준 3으로 구성이 됩니다.
이렇게 기준을 정해놓게 되면, 스크린 리더 유저 입장에서는 일관성있게 검색 페이지를 탐색할 수 있어서 좋고, 또한 저 같은 개발자에게도 많은 도움이 됩니다. 저희 검색팀의 경우 팀 전체 규모도 아주 크고, 각각의 세부 팀들이 전세계의 지사에 흩어져 있습니다. 만일 이런 기준이 없이 예를 들어 광고팀은 광고 팀대로, 저희 영화 검색팀은 영화 검색팀대로, 알아서 제목 수준을 설정해 버리면, 이것들이 한 페이지에 같이 나타났을 때 전체 구조가 혼란스러워 지겠죠. 이렇게 기준을 정하면 서로 다른 파트를 작업 하더라도 일관성있는 구조를 가질 수 있습니다.
두번째로, 검색 페이지에 숨겨진 접근성 메뉴에 대해 소개드리겠습니다. 아마 많은 분들이 모르셨을 거에요. 구글 검색을 한 뒤 키보드의 Tab 키를 누르면 화면에 보이지 않았었던 특수한 메뉴가 뜹니다. 이 숨겨진 접근성 메뉴에는 세 가지 항목이 있는데요, "주요 콘텐츠로 이동"은 현재의 포커스를 검색 결과 내부로 이동시켜 주고요 , "접근성 도움말"은 각종 접근성 디바이스를 활용하여 구글 검색을 이용하는 것에 대한 도움말 페이지로 이동시켜 줍니다. 방금 소개드렸던 제목 수준 기준표도 해당 도움말 페이지에서 찾아보실 수 있어요. 마지막으로 "접근성 관련 의견 보내기" 가 있어요. 구글 검색에서 접근성 관련 문제가 있다면 이 채널을 통해서 의견을 보내주세요. 그러면 저를 비롯한 전 세계의 접근성 담당 엔지니어가 문제를 해결할 수 있도록 노력하겠습니다. 참고로, 이 숨겨진 접근성 메뉴도 heading level이 1로 설정되어 있습니다.
실무에서는 실태조사, 편의제공 등 다양한 현황에 맞춰 접근성에 대응해야 합니다.
접근성을 포함하는 방법과 그 사양을 구현하기 위한
세부적인 가이드가 필요하게 되었습니다.
수행은 접근성팀과 실무자들로 구성된 TF팀이 진행하였습니다.
지침과 체크리스트를 확인하고 우선 순, 반복되는 유형을 선정하여 오류사항 등을 목록화 합니다.
그에 맞는 서비스 사례를 조사하고 W3C명세나, 지침 등의 내용과 대조하여 확인합니다.
테스트를 통해 코드화를 진행하여 샘플 작업을 합니다.
어떤 기능들을 어떻게 사용하는지
IOS는 보이스오버, 안드로이드는 톡백이라는 프로그램을 사용합니다.
이중 IOS는 빠른 탐색을 할 수 있는 로터 기능을 제공합니다.
안드로이드는 음성 안내를 출력 표시해주는 기능을 제공하고 있습니다.
점자 단말기나 화면 자막 등 다양한 도구를 복합적으로 사용하고 있는 것을 알 수 있었습니다.
좌측은 실시간 급상승 화살표의 초점이 콘텐츠 크기와 일치하지 않는 볼 수 있습니다.
우측은 “러시아2018”의 초점의 위치가 다르고 크기도 다릅니다.
구글과 야후 검색에서는 선택된 “상태 값”을 제공하지 않고 있습니다.
선택된 것인지 현재위치인지 구분이 어렵습니다.
좌측은 동일 링크에 초점이 여러 번 이동하여 불필요하게 중복 적용이 된 경우입니다.
우측은 적절하지 않은 대체 텍스트를 제공하고 있습니다.
유투브는 선택된 상태값과 전체 탭의 개수 정보 3개중에 2번째라고 제공하고 있어,
탭이라는 유형과 상태정보를 알 수 있는 경우입니다.
대체 텍스트를 제공하지 않아도 오류이지만, 적절하지 않은 텍스트를 제공하거나
동등한 정보를 제공하지 않아도 오류입니다.
두 배너 모두 적절하지 않으며, 이미지와 동일하지 않는 텍스트를 제공하고 있습니다.
다음은 영어 대체 텍스트입니다. 한글 서비스 경우,
영어를 모르는 사용자들을 배려해서 한글로 제공해주는 것이 좋겠습니다.
‘Delete버튼’이 아니라 ‘삭제버튼’으로 제공합니다.
그러나 영어 콘텐츠 경우는 영어로 제공해도 오류는 아닙니다.
대체 텍스트는 alt, aria를 통해 도움말이나 설명을 추가할 수 있습니다.
좌측 첫번째 조석 예시는 이미지와 텍스트가 동등한 정보를 제공해주고 있지요.
좌측 두번째 별도 예시 경우 이렇게 별도의 텍스트가 있다면 alt는 빈 값으로 제공해도 오류가 아닙니다.
우측은 Aria-label을 통해서도 제공하는 방법입니다.
예시 이미지에 role을 선언하고 Aria-label에 텍스트를 제공한 경우 인데요.
단, 저희가 테스트할 때 클릭 커블한 요소에서만 음성이 지원되는 것을 확인 할 수 있었습니다.
Aria-labelledby(아리아레이블드바이)는 DOM에 있는 다른 요소 ID를 지정해서
관련정보를 제공할 수 있는 관계 속성입니다.
back보다는 뒤로가기, hot보다는 인기, new보다는 신규로 하는 것이 좋겠습니다.
App은 앱으로, id는 아이디로, open은 오픈, 열림으로
password는 패스워드, 비밀번호로 제공해주면 좋겠습니다.
하나의 링크 요소에 여러 번 초점이 이동하는 것은 중복 적용으로 오류이기 때문에
블럭된 형태로 묶어서 제공해주는 것이 좋습니다.
Block, br요소는 초점을 분리합니다.
일체화를 위해서는 인라인 요소가 2개 이상일 때나, 가상요소(before, after) content에
non-breaking-space(논브레이킹스페이스=\00a0) 유니코드를 적용하면 블럭 형태가 됩니다.
좌측을 보시면 화살 모양에 초점이 매우 작게 잡힌 것을 볼 수 있습니다.
이때 터치 기반 디바이스는 최소 9mm이상이 되로독 적용해야 합니다.
IOS는 텍스트, 이미지 기준으로 초점이 크기를 갖지만,
안드로이드는 크기 관련 CSS값으로 적용해주면 됩니다.
초점은 모든 콘텐츠에 적용해야 하지만
“의미가 없는 콘텐츠” 경우는 초점이 이동하지 않도록 하는 것이 좋습니다.
레이아웃에 영향을 주지 않고 Aria-hidden=“true” 로 초점이 이동하지 않도록 한 경우 입니다.
이 외 Display:none;이나 visibility: hidden; 백그라운드를 적용하는 방법 등도 있습니다.
음성으로는 들리는데, 초점이 보이지 않는 경우가 있습니다.
숨김텍스트를 Viewport(뷰포트) 밖으로 위치시켜서 초점이 보이지 않는 것인데요.
text-indent, line-height, position 등의 값을 적용한 경우며,
이는 성능 최적화에도 영향을 주기 때문에 지양하는 것이 좋습니다
초점이 순서적으로 이동하는 것을 확인하였습니다.
모바일은 tabindex가 초점 순서에 영향을 주지 않기 때문에
되도록 HTML 코드 순서에 맞게 구성하는 것이 좋겠습니다.
HTML 자체 기능을 우선으로 하며, 개발과의 혼선을 주지 않기 위해
ARIA와 연결된 ID에 "00_" 형식의 접두사를 적용하는 ARIA만의 네이밍을 제시합니다.
ARIA의 (Role), 속성(Property), 상태(State)를 구성요소 표로 제시하여 필수유무에 따라 선택 적용할 수 있도록 하였습니다.
체크박스는 여러 항목 중 한 개 이상 선택할 때 사용하며 용도, 상태값, 유형 정보를 제공합니다.
구성요소는 role=“checkbox” 상태는 aria-checked로 선택됨을 확인하도록 합니다.
콤보박스는 인라인 텍스트 박스와 리스트 박스 2가지 요소의 조합으로 구성합니다.
자동 선택 목록이 있는 리스트임을 알 수 있도록 유형정보와 “옵션”의 선택된 상태 정보를 제공합니다.
구성요소는 role=“combobox”이며, 하위 콘텐츠가 있을 때 aria-haspopup은 “listbox”라는 명시적인 값을 주어야 합니다.
aria-owns와 aria-autocomplete는 선택사항입니다.
리스트에 role=“listbox’를 aria-selected로 선택된 상태값을 제공합니다.
지못미 마우스이벤트
김혜일
(키보드 사용 보장) 모든 기능은 키보드만으로도 사용할 수 있어야 한다.
도움말 아이콘을 마우스오버로 열 때 키보드의 초점이동만으로 펼쳐진다.
그런데 말입니다.
(사용자 요구에 따른 실행) 사용자가 의도하지 않은 기능(새 창, 초점에 의한 맥락 변화 등)은 실행되지 않아야 한다.
잘 지키고 있는가
초점을 받았을 경우,
사용자가 의도하지 않은 기능은 실행되지 않아야 한다.
키보드사용자의의도
키보드초점이동은 # 콘텐츠 탐색 # 조작을 위한 이동
쇼핑 사이트의 장바구니
키보드 초점 접근시 활성화되는 판매가, 카드헤택, 할인내역 등의 도움말이 많이 제공되었다.
#키보드사용자 #의도하지 않은 정보 인식 #정보의 선택권 X
초점에 의한 맥락의 변화
화면낭독프로그램 초점의이동에따라 콘텐츠가 활성화되어 맥락에 변화가 발생한다.
#화면낭독프로그램 사용자 #의도하지 않은 정보 인식 # 의도하지 않은 콘텐츠의 변화 #정보의 선택권 X
어떻게 하면 좋을까
어느쇼핑사이트1 마우스오버시 활성화되고, 키보드 엔터를 눌럿을 때 활성화됨
어느 쇼핑사이트2 마우스클릭시 활성화되고 키보드 엔터를 누렀을 때 활성화됨
끝판왕 GNB 메뉴
메인메뉴가 초점이동으로 활성화되어 탐색에 어려움이 있다.
이렇게 해보자
#초점이동 #기능실행NO
이렇게해보자 1단계메뉴
초점 접근 > 기능 실행 없음
Enter 입력 > 하위 메뉴 확장
이렇게해보자 2단계메뉴
초점 접근 > 기능 실행 없음
Enter 입력 1뎁스는하위 메뉴 접기 2뎁스는 메뉴 실행
이렇게해보자 3단계메뉴
초점 접근 > 기능 실행 없음
Enter 입력 1,2뎁스는하위 메뉴 접기 3뎁스는 링크 실
이렇게해보자 메뉴링크텍스트
하위메뉴의 펼침 상태에 따라 확장됨, 축소됨과 같은 문구 제공
이렇게해보자 기능이 2개인 메뉴
하위메뉴 확장 전 OOO 확장됨 링크
하위메뉴 확장 후 OOO 이동 또는 바로가기 링크
결론은
키보드 사용자UX가 중요
Page 1
표지: ‘모두가 쉽게 쓰는 그날까지’… 함께 만드는 접근성
삼성전자 백인호(무선), 안현진(생활가전)
Page 2
동영상: 피아니스트 노영서씨와 릴루미노의 ‘특별한 만남’
링크 : https://youtu.be/QE9kHZQvByU
Page 3
만드는 이들의 첫번째 원칙은?
Page 4
사진설명: 보이스 어시스턴트, 소리 감지, 보조메뉴 등 갤럭시 스마트 폰의 다양한 접근성 기능 폰 화면 이미지 (왼쪽부터)
Page 5
사진설명: 아기가 우는 소리에 옆집에서 문을 두들기고 있으나 청각장애인 엄마는 들리지 않아 모르고 자는 모습
소리 감지 : ‘아기가 다른 방에서 우는데 밤새 듣지 못했어요. 옆집에서 우는 소리 듣고 와서 문을 두들겼는데도 몰랐죠. ㅠㅠ’
Page6
사진설명: 보이스 라벨 기능으로 NFC 라벨을 약병에 붙이고 폰으로 태깅하여 음성으로 구분하는 모습의 이미지
보이스 라벨 : ‘형태가 비슷한 약병 등의 물체를 구분 할 수 있도록 해주세요.’
Page7
사진설명: 보이스 라벨 기능으로 NFC 라벨을 반찬 통에 붙이고 폰으로 태깅하여 음성으로 구분하는 모습의 이미지
보이스 라벨 : ‘형태가 비슷한 반찬 통을 구분 할 수 있도록 해주세요.’
Page8
간지 페이지 : 맞춤형에서 유니버설 디자인까지
Page9
사진설명: 삼성 서포터즈 시각, 청각 장애인 분들과 함께 갤럭시 접근성 관련하여 논의하는 모습
Page10
사진설명: 업데이트 된 삼성 고대비 테마 2 및 인터넷 앱 고대비 모드 2 화면 이미지
Page11
사진설명: 업그레이드 된 삼성 키보드 앱 – 고대비 키보드 화면 이미지
Page12
사진설명: 장애인 사용자 분들이 빅스비, 빅스비 비전, 삼성 덱스 등을 이용하는 모습
Page13
간지 페이지: 조금 더 가까운
Page14
사진설명: 삼성전자 시각장애인 임직원 김병호 님이 음성 강의 녹음 하는 모습
Page15
사진설명: 시각장애인분들에게 갤럭시 스마트 폰 사용법을 교육하는 ‘스마트 엔젤’ 봉사활동 모습
(보이스 어시스턴트, 빅스비, 릴루미노, 보이스 라벨 등)
Page16
간지 페이지: 우리 모두가 함께
Page17
“장애인이 아닌 고객으로… 제품을 더 편하게 사용할 수 있도록 해 주세요.“
“것은 사회적 서비스와 연계해서 할 수 있도록 도와야 해요.”
“제품만으로 해 줄 수 없는 것이 있어요. 이런 것은 사회적 서비스와 함께 해주세요.”
“새로운 기술과 서비스가 계속 나오고 있는데 접근성만 갖춘다면
앞으로의 삶이 전보다 편해질 수 있을 것 같아 기대 되요.”
Page18
4차 산업 혁명에서 더욱 더 나은 세상을 만들기 위해
Page19
Change the world, together!
우리 모두가 함께.. 접근성 향상을 위하여 더욱 노력해 나가요!
Page20
가전기기와 음성인식이 더해진다면?
Page21
인지심리학적으로 어떤 제품을 사용할 때 감각-인지-의사-결정의 프로세스를 따릅니다.
이를 세탁기 사용에 대입한다면 세탁기패널을 보고-기능을 인지하고-어떤 기능을 수행할지 결정하고 –원하는 버튼을 찾아 누르는 단계를 거칠 것 입니다.
이런 복잡한 과정을 음성인식을 통해서 직접 명령하고 확인할 수 있습니다.
Page22
영상 설명: 시각장애인 임직원(김병호 프로님) 음성세탁기 사용 영상
Page23
냉장고, 에어컨, 세탁기 등 음성인식 가전기기들은 손과 눈을 자유롭게 하기 때문에 시각 그리고 지체장애인의 접근성을 향상시킬 수 있습니다.
Page24
단순히 음성인식을 적용하는 것이 아닌 함께 만드는 것이 중요합니다.
기획/개발 단계에 시각장애인 임직원 참여/필드 테스트
시/청/지체 장애인 단체 전문가 정기 자문
미국 장애단체 협업(AFB, American Foundation for Blind)
장애인 사용성 테스트
장애인 세탁 전문가 대상 사용성 테스트
Page25
그런데… 여러분 집에 있는 가전기기는 말을 할 수 있나요?
Page26
영상 설명: 냉장고 버튼, 같은 소리만 반복해서 남
Page27
같은 제품, 다른 소리를 가진 세탁기
Page28
영상 설명: 같은 소리가 나는 A세탁기와 개선된 소리를 가진 B세탁기를 사용하는 모습(코스 설정)
Page29
영상 설명: 같은 소리가 나는 A세탁기와 개선된 소리를 가진 B세탁기를 사용하는 모습(온도 설정)
Page30
Principles of Sound
장애인 접근성과 비장애인 사용성 향상을 함께 하는 방향
목적과 특성을 고려한 청각적 정보 설계(On:상승음, Off:하강음)
충분한 볼륨과 적절한 Pitch로 제공
순서값(Ordinal)은 단계별 음, 이름값(Nominal)은 기준점 음 제공
Page31
기존(세탁기A), 개선(세탁기B) 테스트 결과
개선(세탁기B)가 압도적으로 높은 과업 성공률과 설문 점수
Page32
사진 설명: 디지털 프라자
Page33
감사합니다.
[2018널리세미나] 4차 산업혁명에서 정보 접근성 교육 현황과 앞으로의 과제Nts Nuli
4차 산업혁명에서 정보 접근성 교육 현황과 앞으로의 과제
발표 목적
지금까지 여러 접근성 세미나를 통하여
누구나 사용할 수 있는 접근성 개선 방법에 대해 알아보았음.
그러나 기술적인 접근성 개선과 비교하여
실제 사용자의 ICT 활용 수준 격차를 줄일 방법에 대한 논의는 부족하였음.
발전하는 기술 수준과 사용자의 기술 활용 수준을 좁히기 위한 방법은
맞춤화 된 정보화 교육 등의 노력이 필요함.
우리 엔비전스에서는 현재 시각장애인의 기술 활용 수준을 높히기 위한 노력의 일환으로
이루어 지고 있는 국내외 정보화 교육 현황과 앞으로의 과제에 대해 함께 고민해 보려 함.
엔비전스에서 지금까지 발표한 내용들
1. 시각장애인도 다이나믹한 웹 페이지 사용이 가능한가?
: WAI-ARIA 기술 소개
2. 스크린리더 호환성 이슈
: 같은 웹페이지라도 스크린리더에 따라 접근성에 대한 체감 지수가 다를 수 있다.
3. 보조기술의 발전
: 접근성 API 뿐만 아니라 보조기술 쪽에서도 접근성 향상을 위해 많이 노력하고 있다.
4. 4차 산업 혁명이 시각장애인에게 미치는 영향
: 인공지능, 사물인터넷 등이 점점 발전하면서 시각장애인에게 더 편리한 삶을 제공해 줄 수 있다.
접근성에 대한 노력은 계속 되고 있다 1: Accessibility object model
1. HTML DOM과 접근성 API 트리를 분리하여 깔끔한 HTML 제작 가능.
2. 기존과 달리 특정 요소에 WAI-ARIA id를 부여하지 않고 다이렉트로 연결시킬 수 있어 시맨틱한 문서 구조에 용이.
3. 모바일 브라우저에서 구현할 수 없는 커스텀 컨트롤을
보조기술 캡처를 통하여 웹뷰도 앱뷰처럼 사용자가 제스처 할 수 있도록 지원 가능.
접근성에 대한 노력은 지금도 계속 되고 있다 2: Accessibility pane title
안드로이드에서 스마트폰의 특성상 하나의 activity를 fragment를 통하여 activity를 여러 개로 구분한 경우
각 fragment마다 제목을 다르게 읽어줄 수 있도록 하는 API가 개발됨.
접근성을 개선해도 시각장애인이 어렵게 느낄 수 있는 이슈들
1. 스크린리더가 설명하는 언어를 이해하지 못하는 경우.
≫ 윈도 탐색기에서 시연
2. 스크린리더와 커뮤니케이션 하려면 키보드의 단축키 혹은 제스처를 이용해야 하는데
어떤 단축키를 이용해야 하는지 모르는 경우.
≫ 안드로이드의 custom action 시연
3. 스크린리더 호환성 이슈로 접근성이 개선된 항목을 제대로 읽어주지 못하는 경우.
≫ WAI-ARIA로 구현된 drag & drop 시연
4. 조작할 수 있는 설명 제공에 한계가 있는 경우.
≫ 네이버 메모 웹 폴더 작업 시연
정보접근성 교육
이러한 문제를 해결하기 위해 여러 방법으로 정보접근성 교육이 이루어지고 있음.
정보접근성 교육은 음성 혹은 영상으로 제공되는 온라인 강의와 오프라인 강의, 문서 매뉴얼로 나눌 수 있음.
교육 범위
1. 온라인 음성/영상 강의 및 오프라인 강의의 경우 키보드 혹은 터치 제스처 익히기부터 기본적인 윈도 및 스크린리
더 활용, 컴퓨터 관리, 엑셀이나 웹페이지 활용 등을 교육하고 있음.
2. 오프라인 교육은 강사와 실시간 커뮤니케이션이 가능하므로 각 당사자에 맞는 교육이 가능, 시간 및 공간 제약으로 누
구나 원하는 시간에 교육을 받을 수 없음.
3. 문서 매뉴얼의 경우 여러 서비스별 사용방법 및 스크린리더로 해당 서비스 사용 시 참고사항 등을 다룸.
해외의 온라인 정보접근성 교육
섹션 단위로 이동 가능한 팟캐스트나 데이지 형식, webinar 형식으로 주로 진행.
Webinar 형식으로 진행 시 수업 중간에 질문을 자유롭게 할 수 있어 양방향 소통 가능.
특정 서비스 사용 시 필요한 스크린리더 참고사항 등을 문서 형태로 제작하여 웹페이지에 게시.
우리 나라의 정보접근성 교육
1. 음성 강의 혹은 동영상 강의 형태로 제공. (실로암 이러닝, 삼성애니컴)
2. 상황에 따라 스카이프 메신저를 활용하여 10명 이내의 그룹 강의를 하는 경우도 있음.
3. 일부 서비스에 대한 온라인 매뉴얼 제공.
(네이버의 블라인드매뉴얼, 삼성전자 웹접근성 안내, kt 웹접근성 안내)
앞으로의 과제 – 온라인 매뉴얼 제공 확대
우리 나라의 경우 복지관에서 제공하는 온라인 교육은 컴퓨터 혹은 스마트폰의 기본 기능과 인기 있는 서비스 위주로 제공함.
각 서비스를 제공하는 회사에서 접근성 개선과 함께 장애인 당사자를 위한 온라인 매뉴얼 제공 확대 필요.
≫ 네이버 메모의 폴더 이름 변경, 접근성이 고려된 보조배터리 구조 설명을 시연.
온라인 매뉴얼 제공 시 장점 및 유의사항
스크린리더 사용자 관점에서 매뉴얼이 제공되므로 서비스를 더 쉽게 이용할 수 있음.
접근성 개선이 미처 커버하기 어려운 부분에 대한 추가 설명을 제공함으로써 서비스의 이용을 도움.
처음 NWAX 라는 이름으로 서비스를 시작하였습니다. Firefox에 설치해서 페이지를 진단하였습니다. 이후 웹 버전으로 업데이트 되어서 NWAX+라는 이름으로 변경됩니다. 웹 버전이라고 하면, 사용자가 페이지(URL)을 서버에 전달하면 서버에서 그 페이지를 진단하고 결과를 보내줍니다. 이후 고도화를 진행하면서 NACT라고 변경됩니다. NACT는 가상 브라우져 phantomjs를 기반으로 사용자가 보는 화면과 비슷한 환경에 데이터를 받아서 분석하여, 결과를 보내줍니다.
고도화는 항상 필요하죠. 이번에 자세히 설명 드릴 NACT3로 넘어오게 됩니다. NACT3는 24개의 정부지침을 재해석해 규칙(체크리스트)으로 제공하고, 후처리 페이지, WAI-ARIA가 사용된 페이지를 진단하게 됩니다. 내부적으로 node – phantomjs 로 구성되어 있던 NACT를 react – javaFX – webkit 으로 구성하여 처리하게 됩니다.
NACT3 는 엔진과 뷰로 구성됩니다.
엔진은 javaFX + webkit 뒤에 언급하겠지만, 브라우져 때문에 많은 시간이 들었습니다. Chrome -> firefox -> phantom -> webkit 으로 변경하면서 많은 시행착오를 겪었습니다. 중요한 기술적 핵심은 브라우져와 요소들의 수집입니다. 로직적으로 핵심은 a11y 라고 되어 있는 규칙들입니다. 규칙은 접근성 진단을 수행하면서 쌓인 패턴을 분석해서 프로그램 로직으로 만들었습니다. 예를들어 <img> 에서 alt 속성이 없으면 오류다. 같은 규칙이 생기면, method로 구현하게 됩니다.
소스를 살짝 보여드리면, 이렇게 구현이 됩니다.
뷰는 react + parser 위에서 보여드린 json data를 파싱해서 화면으로 뿌려주는 역할을 합니다.
주요 기술을 살펴보겠습니다. 기본적인 틀은 spring으로 되어 있습니다.
스프링은 워낙 유명한 프레임워크이고 다른 좋은 자료들이 많으니 생략하도록 하겠습니다.
A11y 부분은 규칙이 정리된 엑셀 문서를 기반으로 코드화 한 부분입니다. 각 규칙의 지침별로 패키지화 하고, 하나의 규칙을 하나의 메소드로 만들어 진단을 수행시킵니다.
언급되었던 브라우져 입니다. Chrome, Firefox, Phantomjs, Webkit 을 사용해 보았었습니다. 브라우져를 사용하면서 많은 문제점들이 발생하였습니다.
처음 시작은 Chrome 으로 개발하였습니다. 컴퓨터에 Chrome이 설치되어 있고, Chromedriver를 통해서 NACT 시스템과 Chrome이 통신하게 됩니다. 진단되는 과정을 눈으로 볼 수 있으며, 개발자툴을 사용할 수 있어서 개발이 용이합니다. 하지만, 쓰레드로 여러 개의 Chrome을 실행했을때 NACT와 Chrome 사이에 통신 오류가 발생합니다. 다시 말해 1번 쓰레드가 실행시킨 1번 Chrome이 2번 쓰레드 혹은 3번 쓰레드랑 통신하게 되는 경우가 발생합니다. 포트를 통해 통신을 하게 되는데 이 포트에 동기화라고 해야 되나요…? 자신이 실행시킨 포트를 못 찾아가게 되는 현상이 생겼습니다. 그래서 Chrome을 포기하게 되었습니다.
Firefox는 gecko를 통해 통신하는데, 통신의 오류는 없지만 메모리를 엄청 잡아먹고 리소스를 종료 시키지 않는 문제가 발생하였습니다.
Phantom으로 변경하게 되었고, 가상 브라우져입니다. 자세한 내용은 공부하시면 됩니다. Phantom은 통신 오류나 메모리 문제를 해결하였습니다. 하지만, 역시 외부 브라우져를 실행시키고 각 요소를 접근해서 가져오다 보니 진단 시간이 많이 소요되고 요소가 많은 페이지 일때 심각하게 느린 문제를 가지게 되었습니다.
진단 시간에 대한 근본적인 문제는 외부 브라우져를 사용하게 되어서 입니다. 그래서 Webkit를 떠올리게 되었고, javaFX + Webkit를 통해 NACT가 javaFX Application을 실행시키게 되고 실행된 Application에서 Stream으로 data를 받아와서 처리를 수행하는 것으로 해결하게 되었습니다.
물론, javaFX와 Webkit이 완벽한 것은 아닙니다. 완벽했다면 제가 여기 없겠죠. 둘 다 가지고 있는 한계가 있고 처음 개발되는 영역이다보니 자료도 많이 없고 ㅠ 버그도 엄청 많습니다. 계속 고쳐 나가고 있는 상황이며, 올해에는 끝이 날까 ,,, 하는 기대를 해봅니다.
이렇게 자동화를 통해 진단하는 것을 보시면, Error 와 Warning으로 나오시는 걸 보실 수 있습니다. 확실하다 생각되는 규칙은 Error로 애매한 이슈는 Warning으로 구분되어 집니다. 예를 들어 <img> 태그에 alt이 없으면 확실한 오류 입니다. <img> 태그에 alt 값이 빈 값으로 되어 있으면, 애매합니다. 정보성 이미지가 아니거나, 이미지를 설명하는 별도의 텍스트를 제공하고 있는 경우 alt 속성을 빈 값으로 제공해도 되기 때문입니다. 이런 경우는 warning으로 제공해서 확인을 부탁하는 의미로 접근합니다. 화면의 깜박임도 자동으로 진단하기는 어렵습니다.
NACT는 뷰와 엔진을 분리한 이유도 다양한 서비스에서 사용할 수 있게끔 하기 위해서 입니다. 그 첫번째가 NWARS입니다. 작년에 보여드렸었기 떄문에 살짝만 살펴보고 끝내도록 하겠습니다. 네이버는 많은 서비스들이 있고 너무 많은 페이지들이 있습니다. 이러한 서비스들이 매번 NACT에서 진단을 수행하고 처리하게 되면 실제적으로 접근성 개선을 하기 쉽지 않습니다. 지속적으로 관리하고 개선되고 있는 부분들을 볼 수 있게 해주는 서비스가 NWARS입니다.
NWARS는 지속적으로 관리할 서비스와 페이지들을 가지고 있습니다. 이 페이지들을 1주일에 한번 NACT 엔진에 던집니다. NACT는 NWARS가 보내준 페이지를 진단하고 이슈 정보를 보내줍니다. 보내준 이슈를 NWARS는 재 분류해서 저장하고 서비스를 위해 데이터를 가공해서 보여주게 됩니다. 대표적으로 차트 정보가 될 수 있습니다. 그리고 서비스가 얼마나 개선되고 있는 혹은 개악되고 있는지를 보여줄 수도 있습니다.
1 페이지
안녕하세요. 접근성 오류와 진단에 발표를 맡은 접근성팀 신의식입니다.
2 페이지
발표는 개요와 history 10분 Architecture 와 Function 10분 시연을 잠깐 보여드리고 마무리 하도록 하겠습니다.
3 페이지
헤밍웨이도 자신이 쓴 초고 원본은 쓰레기라고 했듯이, 한번 개발로 끝내는 개발은 없을 것입니다. 아무리 잘 하더라도 퇴고하듯이 개발을 진행해야 좋은 개발로 이어진다 생각합니다.
접근성을 잘 지켜 개발을 진행해도 내가 아닌 다른 사람이 검토해 준다면 더 좋은 개발이 될 것입니다. 하지만, 접근성 진단 어려움이 있습니다.
4 페이지
이번 시간에는 두 가지 툴을 소개해드리려고 합니다.
NWARS는 리포팅 툴이고 관리와 이력 서비스를 제공합니다.
NACT는 진단을 수행하는 툴입니다.
NACT는 엔진을 담당하고 NWARS는 서비스를 담당하고 있습니다.
NACT는 일회성으로 빠르게 진단을 수행하고 결과를 보여줍니다.
NWARS는 등록해두면, 주 별로 진단을 수행하고 이력을 저장해서 보여줍니다.
서로 보완하며 서비스를 제공하고 있습니다.
5 페이지
먼저 NWARS를 살펴보겠습니다. NWARS 3.0 이라고 써 있습니다.
느낌 오셨듯이 3번의 큰 변화를 거쳐서 지금의 모습으로 서비스하고 있습니다.
4개의 주요 페이지로 구성되어 있습니다.
전체 > 요약 > 범위 > 이슈 라고 생각해주시면 되겠습니다.
전체는 다른 서비스들에 비교해 어느 수준인지 알아볼 수 있습니다.
요약은 서비스의 접근성 수준을 보여줍니다.
범위는 각 URL에 대해서 이슈가 어느 정도 있는지 알 수 있습니다.
이슈는 접근성 진단에서 문제가 있다고 보여지는 요소를 보여줍니다.
6 페이지
다음으로 NACT 입니다.
얘는 숫자가 없습니다.
2개의 페이지를 보여줍니다.
URL의 입력과 진단 결과 입니다.
실제적으로 실무에서 제일 많이 쓰이는 서비스이고 복잡한 UI보단 단순 명료하게 정보를 전달하려고 합니다.
7 페이지
앞에서 말씀 드렸듯이 NWARS는 3번의 변화를 거쳤습니다.
1.0은 폐기되었습니다.
2.0은 지수와 이력을 주요 기능으로 제공하였습니다.
(지수를 설명하자면, 이슈가 몇 개라는 방식보다는 서비스 담당자들에게 잘 와 닿을 수 있게 100을 기준으로 환산하여 보여주었습니다.)
3.0은 지수가 폐기 되어 서비스 전체에 접근성 진단 요소에 대한 과락을 보여줍니다.
8 페이지
NACT는 원래 NWAX로 불렸었습니다.
NWAX는 파이어폭스에서 설치하여 실행합니다.
NWAXPLUS는 URL을 입력 받아 진단을 수행합니다.
NACT는 NWAXPLUS를 고도화 시켜 서비스를 제공합니다.
9 페이지
NACT는 원래 NWAX로 불렸었습니다.
NWAX는 파이어폭스에서 설치하여 실행합니다.
NWAXPLUS는 URL을 입력 받아 진단을 수행합니다.
NACT는 NWAXPLUS를 고도화 시켜 서비스를 제공합니다.
10 페이지
NWARS에 사용된 기술을 간략히 말씀드리면, Spring을 기반으로 Tiles, Mybatis 등이 쓰였습니다.
배치, 캐싱, 프로시져 등을 사용하였습니다.
각 상세한 기술 내용은 생략하도록 하겠습니다.
11 페이지
NACT는 Node.js와 Phatom.js으로 구성되어 있습니다.
Node는 화면과 전체 기반을 제공합니다.
Phantom은 가상 브라우져의 역할을 하며, 페이지 정보를 넘겨줍니다.
12 페이지
이제 자세한 기능을 살펴 보겠습니다.
NWARS의 대시보드는 상, 중, 하 로 구성됩니다.
상단에는 막대차트를 이용해 도달해야 하는 목표와 다른 서비스들과의 비교를 보여줍니다.
중단에는 파이차트를 활용하여 전체적인 수준을 보여줍니다.
하단에 서비스카드 목록은 각 서비스의 목록과 간략한 수준 정보를 보여줍니다.
13 페이지
대시보드에서 서비스를 선택하면, 그림 같은 요약 화면으로 넘어오게 됩니다.
전체적인 준수도 및 접근성 의견이 보여집니다.
진단 결과를 주요하게 봐주셔야 합니다.
표본 페이지별 진단 결과를 표로 보여줍니다. 이 데이터는 각 항목에 대해 어느 범위가 문제가 있는지를 잘 보여줍니다.
마지막으로 매주 진단이 수행되며 쌓인 추이를 보여줍니다.
14 페이지
NWARS는 서비스 담당자를 지정하여 범위를 관리합니다.
운영 담당자로 지정되면 각 분야의 담당자를 관리 할 수 있습니다.
이 기능으로 통해 서비스에서 진단이 필요한 범위를 관리하게 됩니다.
15 페이지
먼저 보셨듯이 서비스 담당자로 지정되게 되면 붉은색으로 표시된 버튼이 보여지게 됩니다.
범위수정을 통해 범위를 수정하고 대표 범위를 선택할 수 있습니다.
16 페이지
실무자들이 가장 많이 찾는 페이지 입니다.
실제 이슈들을 볼 수 있는 페이지 입니다.
검색을 통해 자신과 관련 있는 이슈들을 볼 수 있습니다.
17 페이지
아까 목록에서 이슈를 선택하고 이슈 상세로 이동하게 됩니다.
각 요소들을 확인합니다.
중요한 정보는 하단에 이슈내용과 관련코드 해결방안을 중점으로 보고 이슈를 처리하도록 안내하고 있습니다.
18 페이지
기타 기능으로 접근성에 관련된 정보나 NWARS에 문의를 할 수 있습니다.
19 페이지
NACT는 먼저 말씀 드린 대로 편리하게 URL만 넣어주시면 됩니다.
진단이 수행된 후 결과를 그림처럼 항목을 나눠 보여주게 됩니다.
20 페이지
NWARS와 NACT의 접근성 진단은 한계를 가지고 있습니다.
1. 어마어마한 코드가 존재하고 방법도 다양합니다. 모든 형태의 소스를 진단하지 못합니다.
2. 후처리 언어의 경우 request와 response의 시간 차로 진단 시점에 따라 결과가 달라집니다.
3. 새로운 기기까지 나옵니다. 해상도도 각각입니다. 이 차이에 의해 진단이 달라져야 하는 경우가 발생합니다.
완전하지 않습니다. 언제나 최선을 다해 도움이 되기만을 바랍니다.
21 페이지
이상으로 마치겠습니다. 고맙습니다.
Page 1
Transparent, inclusive, and accountable/approachable
Page 2
Introduction of Amos Miller
Page 3
Microsoft's Mission
Page 4
When we talk about empowering people, we simply mean that with the right tools, anyone can do anything.
Page 5
Let’s look at how we think about disability.
Page 6
It is not always obvious when someone is living with a disability
Page 7
The majority of disabilities are invisible.
Page 8
Permanent
In the US alone, 26,000 people a year suffer the loss of upper extremities.
Page 9
Temporary
13 million people suffer temporary impairments
Page 10
And 8 million experience situational exclusion because they are holding a child or a bag of groceries.
Page 11
Exclusion
Technology designed with the needs of someone who has one hand or arm, for example, has the potential to benefit everyone.
Page 12
Over a billion people live with disabilities. Their exclusion harms all of us.
Page 13
Microsoft is no stranger to this effort. We have a rich history in this space and have been helping contribute to ? and lead? The advancement of accessible technology for decades.
Page 14
Key investments - Do a lot more - not as a bolt on
Page 15
Four areas that are critical to our success through:
Our culture
- Accessible and Accountable
- Inclusive Interactions
- Investing in our future
Page 16
Our Culture is about the diverse environment with a growth mindset. This includes hiring to designing inclusively as well
Page 17
(Presenting photos of Microsoft Accessibility team member who are having some challenges)
Page 18
Accessible and Accountable
Page 19
Inclusive Interactions
Page 20
PowerPoint Designer
Page 21
Automatic Alternative Text
Page 22
Video Clip for Learning Tools for OneNote
Page 23
Investing in the future
Page 24
Video Clip for Project Emma
Page 25
Video Clip for Gleason Partnership
Page 26
(Presenting photos of Microsoft Accessibility project and stories)
Page 27
Video Clip for Cities Unlocked
Page 28
The Journey Ahead
Page 29
Every person, Empowered. In every context
발표 1 남의 문제 나의 문제 우리의 문제
1페이지 동영상
3페이지
국내외 청각장애인 인구
4페이지
청각장애
5페이지
청각장애인들은 다양한 방법으로 소통합니다
6페이지
청각장애인 의사소통의 어려움
7페이지
1:1 대화상황 수화, 입모양 보임
8페이지
필요
9페이지
기존에 지원된 자막 지원 방법
10페이지
서울특별시 지하철에 게제된 광고
11페이지
타이핑 PC 화면
스마트폰 어플화면
12페이지
쉐어타이핑을 유니버설 디자인 관점에서 소개
13페이지
About 유니버설 디자인?
14페이지
Example 유니버설디자인?
15페이지
AUD
Auditory Universal Deaign
16페이지
유니버설 디자인과 웹접근성, 두가지의 차원으로 이해
17페이지
다양한 디바이스 지원
18페이지
왼쪽 사진은 노트북 대필 해주는 장면
오른쪽 사진은 스마트폰 쉐어타이핑 지원해주는 장면
19페이지
왼쪽 사진은 발표자의 이야기가 스크린 옆의 별도의 스크린에 자막이 지원 되는 장면
오른쪽 사진은 공연장에서 스마트폰 쉐어타이핑으로 실시간 노래가사 자막이 지원되는 장명
20페이지
웹, 앱 접근성 좋은 사례
21페이지
카폐에 모여서 웹접근성 오픈테이블 논의 하는 자리에 다들 사진 찍는 모습
22페이지
진지하게 웹접근성 오픈테이블 논의함
23페이지
인터넷강의
24페이지
인터넷 방송
25페이지
자동자막을 동영상 안에서 출력하는 것이 아니라 동영상 하단에 자막 나오는 칸을 추가해서 화면 몰입도를 방애되지 않게 배치
26페이지
영상채팅통화앱
27페이지
배달앱
28페이지
콜택시앱
29페이지
웹, 앱 접근성 고려해야 할 사항
30페이지
극장이 아닌 스마트폰이나 테블릿, PC 등에서 VOD 시청할때 한국영화 자막이 나와게 해야.
31페이지
아디다스 광고
32페이지
네비게이션
33페이지
청각장애인에게 문자, OTP 등 인증방법을 선택할 수 있어야.
33페이지
Universal Design NAVER
발표 주제: 웹 접근성 체험관을 소개합니다!
발표자: 김보민
1. World Wide Web
2.Special User(고령자/장애인)
앞서 말씀드린 소수 수용자는 장애가 있는 분들 뿐만 아니라 앞으로의 우리인 고령자도 포함됩니다.
- 고령자 인터넷 이용률 그래프 설명: 2013년 17.6%, 2014년 21.9%, 2015년 27.5%
- 장애인 인터넷 이용률 그래프 설명: 2012년 55.5%, 2014년 56.7%, 2014년 59.1%
<장애인구에>
- 장애 인구: 지체장애 1333명, 청각언어장애 279명, 시각장애 251명, 기타 657명
- 웹 접근성 필요 인구: 저시력 66.7%, 전맹 27.05%, 청각장애 4.03%, 지체장애 2.16%
장애 환경 체험 Flow 설명:
저시력시각장애, 전맹 시각장애, 손 운동장애, 중증 운동장에 체험 순서
3. 웹 접근성 체험관 (불가능이 아닌 가능을 이야기하는 공간)
2013.11 / 오프라인 웹 접근성 체험 부스 오픈(네이버 그린팩토리 라이브러리 2F)
- 체험부스 내,외부가 촬영 된 홍보 영상
2014.08 / 온라인 체험관 오픈(널리 사이트 > 체험 > 온라인 장애 체험)
- 화면 확대/반전 소프트웨어(줌 텍스트)이미지 & 체험관에 적용한 툴 이미지
- 스크린리더, 점자정보단말기 이미지 & 체험관에 적용한 툴 이미지
- 한 손 키보드, 트랙볼 마우스 이미지 & 체험관에 적용한 가상 디바이스 이미지
- 빅 키키보드, 키가드, 헤드포인터 이미지 & 체험관에 적용한 가상 키보드 및 펜 모양의 마우스 포인터 이미지
2016.01 / 전체 개편 및 다양한 디바이스 체험 추가(오프라인 & 온라인)
오프라인: 오프라인 체험관에 비치된 아이패드 및 모바일 이미지
- 저시력 체험: 지도 이미지 위에 확대/축소 가능이 설정된 이미지
- 전맹 체험: 화면 암전 상태에서 터치를 이용하여 모바일을 사용하는 이미지
- 손 운동 체험: 그림사전에서 그림의 버튼이 흔들리는 이미지
- 중증 운동 체험: 메일보내기 화면에서 마이크 버튼을 활용하여 타이핑을 하는 이미지
온라인 체험관: 위치는 널리 사이트내의 체험 콘텐츠 내 온라인 장애 체험 클릭
온라인 장애 체험 시연
4. 체험 후기(장애를 바라보는 관점을 바꾸다)
<오프라인>
- 머릿속에서만 상상하던 장면을 직접보니 상대방의 입장을 생각하게 되는 소중한 시간이었어요
- 이 체험을 하고 나서 장애인의 기분을 알게 되어서 앞으로 장애인을 보면 도와주겠습니다.
- 비록 많이 힘들었지만 중중 운동장애인들도 무슨일도 할 수 있다는걸 알았다. 접근성이란 단어를 몸으로 느낀 체험이었습니다.
- 특수교육학을 배우는 학생입니다 체험해보니 막연히 생각했던 것 이상으로 사용이 어렵네요
- 저는 적색,녹색 색약을 가진 아이입니다. 경험해보니 이런것도 있나 싶네요 네이버짱
- 이 키보드가 일반화가 되어야 장애인들이 이러한 서비스를 누릴수 있다고 생각합니다. 응원할게요!
- 시력이 매우 안 좋은데 다양한 효과로 웹 환경을 좀 더 잘 이용할수 있다는게 놀랍습니다. 사회적약자를 생각하는 기업 네이버 화이팅입니다!!
<온라인>
- 비장애인인 저와 다른 신체를 가진 분들의 생활의 일부를 체험해보고 그분들의 번거로움을 느껴보는 뜻 깊은 기회였어요
- 온라인 체험관이라 정말 상상도 못했던 기발한 서비스네요 앞으로 적극 홍보하고 싶네요. 좋은 서비스 감사합니다.
- 장애우분들은 어떻게 웹을 사용할까 궁금했는데 이분들의 입장에서 생각을 해보는 계기를 갖게 되었습니다.
<마무리>
대다수가 어려움을 느끼지 웹에도 노인이나 장애인에게는 힘겹게 느껴지는 문턱이 있습니다.모두가 편하게 이용할 수 있도록 웹의 문턱을 낮추는 노력은
다양한 환경을 이해하고 공감하는 여러분들의 배려에서부터 시작됩니다.
제목 : 모바일애플리케이션 접근성 #이것만 알아두자.
발표자 : 네이버 접근성팀 서미연
1. 모바일 애플리케이션 접근성 이것만 알아두자
2. 지금은 스마트폰 시대. 스마트폰 많이 사용하시죠?
3. 스마트폰 보유율 추이. 스마트폰 보율을 추이만 봐도 2010년 부터 계속 증가하고 있습니다.
4. 모바일 사용하실 때 가장 기본적으로 많이 사용하는 신체기관
5. 눈과 관련 있는 지침. 명도대비를 4.5:1 이상으로 적용하면 저시력, 약시 사용자가 잘 사용할 수 있게 됩니다.
6. 저시력 사용자의 스마트폰 사용 자세. 스마트폰을 눈에 아주 가까이 대고 콘텐츠를 파악합니다.
7. 잘못된 사례. 입력전 입력을 유도하는 텍스트의 명도대비가 너무 낮아.
11. 좋은 사례. 입력전 입력을 유도하는 텍스트 명도대비 5.7:1
13. 명도대비. 텍스트 명도대비는 글자와 배경 간의 명도대비를 측정합니다.
17. 명도대비 #텍스트에 윤곽선이 있을 경우. 텍스트&배경 , 텍스트&윤곽선 중 명도대비가 큰 값으로 결정
19. 명도대비 #텍스트에 후광이 있을 경우. 텍스트&배경 , 텍스트&후광 중 명도대비가 큰 값으로 결정
21. 명도대비 #텍스트 또는 배경에 그러데이션이 적용된 경우. 시작점 명도 + 끝점 명도 / 2 = 평균명도
22. 귀와 관련 있는 지침. 음성으로 들을 수 있도록 대체 텍스트를 넣어주면 전맹 사용자가 사용할 수 있어요.
23. 전맹 사용자의 스마트폰 사용 자세
24. 모바일 스크린리더. iOS의 VoiceOver와 안드로이드의 TalkBack 또는 Voice Assistant.
26. 스크린리더 사용 동영상 #아이폰 보이스오버
30. 주로 대체텍스트가 많이 누락되는 부분은 이렇게 이미지 또는 아이콘형태로 제공되는 버튼들에서 볼 수 있습니다.
31. 대체텍스트 넣기 #iOS. 엑스코드 인터페이스 빌더에서 접근성을 설정할수 있는데요.
33. 대체텍스트 넣기 #Android. xml코드 android:contentDescription = "text" / JAVA 코드 void setContentDescription("text")
34. 대체텍스트 넣기 #팝업, 알림 #iOS. UIAccessibilityPostNotification(UIAccessibilityNotification, UIObject);
35. 대체텍스트 넣기 #팝업, 알림 #Android. View.announceForAccessibility("text")
36. 개선 사례. 네이버 뮤직 iOS 앱이 최근 대체텍스트를 대거 추가하였는데요.
40. 뮤직앱 스크린리더 사용 동영상 #아이폰 보이스오버
41. 손과 관련된 지침. 복잡한 누르기 동작을 대체할 대체 수단을 제공해주면 누르기 동작만으로도 접근할수 있어요.
42. 제스처에는 다양한 종류들이 있는데요. 모든사용자가 사용할수 있을까요?
43. Carousel UI 모바일 스크린리더를 만난다면 어떻게 될까요.
44. 모바일 스크린리더 기본동작
45. Carousel UI 모바일 스크린리더를 만난다면 기존 제스처는사용할수 없기때문에 좌우 페이지 이동이 어렵습니다.
46. 개선. 어떻게 개선해야 할까요?
48. 좋은 사례 동영상
49. 좋은 사례 2. 미리 이 페이지가 좌우 이동하는 콘테츠임을 알림.
50. 모바일 스위치 접근성
51. 스위치란 보조기기는 일반적으로 누를수 있는 버튼 하나로 구성되어 있는데요. 미세한 손가락 움직임이 힘든 사용자이니 현란한 제스처를 사용하는 것은 불가능이겠죠.
52. 스위치 제어 사용 동영상 #아이폰
53. 잘못된 사례. 볼륨컨트롤러 애플리케이션 볼륨조절을 드래그 또는 좌우 스와이프제스춰로만 조절가능하도록 설계되어 있어.
54. 잘못된 사례. 개선. 음량 조절이 가능한 버튼을 플러스, 마이너스로 추가했는데요. 이렇게 단순히 누르기 또는 탭을 통해 기능을 대체해서 수행할수 있도록 해주는것이 좋겠지요.
55. 좋은 사례. 지도 애플리케이션 확대 축소 버튼을 통해 사용할 수 있도록 되어 있습니다.
이렇게 멀티드래그랄지 스와이프랄지 복잡한 제스춰를 통해 동작하는 UI에는 그 기능을 단순하게 누르기 또는 탭을 통해 수행할수 있도록 해주어야 합니다.
56. 마치며..
7. 표현을 기준으로 이름 지어진 태그들은 더 이상 사용하지 않습니다
<b> 굵은 글씨
<i> 이탤릭체
<big> 큰 글씨
<small> 작은 글씨
<blink> 깜빡임
<s> 가로줄
<tt> 타이프체
<u> 밑줄
<center> 중앙 정렬
<nobr> 줄바꿈 안함
<font> 글씨 모양
<marquee> 흐르는 글씨
8. 컨텐츠가 가진 의미를 나타내는 태그들을 가능한 지켜 사용합니다
<strong> 강한 강조
<em> 강조
<p> 문단
<q> 짧은 인용
<cite> 작품 제목
<del> 삭제된 내용
<samp> 시스템 출력
<code> 개발 코드
<ins> 추가된 내용
<address> 주소
<blockquote> 인용문
<abbr> 약자표기
10. 책의 목차는 책의 ‘정보구조’를 담고 있습니다
목차를 보면, 전체 내용이 어떻게 구성 되어있는지를 한 눈에 알 수 있습니다
11. 웹 페이지에서는 헤딩이 목차와 같은 역할을 합니다.
헤딩들을 모아보면 웹 페이지의 내용이 어떤 흐름을 가지고 있는지 한 눈에
알 수 있습니다.
<h1>네이버</h1>
<h2>뉴스스탠드</h2>
<h3>구독목록</h3>
<h3>전체언론사</h3>
<h2>로그인</h2>
<h2>타임스퀘어</h2>
<h2>주제형캐스트</h2>
<h2>홈 유형 선택</h2>
<h2>네이버 설정</h2>
<h2>패밀리 사이트</h2>
12. 헤딩이 잘못 제공되면
사용자에게 잘못된 정보구조를
전달하게 됩니다.
그렇기 때문에, 헤딩은 정보구조를 반영하여 올바른 순서로 작성되어야 합니다.
<h1>네이버</h1>
<h4>로그인</h4>
<h2>안내 팝업</h2>
<h4>확인</h4>
<h3>네이버 설정</h3>
<h2>패밀리 사이트</h2>
<h3>다음 페이지</h3>
…
만약 헤딩이 잘못 되었다면?
29. HTML4 웹 페이지에서는 헤딩이 목차와 같은 역할을 합니다.
하지만, HTML5에서는
섹션이 만드는 구역과 헤딩이 조합하여 아웃라인을 만들고,
이 아웃라인이 목차의 역할을 합니다.
<h1>네이버</h1>
<h2>뉴스스탠드</h2>
<h3>구독목록</h3>
<h3>전체언론사</h3>
<h2>로그인</h2>
<h2>타임스퀘어</h2>
<h2>주제형캐스트</h2>
<h2>홈 유형 선택</h2>
<h2>네이버 설정</h2>
<h2>패밀리 사이트</h2>
41. <h1>예제</h1>
<section>
<h2>멋진 섹션</h2>
</section>
<article>
<h2>아주 좋은 글</h2>
</article>
<section>
여긴 헤딩이 없어요
</section>
HTML 마크업
문서의 아웃라인
1. 예제 1. 멋진 섹션 2. 아주 좋은 글
3. Untitled Section
각 섹션요소는 헤딩에 의해 이름이 지어집니다.
이름이 없을 경우 Untitled Section(무제) 섹션이 됩니다.
43. <h1>책 팝니다</h1>
<section>
<h1>중고 책</h1>
<h2>HTML 공부하기</h2>
<h2>CSS 공부하기</h2>
<h2>연애, 할 수 있다!</h2>
</section>
HTML 마크업
문서의 아웃라인
1. 책 팝니다 1. 중고 책 1. HTML 공부하기
2. CSS 공부하기
3. 연애, 할 수 있다!
한 섹션 안에 헤딩이 여러 개일 때는, 헤딩이 섹션을 만듭니다.
첫번째 헤딩은 섹션의 헤딩이 되고…
나머지는 섹션을 만들어요.
44. <h1>책 팝니다</h1>
<section>
<h1>중고 책</h1>
<h2>HTML 공부하기</h2>
<h2>CSS 공부하기</h2>
<h2>연애, 할 수 있다!</h2>
</section>
HTML 마크업
문서의 아웃라인
1. 책 팝니다 1. 중고 책 1. HTML 공부하기
2. CSS 공부하기
3. 연애, 할 수 있다!
HTML5 문서에서는 새로운 섹션에서 h1 부터 다시 카운팅을 시작해도 됩니다
46. HTML 마크업
문서의 아웃라인
<section>
<h1>중고 책</h1>
<h2>HTML 공부하기</h2>
<h2>CSS 공부하기</h2>
<h2>연애, 할 수 있다!</h2>
</section>
47. <!-- <h1>헤딩이 없네?</h1> -->
<section>
<h1>중고 책</h1>
<h2>HTML 공부하기</h2>
<h2>CSS 공부하기</h2>
<h2>연애, 할 수 있다!</h2>
</section>
HTML 마크업
문서의 아웃라인
1. Untitled Section 1. 중고 책 1. HTML 공부하기
2. CSS 공부하기
3. 연애, 할 수 있다!
body는 섹셔닝 루츠이기 때문에 헤딩이 없으면 문서의 제목이 없는 무제 문서가 됩니다.
49. <h1>물건 팝니다</h1>
<h2>쓰던 물건</h2>
<article>
<h3>볼 펜</h3>
<p>아주 잘 나와요</p>
</article>
<article>
<h3>지갑</h3>
<p>중후한 멋이 있어요</p>
</article>
<article>
<h3>신발</h3>
<p>냄새 안나고 깨끗합니다</p>
</article>
HTML 마크업
문서의 아웃라인
50. <h1>물건 팝니다</h1>
<h2>쓰던 물건</h2>
<article>
<h3>볼 펜</h3>
<p>아주 잘 나와요</p>
</article>
<article>
<h3>지갑</h3>
<p>중후한 멋이 있어요</p>
</article>
<article>
<h3>신발</h3>
<p>냄새 안나고 깨끗합니다</p>
</article>
HTML 마크업
문서의 아웃라인
1. 물건 팝니다 1. 쓰던 물건 1. 볼 펜
2. 지갑
3. 신발
이런 아웃라인이 만들어 질까요?
51. <h1>물건 팝니다</h1>
<h2>쓰던 물건</h2>
<article>
<h3>볼 펜</h3>
<p>아주 잘 나와요</p>
</article>
<article>
<h3>지갑</h3>
<p>중후한 멋이 있어요</p>
</article>
<article>
<h3>신발</h3>
<p>냄새 안나고 깨끗합니다</p>
</article>
HTML 마크업
문서의 아웃라인
1. 물건 팝니다 1. 쓰던 물건 2. 볼 펜
3. 지갑
4. 신발
h2와 article이 형제가 되면서 같은 단계에 위치하는 아웃라인이 만들어집니다
h1은 body 섹션의 첫번째 헤딩이라서…
53. <h1>책 팝니다</h1>
<blockquote>
<h1>중고 책</h1>
<h2>HTML 공부하기</h2>
<h2>CSS 공부하기</h2>
<h2>연애, 할 수 있다!</h2>
</blockquote>
HTML 마크업
문서의 아웃라인
body, blockquote
details, fieldset, figure, td
섹셔닝 루츠
54. <h1>책 팝니다</h1>
<blockquote>
<h1>중고 책</h1>
<h2>HTML 공부하기</h2>
<h2>CSS 공부하기</h2>
<h2>연애, 할 수 있다!</h2>
</blockquote>
HTML 마크업
문서의 아웃라인
1. 책 팝니다
섹셔닝 루츠(body)안에 또 다른 섹셔닝 루츠가 있으면 그 안의 내용은 아웃라인에 포함시키지 않습니다.
없는셈 치자구요…
안녕하세요. ‘시맨틱한 HTML5 마크업 구조 설계, 어떻게 할까?’ 라는 주제로 발표를 맡게된 윤원진입니다.
발표를 시작하기 전에 먼저 살짝 말씀드리면,
이 발표는 HTML5 Outline을 설명하는 발표입니다.
아마 이렇게만 말씀드리면 이제 제가 설명할 내용이 뭔지 다 아시는 분들도 계실겁니다.
발표 제목은 여러분의 흥미를 끌기 위해 뭔가 있어보이는 말로 지었지만,
사실 ‘HTML5 Outline’이라고 제목을 붙였으면 딱 적당했을거에요.
하지만 제가 거짓말을 한건 아닙니다.
HTML5 Outline은 시맨틱, 마크업 구조설계와 관계가 있으니까요.
그리고 제가 발표중에 태그, 요소, 엘리먼트라는 말을 자주 쓸건데요.
다 같은 뜻이라고 생각하시면 됩니다.
엄밀히 따지면 뜻이 다를 수도 있는데, 저는 뭐가 다른지 모르겠어요.
그래도 맥락에 따라서 태그라고 하면 이해가 더 잘 될 때가 있고,
어떤 때는 요소라고 하는게 자연스러울 때도 있어서 막 섞어서 씁니다.
제가 이런 단어를 쓰면, 아 html 태그 말하는거구나 라고 생각하시면 되겠습니다.
그럼 발표를 시작하도록 하겠습니다.
먼저 시맨틱이 뭔지 살짝 짚고 넘어가보도록 할께요.
영어단어니까. 사전을 찾아보죠.
저는 영어를 잘 못해서 영어사전 서비스를 자주 이용하는데요.
시맨틱을 검색하면 화면처럼 ‘의미론적인’ 이라는 결과가 나옵니다.
사실 시맨틱은… 웹표준이에요.
의미에 맞는 태그를 사용하자. 이게 웹표준 아닌가요?
웹접근성, SEO도 마찬가지지요.
의미에 맞게 마크업하면 접근성이 향상되고, 검색결과 최적화가 자연스럽게 되니까요.
예를 들면, 이전에 많이 사용했던 b 태그 같은 경우를 들 수 있겠지요.
b는 bold라는 의미를 담고 있지만, 웹표준이 강조되면서 이제는 strong 태그로 바꿔서 사용합니다.
표현보다는 의미에 집중한 마크업을 하는 것이지요.
이러한 표현과 의미의 분리가 웹표준의 핵심입니다.
그래서 화면에 보이는 것 처럼…
굵은 글씨를 위해 쓰는 b 태그, 이탤릭체를 쓰는 i 태그,
큰 글씨를 쓰는 big 태그,
작은 글씨를 쓰는 small 태그,
중앙 정렬을 하는 center 태그…
이런 태그들은 사용하지 않습니다.
이 태그들은 의미가 아닌 표현에 집중해서 만들어진 태그들이니까요.
대신 이런 태그들을 더 사용하지요.
b 태그 대신 strong 태그,
i 태그 대신 em 태그,
예전엔 s, strike 태그를 사용해서 가로줄을 쳤지만,대신 삭제되었다는 의미를 담은 del 태그를 쓰고…
그리고 주소를 쓸 때는 이게 주소다. 라는 의미를 담은 address 태그…
이렇게 마크업에 의미를 담아가면서 더 시맨틱하게 만들려는 노력들이 있었기 때문에,시각장애인들이 테이블로 얽힌 웹에서 벗어나서 스크린리더로 웹을 사용할 수 있는 세상이 오게 되었습니다.
웹표준이 지금까지도 정착되지 못했다면 스크린리더를 사용할 때 스크린리더가 계속 테이블만 읽어주겠지요?
여러분이 웹을 시맨틱하게 만들기 위해 노력하는 것은 확실히 그럴만한 가치가 있는 일입니다.
자, 다음으로 넘어가보겠습니다.
어떤 책이든 첫 장을 넘기면, 다음에 이러한 목차가 나옵니다.
책의 목차는, 책의 전체 내용이 어떻게 구성 되어있는지를 한 눈에 알 수 있게 해줍니다.
다시 말하면, 책의 목차는 책에 대한 ‘정보구조’를 담고 있다고 할 수 있습니다.
웹 페이지에도 이런 정보구조를 담고 있는 요소가 있습니다.
바로 헤딩인데요. 여러분이 헤딩을 잘 지켜서 사용하면, 웹 페이지도 잘 정리된 정보구조를 갖게 됩니다.
웹 페이지에서는 헤딩이 목차와 같은 역할을 합니다.
어떤 웹페이지를 보고 목차를 작성하려면, 헤딩을 보면 되겠지요.
헤딩들을 보면 내용과 구조를 알 수 있으니까요.
그런데 헤딩이 잘못되었다면 어떨까요?
그러면 결국 사용자에게 잘못된 정보구조를 전달하는 셈이 됩니다.
그렇기 때문에, 헤딩은 정보구조를 반영하여 올바른 순서로 작성되어야 합니다.
그런데 안타깝게도 웹표준이 정착된 지금까지도 이렇게 헤딩을 잘 지켜서 사용한 사이트를 찾기가 쉽지 않습니다.
많은 사이트가 헤딩이 엉망이에요.
헤딩이 정보구조를 담고 있다면, 잘못된 헤딩을 사용하는 웹 페이지는 잘못된 정보구조를 전달하는 것이지요.
여러분이 시맨틱을 생각 할 때 가장 주의하셔야 할 것이 이 부분입니다.
정확한 의미를 전달하기 위해 시맨틱 마크업을 하는 것인데, 의미를 잘못 전달하면 전달하지 않느니만 못하게 되기 때문입니다.
제가 화면에 호랑이 이미지를 띄워놓았는데요.
만약에 이 이미지에 대체텍스트를 ‘코끼리’라고 붙이면 어떻게 될까요?
여러분은 호랑이를 보겠지만, 시각장애인분들은 스크린리더가 ‘코끼리’라고 읽어주겠지요.
많은 의미를 담는 것도 중요하지만, 그 보다 더 중요한 것은 정확한 의미를 담는 것입니다.
자, 지금까지 제가 얘기한 내용들은 HTML4까지의 내용입니다.
HTML4에서는 헤딩이 목차의 역할을 합니다.
하지만 HTML5에서는 바뀌었어요.
뭐가 바뀌었는지 같이 살펴보도록 하겠습니다.
HTML5가 나오면서 새로운 의미를 담은 시맨틱 태그들이 많이 추가가 되었습니다.
새로 추가된 header, footer, section, article, aside... 여러분들은 이런 태그들 잘 사용하고 계신가요?
HTML5의 시맨틱 태그들은 각각 다른 의미와 다른 용도를 가지고 있기 때문에, 잘 따져 가면서 사용을 해야 합니다.
근데 새로 써보는 것이다 보니 내가 맞게 사용하는 것인지 많이 어려워들 하세요.
제가 화면에 띄워놓은건 HTML5 Doctor 라는 사이트에서 배포한 HTML5 마크업 플로우차트인데요.
국내에선 윤석찬님께서 번역을 해주셔서 한글판으로 볼 수 있습니다.
이 플로우차트를 따라서 마크업을 한다면요.
내가 지금 마크업하려는 내용이 메뉴영역인가? 그렇다면 nav를 쓰고,
아니면 플로우 차트를 따라 다음으로 넘어갑니다.
독립적인 콘텐츠인가? 그러면 article을 쓰고,
아니면 또 넘어갑니다.
주요 컨텐츠가 아니고 부수적인 건가? 그렇다면 aside를 쓰고,
아니면 또 넘어가고… 이렇게 반복하는거지요.
그래서 작업을 제대로 하고 싶어하시는 분들은 이런 도움말 플로우차트 를 펴놓고, ‘이 가이드를 잘 따라서 했으니 잘 맞게 했을거야’라고 생각을 하십니다.
그러면 다 된걸까요? 충분할까요?
굉장히 안타깝지만… 아니요. 이걸로는 충분하지 않아요.
여전히 여러분은 잘못된 HTML5 마크업을 만들고 있을 수 있습니다. 그럼, 뭐가 문제일까요?
네. HTML5를 사용하려면 새로 바뀐 내용들을 잘 알고 있어야 합니다.
HTML5 명세에서는 섹셔닝 엘리먼트가 Outline을 만든다고 적혀있습니다.
영어로 되어있으니까 당황스럽죠? 괜찮습니다. 저도 볼 때 마다 당황스러워요.
근데. 이걸 얘기하려면 먼저 섹셔닝 요소가 뭔지부터 알아야 할 것 같아요.
그래서 섹셔닝 요소란게 무슨 말인지 설명을 하고 넘어가도록 하겠습니다.
이걸 알려면 HTML5 컨텐츠 모델이라는 개념을 이해해야하는데요.
HTML5에는 4에 없던 컨텐츠 모델이란 개념이 생겼습니다.
상식을 넓힌다 생각하고 알아두시면 좋을 것 같습니다.
여러가지 HTML 요소들(태그들)을 각각 성격에 따라 카테고리 분류를 만든거에요.
Metadata, Flow, Sectioning, Heading, Phrasing, Embedded, Interactive로 나누어 구분합니다.
하나씩 자세히 살펴보면요.
메타데이터는 문서에 대한 다양한 정보들을 설정하는 요소들입니다.
base, link, meta, noscript, script, style, title 같은 태그들이 이에 해당하구요.
플로우는 body 내에 있는 대부분의 요소를 통칭해서 flow라고 합니다.
메타 데이터 일부를 제외하고 거의 대부분의 요소가 flow에 포함됩니다.
헤딩은 각 섹션의 제목을 정의합니다.
H1~H6 태그가 이에 해당하구요.
hgroup은 최근에 명세에서 빠졌습니다.
섹션 요소 안에 헤딩이 여러 개인 경우 Heading이 섹션을 만든다. 이 부분은 뒤에 또 설명을 하겠습니다.
섹셔닝은 문서의 내용을 분류하는 구역을 생성하는 태그들입니다.
우리가 알아보려고 했던 ‘섹셔닝 요소’라는게 바로 요놈들입니다.
Article, aside, nav, section 딱 이렇게 4개 태그만 해당이 됩니다.
프레이징은 문단을 구성하는 요소들을 모아놓은 거구요.
임베디드는 문서에 그래픽이나 영상, 음성 등 다른 요소들을 삽입할 때 사용하는 요소들을 말합니다.
인터랙티브는 사용자와 웹사이트가 상호작용을 할 수 있게 만들어주는 a나 button, select 같은 태그들을 말합니다.
그럼 다시 돌아와서…
명세에 나와있는 것처럼 섹셔닝 요소는 Outline을 만듭니다.
이 Outline이 무슨 뜻인가 하고 살펴보면, 간단히 말해서 문서의 목차와 같은 겁니다.
HTML5에서는 4와 달라진 목차를 만드는 기준을 명세에 명확하게 정해놓았습니다.
HTML4에서는 헤딩이 목차의 역할을 하지만,HTML5에서는 아웃라인이 목차의 역할을 하는거죠.
HTML5 아웃라인은 명세에 나온대로 섹션과 헤딩의 영향을 받아 만들어집니다.
좀 더 명확히 이야기 하면 아웃라인을 만드는 요소는 3가지로 나눌 수 있습니다.
첫번째, 섹션,
두번째, 헤딩,
세번째, 섹셔닝 루츠입니다.
여러분 이거 잘 모르셨죠? 괜찮습니다. 지금부터라도 알고 제대로 하면 되니까요.
그럼 Outline이 어떻게 만들어지는지 설명을 해볼께요.
아까 봤던 섹셔닝 요소들입니다.
여기에 header, footer는 포함이 안되니 잘 기억을 해두세요.
웹사이트가 이런 구조를 가지고 있다고 해봅시다.
상하단에 헤더,푸터가 있고.
중앙에 nav, section, aside가 있네요.
Section 안에는 header, article, footer가 들어있구요.
섹션은 구역을 만든다고 했으니까. 섹션 요소들만 따로 표시를 하면 이렇게 윤곽선을 그릴 수 있습니다.
근데 아까 설명 안하고 넘어갔던 3번째 요소.
섹셔닝 루츠라는 놈들이 있지요.
이 태그들이 섹셔닝 루츠입니다.
body, blockquote, details, fieldset, figure, td
섹셔닝 루츠는 별개의 새로운 문서로 취급하기 때문에 그 하위에 있는 내용은 아웃라인에 포함시키지 않습니다
이 목록에 보면 제일 처음에 body가 있지요.
그래서 기본적으로 모든 웹페이지는 body라는 섹셔닝루츠를 가지고 시작합니다.
그래서 body에도 윤곽선을 그려주면 이렇게 되겠네요.
여러분이 보시기 편하게 가장 상위의 body 윤곽선에는 노란색,
그 안에 들어있는 섹션들에는 파란색,
또 그 안에 들어있는 요소에는 빨간색으로 표시를 해서 깊이를 색깔로 표시를 했습니다.
자 이 화면이 가지는 HTML5 아웃라인은 이렇습니다.
1번 섹션 안에, 섹션이 있고.
또 그 안에 섹션이 세개 있고, 2번 섹션안에 섹션이 있네요.
HTML5 에서는 이렇게 구조를 가지는 것만으로도 목차가 만들어집니다.
근데 섹션들이 이름이 없네요. 그죠?
그래서 각 섹션에 헤딩으로 이름을 붙여줍니다.
body 안에 우리집이라는 헤딩을 넣고,
각 섹션안에 안방,거실,창고라는 헤딩을 넣고,
거실 섹션안에 들어잇는 아티클 섹션에는 주방이라는 헤딩을 넣어주었습니다.
이렇게 헤딩 태그를 넣어놓으면 그게 섹션의 이름이 되는거지요.
이제 본격적으로 코드를 살펴보도록 하겠습니다.
제가 화면에 HTML 코드를 보여드리는데요.
예제 라는 h1 헤딩이 있고,
그 안에 섹션이 3개 있습니다.
첫번째 섹션은 멋진 섹션이라는 헤딩이 있고,
두번째 섹션은 아주 좋은 글이라는 헤딩이 있어요.
세번째 섹션은 헤딩이 없습니다.
이렇게 이름이 없는 Section 요소들은 무제(Untitled) 섹션이 됩니다.
그래서 Section요소를 사용했을 때는 반드시 그 안에 헤딩요소를 넣어주어야 합니다.
화면의 코드에,
책 팝니다 라는 h1 헤딩이 있고,
그 안에 섹션이 하나 있습니다.
섹션 안에 h1 헤딩이 하나 있고, h2 헤딩이 연달아서 3개가 나오네요.
이렇게 한 섹션 안에 헤딩이 여러 개일 때는, 헤딩이 섹션을 만듭니다.
그래서 결과적으로 이 섹션은 3개의 하위섹션을 포함한 섹션이 되었습니다.
그리고 보시면 문서상에 h1이 두개 있는걸 볼 수 있는데요.
HTML5 문서에서는 섹션 요소 안에서는 새롭게 h1 부터 헤딩을 시작 할 수 있습니다.
이건 아마 많이 들으셔서 대부분 알고 계실거에요.
화면의 코드에,
섹션이 하나있고,
그 섹션 안에는 h1 헤딩 하나와 연달아서 h2 헤딩이 3개 있습니다.
이 코드는 어떤 아웃라인을 갖게 될까요?
body는 섹셔닝 루츠이기 때문에 그 자체로 하나의 섹션이 됩니다.
그래서 body 안에 Section이 아닌 단독 헤딩이 존재하지 않으면, 문서가 제목이 없는 무제 문서가 됩니다.
근데 이 문서는 섹션 시작전에 헤딩이 없지요?
그래서 아웃라인이 Untitled Section으로 시작하는 제목이 없는 문서가 되었습니다.
이 역시 HTML5 문서를 만들 때 많은 분들이 자주 실수하는 부분 중 하나입니다.
이 예제는 어떨까요?
H1, h2가 있고, article이 3개 있습니다.
각각의 Article마다 헤딩이 있구요.
섹션요소마다 헤딩을 꼼꼼히 잘 달아놨으니 문제 없이 잘 정리된 아웃라인이 만들어 질 것 같네요.
그러면 이런 아웃라인이 만들어 질까요?
아니요. 실제로 만들어지는 아웃라인은 이렇습니다.
H2 다음에 섹션요소인 article이 이어져 나오기 때문에, article 안에 있는 헤딩이 h1 이든, h2 든, h3 이든지 관계없이 헤딩과 아티클이 같은 깊이를 가집니다.
자식으로 내려가지 않고, 형제가 되어버리는 거죠.
첫번째 헤딩인 h1은 섹션 내의 첫번째 헤딩이기 때문에 섹션의 제목이 되지만,
두번째 헤딩은 ‘하나의 섹션안에 헤딩이 여러 개 있을 경우, 헤딩이 섹션을 생성한다’라는 규칙 때문에 자신이 하나의 섹션이 되는겁니다.
이런 함정이 있을 수 있기 때문에, html5를 작업 할 때는 항상 아웃라인을 확인하고 주의해서 작업하셔야 합니다.
자, 이제 마지막 예제를 보겠습니다.
또 다른 섹셔닝 루츠인 blockquote 인데요.
인용이라는 의미를 담고 있어서, 인용문에 사용하는 태그죠.
아까 말씀드렸듯이 body, blockquote, details, fieldset, figure, td 이 태그들은 섹셔닝 루츠입니다.
그럼 blockquote를 사용해서 이렇게 헤딩들을 묶으면 어떻게 될까요?
섹셔닝 루츠(body)안에 또 다른 섹셔닝 루츠가 있으면 그 안의 내용은 아웃라인에 포함시키지 않습니다.
이 예제에서는 h1 책팝니다에 이어서 바로 다음에 나온
blockquote안에 헤딩이 여러 개 들어있지만
Blockquote는 섹셔닝 루츠이기 때문에 그 안의 내용은 이 문서의 아웃라인에선 빠지는거지요.
Body외의 섹셔닝 루츠 안에 섹션이나 헤딩이 들어가는 경우가 많이 생기지는 않지만,
이런 부분도 있다는걸 알아두셔야 outline을 완벽히 이해하셨다고 할 수 있을 것 같습니다.
지금까지 살펴보셨듯이 HTML5 아웃라인 개념이 생각보다 그렇게 쉽진 않습니다.
실수하기도 쉽구요.
하지만 다행스럽게도, 여러분들이 이 공식을 다 완전히 암기하실 필요는 없어요.
왜냐면 도와주는 도구들이 있거든요.
그래서 여러분들은 어떤 기준으로 아웃라인이 만들어지는지만 이해하신뒤에,
그 다음부터는 도구로 아웃라인을 확인하시면 작업을 하시면 됩니다.
HTML5 Outliner라는 툴이 있는데요.
검색해보시면 이런 화면의 사이트를 쉽게 찾으 실 수 있을겁니다.
디자인은 투박하지만 굉장히 유용한 사이트입니다.
HTML Validator로 검사할 때 처럼, 주소를 넣거나 소스를 붙여넣기 해서 검사를 할 수 있습니다.
이 검사 도구를 사용해서 검사를 하면 이런 화면을 볼 수 있습니다.
왼쪽은 서울시 웹사이트를 검사한 결과인데요.
국내 사이트들을 검사하면 대개 검사 결과가 엉망인데, 깔끔하게 정리가 잘 된 사례입니다.
오른쪽은 국내의 한 쇼핑몰 사이트인데요.
검사 결과가 굉장히 처참한 상태임을 볼 수 있습니다. 이런 결과가 나오지 않도록 여러분들은 신경을 잘 써주시면 좋겠네요.
크롬 웹스토어에도 HTML5 Outliner 라는 이름의 확장 프로그램이 등록되어 있는데요.
이 확장 프로그램을 설치하시면 아웃라인을 굉장히 쉽게 확인 하실 수 있습니다.
설치를 하시면 우측 상단에 아웃라인 체크 버튼이 생기는데요.
버튼을 클릭하면 아웃라인 구조를 바로 확인이 가능합니다.
작업하실 때 설치해두시고 수시로 확인하면서 작업하시면 Outline 만드실 때 실수를 하시는 일은 없으실 것 같습니다.
그럼 왜 아웃라인을 신경써야 할까요?
예전에 학창시절에 교과서에서 봤던 이야기 중에, 자기를 버리러 산을 타는 아들을 위해서 나뭇잎을 뿌린 어머니 이야기가 있었어요.
집에 돌아갈 때 길 잃어버리지 말라고 미리 뿌려놓은거지요.
미래에 사용될 가능성을 위해 작업하자라는 말씀을 드리려고 준비한 얘긴데.. 이게 적당한 예시가 될지는 모르겠습니다만. ^^
지금 당장은 HTML5 아웃라인을 잘 지켜서 만들어도 실질적으로 사용자가 이득을 보는 부분은 없을 수 있습니다.
하지만 웹 표준이 정착되어서 시각장애인들이 스크린리더를 사용하게 될 수 있게 된 것처럼,
여러분들이 아웃라인이 잘 정리된 문서를 만들어서 그것이 웹의 문화로 정착된다면,
브라우저 개발사들이나 보조기기 개발사들이, 이 아웃라인을 활용해서 다양한 기능들을 개발 할 수 있게 됩니다.
스킵네비게이션을 일일이 만들어 줄 필요도 없어요.
아웃라인 보고 따라가면 되니까요.
시맨틱을 위한 작업은 그렇게 앞으로의 가능성을 보고 하는 작업이기 때문에,
지금은 당장 소득이 없어도 내가 마크업개발자니까.
이 세상에 도움이 되기 위해서 소명의식을 가지고 하는 작업이라고 생각합니다.
발표 마치겠습니다. 감사합니다.