웹 표준 검사 항목

CSS, HTML, JavaScript, Quotes, Web Accessibility, Web Standards 댓글 달기

웹 표준 – 단지 ‘테이블 없는 사이트’ 그 이상

웹 표준이란 말은 사람마다 다른 뜻을 지닐 수도 있다. 어떤 이들에게 이것은 ‘테이블을 안 쓰는 사이트’일 수도 있고, 또 다른 이들에게는 ‘표준에 맞는 코드를 사용하는 것’일 수도 있다. 하지만, 웹 표준이란 이런 것들보단 훨씬 더 광범위한 뜻을 내포하고 있다. 웹 표준에 맞게 제작된 사이트는 표준(HTML, XHTML, XML, CSS, XSLT, DOM, MathML, SVG 등)을 준수해야 하며 그에 따른 올바른 용례들(표준을 준수하는 코드, 접근이 쉬운 코드, 의미 구조론적으로 올바른 코드, 알아보기 쉬운 URLs 등)이 적용되어야 한다.

한 마디로, 웹 표준에 맞게 제작된 사이트란 군더더기 없고, 깨끗하며, CSS 기반에, 접근이 쉽고, 사용하기 쉬우며, 검색 엔진들이 색인하기에도 쉬운 사이트를 말한다.

이 검사 항목의 쓰임새

이 검사 항목은 절대로 완벽한 것이라고 말할 수는 없으며, 아마도 이것 이외의 더 많은 항목들이 더해질 수도 있을 것이다. 또 한 가지 중요한 것은, 이 항목들이 모든 웹 사이트들을 개발하는데 꼭 적용되어야만 하는 것이라고는 할 수 없으며, 단지 단순하게 아래에 얘기된 경우들에서 손쉽게 참고해 볼 수 있는 안내서 정도로 사용됐으면 한다:

  • 웹 표준이라는 광범위한 주제에 대해서 알아보기 위해
  • 웹 사이트를 개발할 때, 개발자들한테 손쉬운 참고가 되기 위해
  • 이제 막 웹 표준에 맞는 사이트로의 전환을 고려중인 개발자들을 위한 좋은 지침서

