[2017널리세미나] 네이버 접근성 진단솔루션
•Download as PPTX, PDF•
0 likes•904 views
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 페이지 이상으로 마치겠습니다. 고맙습니다.
Report
Share
Report
Share
Recommended
[2017널리세미나] Accessibility at Microsoft
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
[2016널리세미나] 모바일 접근성 지침 Ato z 20160405
주제 : 모바일 접근성 지침 AtoZ
부제 : 모바일 애플리케이션 콘텐츠 접근성 지침 2.0 (개정)
발표자 : 아메바 디자인 서효진 수석
2페이지
제목 : 모바일 애플리케이션 접근성 지침서 2.0 개정안 배경
3페이지
제목 : 모바일 애플리케이션 접근성 지침서 2.0 개정안 변경 사항
4페이지
제목 : 모바일 애플리케이션 지침서 2.0(개정안) : 구성 및 목차
5-6페이지
제목 : 용어 정의 및 약어
7페이지
제목 : 인식의 용이성
8페이지
제목 : 6.1 대체 텍스트
9페이지
제목 : 6.2 자막, 수화 등의 제공
10페이지
제목 : 6.3 색에 무관한 인식
11페이지
제목 : 6.4 명도 대비
12페이지
제목 : 6.5 명확한 지시사항
13페이지
제목 : 6.6 알림 기능
14페이지
제목 : 운용의 용이성
15페이지
제목 : 7.1 초점
16페이지
제목 : 7.2 누르기 동작 지원
17페이지
제목 : 7.3 응답시간 조절
18페이지
제목 : 7.4 정지기능 제공
19페이지
제목 : 7.5 컨트롤의 크기와 간격
20페이지
제목 : 이해의 용이성
21페이지
제목 : 8.1 입력 도움
22페이지
제목 : 8.2 사용자 인터페이스의 일관성
23페이지
제목 : 8.3 깜박거림의 사용 제한
24페이지
제목 : 8.4 자동재생 금지
25페이지
제목 : 8.5 예측가능성
26페이지
제목 : 견고성
27페이지
제목 : 9.1 폰트 관련 기능의 활용
28페이지
제목 : 9.2 보조기술과의 호환성
29페이지
제목 : 접근성 사용자 평가 권고
[2016널리세미나] 스크립트를 통한 접근성은 어떻게 지켜야 할까
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. 시간과 고려를 통해 더욱 많은 사람들과 소통하고 공유할 수 있기를 바랍니다.
[2019널리세미나] 청각장애인 택시 운전기사를 위한 접근성
안녕하십니까 청각장애인이 운행하는 친절한 고요한택시 서비스를 운행하는 코액터스 송민표입니다. 저희는 택시 내 의사소통 도구를 개발해서 청각장애인에게 택시 운전기사라는 직업을 열어주고 있습니다. 오늘 해당 의사소통 도구를 개발할 시 청각장애인 택시 운전기사님들을 위해서 고려했던 접근성 이슈를 이야기함과 더불어 접근성에 대한 범주를 좀 더 넓혀, 최대한 모두가 사용할 수 있는 유니버셜 디자인적인 접근으로 승객을 위한 기능들도 함께 소개를 해보겠습니다.
좀 가볍게 편안한 마음으로 저희가 기획할 때 했던 고민들을 들어주셨으면 좋겠습니다. 여러분 Uber 아시나요? 대부분 아실 거라 생각이 듭니다. 모빌리티 공유에 씨앗을 발아시킨 기업이죠. 그렇다면 놀랍게도 미국 Uber에 등록되어 있는 청각장애인 드라이버가 약 6천명 정도인 사실도 아시나요? 6천명 정도가 되니 Uber에서도 청각장애인 기사분들을 위해 여러 고민을 했겠죠? 따라서 저희는 제품을 만들 시 Uber에서 고안한 접근성 부분도 함께 고민을 했었고, 최근에 SK T map 택시와 업무협약을 맺으면서 고요한택시 기사님들을 위해 기능을 추가하기도 했습니다. 이를 사례를 중심으로 말씀드리겠습니다.
먼저 고요한택시가 생소한 분들이 많으실 것 같아서 간략히 소개를 드리자면, 17년 8월 '청각장애인에게 택시 운전기사라는 새로운 취업군을 열어주자'라는 미션으로 시작했습니다. 이후 이 어려운 미션을 해결하기 위해 여러 지자체와 협력도 하고, 해외 전시회에서 발명상도 수상하며 제품을 검증받기도 했습니다. 그리고 기획 및 개발과정을 거쳐 작년 6월부터 1년간 고요한택시 서비스를 운행했습니다. 마지막 세션이기도 하고, 제가 낮은 톤의 목소리라 졸리실 것 같아서 제가 영상을 많이 준비했는데요. 저희 서비스에 관한 내용. 영상을 통해 만나보시죠.
[2019널리세미나] 듣고 말하는 서비스로 발전하는 네이버 어학사전의 접근성 개선
안녕하세요. 저는 네이버 어학 사전에서 접근성을 담당하고 있는 방설주입니다. 저는 중국인이고, 베이징 오피스에서 근무하고 있습니다.네이버 어학 사전은 중국과 한국이 함께 만들어 가는 서비스입니다. 어학 사전은 워낙 다양한 언어를 다뤄야 하므로 양국에 나누어서 운영되고 있습니다. 저는 듣고 말하는 서비스로 발전하는 네이버 사전의 접근성 개선 사례를 설명하고자 이 자리에 섰습니다.
먼저 네이버 어학 사전의 간단한 소개를 드리겠습니다. 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종류는 출판사가 출판한 콘텐츠라서 신뢰도가 높지만, 단점이 하나 있습니다. 업데이트 주기가 길고 복잡합니다. 우리가 사용하고 있는 언어들은 사실 끝없이 성장하고 있어요. 많은 유행어, 신조어, 인테넷용어들이 새로 생성되거나 다른 뜻으로 사용하고 있는 경우가 있는데요. 이런 내용을 대응하기 위해 저희는 인터넷에 있는 논문, 뉴스 등 신빙성이 높은 내용을 네이버 기술에 의해 추출하고 가공하여 사전에 도입하였습니다. 이게 바로 웹수집 콘텐츠입니다.
[2019널리세미나] 접근성은 별책 부록
인류에게 지식의 저장수단은 책으로 표현되는 텍스트에서 이미지로 발전하고 점점 동영상으로 그 형태를 달리해왔습니다. 그에 따라 시각장애인에게 지식을 전달하는 수단도 변화해왔지요. 점자책, 녹음도서에서 홈페이지의 alt text로 그리고 화면해설까지 세상의 변화에 따라가고 있습니다. 하지만 데이터의 폭발이라고 표현할만큼 현대 사회는 엄청난 양의 이미지와 동영상 콘텐츠를 만들어내기 시작햇고 시각장애인은 도저히 따라갈 수 없는 격차를 경험하게 됩니다. 이런 격차는 최근 들어 점점 좁혀지기 시작했는데요 그것은 바로 이 방해단 멀티미디어 콘텐츠를 효율적으로 활용하고자 하는 비장애인들의 노력에서 출발했습니다.
2015년 공개된 기술 이미지에서 사람을 구분하고 그들의 감정을 분석하는 기술이 가능해졌습니다.
MS에서도 사진을 분석해 여러 키워드를 생성하는 분석기술이 있습니다. 설명과 키워드를 보면 단어 형태지만 사진의 내용을 담고 있구요 주요 색상정보와 성인콘텐츠 여부까지 판단할 수 있습니다.
이런 이미지 분석 서비스는 여러 회사에서 다양한 플랫폼으로 소개됩니다. Microsoft Azure Google Cloud vision Google Video Intelligence AWS Amezon Rekognition Nvidia Intelligence Video Analytics
이미지 분석 뿐 아니라 동영상을 실시간으로 분석하는 기술까지 등장하고 있습니다. 거리의 사람들, 차량의 흐름 등을 분석하는 기술이 등장했고 지역의 빈 주차공간이나, 법률의 집행이 정상적으로 이루어졌는지 확인하는 것까지 활용범위가 넓어지고 있습니다. 이러한 영상 분석 기술은 스마트시티의 시스템을 구성하는 기초가 되고 있습니다.
[영상자동재생됨] 영상의 내용을 보면 각 사람을 따라다니는 숫자가 보입니다. 이것은 시간 정보입니다. 영상 속에서 각 사람을 구분하고 그들의 이동을 추적하는 시스템입니다. 특정 공간의 체류시간을 분석하고 사람들의 흐름을 확인할 수 있는 기술이죠. 이렇게 유동인구를 분석하면 지역상권이나 매장의 인기상품 분석, 이상행동을 하는 범죄패턴가지 분석해낼 수 있는 아주 다양한 효과를 거둘 수 있습니다. 영상원본 : https://youtu.be/rY1qmXda0Oo
Recommended
[2017널리세미나] Accessibility at Microsoft
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
[2016널리세미나] 모바일 접근성 지침 Ato z 20160405
주제 : 모바일 접근성 지침 AtoZ
부제 : 모바일 애플리케이션 콘텐츠 접근성 지침 2.0 (개정)
발표자 : 아메바 디자인 서효진 수석
2페이지
제목 : 모바일 애플리케이션 접근성 지침서 2.0 개정안 배경
3페이지
제목 : 모바일 애플리케이션 접근성 지침서 2.0 개정안 변경 사항
4페이지
제목 : 모바일 애플리케이션 지침서 2.0(개정안) : 구성 및 목차
5-6페이지
제목 : 용어 정의 및 약어
7페이지
제목 : 인식의 용이성
8페이지
제목 : 6.1 대체 텍스트
9페이지
제목 : 6.2 자막, 수화 등의 제공
10페이지
제목 : 6.3 색에 무관한 인식
11페이지
제목 : 6.4 명도 대비
12페이지
제목 : 6.5 명확한 지시사항
13페이지
제목 : 6.6 알림 기능
14페이지
제목 : 운용의 용이성
15페이지
제목 : 7.1 초점
16페이지
제목 : 7.2 누르기 동작 지원
17페이지
제목 : 7.3 응답시간 조절
18페이지
제목 : 7.4 정지기능 제공
19페이지
제목 : 7.5 컨트롤의 크기와 간격
20페이지
제목 : 이해의 용이성
21페이지
제목 : 8.1 입력 도움
22페이지
제목 : 8.2 사용자 인터페이스의 일관성
23페이지
제목 : 8.3 깜박거림의 사용 제한
24페이지
제목 : 8.4 자동재생 금지
25페이지
제목 : 8.5 예측가능성
26페이지
제목 : 견고성
27페이지
제목 : 9.1 폰트 관련 기능의 활용
28페이지
제목 : 9.2 보조기술과의 호환성
29페이지
제목 : 접근성 사용자 평가 권고
[2016널리세미나] 스크립트를 통한 접근성은 어떻게 지켜야 할까
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. 시간과 고려를 통해 더욱 많은 사람들과 소통하고 공유할 수 있기를 바랍니다.
[2019널리세미나] 청각장애인 택시 운전기사를 위한 접근성
안녕하십니까 청각장애인이 운행하는 친절한 고요한택시 서비스를 운행하는 코액터스 송민표입니다. 저희는 택시 내 의사소통 도구를 개발해서 청각장애인에게 택시 운전기사라는 직업을 열어주고 있습니다. 오늘 해당 의사소통 도구를 개발할 시 청각장애인 택시 운전기사님들을 위해서 고려했던 접근성 이슈를 이야기함과 더불어 접근성에 대한 범주를 좀 더 넓혀, 최대한 모두가 사용할 수 있는 유니버셜 디자인적인 접근으로 승객을 위한 기능들도 함께 소개를 해보겠습니다.
좀 가볍게 편안한 마음으로 저희가 기획할 때 했던 고민들을 들어주셨으면 좋겠습니다. 여러분 Uber 아시나요? 대부분 아실 거라 생각이 듭니다. 모빌리티 공유에 씨앗을 발아시킨 기업이죠. 그렇다면 놀랍게도 미국 Uber에 등록되어 있는 청각장애인 드라이버가 약 6천명 정도인 사실도 아시나요? 6천명 정도가 되니 Uber에서도 청각장애인 기사분들을 위해 여러 고민을 했겠죠? 따라서 저희는 제품을 만들 시 Uber에서 고안한 접근성 부분도 함께 고민을 했었고, 최근에 SK T map 택시와 업무협약을 맺으면서 고요한택시 기사님들을 위해 기능을 추가하기도 했습니다. 이를 사례를 중심으로 말씀드리겠습니다.
먼저 고요한택시가 생소한 분들이 많으실 것 같아서 간략히 소개를 드리자면, 17년 8월 '청각장애인에게 택시 운전기사라는 새로운 취업군을 열어주자'라는 미션으로 시작했습니다. 이후 이 어려운 미션을 해결하기 위해 여러 지자체와 협력도 하고, 해외 전시회에서 발명상도 수상하며 제품을 검증받기도 했습니다. 그리고 기획 및 개발과정을 거쳐 작년 6월부터 1년간 고요한택시 서비스를 운행했습니다. 마지막 세션이기도 하고, 제가 낮은 톤의 목소리라 졸리실 것 같아서 제가 영상을 많이 준비했는데요. 저희 서비스에 관한 내용. 영상을 통해 만나보시죠.
[2019널리세미나] 듣고 말하는 서비스로 발전하는 네이버 어학사전의 접근성 개선
안녕하세요. 저는 네이버 어학 사전에서 접근성을 담당하고 있는 방설주입니다. 저는 중국인이고, 베이징 오피스에서 근무하고 있습니다.네이버 어학 사전은 중국과 한국이 함께 만들어 가는 서비스입니다. 어학 사전은 워낙 다양한 언어를 다뤄야 하므로 양국에 나누어서 운영되고 있습니다. 저는 듣고 말하는 서비스로 발전하는 네이버 사전의 접근성 개선 사례를 설명하고자 이 자리에 섰습니다.
먼저 네이버 어학 사전의 간단한 소개를 드리겠습니다. 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종류는 출판사가 출판한 콘텐츠라서 신뢰도가 높지만, 단점이 하나 있습니다. 업데이트 주기가 길고 복잡합니다. 우리가 사용하고 있는 언어들은 사실 끝없이 성장하고 있어요. 많은 유행어, 신조어, 인테넷용어들이 새로 생성되거나 다른 뜻으로 사용하고 있는 경우가 있는데요. 이런 내용을 대응하기 위해 저희는 인터넷에 있는 논문, 뉴스 등 신빙성이 높은 내용을 네이버 기술에 의해 추출하고 가공하여 사전에 도입하였습니다. 이게 바로 웹수집 콘텐츠입니다.
[2019널리세미나] 접근성은 별책 부록
인류에게 지식의 저장수단은 책으로 표현되는 텍스트에서 이미지로 발전하고 점점 동영상으로 그 형태를 달리해왔습니다. 그에 따라 시각장애인에게 지식을 전달하는 수단도 변화해왔지요. 점자책, 녹음도서에서 홈페이지의 alt text로 그리고 화면해설까지 세상의 변화에 따라가고 있습니다. 하지만 데이터의 폭발이라고 표현할만큼 현대 사회는 엄청난 양의 이미지와 동영상 콘텐츠를 만들어내기 시작햇고 시각장애인은 도저히 따라갈 수 없는 격차를 경험하게 됩니다. 이런 격차는 최근 들어 점점 좁혀지기 시작했는데요 그것은 바로 이 방해단 멀티미디어 콘텐츠를 효율적으로 활용하고자 하는 비장애인들의 노력에서 출발했습니다.
2015년 공개된 기술 이미지에서 사람을 구분하고 그들의 감정을 분석하는 기술이 가능해졌습니다.
MS에서도 사진을 분석해 여러 키워드를 생성하는 분석기술이 있습니다. 설명과 키워드를 보면 단어 형태지만 사진의 내용을 담고 있구요 주요 색상정보와 성인콘텐츠 여부까지 판단할 수 있습니다.
이런 이미지 분석 서비스는 여러 회사에서 다양한 플랫폼으로 소개됩니다. Microsoft Azure Google Cloud vision Google Video Intelligence AWS Amezon Rekognition Nvidia Intelligence Video Analytics
이미지 분석 뿐 아니라 동영상을 실시간으로 분석하는 기술까지 등장하고 있습니다. 거리의 사람들, 차량의 흐름 등을 분석하는 기술이 등장했고 지역의 빈 주차공간이나, 법률의 집행이 정상적으로 이루어졌는지 확인하는 것까지 활용범위가 넓어지고 있습니다. 이러한 영상 분석 기술은 스마트시티의 시스템을 구성하는 기초가 되고 있습니다.
[영상자동재생됨] 영상의 내용을 보면 각 사람을 따라다니는 숫자가 보입니다. 이것은 시간 정보입니다. 영상 속에서 각 사람을 구분하고 그들의 이동을 추적하는 시스템입니다. 특정 공간의 체류시간을 분석하고 사람들의 흐름을 확인할 수 있는 기술이죠. 이렇게 유동인구를 분석하면 지역상권이나 매장의 인기상품 분석, 이상행동을 하는 범죄패턴가지 분석해낼 수 있는 아주 다양한 효과를 거둘 수 있습니다. 영상원본 : https://youtu.be/rY1qmXda0Oo
[2019널리세미나] 비슷하지만 다른 웹과 모바일 접근성
안녕하세요 비슷하지만 다른 웹과 모바일 접근성에 대해 발표하게 된 NTS 접근성팀 이선주입니다.
연사 초청을 받고 나서 아 주제를 뭐로 해야 할까 고민을 무지 많이 했어요. 항상 무슨 세미나가 있다 그러면 무조건 신청하고 보지 않나요? 회사안가니까, 뭐라도 도움이 되지 않을까, 아니면 경품에 혹해서? 그런데 막상 하루 종일 세미나를 듣고 와도 머리에 남는 건 많지 않나요? 접근성 세미나에서는 보통 웹에는 이런 것들이 있습니다 또는 모바일에서는 이런 것들이 있습니다. 라고 쭉 설명을 하는 경우가 많아서 무엇을 주제로 해야 할까 고민해보다가 세부적인 지침을 다 다루기보다는 웹에만 있거나 모바일에만 있거나 또는 웹과 모바일에 동시에 있어서 헷갈리는 부분들을 다뤄 봐야겠다 라는 생각이 들었습니다. 지금부터 웹과 모바일 접근성 차이에 대해 살펴보도록 하겠습니다. 웹에는 24가지의 접근성 항목이 있는데요, 다들 기본적으로 알고 계시죠..?? 알고 계시죠?? 그래서 이렇게 몇 가지만 모바일과 비교하여 살펴보도록 하겠습니다.
웹에는 키보드 사용 보장 항목이 있는데요 말 그대로 키보드 사용을 보장한다 입니다. 마우스를 사용하기 힘든 사용자들은 키보드로 웹을 탐색하기 때문에 모든 기능은 키보드만으로도 사용할 수 있어야 합니다. 그러려면 마우스로 동작할 수 있는 기능들은 모두 키보드로도 동작할 수 있도록 구현해주셔야 겠죠? 그럼 모바일은 어떨까요? 모바일은 키보드가 없습니다.
모바일은 터치 기반 입니다. 모바일에는 키보드 사용 보장이라는 항목 대신 누르기 동작 지원 항목이 존재하는데요, 모바일에서는 모든 기능이 누르기 동작으로 조작 가능해야 합니다. 이게 무슨말이냐, 통상적인 예로 지도 앱이 있는데요, 지도를 확대시키려면 두 손가락을 이용해야 하죠? 그럼 두 손가락을 이용하지 못하는 사용자는 이 기능을 어떻게 사용해야 할까요? 또한 스크린 리더 사용시 두 손가락 사용은 다르게 탐색하는 기능이기 때문에 다중 누르기, 펜, 끌기와 놓기 등의 복잡한 동작은 단순한 누르기 동작을 함께 제공되어야 합니다.
이렇게 끌어다 놓기로 이동이 가능한 경우 우측과 같이 누르기 동작만으로도 이동이 가능하도록 구현해야 합니다. 다음은 웹에서의 조작 가능 항목인데요, 저만해도 버튼이 너무 작으면 마우스로 클릭하기 힘들거든요, 손 떨림 현상을 가진 사용자와 같이 정교한 마우스 조작이 어려운 사용자들은 작은 컨트롤을 조작하는 것이 더~어 힘들겠죠? 따라서 컨트롤의 크기는 대각선 길이가 6mm이상이 되도록 구현해야 합니다. 가로, 세로가 아니라 대각선 길이 입니다.
모바일에도 비슷하게 컨트롤의 크기와 간격 항목이 있는데요 모바일에서는 컨트롤의 가로, 세로 길이가 각각 9mm 이상이 되도록 구현해주셔야 합니다. 컨트롤 크기는 아무래도 디자이너분들이 신경 써 주셔야 할 영역인 것 같은데요, 즉, 컨트롤을 큼직큼직하게, 클릭하기 쉽게 제공해주시면 됩니다. 웹에는 반복 영역 건너뛰기 항목이 있는데요, 저는 처음에 이게 반복되는 영역으로 건너뛰는 기능 인줄 알았어요. 그래서 메뉴로 바로 가기 이렇게 제공해야 하는 줄 알았는데 그게 아니라 반복되는 영역을 건너뛰는 기능이었습니다. 페이지마다 보통 메뉴가 반복되어 있는데요, 웹 페이지를 들으면서 탐색하는 분들은 다른 페이지에 갈 때마다 이 메뉴를 처음부터 다시 읽어주게 되어 불편합니다. 따라서 페이지마다 반복되는 콘텐츠를 건너뛸 수 있는 기능을 제공해야 합니다.
반복 영역 건너뛰기는 마크업 상 최 상단에 위치해야 하고 당연히 링크는 페이지 내에 존재해야 하며 키보드 접근 시 화면에 노출되어야 합니다. 또한 하단 메뉴로 바로가기 와 같은 위치 정보는 시각장애인의 경우 하단이 어디인지 알 수 없기 때문에 본문으로 바로 가기와 같이 명확하게 제공해야 합니다.
그럼 모바일은 어떨까요? 모바일은 반복 영역 건너뛰기 항목이 없습니다. 모바일은 화면 공간이 협소하기도 하지만 보통 반복되는 콘텐츠인 메뉴를 이렇게 아이콘으로 제공하여 선택 시 메뉴가 노출되기 때문에 굳이 반복 영역 건너뛰기를 제공할 필요가 없습니다. 웹에서는 제목 제공 항목이 있는데요, 이렇게 페이지를 여러 개 띄워 놓은 경우 페이지 제목이 모두 네이버네이버네이버 이면 직관적으로 어떤 페이지인지 인지하기 어려워 불편합니다. 청각으로 웹을 탐색하는 분들 또한 페이지 내용을 다 들어야 어떤 페이지인지 알 수 있기 때문에 페이지에는 페이지를 유추할 수 있는 제목을 제공해야 합니다. 프레임이나 아이프레임에도 제목을 제공해야 하며 콘텐츠 블록에도 제목을 제공해야 하는데요 이렇게 헤딩 태그로 콘텐츠 제목을 제공해주면 스크린리더 사용시 헤딩 태그만 건너뛰는 기능이 있기 때문에 본인이 원하는 콘텐츠를 선택해서 탐색할 수 있습니다.
모바일은 어떨까요? 모바일에는 제목 제공 항목이 없는데요 왜 없을까요? 소스를 볼 수 없으니까요.. 뿐만 아니라 모바일 네이티브 앱에서는 title태그와 같이 페이지 제목을 제공하는 기능이 없습니다. 다만 모바일 웹의 경우에는 “웹뷰 네이버”와 같이 title태그로 제목 제공 시 해당 제목을 읽어줍니다. 또한 모바일은 터치 기반으로 터치하면 내용을 들을 수 있기 떄문에 제목 제공이 아직은 필수는 아니지만 제목 제공 해주는 것을 권장합니다. 콘텐츠 제목을 예로 들면 비장애인분들은 아 이 부분들이 다 메뉴이구나라고 인식할 수 있지만 스크린 리더 사용자는 이 부분이 어떤 영역인지 알 수 없어 사용에 혼란을 줄 수 있습니다.
따라서 이렇게 디자인상으로 콘텐츠에 대한 제목을 제공하거나 다른 방법으로 제목을 제공해 주는 것이 좋습니다. 웹에서는 데이터 테이블을 제공하는 경우 표의 제목과 내용 셀을 구분해야 하며, 제목과 요약 정보를 제공해야 합니다. HTML5부터는 summary속성이 없어져서 많이들 헷갈려 하시는데요, Summary 속성이 없어졌다고 해서 요약 정보를 제공하지 않는 것이 아니라, caption에 제목과 요약 정보를 모두 제공해야 합니다.
[2019널리세미나] 모두를 위한 제품 및 서비스 - 구글 웹 프로덕트 및 구글 플레이의 접근성
안녕하세요, 구글 검색팀 소프트웨어 엔지니어 박재훈입니다.
접근성 향상을 위한 모두의 노력이 한 군데에 모이는 매우 의미있는 ‘널리 세미나'에 연사로 참여하게 되어 무척 영광입니다. 저는 검색팀 내에서 영화 검색의 프론트엔드를 담당하고 있습니다. 오늘 저는 여러분들께 구글 검색에서 지원하는 접근성을 위한 기능들 및 고려사항들을 소개드리고, 추가로 제가 소프트웨어 엔지니어를 꿈꾸는 대학생 대상으로 진행했던 웹 접근성 교육에 대해서도 공유를 드리도록 하겠습니다. 구글이 ‘접근성'이라는 주제를 대하는 방식을 이해하시는 데에 도움이 되기를 바랍니다.
구글의 미션은 "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로 설정되어 있습니다.
[2018널리세미나] 모바일 인앱 실무에 활용한 접근성 해결 방안
실무에서는 실태조사, 편의제공 등 다양한 현황에 맞춰 접근성에 대응해야 합니다.
접근성을 포함하는 방법과 그 사양을 구현하기 위한
세부적인 가이드가 필요하게 되었습니다.
수행은 접근성팀과 실무자들로 구성된 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로 선택된 상태값을 제공합니다.
[2018널리세미나] 지못미(지켜주지 못해 미안해) 마우스이벤트
지못미 마우스이벤트
김혜일
(키보드 사용 보장) 모든 기능은 키보드만으로도 사용할 수 있어야 한다.
도움말 아이콘을 마우스오버로 열 때 키보드의 초점이동만으로 펼쳐진다.
그런데 말입니다.
(사용자 요구에 따른 실행) 사용자가 의도하지 않은 기능(새 창, 초점에 의한 맥락 변화 등)은 실행되지 않아야 한다.
잘 지키고 있는가
초점을 받았을 경우,
사용자가 의도하지 않은 기능은 실행되지 않아야 한다.
키보드사용자의의도
키보드초점이동은 # 콘텐츠 탐색 # 조작을 위한 이동
쇼핑 사이트의 장바구니
키보드 초점 접근시 활성화되는 판매가, 카드헤택, 할인내역 등의 도움말이 많이 제공되었다.
#키보드사용자 #의도하지 않은 정보 인식 #정보의 선택권 X
초점에 의한 맥락의 변화
화면낭독프로그램 초점의이동에따라 콘텐츠가 활성화되어 맥락에 변화가 발생한다.
#화면낭독프로그램 사용자 #의도하지 않은 정보 인식 # 의도하지 않은 콘텐츠의 변화 #정보의 선택권 X
어떻게 하면 좋을까
어느쇼핑사이트1 마우스오버시 활성화되고, 키보드 엔터를 눌럿을 때 활성화됨
어느 쇼핑사이트2 마우스클릭시 활성화되고 키보드 엔터를 누렀을 때 활성화됨
끝판왕 GNB 메뉴
메인메뉴가 초점이동으로 활성화되어 탐색에 어려움이 있다.
이렇게 해보자
#초점이동 #기능실행NO
이렇게해보자 1단계메뉴
초점 접근 > 기능 실행 없음
Enter 입력 > 하위 메뉴 확장
이렇게해보자 2단계메뉴
초점 접근 > 기능 실행 없음
Enter 입력 1뎁스는하위 메뉴 접기 2뎁스는 메뉴 실행
이렇게해보자 3단계메뉴
초점 접근 > 기능 실행 없음
Enter 입력 1,2뎁스는하위 메뉴 접기 3뎁스는 링크 실
이렇게해보자 메뉴링크텍스트
하위메뉴의 펼침 상태에 따라 확장됨, 축소됨과 같은 문구 제공
이렇게해보자 기능이 2개인 메뉴
하위메뉴 확장 전 OOO 확장됨 링크
하위메뉴 확장 후 OOO 이동 또는 바로가기 링크
결론은
키보드 사용자UX가 중요
[2018널리세미나] 모두가 쉽게 쓰는 그날까지... 함께 만드는 접근성
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차 산업혁명에서 정보 접근성 교육 현황과 앞으로의 과제
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 웹접근성 안내)
앞으로의 과제 – 온라인 매뉴얼 제공 확대
우리 나라의 경우 복지관에서 제공하는 온라인 교육은 컴퓨터 혹은 스마트폰의 기본 기능과 인기 있는 서비스 위주로 제공함.
각 서비스를 제공하는 회사에서 접근성 개선과 함께 장애인 당사자를 위한 온라인 매뉴얼 제공 확대 필요.
≫ 네이버 메모의 폴더 이름 변경, 접근성이 고려된 보조배터리 구조 설명을 시연.
온라인 매뉴얼 제공 시 장점 및 유의사항
스크린리더 사용자 관점에서 매뉴얼이 제공되므로 서비스를 더 쉽게 이용할 수 있음.
접근성 개선이 미처 커버하기 어려운 부분에 대한 추가 설명을 제공함으로써 서비스의 이용을 도움.
[2018널리세미나] 정보 접근성 자동화 솔루션 개발 현황 및 방향 II
처음 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는 재 분류해서 저장하고 서비스를 위해 데이터를 가공해서 보여주게 됩니다. 대표적으로 차트 정보가 될 수 있습니다. 그리고 서비스가 얼마나 개선되고 있는 혹은 개악되고 있는지를 보여줄 수도 있습니다.
[2016널리세미나] 청각장애와 유니버셜 디자인 그리고 웹 접근성
발표 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
[2016널리세미나] 사용자 경험 향상을 위한 N가지 생각
1페이지
제목 : 사용자경험 향상을 위한 N가지 생각'
2페이지
제목 : 시각장애인과 IT 콘텐츠
3~6페이지
* 사용자경험, UX, UI, layout, color
* 시각장애인은 IT콘텐츠를 소리로 듣습니다.
* 텍스트를 소리로 듣습니다.
* IT콘텐츠는 텍스트가 됩니다.
7페이지
송중기 이미지의 대체텍스트
8페이지
여자친구 이미지의 대체텍스트
9페이지
버튼으로 들림
10페이지
적절한#1
적절한 대체텍스트, 링크텍스트
11페이지
* 적절한 대체 텍스트 제공
12페이지
적절한
13페이지
즐겨찾기 별아이콘의 대체텍스트
14페이지
검색버튼 로그인 버튼
15페이지
요소가 가지는 의미
16페이지
즐겨찾기 별아이콘의 대체텍스트
17~18페이지
제목 : A카페 즐겨찾는 카페 별 아이콘
19페이지
단순명사형 텍스트의 의미
등록 | 해제
20페이지
즐겨찾는 카페 등록 링크
21페이지
기능과 상태 토글되는 버튼
22페이지
제목 : D카페 즐겨찾기 링크
23페이지
즐겨찾기 별아이콘의 대체텍스트
24페이지
그게 최선입니까? 확실해요?
25페이지
제목 : 중요메일 표시 - A메일
26~27페이지
제목 : SNS링크는 어떨까?
28페이지
제목 : 콘텐츠 레이아웃에 따라 달라지는 의미
29페이지
제목 : 시각장애인의 정보인식
30페이지
제목 : SNS 링크 적절하게 제공하기
31페이지
제목 : SNS 링크 주변 맥락으로 이해하기
32페이지
SNS 링크 이건 너무해요.
33페이지
level up
34페이지
제목 : M공감 서비스
35~36페이지
제목 : 요소 유형의 인식도 중요해요
37페이지
제목 : 설정화면 ? K메신저 (Android)
38페이지
제목 : 적절한 #2 대체텍스트 제공 순서
39페이지
텍스트 제공순서를 고민해볼까요?
40페이지
제목 : 전계좌조회 ? K은행 앱 (iOS)
41페이지
제목 : 전계좌조회 ? K은행 (PC-web)
42페이지
제목 : K메신저 대화내용 (iOS)
43페이지
제목 : K메신저 대화내용 순서를 바꿔 보면…
44페이지
제목 : B음원서비스
45페이지
제목 : B음원 서비스 링크텍스트 순서를 바꿔 보면…
46페이지
핵심 정보는 앞으로 부가정보는 뒤로…
47~48페이지
제목 : 적절한 #3 초점이동
49페이지
제목 : 피드 목록 - Facebook 앱 (iOS)
50페이지
보이지 않는 요소의 초점
51페이지
제목 : SNS공유팝업 - A뉴스
52페이지
* SNS팝업 뒤 배경으로 초점이 접근되는 영상
53페이지
제목 : 공지팝업 - O 고객센터 앱 (iOS)
54페이지
어찌하여 WEB은 APP처럼 하지 않는가?
55~56페이지
저시력 사용자의 좁은 시야
57페이지
제목 : 확대기능 사용과 시야넓이
58페이지
제목 : 확대기능 사용으로 좁아진 시야
59페이지
제목 : D 클라우드 서비스 앱 (iOS)
60페이지
제목 : 친구찾기 ? K메신저 앱 (iOS)
61페이지
제목 : 관심종목추가 - Y증권 앱 (iOS)
62페이지
제목 : 접근성과 사람
65페이지
사람, 장애가 있는 사람
66페이지
제목 : 오프라인의 장애…
67페이지
제목 : 온라인 IT환경의 장애…
68페이지
장애(오프라인 DISSABILITY)가 장애(온라인iNTERERTION)되지 않는 IT환경
69페이지
지하철 출구번호를 큰글씨로 함게 제공
70페이지
제목 : 지침을 아무런 의식없이 적용한다면…
71페이지
유도블럭 중간에 볼라드가 설치된 사진
72페이지
직각으로 꺾이지 않고 곡선으로 이동하는 유도블럭 사진
[2016널리세미나] 웹 접근성 체험관을 소개합니다!
발표 주제: 웹 접근성 체험관을 소개합니다!
발표자: 김보민
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. 체험 후기(장애를 바라보는 관점을 바꾸다)
<오프라인>
- 머릿속에서만 상상하던 장면을 직접보니 상대방의 입장을 생각하게 되는 소중한 시간이었어요
- 이 체험을 하고 나서 장애인의 기분을 알게 되어서 앞으로 장애인을 보면 도와주겠습니다.
- 비록 많이 힘들었지만 중중 운동장애인들도 무슨일도 할 수 있다는걸 알았다. 접근성이란 단어를 몸으로 느낀 체험이었습니다.
- 특수교육학을 배우는 학생입니다 체험해보니 막연히 생각했던 것 이상으로 사용이 어렵네요
- 저는 적색,녹색 색약을 가진 아이입니다. 경험해보니 이런것도 있나 싶네요 네이버짱
- 이 키보드가 일반화가 되어야 장애인들이 이러한 서비스를 누릴수 있다고 생각합니다. 응원할게요!
- 시력이 매우 안 좋은데 다양한 효과로 웹 환경을 좀 더 잘 이용할수 있다는게 놀랍습니다. 사회적약자를 생각하는 기업 네이버 화이팅입니다!!
<온라인>
- 비장애인인 저와 다른 신체를 가진 분들의 생활의 일부를 체험해보고 그분들의 번거로움을 느껴보는 뜻 깊은 기회였어요
- 온라인 체험관이라 정말 상상도 못했던 기발한 서비스네요 앞으로 적극 홍보하고 싶네요. 좋은 서비스 감사합니다.
- 장애우분들은 어떻게 웹을 사용할까 궁금했는데 이분들의 입장에서 생각을 해보는 계기를 갖게 되었습니다.
<마무리>
대다수가 어려움을 느끼지 웹에도 노인이나 장애인에게는 힘겹게 느껴지는 문턱이 있습니다.모두가 편하게 이용할 수 있도록 웹의 문턱을 낮추는 노력은
다양한 환경을 이해하고 공감하는 여러분들의 배려에서부터 시작됩니다.
[2016널리세미나] 모바일애플리케이션접근성 이것만알아두자
제목 : 모바일애플리케이션 접근성 #이것만 알아두자.
발표자 : 네이버 접근성팀 서미연
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. 마치며..
[2016널리세미나] 남의 문제 나의 문제 우리의 문제
주제 : 남의 문제 나의 문제 우리의 문제
부제 : 정보접근성 무엇이 문제인가
발표자 : 미래창조과학부 손창용 사무관
1.접근성(accessibility)은 남의 일? 반성!
2.정보격차 수준은?
3.정보 접근성 수준은?
4.분야별 정보 접근성 수준은?
5.미래창조과학부와 한국정보화진흥원은 무엇을 했는가
6.정보접근성 근거는 무엇인가?
7.구체적인 근거는? 장애인 차별 금지법
8.해외사례1
9.해외사례2
10.해외사례3
11.해외사례4
12.왜 사회적 관심인가? (국가인권위원회 장애차별 진정현황)
13.영국은? (2016. 3월)
영국에서는 지난3월 중 보건노동부장관이 복지예산 삭감과 관련하여 사임한 바 있습니다.
14.정보 접근성 기준은 무엇인가?
15.웹 접근성 품질인증이란
16.정보 접근성 향상은 어떻게?
17.스마트폰 접근성 개선은 어떻게?
18.우리의 목표는
More Related Content
More from Nts Nuli
[2019널리세미나] 비슷하지만 다른 웹과 모바일 접근성
안녕하세요 비슷하지만 다른 웹과 모바일 접근성에 대해 발표하게 된 NTS 접근성팀 이선주입니다.
연사 초청을 받고 나서 아 주제를 뭐로 해야 할까 고민을 무지 많이 했어요. 항상 무슨 세미나가 있다 그러면 무조건 신청하고 보지 않나요? 회사안가니까, 뭐라도 도움이 되지 않을까, 아니면 경품에 혹해서? 그런데 막상 하루 종일 세미나를 듣고 와도 머리에 남는 건 많지 않나요? 접근성 세미나에서는 보통 웹에는 이런 것들이 있습니다 또는 모바일에서는 이런 것들이 있습니다. 라고 쭉 설명을 하는 경우가 많아서 무엇을 주제로 해야 할까 고민해보다가 세부적인 지침을 다 다루기보다는 웹에만 있거나 모바일에만 있거나 또는 웹과 모바일에 동시에 있어서 헷갈리는 부분들을 다뤄 봐야겠다 라는 생각이 들었습니다. 지금부터 웹과 모바일 접근성 차이에 대해 살펴보도록 하겠습니다. 웹에는 24가지의 접근성 항목이 있는데요, 다들 기본적으로 알고 계시죠..?? 알고 계시죠?? 그래서 이렇게 몇 가지만 모바일과 비교하여 살펴보도록 하겠습니다.
웹에는 키보드 사용 보장 항목이 있는데요 말 그대로 키보드 사용을 보장한다 입니다. 마우스를 사용하기 힘든 사용자들은 키보드로 웹을 탐색하기 때문에 모든 기능은 키보드만으로도 사용할 수 있어야 합니다. 그러려면 마우스로 동작할 수 있는 기능들은 모두 키보드로도 동작할 수 있도록 구현해주셔야 겠죠? 그럼 모바일은 어떨까요? 모바일은 키보드가 없습니다.
모바일은 터치 기반 입니다. 모바일에는 키보드 사용 보장이라는 항목 대신 누르기 동작 지원 항목이 존재하는데요, 모바일에서는 모든 기능이 누르기 동작으로 조작 가능해야 합니다. 이게 무슨말이냐, 통상적인 예로 지도 앱이 있는데요, 지도를 확대시키려면 두 손가락을 이용해야 하죠? 그럼 두 손가락을 이용하지 못하는 사용자는 이 기능을 어떻게 사용해야 할까요? 또한 스크린 리더 사용시 두 손가락 사용은 다르게 탐색하는 기능이기 때문에 다중 누르기, 펜, 끌기와 놓기 등의 복잡한 동작은 단순한 누르기 동작을 함께 제공되어야 합니다.
이렇게 끌어다 놓기로 이동이 가능한 경우 우측과 같이 누르기 동작만으로도 이동이 가능하도록 구현해야 합니다. 다음은 웹에서의 조작 가능 항목인데요, 저만해도 버튼이 너무 작으면 마우스로 클릭하기 힘들거든요, 손 떨림 현상을 가진 사용자와 같이 정교한 마우스 조작이 어려운 사용자들은 작은 컨트롤을 조작하는 것이 더~어 힘들겠죠? 따라서 컨트롤의 크기는 대각선 길이가 6mm이상이 되도록 구현해야 합니다. 가로, 세로가 아니라 대각선 길이 입니다.
모바일에도 비슷하게 컨트롤의 크기와 간격 항목이 있는데요 모바일에서는 컨트롤의 가로, 세로 길이가 각각 9mm 이상이 되도록 구현해주셔야 합니다. 컨트롤 크기는 아무래도 디자이너분들이 신경 써 주셔야 할 영역인 것 같은데요, 즉, 컨트롤을 큼직큼직하게, 클릭하기 쉽게 제공해주시면 됩니다. 웹에는 반복 영역 건너뛰기 항목이 있는데요, 저는 처음에 이게 반복되는 영역으로 건너뛰는 기능 인줄 알았어요. 그래서 메뉴로 바로 가기 이렇게 제공해야 하는 줄 알았는데 그게 아니라 반복되는 영역을 건너뛰는 기능이었습니다. 페이지마다 보통 메뉴가 반복되어 있는데요, 웹 페이지를 들으면서 탐색하는 분들은 다른 페이지에 갈 때마다 이 메뉴를 처음부터 다시 읽어주게 되어 불편합니다. 따라서 페이지마다 반복되는 콘텐츠를 건너뛸 수 있는 기능을 제공해야 합니다.
반복 영역 건너뛰기는 마크업 상 최 상단에 위치해야 하고 당연히 링크는 페이지 내에 존재해야 하며 키보드 접근 시 화면에 노출되어야 합니다. 또한 하단 메뉴로 바로가기 와 같은 위치 정보는 시각장애인의 경우 하단이 어디인지 알 수 없기 때문에 본문으로 바로 가기와 같이 명확하게 제공해야 합니다.
그럼 모바일은 어떨까요? 모바일은 반복 영역 건너뛰기 항목이 없습니다. 모바일은 화면 공간이 협소하기도 하지만 보통 반복되는 콘텐츠인 메뉴를 이렇게 아이콘으로 제공하여 선택 시 메뉴가 노출되기 때문에 굳이 반복 영역 건너뛰기를 제공할 필요가 없습니다. 웹에서는 제목 제공 항목이 있는데요, 이렇게 페이지를 여러 개 띄워 놓은 경우 페이지 제목이 모두 네이버네이버네이버 이면 직관적으로 어떤 페이지인지 인지하기 어려워 불편합니다. 청각으로 웹을 탐색하는 분들 또한 페이지 내용을 다 들어야 어떤 페이지인지 알 수 있기 때문에 페이지에는 페이지를 유추할 수 있는 제목을 제공해야 합니다. 프레임이나 아이프레임에도 제목을 제공해야 하며 콘텐츠 블록에도 제목을 제공해야 하는데요 이렇게 헤딩 태그로 콘텐츠 제목을 제공해주면 스크린리더 사용시 헤딩 태그만 건너뛰는 기능이 있기 때문에 본인이 원하는 콘텐츠를 선택해서 탐색할 수 있습니다.
모바일은 어떨까요? 모바일에는 제목 제공 항목이 없는데요 왜 없을까요? 소스를 볼 수 없으니까요.. 뿐만 아니라 모바일 네이티브 앱에서는 title태그와 같이 페이지 제목을 제공하는 기능이 없습니다. 다만 모바일 웹의 경우에는 “웹뷰 네이버”와 같이 title태그로 제목 제공 시 해당 제목을 읽어줍니다. 또한 모바일은 터치 기반으로 터치하면 내용을 들을 수 있기 떄문에 제목 제공이 아직은 필수는 아니지만 제목 제공 해주는 것을 권장합니다. 콘텐츠 제목을 예로 들면 비장애인분들은 아 이 부분들이 다 메뉴이구나라고 인식할 수 있지만 스크린 리더 사용자는 이 부분이 어떤 영역인지 알 수 없어 사용에 혼란을 줄 수 있습니다.
따라서 이렇게 디자인상으로 콘텐츠에 대한 제목을 제공하거나 다른 방법으로 제목을 제공해 주는 것이 좋습니다. 웹에서는 데이터 테이블을 제공하는 경우 표의 제목과 내용 셀을 구분해야 하며, 제목과 요약 정보를 제공해야 합니다. HTML5부터는 summary속성이 없어져서 많이들 헷갈려 하시는데요, Summary 속성이 없어졌다고 해서 요약 정보를 제공하지 않는 것이 아니라, caption에 제목과 요약 정보를 모두 제공해야 합니다.
[2019널리세미나] 모두를 위한 제품 및 서비스 - 구글 웹 프로덕트 및 구글 플레이의 접근성
안녕하세요, 구글 검색팀 소프트웨어 엔지니어 박재훈입니다.
접근성 향상을 위한 모두의 노력이 한 군데에 모이는 매우 의미있는 ‘널리 세미나'에 연사로 참여하게 되어 무척 영광입니다. 저는 검색팀 내에서 영화 검색의 프론트엔드를 담당하고 있습니다. 오늘 저는 여러분들께 구글 검색에서 지원하는 접근성을 위한 기능들 및 고려사항들을 소개드리고, 추가로 제가 소프트웨어 엔지니어를 꿈꾸는 대학생 대상으로 진행했던 웹 접근성 교육에 대해서도 공유를 드리도록 하겠습니다. 구글이 ‘접근성'이라는 주제를 대하는 방식을 이해하시는 데에 도움이 되기를 바랍니다.
구글의 미션은 "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로 설정되어 있습니다.
[2018널리세미나] 모바일 인앱 실무에 활용한 접근성 해결 방안
실무에서는 실태조사, 편의제공 등 다양한 현황에 맞춰 접근성에 대응해야 합니다.
접근성을 포함하는 방법과 그 사양을 구현하기 위한
세부적인 가이드가 필요하게 되었습니다.
수행은 접근성팀과 실무자들로 구성된 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로 선택된 상태값을 제공합니다.
[2018널리세미나] 지못미(지켜주지 못해 미안해) 마우스이벤트
지못미 마우스이벤트
김혜일
(키보드 사용 보장) 모든 기능은 키보드만으로도 사용할 수 있어야 한다.
도움말 아이콘을 마우스오버로 열 때 키보드의 초점이동만으로 펼쳐진다.
그런데 말입니다.
(사용자 요구에 따른 실행) 사용자가 의도하지 않은 기능(새 창, 초점에 의한 맥락 변화 등)은 실행되지 않아야 한다.
잘 지키고 있는가
초점을 받았을 경우,
사용자가 의도하지 않은 기능은 실행되지 않아야 한다.
키보드사용자의의도
키보드초점이동은 # 콘텐츠 탐색 # 조작을 위한 이동
쇼핑 사이트의 장바구니
키보드 초점 접근시 활성화되는 판매가, 카드헤택, 할인내역 등의 도움말이 많이 제공되었다.
#키보드사용자 #의도하지 않은 정보 인식 #정보의 선택권 X
초점에 의한 맥락의 변화
화면낭독프로그램 초점의이동에따라 콘텐츠가 활성화되어 맥락에 변화가 발생한다.
#화면낭독프로그램 사용자 #의도하지 않은 정보 인식 # 의도하지 않은 콘텐츠의 변화 #정보의 선택권 X
어떻게 하면 좋을까
어느쇼핑사이트1 마우스오버시 활성화되고, 키보드 엔터를 눌럿을 때 활성화됨
어느 쇼핑사이트2 마우스클릭시 활성화되고 키보드 엔터를 누렀을 때 활성화됨
끝판왕 GNB 메뉴
메인메뉴가 초점이동으로 활성화되어 탐색에 어려움이 있다.
이렇게 해보자
#초점이동 #기능실행NO
이렇게해보자 1단계메뉴
초점 접근 > 기능 실행 없음
Enter 입력 > 하위 메뉴 확장
이렇게해보자 2단계메뉴
초점 접근 > 기능 실행 없음
Enter 입력 1뎁스는하위 메뉴 접기 2뎁스는 메뉴 실행
이렇게해보자 3단계메뉴
초점 접근 > 기능 실행 없음
Enter 입력 1,2뎁스는하위 메뉴 접기 3뎁스는 링크 실
이렇게해보자 메뉴링크텍스트
하위메뉴의 펼침 상태에 따라 확장됨, 축소됨과 같은 문구 제공
이렇게해보자 기능이 2개인 메뉴
하위메뉴 확장 전 OOO 확장됨 링크
하위메뉴 확장 후 OOO 이동 또는 바로가기 링크
결론은
키보드 사용자UX가 중요
[2018널리세미나] 모두가 쉽게 쓰는 그날까지... 함께 만드는 접근성
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차 산업혁명에서 정보 접근성 교육 현황과 앞으로의 과제
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 웹접근성 안내)
앞으로의 과제 – 온라인 매뉴얼 제공 확대
우리 나라의 경우 복지관에서 제공하는 온라인 교육은 컴퓨터 혹은 스마트폰의 기본 기능과 인기 있는 서비스 위주로 제공함.
각 서비스를 제공하는 회사에서 접근성 개선과 함께 장애인 당사자를 위한 온라인 매뉴얼 제공 확대 필요.
≫ 네이버 메모의 폴더 이름 변경, 접근성이 고려된 보조배터리 구조 설명을 시연.
온라인 매뉴얼 제공 시 장점 및 유의사항
스크린리더 사용자 관점에서 매뉴얼이 제공되므로 서비스를 더 쉽게 이용할 수 있음.
접근성 개선이 미처 커버하기 어려운 부분에 대한 추가 설명을 제공함으로써 서비스의 이용을 도움.
[2018널리세미나] 정보 접근성 자동화 솔루션 개발 현황 및 방향 II
처음 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는 재 분류해서 저장하고 서비스를 위해 데이터를 가공해서 보여주게 됩니다. 대표적으로 차트 정보가 될 수 있습니다. 그리고 서비스가 얼마나 개선되고 있는 혹은 개악되고 있는지를 보여줄 수도 있습니다.
[2016널리세미나] 청각장애와 유니버셜 디자인 그리고 웹 접근성
발표 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
[2016널리세미나] 사용자 경험 향상을 위한 N가지 생각
1페이지
제목 : 사용자경험 향상을 위한 N가지 생각'
2페이지
제목 : 시각장애인과 IT 콘텐츠
3~6페이지
* 사용자경험, UX, UI, layout, color
* 시각장애인은 IT콘텐츠를 소리로 듣습니다.
* 텍스트를 소리로 듣습니다.
* IT콘텐츠는 텍스트가 됩니다.
7페이지
송중기 이미지의 대체텍스트
8페이지
여자친구 이미지의 대체텍스트
9페이지
버튼으로 들림
10페이지
적절한#1
적절한 대체텍스트, 링크텍스트
11페이지
* 적절한 대체 텍스트 제공
12페이지
적절한
13페이지
즐겨찾기 별아이콘의 대체텍스트
14페이지
검색버튼 로그인 버튼
15페이지
요소가 가지는 의미
16페이지
즐겨찾기 별아이콘의 대체텍스트
17~18페이지
제목 : A카페 즐겨찾는 카페 별 아이콘
19페이지
단순명사형 텍스트의 의미
등록 | 해제
20페이지
즐겨찾는 카페 등록 링크
21페이지
기능과 상태 토글되는 버튼
22페이지
제목 : D카페 즐겨찾기 링크
23페이지
즐겨찾기 별아이콘의 대체텍스트
24페이지
그게 최선입니까? 확실해요?
25페이지
제목 : 중요메일 표시 - A메일
26~27페이지
제목 : SNS링크는 어떨까?
28페이지
제목 : 콘텐츠 레이아웃에 따라 달라지는 의미
29페이지
제목 : 시각장애인의 정보인식
30페이지
제목 : SNS 링크 적절하게 제공하기
31페이지
제목 : SNS 링크 주변 맥락으로 이해하기
32페이지
SNS 링크 이건 너무해요.
33페이지
level up
34페이지
제목 : M공감 서비스
35~36페이지
제목 : 요소 유형의 인식도 중요해요
37페이지
제목 : 설정화면 ? K메신저 (Android)
38페이지
제목 : 적절한 #2 대체텍스트 제공 순서
39페이지
텍스트 제공순서를 고민해볼까요?
40페이지
제목 : 전계좌조회 ? K은행 앱 (iOS)
41페이지
제목 : 전계좌조회 ? K은행 (PC-web)
42페이지
제목 : K메신저 대화내용 (iOS)
43페이지
제목 : K메신저 대화내용 순서를 바꿔 보면…
44페이지
제목 : B음원서비스
45페이지
제목 : B음원 서비스 링크텍스트 순서를 바꿔 보면…
46페이지
핵심 정보는 앞으로 부가정보는 뒤로…
47~48페이지
제목 : 적절한 #3 초점이동
49페이지
제목 : 피드 목록 - Facebook 앱 (iOS)
50페이지
보이지 않는 요소의 초점
51페이지
제목 : SNS공유팝업 - A뉴스
52페이지
* SNS팝업 뒤 배경으로 초점이 접근되는 영상
53페이지
제목 : 공지팝업 - O 고객센터 앱 (iOS)
54페이지
어찌하여 WEB은 APP처럼 하지 않는가?
55~56페이지
저시력 사용자의 좁은 시야
57페이지
제목 : 확대기능 사용과 시야넓이
58페이지
제목 : 확대기능 사용으로 좁아진 시야
59페이지
제목 : D 클라우드 서비스 앱 (iOS)
60페이지
제목 : 친구찾기 ? K메신저 앱 (iOS)
61페이지
제목 : 관심종목추가 - Y증권 앱 (iOS)
62페이지
제목 : 접근성과 사람
65페이지
사람, 장애가 있는 사람
66페이지
제목 : 오프라인의 장애…
67페이지
제목 : 온라인 IT환경의 장애…
68페이지
장애(오프라인 DISSABILITY)가 장애(온라인iNTERERTION)되지 않는 IT환경
69페이지
지하철 출구번호를 큰글씨로 함게 제공
70페이지
제목 : 지침을 아무런 의식없이 적용한다면…
71페이지
유도블럭 중간에 볼라드가 설치된 사진
72페이지
직각으로 꺾이지 않고 곡선으로 이동하는 유도블럭 사진
[2016널리세미나] 웹 접근성 체험관을 소개합니다!
발표 주제: 웹 접근성 체험관을 소개합니다!
발표자: 김보민
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. 체험 후기(장애를 바라보는 관점을 바꾸다)
<오프라인>
- 머릿속에서만 상상하던 장면을 직접보니 상대방의 입장을 생각하게 되는 소중한 시간이었어요
- 이 체험을 하고 나서 장애인의 기분을 알게 되어서 앞으로 장애인을 보면 도와주겠습니다.
- 비록 많이 힘들었지만 중중 운동장애인들도 무슨일도 할 수 있다는걸 알았다. 접근성이란 단어를 몸으로 느낀 체험이었습니다.
- 특수교육학을 배우는 학생입니다 체험해보니 막연히 생각했던 것 이상으로 사용이 어렵네요
- 저는 적색,녹색 색약을 가진 아이입니다. 경험해보니 이런것도 있나 싶네요 네이버짱
- 이 키보드가 일반화가 되어야 장애인들이 이러한 서비스를 누릴수 있다고 생각합니다. 응원할게요!
- 시력이 매우 안 좋은데 다양한 효과로 웹 환경을 좀 더 잘 이용할수 있다는게 놀랍습니다. 사회적약자를 생각하는 기업 네이버 화이팅입니다!!
<온라인>
- 비장애인인 저와 다른 신체를 가진 분들의 생활의 일부를 체험해보고 그분들의 번거로움을 느껴보는 뜻 깊은 기회였어요
- 온라인 체험관이라 정말 상상도 못했던 기발한 서비스네요 앞으로 적극 홍보하고 싶네요. 좋은 서비스 감사합니다.
- 장애우분들은 어떻게 웹을 사용할까 궁금했는데 이분들의 입장에서 생각을 해보는 계기를 갖게 되었습니다.
<마무리>
대다수가 어려움을 느끼지 웹에도 노인이나 장애인에게는 힘겹게 느껴지는 문턱이 있습니다.모두가 편하게 이용할 수 있도록 웹의 문턱을 낮추는 노력은
다양한 환경을 이해하고 공감하는 여러분들의 배려에서부터 시작됩니다.
[2016널리세미나] 모바일애플리케이션접근성 이것만알아두자
제목 : 모바일애플리케이션 접근성 #이것만 알아두자.
발표자 : 네이버 접근성팀 서미연
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. 마치며..
[2016널리세미나] 남의 문제 나의 문제 우리의 문제
주제 : 남의 문제 나의 문제 우리의 문제
부제 : 정보접근성 무엇이 문제인가
발표자 : 미래창조과학부 손창용 사무관
1.접근성(accessibility)은 남의 일? 반성!
2.정보격차 수준은?
3.정보 접근성 수준은?
4.분야별 정보 접근성 수준은?
5.미래창조과학부와 한국정보화진흥원은 무엇을 했는가
6.정보접근성 근거는 무엇인가?
7.구체적인 근거는? 장애인 차별 금지법
8.해외사례1
9.해외사례2
10.해외사례3
11.해외사례4
12.왜 사회적 관심인가? (국가인권위원회 장애차별 진정현황)
13.영국은? (2016. 3월)
영국에서는 지난3월 중 보건노동부장관이 복지예산 삭감과 관련하여 사임한 바 있습니다.
14.정보 접근성 기준은 무엇인가?
15.웹 접근성 품질인증이란
16.정보 접근성 향상은 어떻게?
17.스마트폰 접근성 개선은 어떻게?
18.우리의 목표는
More from Nts Nuli (20)
[2019널리세미나] 모두를 위한 제품 및 서비스 - 구글 웹 프로덕트 및 구글 플레이의 접근성
[2019널리세미나] 모두를 위한 제품 및 서비스 - 구글 웹 프로덕트 및 구글 플레이의 접근성
[2012널리세미나] Front-End 최적화의 끝판왕, CSM + Markup Complexity
[2012널리세미나] Front-End 최적화의 끝판왕, CSM + Markup Complexity
[2017널리세미나] 네이버 접근성 진단솔루션
- 2. 목차 1. 개요 2. History 3. Architecture A. NWARS 3.0 (Spring, myBatis, Tiles, Bootstrap) B. NACT (Node.js, Phantom.js) 4. Function A. Reporting B. Management C. Issue D. History(trace) 5. 한계 6. 정리
- 3. 개요 접근성 1. 접근성 진단 2. 진단의 어려움 1. 필요성 2. 전문성 3. 현실성 필요성 전문성 현실성
- 4. NWARS 3.0 & NACT 1. 리포팅 툴 2. 관리 3. 이력 1. 진단 툴 2. 페이지 별로 바로 진단 개요
- 5. NWARS 3.0 1. 대시보드 2. 진단 요약 3. 진단 범위 4. 진단 이슈 개요
- 6. NACT 1. 진단 URL 입력 2. 진단 결과 3. 항목별 4. 이슈 내용 개요
- 7. NWARS 2.0 NWARS 3.0NWARS 1.0 ? History NWARS
- 9. NWARS DataBase Maria DB Nwars3.0 Domain request response Nwars3.0 Server Rule NACT Check Stat Query REST (Json data) NACT Server Phantomjs 회원정보 조직정보 Apache Server Auth API User info Org info Checklist Policy Issue Policy Stat Policy - 체크리스별 이슈기준 - NACT 데이터 유지항목 - 참조데이타 정의 - 비교된 데이터 처리 - 비교 안된 데이터 처리 - 기존 이슈 비교 정의 - 통계 - 이력 Dashboard Summary Client Architecture
- 10. NWARS Client DataBase Maria DB Spring Framework : java 기반의 프레임웍 Maven Framework : 다양한 library에 대한 프레임웍 Mybatis Framework : DB의 접근과 통제 프레임웍 Tiles Framework : 화면 구성에 대한 프레임웍 CKEditor : 에디터 WAS : TOMCAT 7.0 DB : Maria DB 5.5 Nwars3.0 Domain request response Attached file Nwars3.0 Server Spring + Maven Editor Mybatis Tiles Saved file info Attached file 회원정보 조직정보 회원 Server Auth API contents status 회원정보 조직정보 Apache Server Auth API User info / Org info Architecture
- 11. Client DataBase Maria DB request response log file 외부 Server Page Source 점검대상 URL phantomjsnodejs nginx ▶ 트레픽 (동시접속자) – 사내사용자 – 고려대상 낮음 ▶ 접근성 – 사내망 – 외부망 (PartnerED 사이트 배너) ▶ 관리 이슈 – 서버의 안정성 – 백업 정책 없음 NACT Domain NACT Architecture
- 12. 대시보드 2. 접근성 현황 1. 서비스 막대 차트 3. 서비스 카드 Function_Reporting
- 13. 진단 요약 1. 준수도 및 의견 3. 진단 추이 2. 진단 결과 Function_Reporting
- 14. 담당자 관리 1. 담당자 관리 2. 유형별 담당설정 3. 메일 받기 Function_Management
- 15. 진단 범위 관리 1. 범위 수정 2. 신규 범위 추가 3. 범위 수정 4. 주요 표본 선정 Function_Management
- 16. 검색 1. 범위 2. 지침항목 3. 유형 4. 타입 Function_Issue
- 17. 이슈 내용 1. 서비스 정보 2. 진단 정보 3. 이슈 정보 Function_Issue
- 18. 접근성 관련 정보 및 문의하기 1. 서비스 정보 2. 진단 정보 3. 이슈 정보 Function_Etc
- 20. 다양성 1. 다양한 코드 ex) table layout – w3c 에서는 table로 레이아웃을 만들지 않기를 권고한다. ex) <a> onclick 2. 후처리(Dynamic Contents) Ajax, Angularjs 3. 새로운 기기(브라우져) 출현 한계
- 21. Thank you
Editor's Notes
- 안녕하세요. 접근성 오류와 진단에 발표를 맡은 접근성팀 신의식입니다.
- 발표는 개요와 history 10분 Architecture 와 Function 10분 시연을 잠깐 보여드리고 마무리 하도록 하겠습니다.
- 헤밍웨이도 자신이 쓴 초고 원본은 쓰레기라고 했듯이, 한번 개발로 끝내는 개발은 없을 것입니다. 아무리 잘 하더라도 퇴고하듯이 개발을 진행해야 좋은 개발로 이어진다 생각합니다. 접근성을 잘 지켜 개발을 진행해도 내가 아닌 다른 사람이 검토해 준다면 더 좋은 개발이 될 것입니다. 하지만, 접근성 진단 어려움이 있습니다. 1. “기능이 다 잘 작동하는데 뭐가 문제인 겁니까?” 라는 인식의 부족 2. 접근성이라는 분야에 대한 전문적인 지식. 3. 제한된 시간과 자원에 따른 현실적인 어려움. 이러한 어려운 접근성 진단에 조금이나마 도움이 되고자 접근성팀에서 많은 노력을 기울이고 있습니다. 그 중에 작은 부분 접근성 진단 자동화 툴입니다. 자동화 툴은 앞에서 지적했던 전문성과 현실성에 도움을 주고 있습니다. 접근성 진단을 수행하려면 접근성 지침, tag와 같은 개발 등의 지식을 가지고 있어야 합니다. 또한 매일 수십 페이지를 집중해서 노려봐야 하는 끈기와 참을성도 가지고 있어야 합니다. 이러한 능력을 가졌음에도 사람이 실수가 없을 수는 없습니다. 자동화 툴은 개발자만 접근성 진단에 대한 전문성이 따라준다면 진단 수준이 높아집니다. 자동화 툴은 서버만 버텨 준다면 365일 24시간 노려볼수 있습니다. 자동화 툴은 개발자만 실수하지 않는다면, 진단에 대한 실수가 적습니다. 이제부터 이러한 자동화 툴은 어떤 것이 있고, 어떻게 사용되고 있는지 알아보도록 하겠습니다.
- 이번 시간에는 두 가지 툴을 소개해드리려고 합니다. NWARS(Naver Web Accessibility Reporting Service) 와 NACT(Naver Accessibility Content Testing) NWARS는 리포팅 툴이고 관리와 이력 서비스를 제공합니다. NACT는 진단을 수행하는 툴입니다. NACT는 엔진을 담당하고 NWARS는 서비스를 담당하고 있습니다. NACT는 일회성으로 빠르게 진단을 수행하고 결과를 보여줍니다. NWARS는 등록해두면, 주 별로 진단을 수행하고 이력을 저장해서 보여줍니다. 서로 보완하며 서비스를 제공하고 있습니다.
- 먼저 NWARS를 살펴보겠습니다. NWARS 3.0 이라고 써 있습니다. 느낌 오셨듯이 3번의 큰 변화를 거쳐서 지금의 모습으로 서비스하고 있습니다. 4개의 주요 페이지로 구성되어 있습니다. 전체 > 요약 > 범위 > 이슈 라고 생각해주시면 되겠습니다. 전체는 다른 서비스들에 비교해 어느 수준인지 알아볼 수 있습니다. 요약은 서비스의 접근성 수준을 보여줍니다. 범위는 각 URL에 대해서 이슈가 어느 정도 있는지 알 수 있습니다. 이슈는 접근성 진단에서 문제가 있다고 보여지는 요소를 보여줍니다.
- 다음으로 NACT 입니다. 얘는 숫자가 없습니다. 2개의 페이지를 보여줍니다. URL의 입력과 진단 결과 입니다. 실제적으로 실무에서 제일 많이 쓰이는 서비스이고 복잡한 UI보단 단순 명료하게 정보를 전달하려고 합니다. 딱 너 이슈!! 확인해!! 라는 느낌입니다.
- 앞에서 말씀 드렸듯이 NWARS는 3번의 변화를 거쳤습니다. 1.0은 폐기되었습니다. 2.0은 지수와 이력을 주요 기능으로 제공하였습니다. (지수를 설명하자면, 이슈가 몇 개라는 방식보다는 서비스 담당자들에게 잘 와 닿을 수 있게 100을 기준으로 환산하여 보여주었습니다.) 3.0은 지수가 폐기 되어 서비스 전체에 접근성 진단 요소에 대한 과락을 보여줍니다.
- NACT는 원래 NWAX로 불렸었습니다. NWAX는 파이어폭스에서 설치하여 실행합니다. NWAXPLUS는 URL을 입력 받아 진단을 수행합니다. NACT는 NWAXPLUS를 고도화 시켜 서비스를 제공합니다.
- NWARS의 구조도입니다. 세세한 내용 보다는 프로세스의 흐름을 나타내었습니다. NACT에서 진단한 결과를 NWARS의 정책에 맞게 데이터를 가공하고, 통계와 이력을 쌓습니다. 이 정보를 바탕으로 대시보드와 같은 서비스를 제공하게 됩니다.
- NWARS에 사용된 기술을 간략히 말씀드리면, Spring을 기반으로 Tiles, Mybatis 등이 쓰였습니다. 배치, 캐싱, 프로시져 등을 사용하였습니다. 각 상세한 기술 내용은 생략하도록 하겠습니다.
- NACT는 Node.js와 Phatom.js으로 구성되어 있습니다. Node는 화면과 전체 기반을 제공합니다. Phantom은 가상 브라우져의 역할을 하며, 페이지 정보를 넘겨줍니다.
- 이제 자세한 기능을 살펴 보겠습니다. NWARS의 대시보드는 상, 중, 하 로 구성됩니다. 상단에는 막대차트를 이용해 도달해야 하는 목표와 다른 서비스들과의 비교를 보여줍니다. 중단에는 파이차트를 활용하여 전체적인 수준을 보여줍니다. 하단에 서비스카드 목록은 각 서비스의 목록과 간략한 수준 정보를 보여줍니다.
- 대시보드에서 서비스를 선택하면, 그림 같은 요약 화면으로 넘어오게 됩니다. 전체적인 준수도 및 접근성 의견이 보여집니다. 진단 결과를 주요하게 봐주셔야 합니다. 표본 페이지별 진단 결과를 표로 보여줍니다. 이 데이터는 각 항목에 대해 어느 범위가 문제가 있는지를 잘 보여줍니다. 마지막으로 매주 진단이 수행되며 쌓인 추이를 보여줍니다.
- NWARS는 서비스 담당자를 지정하여 범위를 관리합니다. 운영 담당자로 지정되면 각 분야의 담당자를 관리 할 수 있습니다. 이 기능으로 통해 서비스에서 진단이 필요한 범위를 관리하게 됩니다.
- 먼저 보셨듯이 서비스 담당자로 지정되게 되면 붉은색으로 표시된 버튼이 보여지게 됩니다. 범위수정을 통해 범위를 수정하고 대표 범위를 선택할 수 있습니다.
- 실무자들이 가장 많이 찾는 페이지 입니다. 실제 이슈들을 볼 수 있는 페이지 입니다. 검색을 통해 자신과 관련 있는 이슈들을 볼 수 있습니다.
- 아까 목록에서 이슈를 선택하고 이슈 상세로 이동하게 됩니다. 각 요소들을 확인합니다. 중요한 정보는 하단에 이슈내용과 관련코드 해결방안을 중점으로 보고 이슈를 처리하도록 안내하고 있습니다.
- 기타 기능으로 접근성에 관련된 정보나 NWARS에 문의를 할 수 있습니다.
- NACT는 먼저 말씀 드린 대로 편리하게 URL만 넣어주시면 됩니다. 진단이 수행된 후 결과를 그림처럼 항목을 나눠 보여주게 됩니다.
- NWARS와 NACT의 접근성 진단은 한계를 가지고 있습니다. 1. 어마어마한 코드가 존재하고 방법도 다양합니다. 모든 형태의 소스를 진단하지 못합니다. 2. 후처리 언어의 경우 request와 response의 시간 차로 진단 시점에 따라 결과가 달라집니다. 3. 새로운 기기까지 나옵니다. 해상도도 각각입니다. 이 차이에 의해 진단이 달라져야 하는 경우가 발생합니다. 완전하지 않습니다. 언제나 최선을 다해 도움이 되기만을 바랍니다.
- 이상으로 마치겠습니다. 고맙습니다.