사람들의 인터넷 의존도와 이용 시간이 지속적으로 늘어나고 있다. 즉, 인터넷 이용을 가능하게 해주는 "웹 브라우저"가 중요한 도구가 되었다는 것이며 "웹 브라우저"를 효율적으로 사용하고 관리하는 능력은 디지털 시대를 살아가는 우리에게 하나의 핵심 역량이 되었다는 것을 의미한다. 인터넷(웹 브라우저)을 효율적으로 사용하기 위해서 고려해야 될 요소들과 "크롬브라우저"를 통해 업무 시간을 단축할 방법들을 배워본다.
검색엔진 랭킹 상위 - scs(seo curation suite) 서비스 넥스트티eunpyo hong
검색 엔진 상위에 노출을 위한 가장 일반적인 방법은?
SEM, Power Blog(SNS) Marketing이지만 비용 대비 효과는 점점 낮아지고 있습니다.
SCS(SEO Curation Suite) 서비스는 시중 SEO 솔루션과 서비스와는 달리 SEO 컨설팅 영역 중 자동화 할 수 없었던 키워드 컨설팅 영역과 Off Page SEO의 검색엔진 역 로봇을 이용하여 사용자 행태를 적용하여 검색엔진 랭킹 상위로 진입 / 유지하는 마케팅 솔루션입니다.
커빙의 Django, Celery, Azure Cloud, SNS 연동, 컨텐츠 수집 기술을 한눈에 볼 수 있도록 소개한 자료 입니다.
커빙을 처음 개발하면서 많은 어려움이 있었고,
또 많은 분들의 도움으로 좋은 결과를 얻을 수 있었습니다.
조금 더 깊은 내용을 다뤘으면 하는 아쉬움이 있지만,
다른 분들에게 조금이나마 도움이 되었으면 좋겠네요!
사람들의 인터넷 의존도와 이용 시간이 지속적으로 늘어나고 있다. 즉, 인터넷 이용을 가능하게 해주는 "웹 브라우저"가 중요한 도구가 되었다는 것이며 "웹 브라우저"를 효율적으로 사용하고 관리하는 능력은 디지털 시대를 살아가는 우리에게 하나의 핵심 역량이 되었다는 것을 의미한다. 인터넷(웹 브라우저)을 효율적으로 사용하기 위해서 고려해야 될 요소들과 "크롬브라우저"를 통해 업무 시간을 단축할 방법들을 배워본다.
검색엔진 랭킹 상위 - scs(seo curation suite) 서비스 넥스트티eunpyo hong
검색 엔진 상위에 노출을 위한 가장 일반적인 방법은?
SEM, Power Blog(SNS) Marketing이지만 비용 대비 효과는 점점 낮아지고 있습니다.
SCS(SEO Curation Suite) 서비스는 시중 SEO 솔루션과 서비스와는 달리 SEO 컨설팅 영역 중 자동화 할 수 없었던 키워드 컨설팅 영역과 Off Page SEO의 검색엔진 역 로봇을 이용하여 사용자 행태를 적용하여 검색엔진 랭킹 상위로 진입 / 유지하는 마케팅 솔루션입니다.
커빙의 Django, Celery, Azure Cloud, SNS 연동, 컨텐츠 수집 기술을 한눈에 볼 수 있도록 소개한 자료 입니다.
커빙을 처음 개발하면서 많은 어려움이 있었고,
또 많은 분들의 도움으로 좋은 결과를 얻을 수 있었습니다.
조금 더 깊은 내용을 다뤘으면 하는 아쉬움이 있지만,
다른 분들에게 조금이나마 도움이 되었으면 좋겠네요!
This document discusses trends in digital advertising, public relations, and social media. It notes that authenticity, transparency, conversation, thought leadership, and sharing are important across these fields. Companies must engage in social media conversations to extend the power of word-of-mouth. Goals for social media include outreach, engagement, and promotion, and it should fit into a company's overall digital strategy. Metrics like followers, retweets, and mentions can measure social media effectiveness. The document provides best practices and resources for social media strategies.
Web Design Trends & Best Practices (by Blueliner Marketing CEO, Arman Rousta)Arman Rousta
This is a presentation that I have prepared for the DMA (Direct Marketing Association) twice. This updated version was presented as a webinar for Blueliner Marketing. I demonstrate best practices in web design by giving screencast tours of websites.
In this presentation, Perficient leverages its extensive SharePoint user experience design, customization, and implementation expertise to guide you in understanding the criticality of SharePoint user experience (UX) in driving user adoption, and to provide you with user experience best practices in the areas of information architecture and visual design, technical configuration and customization, and user experience server deployments.
The document summarizes the evolution of the POOQ platform from 2012 to present. It began as a joint venture between MBC and SBS in 2012 and initially hosted on a traditional IDC. As user numbers grew, performance issues emerged. This led to a redesign with scalable cloud infrastructure using services like MongoDB, Cassandra, and auto-scaling. The new design successfully supported over 280,000 concurrent users for a major sports event in 2015. Lessons were learned about cloud benefits but also limitations. Future work includes migration to AWS and use of services like Lambda and GPU instances for machine learning.
OWASP에 대응할 수 있는 애플리케이션/웹 보안 솔루션 앱스캔(AppScan)의 Standard Editin에 대한 자료입니다.
AppScan의 다른 에디션인 Source Edition 에 대한 설명은 이쪽으로!
☞https://www.slideshare.net/eunoakcho/ibm-app-scan-source-edition
고객 중심 서비스 출시를 위한 준비 “온오프라인 고객 데이터 통합” – 김준형 AWS 솔루션즈 아키텍트, 김수진 아모레퍼시픽:: AWS C...Amazon Web Services Korea
AWS의 빅데이터 서비스들이 데이터 파이프라인 상에서 어떻게 활용 되는지와 데이터 모델링과 플랫폼 구축을 100% 내재화 하여 AWS와 함께 고객기반 서비스의 경쟁력을 강화 해나가는 고객 사례를 전해 드립니다. 국내 뷰티산업을 리딩 하고 있는 아모레퍼시픽에서 온/오프라인 고객 정보를 AWS 기반의 Data Lake로 통합 하고 고객 관점의 데이터 서비스를 출시 하는데 속도를 높이고 있는 성공 스토리를 직접 전해 드립니다.
분석 워크로드 마이그레이션의 모든 것-김기영, AWS Analytics Specialist SA / 김성일, AWS Analytics Sp...Amazon Web Services Korea
분석 워크로드는 대량의 데이터를 다루는 크고 복잡한 분석 플랫폼 위에서 운영됩니다. 이런 다양하고 복잡한 분석 워크로드를 AWS로 안전하게 마이그레이션 하는 방법에 대해 Big data platform EMR, Data Warehouse Redshift, OpenSearch를 중심으로 살펴봅니다.
Amazon Kinesis Data Analytics는 실시간으로 스트리밍 데이터를 처리하고 분석할 수 있는 서버리스 서비스입니다. Kinesis Data Analytics를 사용하면 로그 분석, 클릭스트림 분석, 사물 인터넷(IoT), 광고 기술, 게임 등의 대규모의 스트림을 처리할 수 있는 애플리케이션을 신속하고 유연하게 구축할 수 있으며 유지관리의 어려움에서 벗어날 수 있습니다. 이 세션에서는 Kinesis Data Analytics의 동작과 기능, 운영상의 모범 사례에 대한 설명을 바탕으로 Streaming Application 개발, Studio Notebook 활용하는 방법을 데모를 통해 알아봅니다.
Similar to [2014널리세미나] 접근성 빅(?) 데이터, 새로운 법칙의 발견! (20)
안녕하십니까 청각장애인이 운행하는 친절한 고요한택시 서비스를 운행하는 코액터스 송민표입니다. 저희는 택시 내 의사소통 도구를 개발해서 청각장애인에게 택시 운전기사라는 직업을 열어주고 있습니다. 오늘 해당 의사소통 도구를 개발할 시 청각장애인 택시 운전기사님들을 위해서 고려했던 접근성 이슈를 이야기함과 더불어 접근성에 대한 범주를 좀 더 넓혀, 최대한 모두가 사용할 수 있는 유니버셜 디자인적인 접근으로 승객을 위한 기능들도 함께 소개를 해보겠습니다.
좀 가볍게 편안한 마음으로 저희가 기획할 때 했던 고민들을 들어주셨으면 좋겠습니다. 여러분 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. 마치며..
1. 스크립트를 통한 접근성은 어떻게 지켜야 할까?
2. 목차 순서로 최종 실무예시 및 해결법에 대해서 중점적으로 다루겠습니다.
3. 접근성은 마크업만 지키면 되는가? 대부분은 접근성은 마크업 개발자들의 책임이라고 생각합니다.
4. 시멘틱 마크업은 필수적이긴 하지만 접근성의 전부라고 할수 없습니다.
5. 기획 디자인 부터 서버개발까지 사용성에 맞는 화면구성 및 디자인 그리고 그에 맞는 데이터 형식을 출력하는데에 모두 접근성을 고려해야합니다.
6. 성능을 저하시켜서 접근성을 지키기보다는 최신 환경 기준에 구환경에서는 최소한의 컨텐츠 가독이 가능하게 하여 신기술 도입장벽을 허물고 생산성을 높히는 단계적 향상을 추구하고 있습니다.
7. 모두 똑같은 정보를 습득할수 있게 전달력이 좋고 가독성이 좋은 것을 접근성이라고 개인적으로 결론 지어봤습니다.
8. 자바스크립트 발전 방향을 알아보겠습니다.
9. 브라우저를 벗어난 활용과 화면 구현을 100% 자바스크립트만으로 그리는 형식으로까지 발전하고 있습니다.
10. 이전에 멀티미디어 플러그인의 리치 인터넷 애플리케이션 형태들이 스크립트만으로 구현하고 있는 추세입니다.
11. 자바스크립트로 html DOM 구조를 변경하다보니 컨텐츠가 엉뚱한 위치에 위치에 생성되기도 합니다.
12. 이런 문제점들에 대해서 어떠떻게 고려할지 예시를 통해서 살펴보도록 하겠습니다.
13. 모든 마우스 액션에 상응하는 키보드 이벤트를 중복으로 줘야 됩니다. mousedown과 keydown, mouseup과 keyup, click과 keypress, mouseover과 focus, mouseout과 blur. 예시를 보시면 mouseover 에만 들어가있는 탭 컨텐츠 노출 기능이 tab 키로 이동시에는 노출이 안됩니다. 따라서 같은 액션을 focus 에도 중복으로 넣어줘야 됩니다.
14. a 링크 태그의 href 속성을 무시하고 click 이벤트를 통해 액션을 제어지만 href 의 속성을 최대한 이용하여 스크립트 미지원 환경에서도 최종적으로 같은 결과의 액션이 일어나도록 처리해줘야 됩니다.
예시를 보시면 스크립트에서 "이동하시겠습니까?" 의 확인 창을 띄운 후 페이지 이동을 하려는 동작을 요할때 a 태그의 href 이동 경로 url 을 그대로 갖고 와서 확인 누르면 이동할수 있게 처리하면 좋습니다.
15. 피이지내에서 사용자 이벤트에 의해 컨텐츠 생성할때 innerHTML 을 많이 사용하지만 해당 document 위치에 문자열 형식의 innerHTML 을 사용하시기 보다는 createElement를 통해서 가상객체를 먼저 생성한 후 appendChild 로 삽입해 주도록 합니다.
예시를 보시면 추가 버튼을 누르면 입력란이 추가로 생성되는데 이와 같이 스크립트에서는 createELement 를 활용하여 넣어주시면 됩니다.
16. show hide 기능을 쓸때는 이벤트 핸들러 바로 뒤에 노출되도록 HTML 구조도에 맞게 보여지도록 하셔야 됩니다.
첫번째 예시로는 설정 버튼을 누르면 노출되는 설정메뉴들이 바로 설정버튼 다음에 나오도록 해야됩니다.
두뻔째 예시로는 전화 입력 폼 에서 번호가 아닌 문자를 입력하시면 경고 dialog 창이 나타나는데 이를 바로 뒤에 넣지 못넣는다면 focus 를 dialog 의 첫번째 텍스트에 focus를 주시고 dialog 내부에 있는 버튼들에 tabindex=1 속성을 줘서 tab 키로 탐색시 dialog 안에서만 이동되고 닫게되면 열리기 전 영역이나 원하는 영역으로 focus 를 주시면 됩니다.
17. a,input,buuton 등 Html 기본 이벤트 핸들러 태그들 외에 어쩔수 없이 액션을 넣어야할 경우 click 이벤트만으로 처리하게 되면 키보드 접근이 안되기 때문에 tabindex=0 , keypress 이벤트, aria-role 속성도 추가해주시면 접근이 가능합니다.
예시를 보시면 img 태그로 되어있는 썸네일 이미지를 클릭하면 큰이미지가 변경이 되는데 click 이벤트만 주고 있어서 키보드 접근이 안됩니다. 위와 같이 해당 속성 및 추가 이벤트를 주시면 키보드로도 이벤트가 활성화 됩니다.
18. 자동 슬라이드 되는 효과나 동영상에 대해서 재생/정지 기능을 제공을 해야합니다. 특히 라이브러리를 사용하실때 이런 접근성이 용이한 기능들이 존재하는지 확인하고 이용해주세요.
19. 브라우저마다 지원 함수들이 다른게 존재하는데 조건문을 줘서 브라우저별 그에 맞는 함수들을 모두 지원해줘야 됩니다.
예시로 addEventListener 함수는 ie8이하에서 지원이 안되고 대신 attachEvent 함수를 지원하고 있기 때문에 조건문으로 addEventListener 인식시 해당 함수를 사용하고 attachEvent 인식시에 이 함수를 사용하게 크로스 브라우징 처리를 해줍니다.
20. 시간과 고려를 통해 더욱 많은 사람들과 소통하고 공유할 수 있기를 바랍니다.
3. NWCAG 1.0
Automated
Manual
ouput
Client-Side Resources Analysis
(HTML, CSS, JS, Image… )
Expert Judgment
Web Service URL
Web Service URL
Web Service URL
Sample
NAVER A11Y Tools
DATA
Storage
input
4. NWCAG 1.0
Automated
Manual
ouput
Client-Side Resources Analysis
(HTML, CSS, JS, Image… )
Expert Judgment
Web Service URL
Web Service URL
Web Service URL
Sample
NAVER A11Y Tools
DATA
Storage
input
5. NWCAG 1.0
Automated
Manual
ouput
Client-Side Resources Analysis
(HTML, CSS, JS, Image… )
Expert Judgment
Web Service URL
Web Service URL
Web Service URL
Sample
NAVER A11Y Tools
DATA
Storage
input
6. NWCAG 1.0
Automated
Manual
ouput
Client-Side Resources Analysis
(HTML, CSS, JS, Image… )
Expert Judgment
Web Service URL
Web Service URL
Web Service URL
Sample
NAVER A11Y Tools
DATA
Storage
input
7. NWCAG 1.0
Automated
Manual
ouput
Client-Side Resources Analysis
(HTML, CSS, JS, Image… )
Expert Judgment
Web Service URL
Web Service URL
Web Service URL
Sample
NAVER A11Y Tools
DATA
Storage
input
8. NWCAG 1.0
Automated
Manual
ouput
Client-Side Resources Analysis
(HTML, CSS, JS, Image… )
Expert Judgment
Web Service URL
Web Service URL
Web Service URL
Sample
NAVER A11Y Tools
DATA
Storage
input
29. 사이트 전반의 URL 형태를 분석 이해가 쉽고 접근이 용이한지 파악
URL
ISSUE
Diagnosis info
…
http://news.naver.com/main/main.nhn?mode=LSD&mid=shm&sid1=102
네이버 뉴스
메인?
메인?
탬플릿 형태?
탬플릿 형태?
색션 아이디
http://news.naver.com/section/?sid=society
제안
30. Navigation Timing API로 Network과 DOM관련 Timing 정보를 측정
Performance info
Network
DOM
Headers
크롬 Dev tools Console에서 확인
Processing Model 참조 : http://www.w3.org/TR/navigation-timing/
안녕하세요. NTS 접근성개발실 김용원입니다.
제가 발표할 주제는 “접근성 데이터를 활용한 또다른 분석”이라는 주제입니다. 다소 생소하실 수 있는데요.
네이버에서 주기적으로 수집되는 접근성 데이터를 어떻게 수집하고 분석하는지 그 정보를 활용하기 위해 어떠한 법칙들을 연구하고 있는지 발표하겠습니다.
접근성 데이터가 뭔가요? 라는 질문을 먼저 던져 보겠습니다. 뭘까요?
쉽게 생각하면 대상 사이트가 KWCAG 즉 웹 컨텐츠 접근성 가이드라인 기준항목에 준하여 체크하고 통과되었는지 여부를 리포팅 한다라고 생각하실 수 았습니다.
이런 데이터 수집 과정을 네이버는 어떻게 수행하고 있는지 설명드리겠습니다.
접근성 진단이 필요한 네이버 서비스에서 주요한 페이지의 URL을 샘플로 추출합니다.
이 추출된 샘플을
NWCAG 1.0 ( 즉 네이버 웹 컨텐츠 접근성 가이드 라인) 을 기반으로 진단을 수행합니다.
물론 항목중에는 자동으로 진단가능한 항목과 사람의 손이 필요한 수동진단항목이 존재합니다.
여기서 자동으로 진단할 수 있는 항목은
NWAX Plus 라는 도구를 활용해 Client Side 리소스들을 다운로드하고 자동으로 진단 합니다.
수동 진단 항목은 접근성 전문가가 눈으로 직접 보거나 사용해보고 이슈 리포트를 작성합니다.
여기에 좀더 편리하게 입력할 수 있도록 N-WARS 라는 네이버 웹접근성 리포팅 시스템을 활용합니다.
그외 N-FEAS라는 접근성 도구가 존재하는데요. 바로 뒤 세션에서 보여드릴 예정입니다.
이 과정에서 수집된 정보들은 한곳으로 모이게 되는데요. 앞에 Manual 진단에서 보셨던 N-WARS가 모든 정보를 저장합니다.
사내 접근성 시스템 화면을 잠시 보여드리겠습니다.
NWAX Plus화면 이구요.
NWARS 대시보드 화면 입니다.
그래도 뭔가 답답하시죠 시원 스럽게 보여 드리고 싶은 데 아쉽게도 사내 시스템이라 보안상 보여드릴 수 가 없네요.
양해 부탁드리구요.
캡쳐로 나마 아쉬움을 달래 보겠습니다.
다시 돌아와서
이렇게 저장한 데이터 속에 어떤 것이 담겨 있나요? 조금 더 구체적으로 설명드리도록 하겠습니다.
크게 코드 조각과 진단정보, 성능정보가 담겨 있습니다.
코드 조각은 서비스의 샘플 URL에서 다운로드해 온 리소스 파일 즉 CSS, HTML, JS 같은 형식의 파일에 코드일부 이구요.
진단정보는 NWCAG 기준 진단된 이슈정보와 그에 해당하는 대상이나, 해결방법 등이 담겨 있습니다.
마지막으로 성능정보는 서비스의 샘플 URL이 정상적으로 접근가능 상태인지를 체크하거나 접근성에 영향을 주는 성능 이슈는 없는 지를 체크하여 그 정보를 저장합니다.
이렇게 쌓인 데이터를 어떻게 모니터링하고 통제하나요?라는 의문이 생길 수 있겠는데요.
단순히 가이드라인 체크항목의 준하여 현재 서비스의 접근성 이슈가 PASS냐 FAIL이냐 만을 보는게 아니라.
특정 주기로 수집된 데이터를 비교분석하여 사이트의 접근성 이슈와 현황을 파악합니다.
서비스별로 잘 개선이 진행되고 있는지를 막대그래프로 비교해 보거나
이슈 건수 변동이 심하진 않은지, 심하다면 사이트의 큰 변화가 있는지를 담당자를 통해 파악합니다.
또한 어떤 이슈유형이 많이 발생하는지 등을 파악하합니다.
이런 현황 파악 이후 합당한 솔루션을 제공하는데요.
특정항목에 대해 오류가 많거나 개선이 잘 안되고 있는 항목이 있으면 개선을 유도하기도 하거나
시스템 저장된 이슈 리포트를 재확인하도록 요청하며 해결 방법을 찾기 어렵다면 접근성 전문가가 나서서 직접 연구하여 해결책을 제시해 주기도 합니다.
또한 접근성에 대한 이해가 부족하다고 판단되면 직무별 세분화된 맞춤 교육을 실시하기도 합니다.
하지만 이렇게만 데이터를 활용하고 묵혀두기에는 데이터가 너무 가치 있다고 판단되어
접근성 준수여부를 체크하는 수준에서 벗어나 더 넓은 의미의 접근성으로 개선하기 위해 필요한 분석결과를 제공해야 한다고 생각하게 되었습니다.
그래서 좀 더 다른 측면에서 데이터를 분석하는 방법을 연구해 보았습니다.
그 첫번째가 키워드 분석을 통한 서비스 분야 파악 이었습니다.
HTML 코드 속에는 무수히 많은 키워드 들이 존재하고 서비스의 성격을 잘 대변하고 있어야 합니다.
간단하게 분석해보면 어떤 키워드들이 자주 등장하고 이런 키워드가 서비스 성격을 잘 대변하고 있는지 분석이 가능해 집니다.
예를 들어 쇼핑관련 단어들이 많이 존재한다면 이것은 쇼핑사이트야 라고 추측이 가능해지고 관련이 없는 단어들은 많이 존재한다면 이 것은 검색엔진최적화 측면에서 잘못된 정보를 검색엔진에 전달할 수 있으니
이를 개선할 수 있도록 사이트별 키워드 목록을 제공하는 것입니다.
물론 키워드를 추출하기 위해선 분야별 단어 사전구축이 필요입니다.
쉽지 않은 문제일 수 있지만 불가능한것은 아닌 것 같습니다.
두번째, 디자인 측면에서 사이트에 사용된 컬러 목록을 CSS 코드 조각들에서 추출할 수 있는데요.
이 데이터는 기본적으로 명도대비를 측정하는데 사용되고, 컬러 코드별 사용빈도순으로 정렬해서
사이트개발 전에 디자인에서 정의했던 브랜딩 가이드의 컬러 스키마와 비교가 가능해지며
컬러사용이 적절한지 브랜드 아이텐티티를 해치는 컬러는 없는지도 확인 할 수 있습니다.
또한 비슷한 컬러 끼리는 묶어서 하나의 컬러로 대체 할 수 있는지 검토하여 CSS 코드 리펙토링 자료로 활용 할 수 있습니다.
보시는 캡쳐 이미지는 Colorfy 라는 사이트에 m.naver.com의 CSS 코드를 입력하여 확인한 결과입니다.
세번째, 요즘은 또 반응형이다 머다 해서 다양한 스크린 사이즈와 디바이스 대응에도 관심이 많아 졌는데요.
CSS 에 선언된 미디어 쿼리를 분석해보면 이사이트가 어떤 스크린 사이즈까지 커버하고
스크린 사이즈에 따라 요소를 재배치 하는 지 파악할 수 있어
반응형 웹 개선 전략에도 활용할 수 있습니다.
보시는 캡쳐 이미지는
크롬브라우저의 확장 프로그램 Responsive Inspector로 확인한 m.naver.com의 미디어 쿼리의 브레이크 포인트 값을 시각화 한 것이며 클릭 시 브라우저가 리사이즈 되면서 반응하는 툴입니다.
네번째, 코드 브라우저 호환성 이슈 검출입니다.
개발자가 어련히 잘아서 하겠지만 사이트 접근에 방해가 되는 잠재적 이슈는 여전히 존재합니다.
아직 구 버전의 브라우저가 HTML 5 시맨틱 테그를 호환하지 않는 부분과
마이크로소프트의 extensions Methods를 사용해서 스크립트 오류를 유발시키거나
CSS속성 중 Vendor 전용속성을 사용해 같은 사용자 경험을 제공하지 않는 많은 이슈들을 추출하고 리포팅하는 것입니다.
물론 여기에 이미 호환이 되도록 다양한 메소드나 속성을 사용하여 해결했겠지만
이걸 가시화하여 참고하고 이슈 브라우저의 변화에 대응이 용이하도록 하는 것입니다.
다섯번째, URL의 단계를 파악하여 분리해보면 파라미터가 많거나 디렉터리 접근단계가 너무 깊어 URL을 브라우저에 직접입력하여 접근하는 것이 용이하지 않은 경우도 파악할 수 있습니다.
네이버 한 서비스의 예인데요. URL만 봐서는 어떤 서비스인지 잘모르시겠죠?
잘 살펴 보면 요소들이 의미가 중복됨을 추측할 수 있으며, 기능 중심의 URL 형태를 갖추고 있어 사용자가 인식이 용이하지 않아 보입니다.
이런 부분도 사용자 접근이 용이한 형태로 제안하자면 아래와 같이 제시될 수 있습니다.
물론 URL를 조정하기 위해 Server side의 기술적인 이슈들이 존재할 수 있죠.
뭐 이건 개발자에 맏겨 분석하도록 하고 개선하는 것이 최선의 방법이겠습니다.
마지막으로 알지만 개선하기 쉽지 않은 부분이 바로 성능입니다.
성능 부분은 기술의 발달로 더 많은 정보를 쉽게 파악할 수 있는데요. 특히 저희가 이부분에 대해 관심을 가지고 많은 연구를 하고 있습니다.
그중 W3C 표준 Navigation Timing API 에 window.performance 객체의 프로퍼티로 접근하면
사용자가 어떤 네트웍 과정과 브라우저에 화면을 출력하는 과정에 시간이 소요되었는지를 확인 할 수 있으며. 심지어 크롬 브라우저는 자바스크립트 메모리 사용에 대한 데이터까지 제공해줍니다.
캡쳐 이미지 처럼 브라우저 제공하는 자바스크립트 콘솔에서 window.performance를 실행해서 살펴보는 것만으로도
성능 측면에서 많은 정보를 쉽게 얻어 저장하고 모니터링 할 수 있습니다.
이 처럼 다양한 측면에서 분석가능한 정보들은 또다시 자동화 및 수동으로 분석이 가능합니다.
물론 그 사이에 세미오토가 존재 할 수도 있겠지만요.
제가 보여 예로 보여 드린 부분은 일부에 불과합니다.
이런 것들이 접근성 데이터의 분석결과로 채워질 때 좀 더 다양한 측면에서 접근성 개선이 가능해 지겠습니다.
이런 다양한 분석결과를 구체적으로 어디에 활용할 수 있는 건가요?
마케팅 측면이 강하겠지만 “SEO 최적화”에 서비스에서 추출한 키워드를 사용할 수 도 있겠구요,
“브랜드 아이덴티티 강화”를 위해 추출한 컬러패턴을 활용할 수 있습니다.
“코드 리팩토링”에는 코드의 호환성을 확인해서 개선할 수 있으며.
“성능 최적화”측면에서 많은 정보를 제공하고 개선할 수 있습니다.
“사용성 개선”은 이런 모든 것들이 개선되면 자연 스럽게 따라 개선 되겠습니다.
그런데 이런 분석이 접근성과 무슨 관련이 있나요?
라고 질문을 던질 수 있겠는데요.
직접적인 관련이 없을 수 있습니다.
단지, 좁은 의미의 접근성에서만요
하지만 좀 더 넓은 의미로 접근성을 생각해보면?
모든 사용자는 정보와 기능에 동등하게 뿐만아니라 편리하고 빠르게 접근할 수 있어여 합니다.
이것이 진정한 유니버설 즉 보편적인 웹 접근성 아니겠습니까?
