'Frontend/Web' 카테고리의 글 목록

웹 페이지 개발을 하면서 유튜브 영상을 가져와서 페이지에서 뿌려주는 경우가 종종 있다.

그리고 영상을 직접 가져오진 않더라도 썸네일을 가져와서 영상 url과 연결을 시켜줄 때가 있다.

1. 유튜브 주소에 따른 썸네일 가져오기

유튜브 영상의 주소가 https://www.youtube.com/watch?v=YwC0m0XaD2E 해당 url일 경우에 썸네일을 가져오는 방법은

1-1. 유튜브 영상의 id값 알기

영상 url의 v= 이후에 나오는 텍스트가 영상의 고유 id 값인데 썸네일을 가져오려면 해당 id값을 알아야한다.

위 영상을 예로 들면 YwC0m0XaD2E 값이 영상의 id 값이다.

1-2. 썸네일 주소 형식에 id값 넣기

id값을 알았으면 유튜브 썸네일 주소 형식에 id값만 넣어주면 된다.

썸네일 주소는 https://img.youtube.com/vi/ + id값 + /0.jpg 이다.

위 영상을 예로 들면 https://img.youtube.com/vi/YwC0m0XaD2E/0.jpg url이 메인 썸네일을 가져오는 주소다.

썸네일 주소 뒤에 0~3.jpg의 숫자를 입력할 수 있는다. 0은 메인, 1~3은 영상 진행별 썸네일 (영상 캡쳐화면)을 가져올 수 있다.

2. 썸네일 상하 여백 잘라서 가져오기 (mqdefault, maxdefault)

1번과 같은 방법으로 썸네일을 가져와서 페이지에 뿌릴 경우 내가 원하는 비율이 나오지 않을 것 이다.

그건 0.jpg 형식으로 썸네일을 가져오게 되면 유튜브 자체에서 넣어주는 상하에 검은색 여백이 존재하기 때문이다.

이런 여백 자르기 위해 css로 강제로 이미지를 조정하는 방법도 있겠지만

애초에 0.jpg 형식이 아닌 mqdefault.jpg 형식으로 썸네일을 가져오면 상하에 여백 없이 내가 원하는 썸네일을 가져올 수 있다.