검사 항목들

  1. 코드의 품질
    1. 사이트는 올바른 Doctype을 사용하고 있는가?
    2. 사이트는 Character set을 포함하고 있는가?
    3. 사이트는 표준을 준수하는 (X)HTML을 사용하고 있는가?
    4. 사이트는 표준을 준수하는 CSS를 사용하고 있는가?
    5. 사이트는 어떠한 변형된 CSS 속임수를 사용하고 있는가?
    6. 사이트는 필요없는 class들이나 id들을 쓰고 있지는 않은가?
    7. 코드는 구조적으로 잘 구성되어 있는가?
    8. 사이트에 깨진 연결고리(link)는 없는가?
    9. 사이트는 속도/페이지 크기에 비추어서 어떠한 성능을 보여주는가?
    10. 사이트에 JavaScript 오류는 없는가?
  2. 내용과 정보 전달 방식이 분리되어 있는 정도
    1. 사이트는 정보 전달을 위한 모든 표현 형식들(글꼴, 색깔, 여백, 테두리 등)을 위해 CSS를 사용하고 있는가?
    2. 치장을 위한 모든 그림들은 CSS에 정의되어 있는가, 아니면 (X)HTML 안에 나타나 있는가?
  3. 사용자들을 위한 접근 용이성
    1. 모든 설명 그림들에 “alt” 속성값들이 제대로 주어져 있는가?
    2. 사이트의 글자 크기를 지정하는데 절대 단위 대신에 상대 단위를 쓰고 있는가?
    3. 글꼴 크기가 커지면 전체 페이지의 배치 구조가 변하지는 않는가?
    4. 사이트는 눈에 보이는 건너뜀 메뉴를 제공하고 있는가?
    5. 사이트는 접근이 쉬운 form들을 사용하고 있는가?
    6. 사이트는 접근이 쉬운 table들을 사용하고 있는가?
    7. 색깔의 밝기와 대비는 충분한가?
    8. 중요한 정보가 색깔에만 의존해서 전달되지는 않는가?
    9. 누르면 흘러내려서(dropdown) 보여지는 메뉴들이 (저하된 운동 능력을 가지고 있는 사용자들을 위해) 약간 지연된 반등속도를 보이는가?
    10. 모든 연결고리가 (시각 장애인들을 위해) 연결될 페이지의 내용을 설명해주는 이름으로 되어 있는가?
  4. 장치들을 위한 접근 용이성
    1. 사이트는 현재와 예전 브라우저를 망라해서 비교적 수월하게 접근할 수 있는가?
    2. 사이트의 내용은 CSS를 끄거나 혹은 지원되지 않은 상태에서 접근 가능한가?
    3. 사이트의 내용은 그림을 표시하지 않거나 지원되지 않은 상태에서도 접근 가능한가?
    4. 사이트는 Lynx와 같은 글자 브라우저에서도 잘 작동하는가?
    5. 사이트의 내용은 보기 편하게 인쇄될 수 있는가?
    6. 사이트는 휴대 장비들에서도 잘 보여지는가?
    7. 사이트는 자세한 metadata를 갖고 있는가?
    8. 사이트는 여러 크기의 브라우저 창에서도 잘 작동하는가?
  5. 기본적인 접근 용이성
    1. 명확한 가시적 계층구조를 가지고 있는가?
    2. 머릿말 단계들은 구별이 쉽도록 되어 있는가?
    3. 사이트는 쉽게 이해할 수 있는 이동 수단을 가지고 있는가?
    4. 사이트는 일관성 있는 이동 수단을 사용하고 있는가?
    5. 연결고리엔 밑줄이 그어져 있는가?
    6. 사이트의 내용은 일관성 있고 적절한 언어를 구사하고 있는가?
    7. 사이트 지도 페이지와 연락처 페이지는 있는가? 그리고 쉽게 찿을 수는 있는가?
    8. 큰 사이트일 경우, 검색 기능은 있는가?
    9. 사이트의 매 페이지들마다 첫 페이지로 이동할 수 있는 연결고리는 있는가?
    10. 방문했던 페이지들은 독자적인 색깔로 정의되어서 구별하기 쉬운가?
  6. 사이트 관리
    1. 사이트는 알기 쉽고 도움이 될 만한 404 오류 페이지를 가지고 있으며 사이트의 어느 곳에서라도 쓰일 수 있는가?
    2. 사이트는 알기 쉬운 URL들을 사용하는가?
    3. 사이트의 URL들은 “www” 없이도 잘 작동하는가?
    4. 사이트는 favicon을 가지고 있는가?

1. 코드의 품질

1.1 사이트는 올바른 Doctype을 사용하고 있는가?

Doctype(‘document type declaration’의 줄인 말)은 Vaildator에게 무슨 버전의 (X)HTML을 사용하고 있는지를 알려주며, 모든 웹 페이지들의 맨 위에 선언되어 있어야 합니다. Docktype은 모든 웹 페이지에 포함되어야 할 중요한 구성 요소이고, 그래서 이것이 없으면 웹 페이지와 CSS는 표준 인가를 받을 수 없습니다.
http://www.alistapart.com/articles/doctype/

더 자세히:

1.2 사이트는 Character set을 포함하고 있는가?

만약 user agent(예. 브라우저)가 웹 문서에 사용된 글자 인코딩을 못 찾을 경우, 사용자는 읽을 수 없는 글자들로 채워진 웹 문서를 보게 됩니다. 이 정보는 특히 다국어 사이트를 운영하는 곳에서도 아주 중요한 것이겠지만, 문서에 글자 인코딩을 선언해 놓는 것은 XHTML/HTML 혹은 CSS를 작성하는 이들에게도 잊지 말야야 할 항목입니다.
Tutorial: Character sets & encodings in XHTML, HTML and CSS

더 자세히:

1.3 사이트는 표준을 준수하는 (X)HTML을 사용하고 있는가?

표준을 준수하는 코드는 오류를 일으키는 코드보다는 더 빨리 실행됩니다. 표준을 준수하는 코드는 그렇지 않은 코드보다도 페이지를 더 멋지게 보여줍니다. 요새는 점점 더 많은 브라우저들이 표준을 지원하고 있으며, 이러한 이유로 올바르고 표준을 준수하는 HTML 코드를 작성하는 필요성은 더욱 늘어가고 있습니다.
What is valid code

