모바일 웹코딩 2015.3 퍼블리싱 팀 최 웅 대리 ※ 본 강의는 ‘어비의 모바일 웹’을 참고하여 제작하였습니다.

Presentation on theme: "모바일 웹코딩 2015.3 퍼블리싱 팀 최 웅 대리 ※ 본 강의는 ‘어비의 모바일 웹’을 참고하여 제작하였습니다."— Presentation transcript:

1 모바일 웹코딩 2015.3 퍼블리싱 팀 최 웅 대리 ※ 본 강의는 ‘어비의 모바일 웹’을 참고하여 제작하였습니다.

2 1. px코딩과 em코딩의 차이 2. em코딩법 계산법 3. 모바일 웹 활용기법 4. 모바일 접근성 사례 목차

3 1. px코딩과 em코딩

4 모바일 웹 상대적 단위(em, %) PC기반 웹에서 쓰던 px형태의 절대적인 크기를 나타내는 속성값 이외에 em, %라는 상대적인 크기를 나타내는 속성값을 사용하 기도 합니다. 현재는 em코딩법에 대하여 공부 중이니 상대적인 크기의 속성값에 대해 알아봅시다. IE기준으로 글꼴크기가 “normal”일 경우 크기는 1em, 12pt, 16px과 같습니다. 기준 폰트로 일반적으로 설정합니다. em폰트는 상대적이기 때문에 디바이스 브라우저의 크기에 상대적으로 비례하여 글자 크기도 변합니다. 예를 들어 세로화면으로 디바이스를 보고 있다가 가로로 화면회전을 시킨다면 가로 화면 비율에 맞추어 이미지나 텍스트의 크기 역 시 변화하게 됩니다. 즉, 디바이스 별로 최적의 이미지 크기를 보여주고 싶다거나 언제나 해당 비율의 디자인을 고수하고 싶은 디자인 위주의 사이트라 면 em코딩이 좋습니다. 왼쪽의 이미지는 각각 노트3크기의 핸드폰을 가로 세로로 화면 회 전시킨 모습입니다. 가로화면의 이미지 및 텍스트 크기와 세로 화 면의 텍스트 및 이미지 크기가 다른 것을 볼 수 있습니다. 다음과 같이 디자이너가 맞춰준 대로 그 비율을 고수 할 수 있습니 다. 하지만 가로화면의 크기는 워낙 비율이 확대된 나머지 이미지 가 브라우저 밖으로 나가버리고 한 화면에서 볼 수 있는 정보의 양 이 세로 화면보다 상대적으로 줄어들었음을 알 수 있습니다. 또한 em코딩은 상대적으로 개발이 좀 어렵습니다. 디자인 등에서 사용된 픽셀 단위를 계속 환산하여 상대적 크기를 계산해야 하기 때문에 일반 px코딩보다 최소 1.5배 이상의 시간이 더 소요됩니다.

5 모바일 웹 절대적 단위(px) 그럼 px단위로 코딩 된 모바일 웹을 살펴봅시다. px 코딩 역시 px과 가로 사이즈의 경우는 %를 혼용하여 제작합니다. 네이버 모바일 페이지 같은 경우는 px단위로 코딩이 되었기 때문에 세로 화 면이든 가로화면 이든 동일한 텍스트와 이미지 사이즈가 동일하여 보다 많은 내용을 화면 내에서 보여 줄 수 있습니다. 즉 다음과 같이 정보위주의 페이지가 많은 경우 px단위의 코딩이 유리합니다. 하지만 네이버와 같은 가로화면에서의 이단 구성을 보여주려면 애초에 디자인에서부터 두벌을 받 아서 가로화면 세로화면일 경우의 디자인 구성을 달리 해줘야 저런 형태의 디자인이 나옵니다. 삼성증권 모바일 웹 또한 px로 작업이 되었습니다. 이미지와 텍스트 크기 는 모두 동일합니다. 다만 가로사이즈를 100%로 잡고 가기 때문에 동그 라미 사이의 간격이 달라지게 됩니다. 즉 세로의 간격은 px로 가지만 가로의 간격은 %로 디바이스 브라우저에 비례해서 갈 수 밖에 없기 때문에 다음과 같은 현상이 생깁니다. 1. px코딩과 em코딩