(https://img.youtube.com/vi/YwC0m0XaD2E/mqdefault.jpg)

그리고 mqdefault.jpg로 이미지를 가져왔는데 이미지가 너무 작아서 실제 페이지에 적용 했을 때 깨지거나 번져 보인다면 maxresdefault.jpg 형식으로 이미지를 가져오면 등록된 썸네일 최대 퀄리티와 크기로 이미지를 가져올 수 있다.

(https://img.youtube.com/vi/YwC0m0XaD2E/maxresdefault.jpg)

[!] maxresdefault.jpg 형식의 이미지 파일은 유튜브 영상에 따라 불러오지 못하는 경우가 있다.

3. 정리

- 영상 가져오기 (기본/상하여백 o)

: https://img.youtube.com/ + id + /0.jpg

(ex. https://img.youtube.com/vi/YwC0m0XaD2E/0.jpg)

- 영상 가져오기 (기본/상하여백 x)

: https://img.youtube.com/ + id + /default.jpg

(ex. https://img.youtube.com/vi/YwC0m0XaD2E/default.jpg)

- 영상 가져오기 (상하 여백 없는 mqdefault)

: https://img.youtube.com/ + id + /mqdefault.jpg

(ex. https://img.youtube.com/vi/YwC0m0XaD2E/mqdefault.jpg)

- 영상 가져오기 (상하 여백없는 default, 최대 크기)

: https://img.youtube.com/ + id + /maxresdefault.jpg

(ex. https://img.youtube.com/vi/YwC0m0XaD2E/maxresdefault.jpg)

저작자표시 비영리

'Frontend > Web' 카테고리의 다른 글

[웹접근성] 스킵 네비게이션 (skip navigation) (1)	2021.12.31
[웹접근성] 웹 접근성을 고려한 마크업 - 인식의 용이성 (대체 텍스트) (0)	2021.05.20
WAI-ARIA 접근성2. 영역에 대한 설명, 레이블 (aria-label, aria-labelledby) (0)	2021.03.27
WAI-ARIA 접근성1. 소개 및 주의사항, 태그별 role의 사용 (0)	2021.03.20
크로스 브라우징이란? (0)	2020.09.12

브라우저를 통해 페이지를 탐색할 때 비장애인의 경우엔 내가 보고 싶은 컨텐츠를 마우스로 편하게 클릭하고 이용할 수 있다. 하지만 시각 장애인의 경우 tab키, 방향키 등을 사용한 스크린리더를 통해 페이지에서 원하는 정보를 얻을 수 있다. 그렇기 때문에 페이지의 양이 많다면 그리고 그 정보가 페이지 하단부에 있다면 정보를 얻기까지 수도 없이 많은 tab, 방향키 입력이 필요할 것이다. 이러한 접근성이 부족한 내용을 해결하기 위해 사용하는 것이 스킵 네비게이션이라는 방법이다.

1. 스킵 네비게이션(skip navigation)

스킵 네비게이션은 원래는 말 그대로 네비게이션 영역의 많은 링크들을 건너뛰고 바로 컨텐츠 정보를 탐색하기 위해 사용하는 용도를 가지고 있다.

<body>
  <div class="skip_nav">
    <a href="#content">컨텐츠 바로가기</a>
  </div>
  
  <header>
    <h1><a href="#">logo</a></h1>
    <nav>
      <ul>
        <li><a href="#">회사소개</a></li>
        <li>
          <a href="#">제품정보</a>
          <ul>
            <li><a href="#">스낵</a></li>
            <li><a href="#">음료</a></li>
            <li><a href="#">아이스크림</a></li>
            <li><a href="#">조미료</a></li>
          </ul>
        </li>
        <li><a href="#">채용</a></li>
        <li><a href="#">CONTACT</a></li>
      </ul>
    </nav>
  </header>
  
  <div id="content" class="wrap">
    <section id="mainService">...</section>
    <section id="mainLogin">...</section>
    <section id="mainShopping">...</section>
    <section id="mainShopping">...</section>
    <section id="mainNotice">...</section>
  </div>
</body>

위의 예시와 같은 구조를 가지고 있는 페이지들이 많이 있다.

위의 경우에 메인 컨텐츠를 탐색하기 위해선 nav 영역의 많은 링크들을 거쳐야 메인 컨텐츠들에 접근이 가능하다.

이러한 경우를 위해 스킵 네비게이션을 사용해 네비게이션 영역을 건너뛰고 메인 컨텐츠(#content) 영역으로 한번에 접근 가능하도록 작업할 수 있다.

2. 스킵 네비게이션의 활용

<body>
  <div class="skip_nav">
    <a href="#mainService">주요 서비스 바로가기</a>
    <a href="#mainMedia">미디어 정보 바로가기</a>
    <a href="#mainShopping">쇼핑 바로가기</a>
    <a href="#mainNotice">공지사항 바로가기</a>
    <a href="#mainLogin">로그인 바로가기</a>
  </div>
  
  <header>...</header>
  
  <div class="wrap">
    <section id="mainService">...</section>
    <section id="mainLogin">...</section>
    <section id="mainShopping">...</section>
    <section id="mainShopping">...</section>
    <section id="mainNotice">...</section>
  </div>
</body>

1번에서 설명한 예시와 달리 위의 방법은 각 주요 서비스 섹션을 스킵 네비게이션으로 연결하여 바로바로 접근할 수 있도록 작업하였다.

스킵 네비게이션은 위에서 설명한바와 같이 기본적으로 네비게이션을 스킵(건너뛰기)하기 위해서 사용을 한다.

그리고 과거에는 그 용도 외에 페이지 각 세부 영역별로 스킵 네비게이션과 연결하면 오히려 접근성을 저해하고 페이지 이용을 복잡하게 만든다고 추천하지 않았다.

하지만 최근들어 많은 대규모 페이지나 플랫폼에서 스킵 네비게이션을 단순 네비게이션을 스킵하기 위한 용도가 아닌 원하는 서비스나 정보를 한번에 이용할 수 있게 만든 하나의 링크 묶음으로 사용하고 있다.

이 부분은 명확히 어떤게 옳고 그르다고 말하기엔 방법에 대한 고민이 필요해보인다.

3. 스킵 네비게이션 스타일

스킵 네비게이션은 비장애인 사용자들이 페이지를 이용할 때 화면에서 보이지 않게 작업해야한다. 키보드나 스크린리더로 페이지를 tab 하였을 때 스킵 네비게이션이 노출되고 사용될 수 있게 해야한다.

그렇기 때문에 페이지에 맨 처음 접근하게 되면 일반적인 상황에서는 스킵 네비게이션을 확인할 수 없다. 그리고 그러한 이유로 스킵 네비게이션에 따로 css 스타일을 입히지 않아도 된다고 생각할 수 있다.

하지만 보통의 상황에서는 스킵 네비게이션 링크에 tab이 되었을 경우 tab이 활성화 된 링크에 css 스타일 효과를 줘서 화면에 노출되게끔 처리하는 것이 많이들 사용하는 방법이고 좋은 방법이라 생각한다.

.skip_nav a{position:absolute; top:-30px; left:0; background:#000; height:30px; line-height:30px; color:#fff; font-size:12px; padding:0 6px;}
.skip_nav a:focus,
.skip_nav a:active{top:0;} <!-- 해당 a태그가 focus 혹은 active 되었을 경우 a태그가 화면에 노출되게 처리 -->

4. 스킵 네비게이션 사용시 주의사항

스킵 네비게이션을 사용할 때에 몇 가지 주의 사항이 있다.

1. 스킵 네비게이션의 위치는 가능하면 최대한 body태그 맨 처음으로 위치해야 한다.

: 이유는 스킵 네비게이션의 목적이 네비게이션 영역을 스킵하기 위해서 혹은 주요 서비스로 페이지 초입에서 바로 접근하기 위해 사용을 하기 때문에 네비게이션 영역 뒤에나 컨텐츠 영역 뒤에 위치하게 되면 스킵 네비게이션을 쓰는 목적이 사라지기 때문이다.

2. 스킵 네비게이션은 페이지 구석구석 여러번 사용하는 것이 아니라 처음에 한번만 사용해야 한다.

: 시각 장애인 입장에서 페이지를 구성한다고 했을 때 스킵 네비게이션이 페이지 이용하는 중간 중간에 위치해서 페이지 요소들을 넘나들며 여기저기 바로바로 이용할 수 있게 한다면 좋을 것 같다는 생각을 가끔했다. 하지만 스킵 네비게이션은 페이지 첫 부분에 딱 한번 사용하는 것이 적절하다.

오히려 과한 스킵 네비게이션의 사용은 페이지의 구조와 페이지 이용을 더 복잡하게 할 뿐이다.

참조

https://jangkunblog.com/wp/skip-navigation-is-not-a-quick-link/

저작자표시 비영리

'Frontend > Web' 카테고리의 다른 글

유튜브(Youtube) 썸네일 이미지 가져오기 (상하 여백 있게/없게) (0)	2022.03.04
[웹접근성] 웹 접근성을 고려한 마크업 - 인식의 용이성 (대체 텍스트) (0)	2021.05.20
WAI-ARIA 접근성2. 영역에 대한 설명, 레이블 (aria-label, aria-labelledby) (0)	2021.03.27
WAI-ARIA 접근성1. 소개 및 주의사항, 태그별 role의 사용 (0)	2021.03.20
크로스 브라우징이란? (0)	2020.09.12

처음 마크업을 시작하고 어느정도 내가 원하는 화면을 디자인과 같이 구현할 수 있게 되었을 때부터,

단순한 코드 작성에 의미를 두는 것이 아닌 효율적인 코딩을 하기위해 노력하기 시작했다.

단순히 효율적인 레이아웃을 짜고 반복되는 css를 최소화 하는 등의 운용상의 효율이 아닌

내가 만든 마크업 페이지를 장애인, 비장애인 모두가 보다 쉽게 사용할 수 있도록 접근성을 고려한 코딩을 하는 것에 대한 고려가 필요하단 생각을 했다.

오늘은 웹 접근성을 고려하여 마크업을 하기 위한 방법 중 인식의 용이성이라는 주제 중 대체 텍스트에 대한 내용으로 포스팅을 하려한다.

(포스팅 내용은 한국형웹콘텐츠접근성지침2.1을 기준으로 작성하였다.)

1. 인식의 용이성

인식의 용이성은 사용자의 장애 유무를 떠나 모든 사용자가 페이지에 노출되는 컨턴체들을 동등하게 이용할 수 있게 작업 하는 것을 말한다.

인식의 용이성에는 크게 3개의 지침이 있다.

- 대체 텍스트

- 멀티미디어 대체 수단

- 명료성

2. 대체 텍스트 특징

비장애인의 경우 일반적인 웹 서핑을 할 때,

페이지에 있는 이미지를 한 눈에 알아보고 어떤 이미지인지, 뭘 나타내는 지를 바로 파악할 수 있지만

장애를 가진 이용자의 경우 '스크린 리더' 라는 프로그램을 이용해서 이미지에 대한 설명을 귀로 듣게 된다.

그렇기 때문에 이미지의 용도나 성격을 설명할 수 있는 대체 텍스트를 작업자가 따로 넣지 않는다면

장애를 가진 사용자들은 그 이미지가 어떤 이미지인지 전혀 알 방법이 없다.

때문에 이미지가 정보의 주를 이루는 페이지의 경우는 대부분의 정보를 습득할 수 없게된다.

대체 텍스트를 작성할 때 유의해야할 점은 다음과 같다.

1. 대체 텍스트는 간단하고 명료하게 제공되어야 한다.

2. 이미지를 클릭하면 링크가 이동하거나 이미지를 이용한 버튼의 경우 링크이동, 클릭 이벤트 등의 용도가 분명하기 때문에 해당 이미지를 클릭하면 어떤 기능이 나타나는지에 대한 설명을 대체 텍스트로 제공 해야한다.

<!-- QR코드 이미지 링크 -->
<a href="QRCode.com">
  <img src="qr.jpg" alt="QRcode.com으로 이동하는 QR코드">
</a>

<!-- 더보기 버튼 -->
<button type="button>
  <img src="more.png" alt="쇼핑 아이템 더보기">
</button>

위의 예시와 같이 QR코드 이미지를 클릭하면 QR코드를 인증할 수 있는 페이지로 이동한다고 했을 때

해당 이미지가 어떤 페이지로 이동이 되는지에 대해 alt="" 대체 텍스트를 통해 설명하고 있다.

그리고 일반적인 이벤트 버튼의 경우에도

단순히 이미지 설명을 '더보기'에서 끝내는 것이 아닌 해당 이미지 버튼을 누르면 어떤 영역이 더보기가 되는지에 대해 명확하게 표기할 필요가 있다.

3. 의미있는 배경 이미지의 경우 이미지에 대한 정보를 제공해야한다.

위와 같이 배경 이미지 안에 텍스트가 들어가 있는 경우

<img src="banner.jpg" alt="코로나19 나의 백신 예방접종 장소는?">

img태그의 alt 속성에 이미지에 들어가 있는 텍스트 정보를 명시해줘야한다.

4. 데이터 차트와 같이 내용이 복잡한 이미지나 컨텐츠의 경우에 사용자가 해당 내용을 파악할 수 있도록 충분한 대체 텍스트가 제공 되어야한다.

위와 같은 그래프 이지미가 있다고 했을 때

<img src="graph.png" alt="코로나 확진환자 지역별 비율 그래프 서울 31.2%, 기타 29.3%, 경기 27.9%, 대구 7.1%, 인천 4.5%">

alt 속성 값에 차트와 관련된 데이터 내용을 명시해줘야한다.

3. 대체 텍스트를 제공하지 않거나 제한적으로 제공하는 경우

접근성을 위해 대체 텍스트의 사용은 필수이다.

하지만 무분별한 대체 텍스트의 사용은 페이지 이용을 어지럽게 만들 수 있기 때문에

대체 텍스트를 제공하지 않아도 되는 경우나 아주 제한적으로만 간략하게 제공해도 되는 경우에 대해서도

알아둘 필요가 있다.

1. 수화 동영상과 같이 이미 해당 컨텐츠의 역할이 대체 콘텐츠의 역할을 하는 경우 별도의 텍스트를 제공해줄 필요가 없다.

2. 생방송과 같이 지속적으로 예측할 수 없는 내용의 변화가 있는 컨텐츠라면 하나하나 대체 텍스트를 제공하기 어렵기 때문에 간략하게 어떤 주제를 가진 방송인지 정도의 용도를 설명해주면 된다.

또한 색맹검사, 청각검사, 시력검사, 받아쓰기 등 검사 및 시험의 경우도 간략한 대체 텍스트로 용도를 설명해주면 된다.

3. 악기의 연주나 미술품 등의 시각적 예술 작품의 경우에도 해당 콘텐츠의 주제나 간단한 용도에 대한 대체 텍스트만 제공한다.

4. 특별한 의미가 없는 단순 이미지의 경우 대체 텍스트를 제공하지 않는다.

참고

https://www.wah.or.kr:444/Participation/%ED%95%9C%EA%B5%AD%ED%98%95%EC%9B%B9%EC%BD%98%ED%85%90%EC%B8%A0%EC%A0%91%EA%B7%BC%EC%84%B1%EC%A7%80%EC%B9%A82.1.pdf

https://accessibility.naver.com/acc/guide_01

저작자표시 비영리

'Frontend > Web' 카테고리의 다른 글

유튜브(Youtube) 썸네일 이미지 가져오기 (상하 여백 있게/없게) (0)	2022.03.04
[웹접근성] 스킵 네비게이션 (skip navigation) (1)	2021.12.31
WAI-ARIA 접근성2. 영역에 대한 설명, 레이블 (aria-label, aria-labelledby) (0)	2021.03.27
WAI-ARIA 접근성1. 소개 및 주의사항, 태그별 role의 사용 (0)	2021.03.20
크로스 브라우징이란? (0)	2020.09.12

2021.03.20 - [Frontend/Web] - WAI-ARIA 접근성1. 주의사항 및 특징, 역할 (role)의 사용

WAI-ARIA 접근성1. 소개 및 주의사항, 태그별 role의 사용

WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications)는 W3C에서 만든 기술로, WAI-ARIA 혹은 ARIA로 불린다. 1. WAI-ARIA 란? 마우스와 같은 포인팅 장비를 사용하기 힘든, 스크린..

abcdqbbq.tistory.com

이전 포스팅에서 WAI-ARIA의 기본적인 내용에 대해 알아봤다면

이번엔 자주 사용하는 ARIA 속성에 대해서 알아보려한다.

ARIA는 HTML요소에 접근 가능한 설명용 텍스트를 넣을 수 있다.

그 방법이 바로 ARIA의 속성 중 label과 관련된 속성을 사용하는 것이다.

간단하게 설명을 먼저 하자면

aria-label은 화면에 현재 요소를 설명할 텍스트가 없을 경우에 사용하는 설명용 텍스트를 담고있고

aria-labelledby는 화면에 현재 요소를 설명할 텍스트가 있을 경우에 해당 텍스트 영역과 현재 요소를 연결할 때 사용한다.

1. aria-label

1-1. aria-label은 모든 html 태그에서 사용할 수 있다.

1-2. 이미지를 사용해 시각적 표현을 할 경우 대체 텍스트 역할을 한다.

일반적인 텍스트를 사용해서 영역을 표현하는 경우가 아닌

이미지를 통해 영역을 표현하는 경우 해당 영역이 어떤 영역인지 설명할 수 있는 요소가 있어야한다.

그런 설명하는 역할을 하는 속성이 바로 aria-label 속성이다.

<button class="bt_menu" aria-label="navigation menu"></button>

예를들어 햄버거 메뉴 버튼이 있다고 한다면

일반적인 사용자들의 경우 햄버거 메뉴 이미지를 보고 클릭을 하고 사용하겠지만

시각적으로 햄버거 메뉴 이미지를 확인할 수 없는 사용자들의 경우

해당 영역이 어떤 버튼인지 인지 할 수 없다. 그렇기 때문에

aria-label 속성을 사용해 해당 영역이 navigation menu 라는 정보를 담아준다.

1-3. 네이티브 텍스트와 aria-label과 같이 사용하게 되면 aria-label 속성에 작성한 정보를 사용한다.

위의 예시에서 사용한 버튼을 예로 들면

<button class="bt_menu" aria-label="navigation menu">네비용 버튼</button>

해당 소스와 같이 aria-label엔 'navigation menu'를

button 태그 안에는 '네비용 버튼' 이라는 텍스트를 넣었을 경우에

스크린리더로 정보를 불러올 때 aria-label에 담긴 'navigation menu' 값을 사용한다.

2. aria-labelledby

aria-labelledby는 맨 처음 aria-label을 설명하기 전에 설명했듯이

화면에 현재 요소를 설명할 텍스트가 있을 경우에 해당 텍스트 영역과 현재 요소를 연결할 때 사용한다.

위 이미지는 aria-labelledby에 대해 아주 잘 나타낸 예시이다.

<span id="rg-label">
  Drink options
</span>

<div role="radiogroup" aria-labelledby="rg-label">
  <div>
    <input type="radio" name="drink" id="drink1">
    <label for="drink1">Water</label>
  </div>
  <div>
    <input type="radio" name="drink" id="drink2">
    <label for="drink2">Tea</label>
  </div>
  <div>
    <input type="radio" name="drink" id="drink3">
    <label for="drink3">Coffee</label>
  </div>
  <div>
    <input type="radio" name="drink" id="drink4">
    <label for="drink4">Cola</label>
  </div>
  <div>
    <input type="radio" name="drink" id="drink5">
    <label for="drink5">Ginger Ale</label>
  </div>
</div>

위와 같은 소스로 작성했을 경우

Water ~ Ginger Ale 을 담고 있는 radiogroup 영역에 대한 설명용 텍스트가

해당 div 영역 밖인 <span id="rg-label">에 있기 때문에

해당 id 값과 radiogroup div의 aria-labelledby의 값을 일치 시켜줘서

radiogroup 영역이 어떤 요소들의 집합인지를 설명해줄 수 있다.

1-1. aria-labelledby는 모든 html 태그에서 사용할 수 있다.

1-2. aria-labelledby는 숨겨져 있는 요소도 참조할 수 있다. (display:none or visibility:hidden)

<!-- 
  display:none,
  visibility:hidden을 적용한 영역도 참조할 수 있다. 
-->
<span id="rg-label" style="display:none">
  Drink options
</span>

<div role="radiogroup" aria-labelledby="rg-label">
  <div>
    <input type="radio" name="drink" id="drink1">
    <label for="drink1">Water</label>
  </div>
  <div>
    <input type="radio" name="drink" id="drink2">
    <label for="drink2">Tea</label>
  </div>
  <div>
    <input type="radio" name="drink" id="drink3">
    <label for="drink3">Coffee</label>
  </div>
  <div>
    <input type="radio" name="drink" id="drink4">
    <label for="drink4">Cola</label>
  </div>
  <div>
    <input type="radio" name="drink" id="drink5">
    <label for="drink5">Ginger Ale</label>
  </div>
</div>

1-3. aria-labelledby와 네이티브 텍스트, aria-label과 함께 사용이 된다면 aria-labelledby에 있는 내용이 최우선된다.

<span id="labelledby-text">navigation menu1</span>
<button class="bt_menu" aria-label="navigation menu2" aria-labelledby="labelledby-text">
  navigation menu3
</button>

위와 같은 소스일 경우에

aria-labelledby의 경우 <span id="labelledby-text">navigation menu1</span>

aria-label의 경우 navigation menu2

네이티브 텍스트의 경우 navigation menu3의 값을 가지고 있는데

이처럼 3개의 내용이 동시에 적용될 경우

aria-labelledby 속성으로 정의한 내용이 최우선 된다.

developers.google.com/web/fundamentals/accessibility/semantics-aria/aria-labels-and-relationships?hl=ko

www.w3.org/TR/wai-aria-1.1

저작자표시 비영리

'Frontend > Web' 카테고리의 다른 글

[웹접근성] 스킵 네비게이션 (skip navigation) (1)	2021.12.31
[웹접근성] 웹 접근성을 고려한 마크업 - 인식의 용이성 (대체 텍스트) (0)	2021.05.20
WAI-ARIA 접근성1. 소개 및 주의사항, 태그별 role의 사용 (0)	2021.03.20
크로스 브라우징이란? (0)	2020.09.12
SEO(검색 엔진 최적화)란? (0)	2020.04.21

WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications)는

W3C에서 만든 기술로, WAI-ARIA 혹은 ARIA로 불린다.

1. WAI-ARIA 란?

마우스와 같은 포인팅 장비를 사용하기 힘든, 스크린 리더를 사용하는 사용자들에게

동적 컨텐츠, javascript, ajax, vue, react 등과 같이 페이지를 새로고침 하지 않고도

페이지의 내용과 데이터가 바뀌는 영역에 역할, 속성, 상태 정보를 추가하여

동적인 컨텐츠에 보다 원활하게 접근하고

페이지에 접근성을 높여 여러 사용자들에게 원활한 페이지 이용을 도와준다.

(ex. 버튼을 클릭하여 페이지 새로고침이나 링크 이동으로 페이지가 전환되는 것이 아닌

컨텐츠 내용이나 구조가 바뀌는 상황에서 페이지 전환 상태나 정보를 WAI-ARIA로 알려준다.)

또한

WAI-ARIA는 단순 HTML로 표현할 수 없는 의미들을 태그에 부여하여 시각적인 불편함이 있는

사용자들게 일반적인 구조의 HTML에서 필요한 요소에 적절한 정보를 전달받아

원활하게 페이지 탐색 및 이용을 하도록 도와준다.

<li tabindex="0" class="checkbox" checked>
  Receive promotional offers
</li>

예를 들어 위와 같은 태그를 살펴 봤을 때

li태그에 .checkbox 클래스를 부여하여 css상으로 체크박스 형태의 모양을 만들어 사용할 경우

시각적 불편함이 없는 사용자들의 경우 css 화면을 보고 해당 영역이

체크박스임을 인지할 수 있지만 스크린리더로 화면을 탐색해야하는 사용자들의 경우

위의 css 정보를 얻을 수 없다.

이때 스크린리더 사용자들을 위한 방법이 WAI-ARIA를 사용하는 것이다.

<li tabindex="0" class="checkbox" role="checkbox" checked aria-checked="true">
  Receive promotional offers
</li>

기존 소스와 다르게 role, aria-checked ARIA 속성을 사용하여

해당 영역이 체크박스인지, 체크가 되었는지 안되었는지 까지 명시할 수 있다.

2. WAI-ARIA 사용시 주의사항

- 올바르지 못한 ARIA를 사용할 바엔 ARIA를 사용하지 않는 편이 좋다.

스크린리더를 사용하여 페이지에 접근하는 경우 ARIA의 정보에 의지하게 되는데

바르지 못한 정보를 제공하게 되는 경우 스크린리더 사용자의 페이지 접근에 치명적인 영향을 주게된다.

ex)

<div role="button">주문하기</div>

예를 들어,

쇼핑몰에서 위의 소스처럼 div 영역을 버튼으로 사용하고 클릭시 주문이 되도록

소스를 작성했다고 했을 때, role="button"을 작성한다고 해서 실제 html 상에 키보드 포커싱이

일반 버튼처럼 역할을 주는 것은 아니다. (키보드로 해당 div가 접근이 안된다.)

키보드로 접근을 할 때, a, button과 같은 상호작용을 하는 태그가 아니라면 키보드로 해당 컨텐츠를

접근할 수 없다. 그렇기 때문에 위의 소스로 작성을 하게 된다면

키보드로 해당 div 영역을 접근할 수 있도록 처리를 해주거나 (강제로 tabindex 속성을 주거나 스크립트 처리)

버튼의 용도에 맞게 a, button 태그를 사용해야한다.

- ARIA를 사용하기 전에 태그의 역할과 의미에 맞게 작성한다.

html 태그는 각 태그별로 담당하고 있는 역할이 있다.

예를 들면 a태그는 상호작용과 링크 이동과 같은 역할을 button 태그는 말 그대로 버튼의 역할을...

이처럼 각 태그를 사용할 때 태그가 가지고 있는 역할에 맞게 사용한다면 불필요한 ARIA 속성을 줄이고

보다 접근성 향상에 도움을 줄 것이다.

<!-- X -->
<div role="button">버튼</div>

<!-- O -->
<button>버튼</button>

- 태그의 기본 의미를 중복해서 선언할 필요는 없다.

위의 내용들과 연관 지을 수 있는 내용인데

html의 각 태그에는 기본적으로 갖고 있는 역할과 의미가 있다.

그렇기 때문에 태그의 기본 속성에 덧붙여서 속성을 중복하여 정의할 필요 없다.

<!-- O -->
<input type="checkbox">
<button>버튼</button>
<fieldset>...</fieldset>
<ul>...</ul>

<!-- X (중복선언) -->
<input type="checkbox" role="checkbox">
<button role="button">버튼</button>
<fieldset role="group">...</fieldset>
<ul role="list">...</ul>

- 페이지에서 사용하는 태그의 역할이 잘못된 ARIA를 선언하면 안된다.

<!-- X -->
<button role="heading">버튼</button>

위의 예시처럼 button의 역할을 하는 태그에 heading이라는 역할을 주게 되면

접근성에 치명적 오류를 범하게된다.

3. 태그별 role(역할)

html 각 태그별로 암묵적으로 가지고 있는 role(역할)이 있다.

그리고 각 태그별로 적용할 수 있는 역할도 있다.

HTML 태그	암묵적 기본 역할 (role="")	적용 가능한 역할 (role="")
<a href="">	role="link"	button, checkbox, menuitem, menuitemcheckbox, menuitemradio, option, radio, switch, tab
<a> (href 속성 없이)	x	어떤 role이든 적용 가능
<article>	role="article"	application, document, feed, main, none, presentation, region
<aside>	role="complementary"	feed, none, note, presentation, region, search
<header>	article, aside, main, nav, section 태그의 자손 요소이거나 role=article, complementary, main, navigation, region을 사용한 태그의 자손일 경우엔 암묵적 역할이 따로 없고 해당 요소들의 자손요소가 아닐 경우엔role="banner"이다.	group, none, presentation
<footer>	article, aside, main, nav, section 태그의 자손 요소이거나 role=article, complementary, main, navigation, region을 사용한 태그의 자손일 경우엔 암묵적 역할이 따로 없고 해당 요소돌의 자손요소가 아닐 경우엔 role="contentinfo"이다.	group, none, presentation
<section>	accessible name을 가지고 있다면 role="region" 그렇지 않다면 역할이 따로 없다.	alert, alertdialog, application, banner, complementary, contentinfo, dialog, document, feed, log, main, marquee, navigation, none, note, presentation, search, status, tabpanel
<button>	role="button"	checkbox, link, menuitem, menuitemcheckbox, menuitemradio, option, radio, switch, tab
<div>	x	어떤 role이든 적용 가능
<dl>	x	group, list, presentation, none
<dt>	role="term"	listitem
<dd>	role="definition"	x
<fieldset>	role="group"	none, presentation, radiogroup
<form>	accessible name을 가지고 있다면 role="form" 그렇지 않다면 역할이 따로 없다.	search, none, presentation
<h1> ~ <h6>	role="heading"	none, presentation, tab
<img alt="텍스트">	role="img"	button, checkbox, link, menuitem, menuitemcheckbox, menuitemradio, option, progressbar, scrollbar, separator, slider, switch, tab, treeitem
<img alt="">	x	x
<img> (alt 속성 없이)	role="img"	x
<ul>	role="list"	directory, group, listbox, menu, menubar, none, presentation, radiogroup, tablist, toolbar, tree
<ol>	role="list"
<li>	role="listitem"	menuitem, menuitemcheckbox, menuitemradio,option, none, presentation, radio, separator, tab, treeitem
<nav>	role="navigation"	menu, menubar, tablist
<svg>	role="graphics-document"	어떤 role이든 적용 가능
<input type="button">	role="button"	link, menuitem, menuitemcheckbox, menuitemradio, option, radio, switch, tab
<input type="checkbox">	role="checkbox"	button(사용할 경우 aria-pressed 함께 사용), menuitemcheckbox, option, switch
<input type="radio">	role="radio"	menuitemradio
<input type="text">	role="textbox"	combobox, searchbox, spinbutton

위의 표와 같이 각 태그는 기본적으로 가지고 있는 암묵적 role(역할)과

적용할 수 있는 role이 정해져 있다.

자세한 내용은

www.w3.org/TR/html-aria/#docconformance

에서 확인할 수 있다.

또 각 role별로 필수 속성 및 지원이 가능한 속성도 별도로 있으니

www.w3.org/TR/html-aria/#case-sensitivity

에서 확인하면서 작업하면 도움이 될 것이다.

참고

www.w3.org/TR/html-aria

www.w3.org/TR/wai-aria-practices-1.1

developers.google.com/web/fundamentals/accessibility/semantics-aria?hl=ko

'Frontend > Web' 카테고리의 다른 글

[웹접근성] 웹 접근성을 고려한 마크업 - 인식의 용이성 (대체 텍스트) (0)	2021.05.20
WAI-ARIA 접근성2. 영역에 대한 설명, 레이블 (aria-label, aria-labelledby) (0)	2021.03.27
크로스 브라우징이란? (0)	2020.09.12
SEO(검색 엔진 최적화)란? (0)	2020.04.21
웹해상도 (물리픽셀, 논리픽셀, 고밀도 해상도, PPI) (0)	2020.04.21

마크업 작업을 하다보면 크롬과 같은 주로 사용하는 브라우저에서 확인을 하다가

IE (Internet Explorer) 나 Firefox 와 같은 다른 브라우저에서 확인할 때

레이아웃이 틀어지거나 원하지 않는 화면이 표시되는 것을 볼 수 있다.

이는, 각 브라우저가 가지고 있는 렌더링 엔진이 다르기 때문이다.

이렇듯 한 브라우저에서 적용된 소스의 내용이 모든 브라우저에

동일하게 적용될 수 없는데 이렇게 각 브라우저들을 맞추기 위한 작업을

크로스 브라우징이라 한다.

이러한 크로스 브라우징을 하기 위해선 몇 가지 방법이 필요하다.

1. Reset CSS

각 브라우저별로 태그마다 주는 속성이나 속성 값들이 다 다른데

이러한 것들을 맞추기 위해 우리는 css를 초기화 해줄 필요가 있다.

즉, 모든 태그들을 동일한 조건에서 시작할 수 있게 해준다.

(ex. 각 태그별 margin, padding 0으로 초기화, ol, ul태그 list-style 초기화...)

자세한 내용은 이전에 포스팅한 Reset.css 를 참고 하면 된다.

2020/02/19 - [Frontend/CSS] - CSS Reset (초기화)

2. 브라우저별 적용되지 않는 css 속성 찾기

우리가 크로스 브라우징을 할 때,

가장 문제가 되는 브라우저는 뭐니뭐니해도 IE(Internet Explorer)일 것이다.

IE의 경우는 최신 버전이 아닌 IE8, IE9 버전 등 하위 브라우저의 경우

지원하지 않는 속성이 많이 있기 때문이다.

그렇기 때문에

can I use 와 같이 브라우저별로 지원하는 css를 찾아보고 작업하는 것이 중요하다.

caniuse.com

예를 들어 프로젝트에서 IE8 이상부터 지원하게 작업해야 한다면

transition (IE10+), transform(IE9+) 와 같은 IE8보다 상위 브라우저 부터 지원하는

css는 사용할 수 없을 것이다.

그렇기 때문에 스크립트나 이미지 파일을 사용해서 해당 기능들을 구현하는 것이

크로스 브라우징을 위해 좋은 방법으로 이용될 것이다.

저작자표시 비영리

'Frontend > Web' 카테고리의 다른 글

WAI-ARIA 접근성2. 영역에 대한 설명, 레이블 (aria-label, aria-labelledby) (0)	2021.03.27
WAI-ARIA 접근성1. 소개 및 주의사항, 태그별 role의 사용 (0)	2021.03.20
SEO(검색 엔진 최적화)란? (0)	2020.04.21
웹해상도 (물리픽셀, 논리픽셀, 고밀도 해상도, PPI) (0)	2020.04.21
브라우저 렌더링 성능 최적화 (2)	2020.04.16

SEO란 Search Engine Optimization 의 약자이며

검색 엔진 최적화를 뜻한다.

웹페이지(특히 구글)의 검색엔진이 페이지의 자료를 수집하고

해당 검색 엔진이 좋아하는 조건을 맞춰

다른 사용자들이 키워드를 검색을 했을 때 내가 작업한 페이지를 상위 배치하는 작업을 말한다.

최근에 기업에서는 마케팅과 연관지어 검색 유입을 늘리고

광고 효과를 늘리기 위해 더욱 더 많은 관심을 갖고있는 분야이다.

1. SEO(검색 엔진 최적화)의 필요성

SEO를 적용하면 뭐가 좋길래,

검색 엔진에 상위에 배치가 되면 어떤 점이 좋길래

SEO의 중요성이 점점 증가하게 되는걸까를 생각해보았다.

우선 전 세계적으로 가장 많은 사용자들이 사용하는 웹사이트인 '구글'의 예를 들면

위의 이미지와 같이 거의 모든 사용자들이

구글 검색을 해서 검색결과를 얻을 때,

1페이지에서만 머무르며 원하는 정보를 얻어가는 것을 알 수 있다.

즉, 2페이지 이후의 내용들은

사용자들의 관심을 받지 못한다.

쉽게 말하자면 '나이키 신발' 이라는 키워드를 검색했을 때,

내가 판매하는 페이지가 1페이지 이후에 있다면

많은 사용자들이 내가 판매하는 페이지를 클릭조차 안한다는 얘기가 된다.

2. SEO(검색 엔진 최적화) 적용 방법

SEO를 적용하기 위해서는 크게 6가지의 방법을 적용할 수 있다.

2-1. 보안 프로토콜 (HTTPS)

2014년 구글에선 HTTP 일반 프로토콜을 사용하는 웹 사이트보다

HTTP 일반 프로토콜에 SSL이라는 보안 프로토콜을 더한 HTTPS 보안 프로토콜을

사용하는 웹 사이트가 더 높은 점수를 받을 것이라 발표 하였다.

그리고 2017년부터는 HTTPS 보안 프로토콜로 접속하는 사이트가 아닌 경우 크롬에서

경고 문구가 노출된다.

2-2. robots.txt (로봇 배제 표준 파일), Sitemap.xml (사이트맵)

- robots.txt

robots.txt는 검색엔진 로봇들의 접근을 제어한다.

웹사이트의 사이트맵이 어디있는지 알려주고 특정 페이지를 검색엔진에 비노출 시킬때도 사용한다.

* 파일명은 robots.txt로 지정해야하고 utf-8로 인코딩 되어 있어야한다.

* 웹사이트에는 robots.txt 파일은 하나만 있어야한다.

* robots.txt 파일은 웹사이트의 루트에 있어야 한다.

예를 들어

abcdqbbq.tistory.com 아래의 모든 페이지를 제어하려면

abcdqbbq.tistory.com/robots.txt에 파일이 위치해야한다.

- Sitemap.xml 사이트맵

사이트맵은 웹사이트 내에 모든 페이지들의 목록을 나열한 파일로 책의 목차와 같은 역할을 한다.

사이트맵은 웹사이트 내의 모든 페이지들이 원활하게 크롤링되고 색인될 수 있도록 도와준다.

* 사이트맵은 어디에서나 게시할 수 있지만 게시된 위치의 하위 항목에만 영향을 주기 때문에

사이트의 루트에 게시하는 것이 좋다.

* utf-8로 인코딩 되어있어야 한다.

* 페이지가 모바일, pc 두 버전의 URL이 다르다면 사이트맵에서 한 버전에만 연결하는 것이 좋다.

하지만 두 버전 모두 연결이 필요한 경우 URL에 주석을 추가하여 모바일, pc버전을 표시해준다.

2-3. <title>, description 태그의 사용

<title> 태그는 페이지의 제목을

<head>
   <title>SEO란 무엇인가?</title>
   <meta name="description" content="SEO는 S">
</head>

두 태그 모드 <head></head>영역 안에 작성하는 태그이며

title과 meta태그의 description을 작성시엔

모든 페이지들을 똑같이 작성하는 것이 아니라

각 페이지별로 그 페이지의 특성에 맞게 작성하는 것이 중요하다.

SEO와 관련된 내용을 찾다보면

title태그와 description이 SEO와 관계없다는 내용들도 보이는데

사용자들이 검색했을 때 보여지는 제목(A영역)과 설명(B영역) 영역이기 때문에

설령 SEO와 연관이 없다고 하더라도

사용자들의 유입을 위해 효율적인 <title>, description 작성이 필요하다.

2-4. 소셜 검색엔진 최적화 메타태그 & OpenGraph

구글은 소셜 미디어를 통해 유입되는 경로나 활동 등을 분석하고 평가한다.

소셜 미디어에 얼마나 공유가 되었고 페이스북, 인스타그램과 같은 SNS를 통해

얼마나 많은 유입이 있는지를 분석한다.

그러한 분석을 통해 페이지에 점수를 준다.

그렇기 때문에 소셜 미디어 또한 SEO 적용을 하기 위해선

중요하게 고려해야할 사항이다.

소셜 미디어를 고려하기 위해선 OpenGraph 라는 정보에 대해 알아야한다.

OpenGraph 즉, 오픈그래프란 웹페이지가 소셜 미디어 혹은 오픈 그래프를 활용한

사이트로 공유될 때 사용되는 정보이다.

즉, 카톡이나 페이스북에 공유될 때 보여지는

페이지의 제목, 설명, 이미지 등을 meta태그에 담을 수 있다.

<head>
   <meta property="og:type" content="website">
   <meta property="og:title" content="페이지 제목">
   <meta property="og:description" content="페이지 설명">
   <meta property="og:image" content="./src/Main_img.png">
   <meta property="og:url" content="http://abcdqbbq.tistory.com">
</head>

2-5. 이미지 태그의 올바른 사용(alt 속성)

구글에서 이미지 검색의 비중은 해마다 높아지고 있다.

실제로 미국에서는 구글에서 이뤄지는 검색의 1/3 이상이 구글 이미지 검색으로 이루어지고 있다고 한다.

그렇기 때문에 이미지 태그의 중요성이 더욱 높아지고 있다.

특히나 예전엔 이미지 태그의 alt 속성의 경우 스크린 리더를 사용하는 사람들만을 위한,

웹 접근성만을 위한 도구로 생각했다면

요즘은 SEO를 위한 도구로도 사용이 된다.

가능하면 img태그를 사용하는 모든 영역에 alt 속성을 추가해주는 것이 좋다.

<img src="coconut.jpg" alt="코코넛 열매" />

2-6. 모바일 최적화

스마트폰이 보급되면서 모바일의 사용 비중은 나날이 증가하고 있다.

실제로 가정에 컴퓨터 없는 가정은 있어도 스마트폰이 없는 가정은 찾아보기 힘들 정도이다.

그렇기 때문에 모바일 최적화 또한 중요한 SEO 적용 요소로 부각되고있다.

모바일 최적화를 하기 위해서는

반응형 웹사이트를 만들어서 하나의 페이지에서 하나의 소스로

검색 엔진을 최적화 해주는 것이 좋다. (하나의 사이트맵 사용 등...)

부득이하게 PC와 모바일 버전을 분리해서 페이지를 만들어야 할 경우

Canonical 및 Alternate 태그를 사용하여

PC와 모바일 버전의 관계를 확실하게 표시해주는 것이 필요하다.

/* PC 페이지 */
<head>
  <link rel="alternate" media="only screen and (max-width:640px)" href="https://m.abcdqbbq.com">
</head>


/* Mobile 페이지 */
<head>
  <link rel="canonical" href="https://www.abcdqbbq.com">
</head>

* 구글 모바일 친화성 테스트

https://search.google.com/test/mobile-friendly

참고

https://www.twinword.co.kr/blog/search-engine-optimization-guide/

https://junhobaik.github.io/meta-tag/

저작자표시 비영리

'Frontend > Web' 카테고리의 다른 글

WAI-ARIA 접근성1. 소개 및 주의사항, 태그별 role의 사용 (0)	2021.03.20
크로스 브라우징이란? (0)	2020.09.12
웹해상도 (물리픽셀, 논리픽셀, 고밀도 해상도, PPI) (0)	2020.04.21
브라우저 렌더링 성능 최적화 (2)	2020.04.16
XML과 HTML (0)	2020.04.14

모바일 UI개발을 하다보면

아이폰5 기준(320px)으로 작업을 하게되는 경우

보통 디자인 파일은 320px의 2배인 640px로 받아서 작업을 진행하게 된다.

단순히 2배 혹은 3배의 이미지를 받아오기 위해

원래의 화면 크기보다 큰 디자인으로 받아서 작업을 한다는 생각을 해보기 전

해상도에 대해 알아볼 필요가 있다.

1. 고밀도 해상도

모바일 뿐만 아니라 태블릿, 데스크탑까지 구분 없이 작은 크기의 영역(디바이스)에

높은 밀도의 해상도를 가진 화면을 말한다.

애플에서 사용한 레티나 디스플레이부터 보편화되기 시작하였다.

2. PPI란?

Pixel per inch의 약자로 1인치당 몇 개의 픽셀로 이뤄졌는지를 나타내는 밀도의 단위이다.

(ppi는 일반적인 디바이스나 화면에서, dpi는 인쇄물에서 주로 사용)

10PPI면 정사각형 한 면 (1inch, 2.54cm)에 10개의 픽셀이 있고

가로 세로 10px을 곱하게 되면 총 100px로 이루어져 있다는 뜻이 된다.

위의 이미지에서 살펴보면 10ppi 보다 20ppi가 훨씬 밀도가 높고

높은 해상도를 자랑하는 것을 볼 수 있다.

그리고 화면이 작은 기기일수록

더 높은 밀도의 해상도를 통해 선명한 화면을 구현한다.

3. 물리픽셀과 논리픽셀

고밀도 해상도의 간단한 예로 아이폰 4를 예시로 들자면

아이폰 4가 구현하는 해상도는 640*960 이고, (물리 픽셀)

CSS로 표현할 수 있는 값은 320*480이다. (논리 픽셀)

즉, CSS로 구현하는 화면은 320px이지만

실제 해상도는 640px로 2배의 밀도를 가지게 된다. (ratio 2)

만약 아이폰4에 디자인 작업을 할 때 320px의 디자인 파일을 받아서 작업을 하게 된다면,

640px의 해상도 화면에 320px의 디자인이 적용되기 때문에

이미지를 늘여 놓은 것과 같은 뿌연 화면이 나타나게 된다.

그렇기 때문에 우리가 모바일 작업을 할 때

물리 픽셀에 맞춘 디자인으로 작업을 하게 되는 것이다.

그리고 우리가 논리픽셀을 적용하기 위한 수단으로

우리는 meta태그의 viewport 속성을 이용한다.

<meta name=“viewport” content=“width=device-width”>

저작자표시 비영리

'Frontend > Web' 카테고리의 다른 글

크로스 브라우징이란? (0)	2020.09.12
SEO(검색 엔진 최적화)란? (0)	2020.04.21
브라우저 렌더링 성능 최적화 (2)	2020.04.16
XML과 HTML (0)	2020.04.14
URI vs URL 비교 (0)	2020.04.10

2020/04/09 - [Web] - 브라우저 렌더링

브라우저 렌더링에 대해서 알아본 후에

브라우저가 렌더링 되는 과정이 조금 더 빠르게 만들고

그로인해 사용자들의 편의성이나 페이지 유입을 늘리기 위해서

브라우저 렌더링을 최적화 하는 방법은 뭐가 있을지에 대해 알아보았다.

1. Reflow, Repainting

맨 처음 브라우저가 로딩될 때 렌더링 과정을 통해 화면이 그려진다.

그리고 그려진 화면은 자바스크립트에 의해 DOM 트리, CSSOM 트리가 변경될 때 재구성 된다.

DOM이 추가/삭제 되거나 DOM 요소에 높이, 너비, 위치 등의

기하학적 영향을 주는 CSS 내용이 변경될 경우에 렌더 트리가 재구성 되는데

이것을 Reflow(리플로우) 혹은 재배치라고 한다.

리플로우는 요소에 기하학적인 영향을 주는 CSS가 변경 되었을 때 발생하는데

반대로 기하학적 영향을 주지 않는 CSS 속성이 변경되었을 경우는 리플로우 과정을 건너뛰고

Paint 과정부터 수행한다. 이를 Repaint(리페인트)라고 한다.

리플로우가 일어나면 전체 픽셀을 다시 계산하는 과정을 거치기 때문에 부하가 크지만,

리페인트는 재배치 과정을 건너뛰고 화면에 그리는 작업만 수행하기 때문에 부하가 적다.

* 리플로우가 되는 CSS 속성 : top, left, right, bottom, width, height, line-height, font-size 등
* 리플로우 건너뛰고 리페인트 되는 CSS 속성 : background-image, color, visibility, outline 등

- 참고
https://docs.google.com/spreadsheets/u/0/d/1Hvi0nu2wG3oQ51XRHtMv-A_ZlidnwUYwgQsPQUg1R2s/pub?single=true&gid=0&output=html

리플로우와 리페인팅이 일어나면 렌더링 시간이 늘어나게 된다.

그렇기 때문에 불필요한 리플로우와 리페인팅을 없애기 위해 신경써야한다.

2. 렌더링 최적화 (로딩 최적화)

위에서 살펴본바와 같이

리플로우, 리페인팅으로 인한 초기 로딩 후에 렌더링 시간 지연이 있고

페이지에 진입했을 때 초기 로딩이 지연되는 경우가 있다.

이런 초기 로딩의 속도를 높이기 위해서 고려해야할 점들이 있다.

1. 블록 리소스 최적화

블록 리소스란 HTML이 파싱될 때 CSS나 자바스크립트로 인해 파싱이 중단되는 경우가 있다.
이렇게 HTML의 파싱을 막는 CSS나 자바스크립트의 리소스를 블록 리소스라고 한다.

css 최적화

렌더 트리를 구성하기 위해서는 DOM 트리와 CSSOM 트리가 필요하다.

DOM 트리는 파싱 중에 태그를 발견할 때마다 순차적으로 구성을 하지만

CSSOM 트리는 CSS를 모두 해석해야 다음 순서로 넘어가게 된다.

즉, CSSOM 트리가 모두 해석되지 않고 구성되지 않으면 렌더트리를 끝까지 만들지 못하고

렌더링이 차단된다.

이러한 이유로 CSS를 렌더링 차단 리소스라고 하고

렌더링이 차단되지 않도록 CSS는 가능하면 항상 HTML문서 최상단인 <head> 태그 안쪽에 배치해야한다.

<html>
   <head>
      <link rel="stylesheet" href="style.css">
   </head>
</html>

그리고 외부 스타일 시트를 가져올 경우 @import 사용은 피하고

link 태그를 사용하여 CSS를 불러와서 CSS 로드 속도를 줄여야한다.

(@import 사용시 직렬 로드를 하기 때문에 속도가 느리다.)

2020/03/03 - [CSS] - CSS 적용을 위한 또 다른 방법, @import

또한, 특정한 경우에서만 사용하는 CSS를 넣을 경우

미디어 쿼리를 사용하여 CSS를 분리해서 필요할 때만 로드될 수 있도록 한다.

<link rel="stylesheet" href="main.css">
<!-- 인쇄할 경우 -->
<link rel="stylesheet" href="main_print.css" media="print">
<!-- 세로모드일 경우 -->
<link rel="stylesheet" href="main_portrait.css" media="orientation:portrait">

자바스크립트 최적화

자바스크립트는 DOM 트리와 CSSOM 트리를 동적으로 제어하고 변경할 수 있기 때문에

블록 리소스에 해당한다.

그리고 스크립트가 실행될 동안에는 DOM 트리 생성은 중단된다.

그렇기 때문에 <script> 태그는 모든 DOM 요소가 생성된 이후에 가져오는 것이

블록 리소스를 최소화하는 좋은 방법이다.

(HTML 문서 최 하단 </body> 태그 직전에 배치)

<body>
   <div>test</div>
   <p>test desc</p>
   
   <script type="text/javascript" src="src.js"></script>
</body>

2. 리소스 요청 수 줄이기

CSS, 자바스크립트, 이미지 등의 리소스는 서버 요청 후 다운로드 되어야 사용할 수 있다.

특히나 이미지 파일은 용량도 크고 무겁기 때문에 이미지 로드에 많은 시간이 소비된다.

그렇기 때문에 페이지 로드시 필요한 이미지만 요청해서 가져올 수 있도록 최적화를 해야한다.

이미지 스프라이트

여러개의 아이콘 파일을 필요한 페이지에 각각 로드를 하게 된다면

아이콘 파일의 수 만큼 이미지 리소스를 불러와야 할 것이다.

그렇기 때문에 사용 용도에 맞게 아이콘들을 하나의 이미지로 합쳐서 만드는

이미지 스프라이트를 사용하게되면 여러번 불러와야 할 이미지들을

한 번만 불러와서 이미지 요청을 최소화 할 수 있다.

예시) 각각 처리할 수 있는 sns 아이콘을 하나의 이미지 파일로 합쳐서 관리한다.

/* background-position 값을 이용하여 이미지 위치 표현 */
.facebook{background:url(./ic_sns.png) -150px 0 no-repeat; width:150px; height:150px;}

3. 리소스 용량 줄이기

중복되는 코드 줄이기

자바스크립트에서 자주 사용하는 내용에 대해서 함수처리하여

중복되는 내용을 최소화 한다.

HTML 마크업 최적화

HTML 태그의 중첩을 최소화 하고 (HTML의 depth가 깊어지면 렌더링 속도에 영향을 준다.)

공백 주석 등도 최소화 하여 작업한다.

불필요한 마크업 사용을 자제하여 DOM 트리가 커지는 것을 방지하는 것이 좋다.

간결한 CSS 선택자 사용

CSS 스타일을 적용할 때 반복되고 공통되는 스타일은 클래스를 사용하여

다른 선택자의 사용을 최소화 한다.

<수정 전>

<head>
   <style>
      .text01{padding:10px; font-size:13px; color:#ddd; font-weight:bold;}
      .text02{padding:10px; font-size:13px; color:#333; font-weight:bold;}
   </style>
</head>
<body>
   <p class="text01">test용 텍스트</p>
   <div>
      <p class="text02">안녕하세요 Olleh</p>
   </div>
</body>

<수정 후> - 공통되는 내용을 .text 클래스에 담아서 반복되는 css 스타일을 최소화 하였다.

<head>
   <style>
      .text{padding:10px; font-size:13px; font-weight:bold;}
      .text01{color:#ddd;}
      .text02{color:#333;}
   </style>
</head>
<body>
   <p class="text text01">test용 텍스트</p>
   <div>
      <p class="text text02">안녕하세요 Olleh</p>
   </div>
</body>

display:none 속성 사용

display:none 속성을 사용해서 요소를 숨겨버리면 DOM 트리에는 반영이 되지만 렌더트리에는 반영되지 않아서 리플로우나 리페인팅도 발생하지 않는다.

초기 로딩에서 css를 적용해서 렌더트리에 반영이 필요하지 않는 영역의 경우 display:none으로 숨겨서 노출을 하는 것도 로딩 속도 향상을 위한 방법 중에 하나이다.

(visibility:hidden 속성으로 숨긴 영역은 렌더트리 구성에 포함이 된다.)

** 참고 **

https://ui.toast.com/fe-guide/ko_PERFORMANCE/

성능 최적화

애플리케이션 성능 최적화는 앱과 웹에서 모두 중요하다. 최근 웹 애플리케이션은 Ajax 통신, 복잡한 UI 등 많은 기능을 담으면서 크고 무거워졌다. 무거워진 웹은 긴 로딩 시간 함께 사용자 경험에 안 좋은 영향을 끼친다. Pinterest는 긴 로딩 시간으로 인해 사용자가 페이지를 나가는 비율이 높았는데, 최적화를 통해 사용자 이탈률을 줄이고 매출은 40%로 증가시켰다. 이처럼 매출 실적과 연결될 정도로 웹 애플리케이션의 성능 최적화는 매우 중요하다.

ui.toast.com

저작자표시 비영리

'Frontend > Web' 카테고리의 다른 글

SEO(검색 엔진 최적화)란? (0)	2020.04.21
웹해상도 (물리픽셀, 논리픽셀, 고밀도 해상도, PPI) (0)	2020.04.21
XML과 HTML (0)	2020.04.14
URI vs URL 비교 (0)	2020.04.10
브라우저 렌더링 (0)	2020.04.09

XML과 HTML을 비교하기에 앞서 XML의 특징을 확인해봐야 할 것이다.

1. XML이란

XML은 Extensible Markup Language 의 약자로 W3C 권고 범용 마크업 언어이다.

* XML의 특징

- XML은 다른 목적의 마크업 언어를 만드는데 사용되는 다목적 마크업 언어이다.

- XML은 다른 시스템끼리 다양한 종류의 데이터를 손쉽게 교환할 수 있도록 해준다.

- XML은 새로운 태그를 만들어 추가해도 계속해서 동작하므로 확장성이 좋다.

- XML은 데이터를 보여주지 않고 데이터를 전달하고 저장하는 것만을 목적으로 한다.

- XML은 텍스트 데이터 형식의 언어로 모든 XML 문서는 유니코드 문자로만 이루어진다.

- XML은 SGML을 기반으로 만들어졌다.

- XHTML, MathML, SVG, RSS, RDF 등이 XML을 기반으로 만들어 졌다.

2. XML과 HTML의 차이

2-1. HTML은 데이터의 표현에 목적, XML은 데이터 교환을 위한 구조 정의에 목적

앞서 살펴본 XML 특징 중 하나인 데이터를 전달하고 저장하는 것만을 목적으로 한다는 점에서

생각해본다면 HTML의 차이를 생각할 수 있다.

2-2. HTML은 정해진 태그의 틀이 있다면 XML은 사용자가 태그를 직접 정의해서 사용

HTML은 html태그 안에 head태그, body태그가 있고

head 태그안에 title태그, meta태그를 사용하는 등 각 태그가 미리 정해진 형식에 따라 사용하고

각 태그마다의 의미도 정해져 있다면

XML태그는 사용자가 직접 태그명을 만들어서 필요에 맞춰 사용한다.

<!-- HTML -->
<html>
   <head>
      <title>abcdqbbq의 Tistory</title>
      <meta charset="utf-8">
   </head>
   <body>
      <div>
         <h1>학생이름</h1>
         <p>주소</p>
         <span>나이</span>
      </div>
   </body>
</html>


<!-- XML -->
<student>
   <name>학생이름</name>
   <addr>주소</addr>
   <age>나이</age>
</student>

2-3. HTML은 웹 환경에서만 작동되는 언어, XML은 어떤 환경에도 구애 받지 않는 언어

HTML은 웹브라우저라는 환경에서만 사용할 수 있고

XML의 경우 다목적 마크업 언어이므로 특정 어플리케이션에 종속되지 않고 사용할 수 있다.

2-4. HTML은 데이터 + 데이터 표현, XML은 데이터만 갖고있는 언어

HTML은 가지고 있는 데이터를 웹브라우저 환경에서 표현하고 나타낼 수 있지만

XML은 가지고 있는 데이터를 전달하고 저장하는게 목적인 언어이기 때문에

별도의 브라우저나 어플리케이션 환경에서 데이터를 표현하진 않는다.

참조 페이지

http://tcpschool.com/xml/xml_intro_basic

https://www.crocus.co.kr/1493

https://www.w3schools.com/xml/xml_whatis.asp

저작자표시 비영리

'Frontend > Web' 카테고리의 다른 글

SEO(검색 엔진 최적화)란? (0)	2020.04.21
웹해상도 (물리픽셀, 논리픽셀, 고밀도 해상도, PPI) (0)	2020.04.21
브라우저 렌더링 성능 최적화 (2)	2020.04.16
URI vs URL 비교 (0)	2020.04.10
브라우저 렌더링 (0)	2020.04.09

작업을 하면서 URL이라는 얘기는 많이 들어봤지만

URI에 대해서는 들어볼 기회가 없었다.

URI에 대해 알아보면서 URN이란 개념도 같이 알아보았다.

1. URI (Uniform Resource Identifier)

통합 자원 식별자라는 뜻을 가진 개념으로

인터넷에 있는 자원을 나타내는 유일한 주소를 말한다.

URI의 개념 안에는 URL과 URN이 포함된다.

2. URL (Uniform Resource Locator)

자원,

웹사이트 서버들에 있는 파일의 위치(리소스의 위치)

URI의 개념에 포함된다.

3. URI와 URL의 차이

위의 정의된 내용만 보면 어떤 얘기인지 감지 잡히지 않는다.

예시를 들어 둘의 차이를 설명하자면

URI : https://abcdqbbq.tistory.com/3?category=843598

URL(URI이자 URL) : https://abcdqbbq.tistory.com/3

위의 예시를 보면

?category=843598 이라는 식별자를 포함하고 있기 때문에

유일한 주소가 되고 URI에 해당한다.

그리고,

식별자 이전까지인 주소의 위치가 URL의 개념에 포함된다.

4. URN (Uniform Resource Name)

URI에 포함되는 개념으로

URL이 주소의 위치를 가지고 있다면

URN은 위치와 관계없이 리소스의 이름값만을 이용해서 접근하는 방식이다.

예를들면

https://abcdqbbq.tistory.com/category/1 의 위치에서

https://abcdqbbq.tistory.com/1 의 위치로 실제 파일이 위치 이동을 하게 된다면

위의 category/1 의 url을 알고 있던 사람들은 기존의 주소로 접근할 수 없을 것이다.

하지만 URN으로 적용을하면 위치 기준이 아닌 이름값 기준으로 접근하기 때문에

그러한 문제가 해결된다.

저작자표시 비영리

'Frontend > Web' 카테고리의 다른 글

SEO(검색 엔진 최적화)란? (0)	2020.04.21
웹해상도 (물리픽셀, 논리픽셀, 고밀도 해상도, PPI) (0)	2020.04.21
브라우저 렌더링 성능 최적화 (2)	2020.04.16
XML과 HTML (0)	2020.04.14
브라우저 렌더링 (0)	2020.04.09

Internet Explorer(IE), Chrome, FireFox, Safari, Opera 등 많은 브라우저가 존재한다.

이렇게 많은 브라우저들이 사용자들에게 페이지나 콘텐츠들을 어떻게 보여주는 지에 대해

알아보려고 한다.

1. 브라우저의 주요 기능

브라우저는 사용자가 URI에 입력하고 요청(request)한 내용을 보여준다.

그리고 브라우저는 HTML과 CSS 기본 명세에 따라 각 파일을 해석하고 표시하는데

이 명세는 웹 표준화 기구인 W3C의 기준을 따른다.

2. 브라우저의 기본구조

브라우저 렌더링을 알아보기 전 먼저 브라우저의 기본 구조에 대해 알아봐야한다.

1. 사용자 인터페이스 : 주소 표시줄, 이전/다음 버튼, 북마크 메뉴 등 요청한 페이지 창을 제외한 나머지 부분.

2. 브라우저 엔진 : 사용자 인터페이스와 렌더링 엔진 사이에서 동작을 제어.

3. 렌더링 엔진 : HTML을 요청하면 HTML, CSS를 파싱하여 화면에 나타내는 등의 사용자가 요청한 내용을 표시.

4. 통신 : HTTP 요청과 같은 네트워크 호출에 사용.

5. UI 백엔드 : 콤보 박스와 창 같이 기본적인 장치를 그림.

6. 자바스크립트 해석기 : 자바스크립트 코드를 해석하고 실행.

7. 자료 저장소 : 쿠키를 비롯한 모든 종류의 자원 및 자료를 하드 디스크에 저장할 수 있는 저장소이다.

*크롬(chrome)은 대부분의 브라우저와 달리 각 탭별로 독립된 프로세스로 처리된다

3. 렌더링 엔진 동작 과정

앞서 살펴본바와 같이 렌더링 엔진은

사용자에게 요청 받은 내용을 브라우저에 표시하는 역할을 한다.

렌더링 엔진은 크게

웹킷(Webkit) 엔진과 게코(Gecko) 엔진이 있는데

웹킷은 사파리와 크롬, 게코는 파이어폭스 브라우저에서 사용된다.

(*크롬의 경우 웹킷에서 블링크(Blink) 엔진으로 변경되었다.)

렌더링 엔진의 동작 순서를 살펴보자면

1. DOM 트리 구축을 위한 HTML 파싱

서버로 부터 HTML 문서를 받아서 파싱하고 컨텐츠 트리 내부에서 태그를 DOM 노드로 변환한다.

그리고 CSS 파일도 받아서 CSSOM(CSS Object Model)로 변환한다.

그 후에 DOM Tree와 CSSOM Tree를 이용하여 렌더 트리라는 또 다른 트리를 생성한다.

2. 렌더 트리 구축(생성)

HTML과 CSS를 파싱해서 만들어진 렌더 트리는 색상 또는 면적 등의

시각적 속성이 있는 사각형을 포함하고 있고 정해진 순서대로 렌더링하게 된다.

순수한 요소들의 구조와 텍스트만 존재하는 DOM Tree와는 다르게 렌더 트리(Render Tree)에는 스타일 정보가 설정되어 있고

실제 화면에 표현되는 노드들로만 구성이 된다.

* 실제 화면에 표현되는 노드들로만 구성이 된다는 말은 display:none 속성이 설정된 노드와 같이 어떠한 공간도 차지하지 않고 보여지지 않는 노드들은 렌더 트리에서 제외된다는 것을 말한다.

(단, visibility:hidden 과 같이 공간은 차지하지만 내용만 숨겨줄 경우 렌더 트리를 그릴 때 포함이 된다.)

3. 렌더 트리 배치(Layout)

렌더 트리 구축이 끝난 뒤에 렌더 트리 배치가 시작되는데

이것은 브라우저의 뷰포트(Viewport) 내에서 각 노드를 정확한 위치에 표시되는 것을 의미한다.

4. 렌더 트리 그리기(Paint)

배치가 완료된 렌더 트리를 UI 백엔드에서 각 노드를 가로지르며 그리기 작업을 진행한다.

이전 단계에서 요소들의 위치나 크기, 스타일 계산이 완료된 렌더 트리를 이용해

실제 픽셀 값을 채워넣게 된다.

이 때, 텍스트, 색, 이미지, 그림자 효과 등이 모두 처리된다.

그리고 처리해야 하는 스타일이 복잡할수록 paint 과정에서 소요되는 시간은 늘어난다.

예를 들어, 단순히 color값을 변경하는 속성보다 text-shadow나 그라데이션 효과가

painting 과정이 더 오래 걸린다.

위와 같은 과정을 진행하면서

렌더링 엔진은 좀 더 나은 사용자 경험을 위해 최대한 빠르게 내용을 표시하게 되는데

모든 HTML을 파싱할 때까지 기다리지 않고 배치와 그리기 과정을 시작한다.

네트워크로부터 나머지 내용이 전송되기를 기다리는 동시에

받은 내용의 일부를 화면에 먼저 표시한다.

- webkit의 동작 과정

- Gecko의 동작 과정

Webkit(웹킷)과 Gecko(게코)에서 사용하는 용어들은 조금씩 다르지만

동작 과정은 기본적으로 동일하다.

- Webkit은 시각적으로 처리되는 렌더를 렌더트리라고 표현하고 각 요소를 렌더 객체로 표현

- Gecko는 형상 트리라고 표현하고 각 요소를 형상이라고 지칭한다.

- Webkit에서는 요소를 배치하는데 배치라는 용어를 사용하지만

- Gecko는 리플로우 라는 용어를 사용한다.

- Webkit은 HTML과 CSS를 각각 파싱한 자료를 합쳐서 렌더 트리를 생성하는 작업을 어테치먼트라고 표현

- Gecko는 형상 구축이라 표현한다.

- Webkit은 HTML과 Stylesheet를 처음부터 분리하여 작업

- Gecko는 HTML을 최초로 호출하고 콘텐츠 싱크 과정을 두어 Stylesheet를 분리해서 작업한다.

* 위의 과정의 차이는 DOM 요소를 생성하는 과정으로 크게 의미있는 차이라고 보지 않는다.

참고

https://d2.naver.com/helloworld/59361

https://vallista.kr/2019/05/06/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-%EB%A0%8C%EB%8D%94%EB%A7%81-%EA%B3%BC%EC%A0%95/

저작자표시 비영리

'Frontend > Web' 카테고리의 다른 글

SEO(검색 엔진 최적화)란? (0)	2020.04.21
웹해상도 (물리픽셀, 논리픽셀, 고밀도 해상도, PPI) (0)	2020.04.21
브라우저 렌더링 성능 최적화 (2)	2020.04.16
XML과 HTML (0)	2020.04.14
URI vs URL 비교 (0)	2020.04.10

Frontend/Web

1. 유튜브 주소에 따른 썸네일 가져오기

2. 썸네일 상하 여백 잘라서 가져오기 (mqdefault, maxdefault)

3. 정리

'Frontend > Web' 카테고리의 다른 글

1. 스킵 네비게이션(skip navigation)

2. 스킵 네비게이션의 활용

3. 스킵 네비게이션 스타일

4. 스킵 네비게이션 사용시 주의사항

'Frontend > Web' 카테고리의 다른 글

1. 인식의 용이성

2. 대체 텍스트 특징

3. 대체 텍스트를 제공하지 않거나 제한적으로 제공하는 경우

'Frontend > Web' 카테고리의 다른 글

1. aria-label

2. aria-labelledby

'Frontend > Web' 카테고리의 다른 글

1. WAI-ARIA 란?

2. WAI-ARIA 사용시 주의사항

3. 태그별 role(역할)

'Frontend > Web' 카테고리의 다른 글

1. Reset CSS

2. 브라우저별 적용되지 않는 css 속성 찾기

'Frontend > Web' 카테고리의 다른 글

1. SEO(검색 엔진 최적화)의 필요성

2. SEO(검색 엔진 최적화) 적용 방법

2-1. 보안 프로토콜 (HTTPS)

2-2. robots.txt (로봇 배제 표준 파일), Sitemap.xml (사이트맵)

2-3. <title>, description 태그의 사용

2-4. 소셜 검색엔진 최적화 메타태그 & OpenGraph

2-5. 이미지 태그의 올바른 사용(alt 속성)

2-6. 모바일 최적화

'Frontend > Web' 카테고리의 다른 글

1. 고밀도 해상도

2. PPI란?

3. 물리픽셀과 논리픽셀

'Frontend > Web' 카테고리의 다른 글

1. Reflow, Repainting

2. 렌더링 최적화 (로딩 최적화)

'Frontend > Web' 카테고리의 다른 글

1. XML이란

* XML의 특징

2. XML과 HTML의 차이

2-1. HTML은 데이터의 표현에 목적, XML은 데이터 교환을 위한 구조 정의에 목적

2-2. HTML은 정해진 태그의 틀이 있다면 XML은 사용자가 태그를 직접 정의해서 사용

2-3. HTML은 웹 환경에서만 작동되는 언어, XML은 어떤 환경에도 구애 받지 않는 언어

2-4. HTML은 데이터 + 데이터 표현, XML은 데이터만 갖고있는 언어

'Frontend > Web' 카테고리의 다른 글

1. URI (Uniform Resource Identifier)

2. URL (Uniform Resource Locator)

3. URI와 URL의 차이

4. URN (Uniform Resource Name)

'Frontend > Web' 카테고리의 다른 글

1. 브라우저의 주요 기능

2. 브라우저의 기본구조

3. 렌더링 엔진 동작 과정

'Frontend > Web' 카테고리의 다른 글

티스토리툴바