더 자세히:

1.4 사이트는 표준을 준수하는 CSS를 사용하고 있는가?

작성한 HTML 혹은 CSS에는 어떠한 오류도 없어야 하며, 이것은 오류로 말미암아 문서가 보기 흉하게 표시되는 부작용을 피할 수 있게 합니다.
Help! My CSS Isn’t Working!

더 자세히:

1.5 사이트는 어떠한 변형된 CSS 속임수를 사용하고 있는가?

기본적으로, 이 속임수는 개인 취향에 따라 다르겠지만, 얻고자 하는 특정 디자인을 위해서는 때론 어느 정도의 차선책들이 사용될 수도 있습니다.
Standard Hacks?

더 자세히:

1.6 사이트는 필요없는 class들이나 id들을 쓰고 있지는 않은가?

나는 종종 개발자들이 새로운 기술들을 배우고 적용하는 와중에, 올바른 CSS를 사용하면서도 이와 함께하는 XHTML은 엉성하게 짜여져 있는 것을 목격하곤 한다. 특히, HTML 코드는 불필요하게 너무나 많은 div들과 id들로 채워져 있다. 결과적으로 이것은 별 의미 없는 HTML과 부풀려진 style sheet의 형태를 초래하고 만다 .
Markup tactics

1.7 코드는 구조적으로 잘 구성되어 있는가?

구조적으로 올바르게 짜여진 코드란 html 요소들이 각각의 주어진 목적에 맞게 사용된 코드를 말한다. 잘 짜여진 HTML은 (style sheet를 지원하지 않는 브라우저나, 글자 브라우저, PDA, 검색 엔진들과 같은) 다향한 user agnet들에게도 의미론적으로 올바르게 해석되어진다.
Semantically correct markup

더 자세히:

1.8 사이트에 깨진 연결고리(link)는 없는가?

깨진 연결고리는 사용자로 하여금 당황스럽게 만들고, 결국은 고객들을 멀리하게 만드는 요인이 됩니다. 또한 깨진 연결고리로 인해 검색 엔진들한테는 사이트를 올바로 색인할 수도 없게 만듭니다.

더 자세히:

1.9 사이트는 속도/페이지 크기에 비추어서 어떠한 성능을 보여주는가?

기다리기 싫어요… 이것은 여러 조사들을 통해 사용자들이 꾸준하게 불평하는 말이다. 더욱이 빠른 속도의 인터넷 사용자들한테도 이러한 불편은 남의 일이 아니다 .
Speed Up Your Site: Web Site Optimization

1.10 사이트에 JavaScript 오류는 없는가?

Windows의 Internet Explore는 디버거(debugger)를 켜서 사이트의 javascript 오류들을 발견시, 새로운 창을 띄워서 오류들을 보여주게 하는 기능이 있다 . 이 기능은 고급 탭의 ‘인터넷 옵션’에서 설정할 수 있는데, ‘스크립트 디버깅 끄기’ 항목을 선택해제 하면 된다.

2. 내용과 정보 전달 방식이 분리되어 있는 정도

2.1 사이트는 정보 전달을 위한 모든 표현 형식들(글꼴, 색깔, 여백, 테두리 등)을 위해 CSS를 사용하고 있는가?

내용의 배치와 보여질 정보의 전달 형태들을 지정할 경우는 스타일 쉬트(style sheets)를 사용하십시오.
Web Content Accessibility Guidelines 1.0 – checkpoint 3.3

2.2 치장을 위한 모든 그림들은 CSS에 정의되어 있는가, 아니면 (X)HTML 안에 나타나 있는가?

웹 개발자들이 염두에 두어야 할 주요 목표는 모든 표현 전달 형식들을 html 코드에서 끌어 내어서, 남는 것은 결국 깨끗하고 의미론적으로도 올바른 형태의 html 문서로 만드는 것이다.
Why use CSS to separate content from presentation?

3. 사용자들을 위한 접근 용이성