6 어떤 단위를 사용하여 제작해야 될까? em  디자이너가 디자인 한 비율 그대로 디바이스 브라우저 별로 적용가능  비율 별로 한번에 모든 디바이스 브라우저에 최적화 하기 용이함  가로 화면으로 보게 될 경우엔 거의 컨텐츠가 가려지게 됨  개발하는데 일일히 px을 em단위로 변경해야 되는 어려움이 있음  디자인 위주의 모바일 페이지에 적합함  디자이너가 디자인 한 비율 그대로 디바이스 브라우저 별로 적용가능  비율 별로 한번에 모든 디바이스 브라우저에 최적화 하기 용이함  가로 화면으로 보게 될 경우엔 거의 컨텐츠가 가려지게 됨  개발하는데 일일히 px을 em단위로 변경해야 되는 어려움이 있음  디자인 위주의 모바일 페이지에 적합함 px  기존의 px단위로 작업하기 때문에 개발이 웹 작업과 마찬가지로 용이함  가로, 세로 화면에서 똑같은 크기를 보여주기 때문에 보다 많은 정보를 보여줄 수 있음  가로 화면의 경우를 따로 네이버처럼 디자인하지 않는 경우는 가로 비율자체가 다소 애매하 게 띄어질 수 있음  정보성 위주의 모바일 페이지에 적합함  모바일 웹이지만 고객사에 따라 태블릿까지 반응형으로 지원해달라는 겨우  기존의 px단위로 작업하기 때문에 개발이 웹 작업과 마찬가지로 용이함  가로, 세로 화면에서 똑같은 크기를 보여주기 때문에 보다 많은 정보를 보여줄 수 있음  가로 화면의 경우를 따로 네이버처럼 디자인하지 않는 경우는 가로 비율자체가 다소 애매하 게 띄어질 수 있음  정보성 위주의 모바일 페이지에 적합함  모바일 웹이지만 고객사에 따라 태블릿까지 반응형으로 지원해달라는 겨우 1. px코딩과 em코딩

7 2. em코딩 계산법

8 2. em코딩법 계산법 모바일 웹 해상도 모바일 웹을 위한 마크업 중 가장 중요한 것은 해상도 입니다. 보통 일반적인 PC기반의 웹 페이지를 제작할 때에는 1024*768, 1280*1024 등 해상도에 최적화된 마크업을 했습니다. 하지만 모바일의 경우는 320*480, 640*960, 480*800, 1024*600 등 모바일 기기마다 해상도가 다르기 때문에 각각의 해상도를 고려한 마크업이 필요합니다. http://troy.labs.daum.net/ 참고 http://troy.labs.daum.net/ 위 사이트는 모바일의 해상도를 한눈에 보고 모바일 시뮬레이션을 해볼 수 있는 유용한 사이트 입니다. 크롬, 파이어폭스, 익스 상위버젼에서만 접속 가능합니다. 모바일 시뮬레이션을 위한 다른 방법으로는 크롬에서 F12키를 눌러 개발자 도구를 누른 뒤에 버튼을 눌러 활성화 할수 있고, 파이어 폭스에서 F10키를 누르고 도구 > 웹개발 도구 > 반응형 웹 디자인 보기 버튼으로 확인할 수 있습니다.

9 모바일 웹 해상도 Q. 왜? 크기가 똑같을까? A. 아래의 두 디바이스는 각각 아이폰4와 아이폰3GS입니다. 보여지는 폰의 브라우저 크기는 같지만 두 개의 해상도는 각각 320*480, 640* 960으로 다릅니다. 즉 브라우저 크기는 같지만 해상도가 다르기 때문에 3GS에 비해 2배의 화질차이가 있습니 다. 이른 바 레티나 디스플레이라 불리는 기술입니다. 2. em코딩법 계산법