3.1 모든 설명 그림들에 “alt” 속성값들이 제대로 주어져 있는가?

글자가 아닌 형태의 모든 요소들에는 해당 요소들을 설명해 주는 글자도 같이 제공해야 한다
Web Content Accessibility Guidelines – checkpoint 1.1

3.2 사이트의 글자 크기를 지정하는데 절대 단위 대신에 상대 단위를 쓰고 있는가?

HTML의 속성 값과 CSS 특성 값들에는 절대 단위 대신에 상대 단위를 써라
Web Content Accessibility Guidelines – checkpoint 3.4

더 자세히:

3.3 글꼴 크기가 커지면 전체 페이지의 배치 구조가 변하지는 않는가?

간단한 실험을 한 번 해봅시다. 당신의 웹 사이트를 글꼴 크기를 조절할 수 있는 브라우저에서 열고 글꼴 크기를 계속 늘려 보십시오. 페이지의 구조와 형태가 변하지는 않습니까? 모든 사람들이 기본 글꼴 크기로 페이지를 볼 것이라는 추축은 개발자들에게는 아주 위험한 생각입니다.

3.4 사이트는 눈에 보이는 건너뜀 메뉴를 제공하고 있는가?

사용자들에게 귀찮고 반복적인 이동을 위한 연결고리를 건너뛸 수 있는 수단이 제공되어야만 한다.
Section 508

관련 연결고리를 한데 묶고, 묶음을 뛰어 넘을 수 있는 방법을 제공하라
Web Content Accessibility Guidelines – checkpoint 13.6

…시각 장애인들만이 이동 메뉴에 있는 너무나 많은 연결고리로 인해 불편을 겪는 것은 아니다. 이것은 새로운 기술의 수용이 어려운 이동이 불편한 장애인이 마치 늪지대에서 허우적 거리는 것과 같은 처지를 만들 수도 있다는 것을 명심해야 한다.
Keep them visible!

3.5 사이트는 접근이 쉬운 form들을 사용하고 있는가?

Form들은 장애를 가진 사람들이 사용하기에는 결코 만만한 것이 아닙니다. 그래서, 평이한 내용이 쓰여있는 페이지들을 그냥 둘러보는 것 하고, form 항목들과 입력 정보들을 간에 왔다갔다 하는 것은 완전 다른 얘기랍니다
Accessible forms

더 자세히:

3.6 사이트는 접근이 쉬운 table들을 사용하고 있는가?

자료를 담아두는 테이블에는, 행과 열을 위한 머릿말들을 지정하라… 행과 열을 위한 머릿말들이 두 개 이상의 논리적 단계들로 구성되어 있다면, 자료를 담아놓은 칸(cell)들과 머릿말 칸에는 관련 HTML 꼬리표들을 지정할 것.
Web Content Accessiblity Guidelines – checkpoint 5.1

더 자세히:

3.7 색깔의 밝기와 대비는 충분한가?

색깔 구별에 장애를 가진 사람들이 웹 페이지를 보는 경우를 대비해서, 배경 색깔과 표면 색깔이 충분한 대비를 갖도록 할 것
Web Content Accessibilty Guidelines – checkpoint 2.2

더 자세히:

3.8 중요한 정보가 색깔에만 의존해서 전달되지는 않는가?

색깔에 의존해 전달되는 정보는 색깔 없이도 HTML이나 문맥을 통해서 전달 의미가 올바로 해석될 수 있도록 하십시오.
Web Content Accessibilty Guidelines – checkpoint 2.1

보통 색맹에는 세 가지의 유형이 있습니다; Deuteranope (빨강/초록 색맹), Protanope (또 다른 형태의 빨강/초록 색맹) 그리고 Tritanope (매우 드문 파랑/노랑 색맹).

더 자세히:

3.9 누르면 흘러내려서(dropdown) 보여지는 메뉴들이 (저하된 운동 능력을 가지고 있는 사용자들을 위해) 약간 지연된 반등속도를 보이는가?

저하된 운동 능력을 가지고 있는 사용자들에게는 반응속도가 너무 빠르게 설정되어 있는 dropdown 메뉴를 사용할 때는 어려움을 겪을 수도 있습니다.