10 모바일 웹 해상도 Q. PSD크기는 어떻게 받아야 될까? A. 일반적으로 아이폰4의 레티나 디스플레이를 대응하기 위해 가로 640사이즈의 psd를 받았습니다. 또한 갤럭시의 대응을 위해 720의 psd를 사용하는 경우도 있었습니다. 요새는 폰에서 지원하는 해상도의 크기가 점점 더 커지는 추세라 노트3, S5 기준의 1080 가로사이즈 psd를 받아서 해당 이미지의 크기를 줄여서 작업을 하고 있습니다. 이렇게 크게 받은 해상도의 psd는 상대적 으로 이미지가 깨지지 않고 고해상도 모바일에서 선명하게 보이게 됩니다. 위의 폰의 브라우저 사이즈는 실제로 받은 1080psd보다 정확히 3배가 작습니다. 즉 모바일 작업을 처음 시작할 때는 기준 폰을 선 정하여 해당 폰을 기준으로 비례하여 다른 해상도 폰의 크기를 정해줍니다. 예를 들어 S5를 가장 최적화 폰으로 기준하여 모바일 작업을 한다고 했을 경우 1080/360 = 3으로 PSD와 기준디바이스 해상도 비 율이 3이라는 것을 알 수 있습니다. 이 3의 비율을 기억하시기 바랍니다. 즉 받은 이미지는 S5안에서 3배로 축소한 이미지로 들어가게 됩니다. 2. em코딩법 계산법

11 em 코딩 계산 360디바이스 기준으로 1080psd를 받았을 때 300px로 잘라진 이미지를 em단위로 변환해 봅시다. 아까 3의 비율을 기억하실 겁니다. 이 3의 비율대로 1080에서 잘라낸 300px의 단위를 3으로 나눠 줍시다.(300/3 = 100) 그렇다면 360 디바이스 기준으로 보았을 경우 300px은 실제 브라우저 디바이스에서는 100px로 표현이 되게 됩니다. 이번에는 기준폰트를 기억해 봅시다. IE기준으로 글꼴크기가 “normal”일 경우 크기는 1em, 12pt, 16px과 같습니다. 일반적으로 기준폰트로 16px을 1em으로 잡기 때 문에 1:16 = X : 100 이라는 비례식이 성립이 됩니다. 즉 16*X = 100 이므로 X의 값을 구하려면 100을 16으로 나눠줍니다. 6.25라는 값이 나오게 되는데 이 값이 바로 1080에서 잘라낸 300px의 em단위 값입니다. 즉 1em:16px = 6.25em:100px이고 이 값은 실제 1080psd에서 3배로 축소한 비율입니다. 왜 3배로 축소했는지는 앞서 설명드린 것처럼 노트3나 S5같은 고해상도의 폰의 실제 해상도가 1080사이즈이기 때문에 고해상도 폰에 대응하기 위해 이미지를 축소하여 흐리게 보이지 않고 선명해 보이도록 대응한 것입니다. 나누는 과정에서 소수점이 나오게 될 경우에는 3자리까지 대응해주고 그 이하 ex)132.666…는 반올림을 할 것인지 버림을 할 것 인지 기준을 정해 모두 통일하도록 합니다. 어떤 것은 반올림하고 어떤 것은 버림을 하고 이런식으로 통일 되지 않을 경우 기준 자 체가 애매모호 해지기 때문에 정확한 비율로의 상대적 계산이 어려워지니 꼭 통일하도록 합니다. 2. em코딩법 계산법