3.10 모든 연결고리가 (시각 장애인들을 위해) 연결될 페이지의 내용을 설명해주는 이름으로 되어 있는가?

연결고리의 이름은 문맥상으로 쉽게 알 수 있도록 의미 있는 것으로 되어 있어야 하며, 그 자체 혹은 일련의 연결고리 사이에서도 뜻이 명확해야 합니다. 또한 이름은 간단 명료해야 합니다.
Web Content Accessibility Guidelines 1.0 – checkpoint 13.1

4. 장치들을 위한 접근 용이성

4.1 사이트는 현재와 예전 브라우저를 망라해서 비교적 수월하게 접근할 수 있는가?

CSS 기반의 구조를 가진 웹 페이지를 작성하기 전에, 어떤 브라우저를 지원할 것인지 그리고 어느 정도의 수준으로 이들을 지원할 것인지를 결정해야 합니다.
Colored boxes – one method of building full CSS layouts

4.2 사이트의 내용은 CSS를 끄거나 혹은 지원되지 않은 상태에서도 접근 가능한가?

드물지만 어떤 사람들은 아직 CSS를 지원하지 않는 브라우저를 쓰거나 혹은 브라우저의 CSS 표시를 꺼놓고 페이지를 읽을 수도 있습니다. 하지만, 내용이 잘 정리된 구조로 되어 있다면 이것은 별 문제가 안될 것입니다.

4.3 사이트의 내용은 그림을 표시하지 않거나 지원되지 않은 상태에서 접근 가능한가?

어떤 이들은, 특히 매우 느린 인터넷 접속 환경을 가진 사람들은, 그림 표시 기능을 꺼놓고 웹 사이트들을 돌아다니는 경우도 있습니다. 이러한 사람들한테도 사이트 내용은 여전히 잘 전달될 수 있어야 합니다.

4.4 사이트는 Lynx와 같은 글자 브라우저에서도 잘 작동하는가?

이 경우는 꼭 그림과 CSS 표시를 꺼버린 상황과 비슷합니다. 글자 기반 브라우저는 정보를 전달하는 데는 오직 구조적으로 잘 정리된 내용들만을 의지하게 됩니다.

더 자세히:

4.5 사이트의 내용은 보기 편하게 인쇄될 수 있는가?

어떠한 (X)HTML 문서를 가지고서도 ,HTML 코드의 수정 없이, 보기 편하게 인쇄될 수 있도록 할 수 있는 아주 간단한 방법이 있답니다.
Going to print

더 자세히:

4.6 사이트는 휴대 장비들에서도 잘 보여지는가?

이것은 휴대 장비들이 올바른 미디어 형식들을 지속적으로 지원하지 않는 한은 다루기 어려운 일이긴 합니다. 하지만, 배치 구조의 형태만 잘 갖추어져 있다면 현재 사용되는 휴대 장비들에서도 잘 보이게 할 수 있습니다. 여기서, 휴대 장비 지원의 중요도는 목표로 하는 독자층이 어떤 집단이냐에 따라 달라질 수도 있습니다.

4.7 사이트는 자세한 metadata를 갖고 있는가?

Metadata는 기계에 의해 해석될 수 있는 Web 정보를 말한다
W3C – Metadata and Resource Description

Metadata는 여러 특정한 자원들을 설명하기 위해 만들어지고 특정한 형식으로 조직화되어 있는 정보를 말하는데, 이것은 다른 말로, ‘자료에 대한 자료’라고 할 수 있습니다.

4.8 사이트는 여러 크기의 브라우저 창에서도 잘 작동하는가?

일발적으로 개발자들 사이에서는 사용되는 평균 화면의 크기는 점점 증가하고 있다고 여기고 있습니다. 또한 어떤 개발자들은 현재 사용되는 평균 화면의 크기는 너비가 1024px일 것이이라고 믿고 있을 것입니다. 그렇다면, 작은 모니터를 쓰는 사용자들과 휴대 장비를 이용하는 사용자들은 어떻게 해야 할까요? 그들은 당신이 염두에 두고 있는 독자층에 포함됩니까? 그렇다면 과연 그들을 무시해도 될까요?

5. 기본적인 접근 용이성

5.1 명확한 가시적 계층구조를 가지고 있는가?

페이지 내용을 구성하고 그 중요도를 나타내는 데에는 글자의 크기, 두드러짐 그리고 내용의 연관성에 따른 형태의 변화를 활용하라
Create a Clear Visual Hierarchy

5.2 머릿말 단계들은 구별이 쉽도록 되어 있는가?

문서의 구조와 형태를 배열할 때는 머릿말(header) 요소들을 해당 용법에 맞게 적절히 사용하라
Web Content Accessibility Guidelines 1.0 – checkpoint 3.5

5.3 사이트는 쉽게 이해할 수 있는 이동 수단을 가지고 있는가?

웹 사이트의 이동 쳬계는 방문자들에게 현재의 페이지가 사이트의 어느 지점에 위치하는지를 잘 나타내 주어야 하고, 또 어는 곳으로 이동할 수 있는지도 쉽게 이해될 수 있어야 한다.
Design Tutorial – Navigation

5.4 사이트는 일관성 있는 이동 수단을 사용하고 있는가?

만약 사이트의 각 페이지들이 일관된 형태의 이동 수단을 제공하고 있다면, 방문자들에게는 페이지 이동과 정보 수집이 훨씬 수월할 것입니다.
Juicy studios – Navigation

5.5 사이트의 내용은 일관성 있고 적절한 언어를 구사하고 있는가?

명확하고 간단한 언어의 사용은 효율적인 의미 전달을 보장합니다. 형편없는 문법으로 쓰여진 것은, 특히 쓰여진 언어가 방문자의 모국어가 아닐 경우에는 더더욱, 읽기가 어려워 지므로 되도록이면 명확안 언어를 사용해서 쉽게 이해될 수 있도록 해야 할 것입니다.
http://www.juicystudio.com/tutorial/accessibility/clear.aspClear language

5.6 사이트 지도 페이지와 연락처 페이지는 있는가? 그리고 쉽게 찿을 수는 있는가?

대부분의 사이트 지도들은 사이트가 보유하고 있는 여러 층들로 이루어진 정보의 구조를 재대로 표시해 주지 못 하고 있다. 실제 사용자들의 사용 형태를 살펴보면, 사이트 지도를 아예 무시거나 혹은 사이트 지도를 찾을 수 없는 경우도 있다. 문제의 원인은 바로 복잡함에 있다: 사이트 지도는 말 그대로 지도이어야지, 그 자체로 이동에 장애가 된다면 전혀 쓸모가 없을 것이다.
Site Map Usability

5.7 큰 사이트일 경우, 검색 기능은 있는가?

작은 사이트일 경우에는 검색 기능은 필요가 없을지 몰라도, 사이트 안에서 사용 가능한 검색 기능은 여러 이동 수단들과 함께 아주 유용하게 쓰일 수도 있습니다.

5.8 사이트의 매 페이지들마다 첫 페이지로 이동할 수 있는 연결고리는 있는가?

어떤 사람들은 사이트 안의 특정 페이지로 이동한 후에, 다시 사이트의 첫 페이지로 이동하는 경향이 있습니다. 이런 사람들에게는 이 첫 페이지는 베이스 캠프와도 같은 구실을 해서, 새로운 정보를 찾으러 이동하기 전에 돌아와서 재출발할 수 있는 일종의 출발점 구실을 하게 됩니다.

5.9 연결고리엔 밑줄이 그어져 있는가?

클릭할 수 있는지를 나타내는 적용 인지 가능성을 최대한 높이려면, 연결고리 글자에 색깔을 주고 밑줄을 그어 놓으십시오. 사용자들은 어떤 것들이 눌러서 이동할 수 있는 것인지를 고민하거나, 알아내기 위해 마우스를 가지고 페이지 위를 이리저리 문댈 필요는 없어야 합니다.
Guidelines for Visualizing Links

5.10 방문했던 페이지들은 독자적인 색깔로 정의되어서 구별하기 쉬운가?