12 CSS3 미디어 쿼리 CSS3의 미디어 쿼리를 이용하여 각 해상도에 따라 기준 폰트 사이즈를 변경합니다. 각 가로 해상도에 기준하여 예를 들어 360해상도를 1em 기준으로 잡았다면 그에 맞게 다른 해상도를 설정합니다. ex) 360:1 = 320: X → 320 / 360 = X → X = 0.8888888888888889 (소수점 3자리 이후로 반올림 or 버림 합니다.) @media only screen and (min-width:320px){ body {font-size:0.888em;} } @media only screen and (min-width:360px){ body {font-size:1em;} } @media only screen and (min-width:384px){ body {font-size:1.066em;} } @media only screen and (min-width:400px){ body {font-size:1.111em;} } @media only screen and (min-width:439px){ body {font-size:1.219em;} } @media only screen and (min-width:480px){ body {font-size:1.333em;} } @media only screen and (min-width:533px){ body {font-size:1.480em;} } @media only screen and (min-width:568px){ body {font-size:1.577em;} } @media only screen and (min-width:585px){ body {font-size:1.625em;} } @media only screen and (min-width:598px){ body {font-size:1.661em;} } @media only screen and (min-width:640px){ body {font-size:1.777em;} } @media only screen and (min-width:683px){ body {font-size:1.897em;} } @media only screen and (min-width:768px){ body {font-size:2.133em;} } @media only screen and (min-width:1024px){ body {font-size:2.844em;} }

13 2. em코딩법 계산법 meta tag(viewport) 메타태그는 다음과 같이 설정합니다. 속성설명 Width=device-width각 모바일 기기의 해상도에 맞춰서 보일 수 있도록 설정합니다. Initial-scale 페이지가 보이는 기본 비율을 설정합니다.(아이폰은 scale이 1이면 가로 320px에 맞춰집니다.) Maximum-scale 페이지가 보이는 최대 비율입니다. Minimum-scale페이지가 보이는 최소 비율입니다. User-scalable모바일 기기에서 웹페이지의 확대가능 여부를 지정합니다. target-densitydpi 안드로이드에서만 지원합니다. 모바일의 경우도 모든 브라우저가 지원하는게 아니라 지원하지 않는 브라우저도 있습니다. medium-dpi로 보통 많이하나 레이아웃 크기가 디바이스마다 따로 노는 경우 가 발생하기도 합니다. 그럴 경우 device-dpi로 작성하면 해결됩니다. 모바일 해상도로 맞춰서 보여 준다라는 뜻입니다.

14 2. em코딩법 계산법 브라우저 주소 입력창 감추기 모바일 웹 페이지에 접속하면 웹 브라우저의 위쪽에 주소 입력창이 있습니다. 모바일 기기의 화면 크기는 상대적으로 작으므로 조 금이라도 넓은 영역을 볼 수 있도록 주소 입력창을 숨길 수 있습니다. window.addEventListener('load', function() { setTimeout(scrollTo, 0, 0, 1); }, false);

15 2. em코딩법 계산법 모바일 웹 바로가기 아이콘 스마트폰이나 태블릿 PC에서는 기본적으로 모바일 웹 페이지를 즐겨찾기 하여 홈 화면에 앱 아이콘 형태로 배치 할 수 있습니다. 이때 이 바로가기 아이콘을 직접 제작 할 수 있습니다. 스마트폰이나 태블릿 PC에서는 웹보다 아이콘 해상도가 좀 더 높기 때문에 따로 제작합니다. 아이콘 파일은 PNG형태로 저장하며 크기는 다음과 같습니다. 모바일 기기권장 크기 아이폰 3GS57 X 57 아이폰 4,4S114 X 114 아이패드 1,2 72 X 72 안드로이드 스마트폰(800 * 400 기준)72 X 72

16 3. 모바일웹 활용 기법