가장 중요한 것은 이미 방문했던 페이지들은 달리 표시되어서, 원치않게 이미 방문했던 페이지들을 다시 방문하도록 하는 것을 미연에 방지해야 합니다.
Change the Color of Visited Links

6. 사이트 관리

6.1 사이트는 알기 쉽고 도움이 될 만한 404 오류 페이지를 가지고 있으며 사이트의 어느 곳에서라도 쓰일 수 있는가?

주소 막대에 직접주소를 입력했더니 혹은 오랫동안 갱신되지 않은 어떤 연결고리를 눌렀더니, 예기치도 않게 알 수 없는 곳에 도달했던 경험이 있을 겁니다. 이럴 때 사용자들을 배려하는 웹 사이트에서는 도움의 손길을 뻗을 테지만 어떤 곳은 그냥 웹 브라우저에 있는 기본 기능에만 의존해서 어떤 문제가 발생했는지만 덩그러니 떨어뜨려 놓는 경우도 있습니다.
The perfect 404

6.2 사이트는 알기 쉬운 URL들을 사용하는가?

(Google과 같은 몇몇 엔진들은 제외하고) 대부분의 검색 엔진들은 URL에 물음표 혹은 기타 특수문자(앰퍼샌드-& 혹은 등호)와 같은 것들을 포함하고 있는 페이지들을 색인하지 못 합니다. 이렇게 해서, 아무도 찾을 수 없는 사이트가 과연 무슨 소용이 있겠습니까?
Search Engine-Friendly URLs

사용자 인터페이스 측면에서 보면, 웹 요소들 중에서 가장 불편한 것은 URL입니다. 하지만, 짧고, 논리적이며 자동 오류 수정의 기능을 갖고 있다면, URL들은 그나마 사용할 만 할 겁니다.
How to make URLs user-friendly

더 자세히:

6.3 사이트의 URL들은 “www” 없이도 잘 작동하는가?

이것이 그리 중요한 것도 아니고, 특별한 경우에는 가능하지도 않겠지만, 사용자들에게 두 가지 선택사항들 중에 하나를 고를 수 있게 하는 것은 언제나 권장될 만한 사항입니다. 그래서, 혹 사용자가 www 없이 도메인 이름을 쳤을 때 해당 사이트를 방문할 수 없게 된다면, 이것은 사용자나 그 사이트의 주인 모두에게 불리한 요소로 작용할 것입니다.

6.4 사이트는 favicon을 가지고 있는가?

Favicon은 개발되어 있는 거이 모든 대형 사이트들에 포함되어 있으면서, 다양한 해상도를 갖는 그림 파일이랍니다. 이 Favicon은 웹 개발자에게는 그들의 사이트를 더 잘 홍보할 수 있도록 하는 수단이 되며, 방문자의 브라우저에서는 더욱 개성 있는 모습으로 나타나게 됩니다.
Favicon.com

물론, Favicons이 그렇게 중요한 것은 아닙니다. 하지만, 이것이 없다면, 브라우저의 기록 파일(logs)에는 404 오류들의 자국을 남기게 됩니다. 그리고 IE와 같은 브라우저는 사이트를 책갈피에 담아 놓을 때마다 서버에게 favicon을 요청하게 됩니다. 그래서, 만약 favicon이 없다면 404 오류가 발생됩니다. 그래서, favicon을 포함하고 있다면, favicon때문에 발생하는 404 오류들은 미연에 방지할 수 있게 됩니다. 이것은 ‘robots.txt’ 파일에도 비슷하게 적용됩니다.

이 검사 항목에 대하여

이 검사 항목은 처음에는 2004 년 5 월 Web Standards Mail 항목에서 큰 틀의 윤곽을 갖게 되었습니다. 그리고 나서, 2004 년 8 월 5 일에 Sydney Web Standards Group으로 보내지게 됩니다. 그리고, 이 검사 항목은 개발자들을 위해 pdf 형태로 배포되고 있습니다.

교정을 해주신 Rose씨께 감사드리며, 개발자 검사 항목을 작성하는데 여러 제안을 제공해 주신 Lea de Groot씨께도 감사드립니다.

Russ Weakley
13-August-04

따옴 – Max Design

꼬리표:

관련된 주제의 글

댓글을 남겨 주세요