17 Font family 웹에서 쓸 수 있는 여러가지 웹폰트가 있지만(나눔고딕, 나눔바른고딕, 윤고딕…) 다음과 같은 폰트들은 웹폰트 이기 때문에 용량에 대한 이슈가 있습니다. 예를 들어 폰트 자체가 먹는 용량이 웹이나 모바일에서 불러 올 때 크기 때문에 폰트가 간혹 폰트가 뒤늦게 불러진다던지 기본 시스템 폰트(굴림체)로 보이다가 웹폰트로 바뀌는 경우도 있습니다. 이러한 구조적인 문제를 애초에 막기 위해서는 웹에서는 기본이 되는 시스템 폰트로 맑은 고딕으로 가고 각 모바일에서는 해당 모바일에 맞는 폰트가 나오도록 유지하는 것이 가장 좋 습니다. 즉 PSD는 기본 웹에 맞는 ‘맑은 고딕’으로 작업해 주시기 바랍니다. 윈도우 비스타,7,8 - 맑은고딕 안드로이드 4.1이하 – droid sans fallback(고딕) 안르도이드 4.2이상 – 나눔고딕 안드로이드 5.0이상(롤리팝) – 본고딕(Noto Sans) ios 5.x 이하 – 애플 고딕 ios 6.x - 애플 산돌 고딕 네오(일반체와 볼드체) ios 7.x 이상 – 애플 산돌 고딕 네오 (100 ~ 900) 윈도우 – 마이크로소프트 네오 고딕 font-family: 맑은 고딕, malgun gothic, AppleGothicNeoSD, Apple SD 산돌고딕 Neo, Microsoft NeoGothic, Droid sans, "나눔고딕", NanumGothic, "본고딕",Noto Sans CJK Regular, sans-serif; 3. 모바일웹 활용기법

18 IR기법 Image Replacement (IR 기법) 의미가 포함되어 있는 이미지를 배경으로 처리하고 대신 전경에 상응하는 텍스트를 넣는 방법으로써 시각이 있는 사용자는 이미지 로 처리된 화면을 볼 수 있지만 '화면 낭독기를 사용하는 시각 장애인, CSS 제거, 인쇄' 시에는 텍스트 데이터에 접근하거나 텍스트 를 볼 수 있는 형태로 설계하는 기법을 말합니다. 이 기법의 장점은 접근성을 떨어뜨리지 않으면서도 검색엔진으로부터 높은 가중치를 받을 수 있다는 점 입니다. 한편 모바일 디바이스장치에서 전송 요금 등을 고려하여 일부러 이미지를 끈 상태로 웹 사이트를 이용하는 사용자에게는 이미지와 텍스트가 모두 출력되지 않기 때문에 치명적일 수 있습니다. 따라서 의미가 포함된 이미지는 전경으로 처리한다는 원칙을 먼저 세우고 여러 조각의 이미지가 전송 성능에 영향을 미치지 않도록 고려해야 하는 경우에만 Sprite(조각난 이미지들을 하나의 이미지로 배경 처리해서 전송 성능을 높이는) 기법과 함께 사용하는 것이 좋습니다. 의미가 포함된 이미지를 배경으로 처리하고 그 내용을 텍스트로 넣은 후 css로 숨기는 기법

19 3. 모바일웹 활용기법 text-indent: -9999의 오류 사례 우리는 IR기법 사용을 위하여 text-indent: -9999px을 웹에서 종종 사용합니다. 하지만 voiceover, talkback실행 환경에서 line-height, text-indent ir기법을 사용하였을 때 링크가 틀어지거나 포커스가 안가는 현상이 나타난다.

20 3. 모바일웹 활용기법 해결법 1 1. color:transparent : 대체텍스트의 영역의 길이가 길면 영역 넘침 현상 2. : span태그를 추가해야하는 번거로움 3. letter-spacing:-7px; color:transparent : 글자 간격을 줄여서 영역 넘침 방지 4. font-size:5px;color:transparent : 글자크기 줄여서 영역 넘침 방지 a태그에 링크 영역이 잡히는 안드로이드와 달리 ios에서 텍스트영역에만 링크와 포커스가 잡히므로 font-size:0이나 line-height, text-indent를 이용한 IR기법은 ios에서 정상작동하지 않습니다. color:transparent나 z-index:-1를 이용해 숨김처리 할때 ios에서는 텍스트영역만큼 포커스가 잡히므로 대체텍스트가 길어질 경우 자신의 영역을 넘어가기 때문에 letter-spacing나 font-size를 이용해 텍스트영역의 넓이를 줄여 맞추어 줍니다. (주의:대체텍스트 길이가 짧을경우 letter-spacing을 많이 주면 포커스가 이상하게 잡힐 경우가 있다.)

21 3. 모바일웹 활용기법 해결법 2(css수정이 어려울 경우) before태그의 활용 삼성증권에서의 이슈사항중 하나였던 이미 text-indent등으로 설정이 되어있는 경우 일일히 찾아서 css수정이 어려운 상황이었습니다. 그 때 befor 태그를 활용하여 width,height 값을 설정하여 줌으로서 버튼 영역을 잡아주었고 content에는 의미는 없지만 읽히지 않는. 을 집어 넣어서 순차적으로 voiceover가 before 태그의.을 통해 내용을 클릭을 잡아 준 뒤 이어서 대체 텍스트까지 읽어주도록 하였습니다. footer.floating{ display:block;position:fixed;left:0;bottom:0;width:75px;height:75px;text-align:center;text-indent:- 5000em;color:transparent;background:url(/images/mobile/common/ico_floating.png) no-repeat;background-position:0 0;z- index:5;background-size:75px auto; } footer.floating:before{ position:absolute;top:0;left:0;width:75px;height:75px;background:transparent;color:transparent;z-index:-1;content:'.';vertical- align:middle }

22 3. 모바일웹 활용기법 em코딩시 IS기법 background:url(/front/img/com/mobile_zip.png) no-repeat 1.15em -19em;background-size:20.833em 20.833em; 다음과 같이 IS기법을 사용하여 모바일 웹에서도 코딩을 할 수 있습니다. 다만 주의해야 할 점은 웹과는 다르게 background-size를 지정해줘야 합니다. 이유는 바로 PSD의 크기에 있습니다. 우리가 만약 1080사이즈의 PSD를 받았다면 360기준 디바이스의 3배 크기의 이미지를 받게 됩니다. 그 이미지를 토대로 1000px X 1000px의 백판에다가 아이콘 등 여러가지를 몰아 넣는다고 했을 때, 사이즈를 지정해주지 않는다면 3배 이상의 px사이즈를 가진 백판을 background로 지정하게 됩니다. 그렇게 될 경우에는 우리가 지정해놓은 em단위에 따라 백그라운드가 맞춰지지 않습니다. 그래서 1000px또한 em단위로 변경하여 20.833em 같이 설정해주면 비로소 em단위로 바뀌어진 백판은 해상도에 따라 맞추어지게 됩니다.

23 4. 모바일 접근성 사례 http://ui.daum.net/accessibility/mobile

24 4. 모바일 접근성 사례 voiceover 설정방법 ios의 voiceover기능은 웹, 앱 구별 없이 음성지원을 잘 해주고 있는 반면, 안드로이드의 talkBack기능은 문제가 좀 많은 편이라 접근성 테스트시 일반적으로 voiceover를 사용하여 테스트 합니다. 동작방법은 간단합니다. 읽어 들이고 싶은 부분을 한번 터치하면 해당 텍스트나 대체 텍스트를 읽어줍니다. 두번 터치하면 실행합니다. 간단히 정리해 보겠습니다. 살짝 누르기: 항목을 말한다. 두 손가락으로 위로 쓸어넘기기 : 화면 상단의 항목부터 모두 읽는다. 두 손가락으로 아래로 쓸어넘기기 : 현재 위치의 항목부터 모두 읽는다. 세 손가락으로 위 또는 아래로 쓸어넘기기 : 한번에 한 화면만큼 스크롤 한다. 세 손가락으로 오른쪽 또는 왼쪽으로 쓸어 넘기기 : 다음 또는 이전 페이지로 이동한다.

25 4. 모바일 접근성 사례 롤링 베너의 대체 텍스트 텍스트가 아닌 콘텐츠는 대체 가능한 텍스트와 함께 제공되어야 한다. alt값은 빠짐없이 반드시 써줘야 하고 또한 이벤트 롤링 베너의 버튼에는 해당 버튼을 클릭하게 되면 몇번 째 베너를 보게 되는지 까지 상세히 써줘야 합니다. 또한 IR기법을 사용할 경우에 대한 이슈사항은 위에서 설명 드렸으니 반드시 염두에 두고 작업해야 합니다.

26 초점이동 순서 클라우드 구축 중 접근성 초점 이동 때문에 걷어내게 된 기능 다음과 같은 다양한 크기의 박스 형태에서는 화면 해상도를 조절하게 될 경우에 masonry 플러그 인을 사용하여 박스의 빈 칸을 채워주며 자동으로 빈 곳을 채워주는 형태의 소스를 사용했었습니다. 하지만 기껏 다 만들어 놨을 때 접근성에서 걸리는 부분이 있었습니다. 바로 초점이동입니다. li 의 순서대로 초점이 이동하기 때문에 masorny 플러그인이 시각적으로 빈 곳을 채워주더라도 초점은 li의 순서대로 움직이기 때문에 뒤죽박죽으로 초점이동이 되는 것입니다. 그래서 눈물을 머금고 해당 기능을 삭제했습니다. (정사각 박스로만 이뤄진 형태일 경우는 저렇게 순서가 뒤바껴서 배열되는 경우가 없어서 괜찮을 것으로 예상됩니다.) http://kloudbeer.com/ http://desandro.github.io/masonry/demos/infinite-scroll.html 4. 모바일 접근성 사례

27 초점의 이동 다음과 같이 마크업이 li구조로 각각 따로따로 마크업이 되 있을 경우 예를 들어 트레이딩을 클릭하면 안의 국내주식으로 포커스(초점) 이동이 되어야 합니다. 4. 모바일 접근성 사례

28 자막 제공 “멀티미디어 콘텐츠에는 동등한 내용의 자막, 원고 또는 수화가 제공되어야 한다." 동영상이 플레이 됨에 따라 자동으로 원고가 따라 흐르는 것이 가장 좋지만 기술적으로 힘들 경우에는 다음과 같이 스크롤을 해서라도 자막이나 원고를 볼 수 있도록 해야 합니다. * 스타일로 overflow:scroll 속성이 제공될 경우 해당 엘리먼트에 tab-index=“0” 을 적용해야 된다. 4. 모바일 접근성 사례

29 레이어 팝업 클로즈시 초점의 귀환 레이어 팝업을 보고 난 뒤 X(클로즈버튼)을 누를 경우에는 반드시 초점 이동을 시켜 레이어 팝업을 띄워주도록 눌렀던 버튼으로 다시 돌아가도록 합니다. 이 부분은 정말 많이 누락하는 경우가 많으니 꼭 신경 써서 작업합시다.

30 4. 모바일 접근성 사례 컨트롤 간 충분한 간격 “컨트롤은 충분한 간격으로 배치하는 것이 바람직하다." 모바일 기기의 화면 크기에 관계없이 컨트롤 중심간 간격은 13mm 이상을 권장합니다. 13mm의 간격은 물리적인 길이를 뜻합니 다. 따라서, 같은 pixel의 버튼 간격이라도 디바이스의 화면 크기와 해상도에 따라 달라질 수 있습니다. 또한 선택해야 하는 컨트롤 영역의 크기는 8.5mm X 8.5mm 이상을 권장합니다. http://ui.daum.net/accessibility/mobile/index_web_14_1

31 감사합니다