[번역] 웹 표준 점검 목록

A web standards checklist를 번역했습니다.
웹 표준과 관련해 점검 해야 할 것들에 관한 간단한 문서 입니다.

A web standards checklist(원문) by Max Design

[su_highlight background=”#99e7ff”]2018.08.15
기존엔 별도 문서로 되어 있었습니다.
최신판으로 내용 업데이트와 함께 본 문서에 포함하는 방식으로 변경했습니다.
더불어 본문에 추가된 내용이 생겨서 번역이 안된 부분이 있습니다. 번역 작업 중입니다.[/su_highlight]


웹 표준 – ‘테이블 없는 사이트’를 뛰어 넘어

웹 표준이라는 용어는 사람들 마다 다른 것을 의미할 수 있다. 예를 들자면, ‘테이블이 없는 사이트’일 수도 있고, 또 다른 이들에겐 ‘유효한 코드를 사용했다’ 일수도 있다. 하지만 웹 표준은 그것 보다 훨씬 광범위하다. 웹 표준은 다음과 같이 정의 할 수 있다:
표준을 엄수하고 (HTML, XHTML, XML, CSS, XSLT, DOM, MathML, SVG etc) 최고의 업무를 실행하는 것 (유효한 코드, 접근성 높은 코드, 의미상으로 올바른 코드, 사용자가 인식하기 쉬운 URL 등).
다르게 말하자면…
사이트를 웹 표준에 맞게 제작하려면 군더더기가 없고, 깨끗하고, CSS 기반이고, 접근하기 쉬우며 사용하기 쉽고, 검색 엔진에 친화적이어야 한다.

점검 목록에 대해

이것은 최고의 점검 목록이 아니다. 아마도 더 추가할 수 있는 것들이 많이 있을 것이다. 더 중요한 것은, 당신이 개발하는 모든 사이트에서 다루어 져야 하는 항목의 목록처럼 보여서는 안된다. 다음과 같이 사용할 수 있다.

  • 웹 표준의 폭을 보여주기 위해
  • 웹 사이트를 제작하는 과정 중 개발자들에게 편리한 도구로서
  • 웹 표준에 흥미가 있는 개발자를 위한 도우미로서

점검목록

  1. 코드의 품질
    1. 올바른 Doctype을 사용하고 있는가
    2. Character set을 사용하고 있는가?
    3. 유효한 (X)html을 사용하고 있는가?
    4. 유효한 CSS를 사용하고 있는가??
    5. 어떠한 CSS을 사용하고 있지 않은가?
    6. 불필요한 class나 id를 사용하고 있지 않은가?
    7. 코드가 구조적으로 짜여져 있는가?
    8. 사이트에 깨진 링크는 없는가?
    9. 속도와 문서 크기의 사이에서 사이트가 어떻게 실행되는가?
    10. 자바스크립트 에러는 없는가?
  2. 내용(구조)과 표현의 분리 정도
    1. 사이트의 모든 표현적인 외관을 위해 CSS를 사용하고 있는가? (글꼴, 색상, padding, borders 등)?
    2. 장식적인 모든 이미지가 CSS안에 있는가, 아니면 (X)HTML에 나타나 있는가?
  3. 사용자를 위한 접근성
    1. 설명을 위한 이미지에 “alt” 속성을 사용하고 있는가?
    2. 글자 크기에 절대적인 단위 보다는 상대적인 단위를 사용하고 있는가?
    3. 폰트 크기를 키웠을때 레이아웃의 외형이 깨지는 곳이 있는가?
    4. 눈에 보이는 바로가기 메뉴를 제공하는가?
    5. 접근하기 쉬운 폼(form)을 사용하는가?
    6. 접근하기 쉬운 테이블(table)을 사용하는가?
    7. 색상의 밝기와 대비가 충분한가?
    8. 중요한 정보에 컬러만을 사용하고 있지는 않은가?
    9. 드롭다운 메뉴를 위해 지체된 응답이 있지는 않은가? (지체에 장애가 있는 사용자를 위하여)
    10. 모든 링크가 설명적인가? (시력에 장애가 있는 사용자를 위하여)
  4. 장치를 위한 접근성
    1. 최근의 브라우저와 구형의 브라우저에게 받아들여지도록 동작하는가?
    2. CSS를 끄거나 지원하지 않아도 내용에 접근이 가능한가?
    3. 이미지를 끄거나 지원하지 않아도 내용에 접근이 가능한가?
    4. Lynx같은 텍스트 브라우저에서도 동작하는가?
    5. 인쇄하였을때 잘 보여지는가?
    6. 휴대 장치에서 잘 동작하는가?
    7. 상세한 메타데이터를 포함하고 있는가?
    8. 브라우저 창 크기의 범위 안에서 사이트가 잘 작동하는가?
  5. 기본적인 사용성
    1. 깔끔한 시각적 계층구조인가?
    2. 헤딩 레벨을 구분해 내기 쉬운가?
    3. 이해하기 쉬운 네비게이션인가?
    4. 일관적인 네이게이션을 사용하고 있는가?
    5. 링크에 밑줄이 쳐져있는가?
    6. 일관적이고 적당한 언어를 사용하고 있는가?
    7. 사이트맵 페이지와 연락할 수 있는 페이지를 가지고 있는가? 그리고 찾기 쉬운 곳에 있는가?
    8. 규모가 큰 사이트인 경우에 검색 툴이 있는가?
    9. 사이트의 모든 페이지에 홈으로 갈 수 있는 링크가 있는가?
    10. 방문했던 링크는 특별한 색으로 확실하게 정의되어 있는가?
  6. 사이트 관리
    1. 사이트의 모든 곳에서 작동하는 의미있고 도움되는 404에러 페이지가 있는가?
    2. 친화적인 URL을 사용하고 있는가?
    3. “www”를 빼도 작동하는 URL인가?
    4. 파비콘이 있는가?

1. 코드의 품질

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

A doctype (short for ‘document type declaration’) informs the validator which version of (X)HTML you’re using, and must appear at the very top of every web page. Doctypes are a key component of compliant web pages: your markup and CSS won’t validate without them.
Fix your site with the right doctype

More:

1.2 Character set을 사용하고 있는가?

If a user agent (eg. a browser) is unable to detect the character encoding used in a Web document, the user may be presented with unreadable text. This information is particularly important for those maintaining and extending a multilingual site, but  declaring the character encoding of the document is important for anyone producing XHTML/HTML or CSS.

Tutorial: Character sets & encodings in XHTML, HTML and CSS

More:

1.3 유효한 (X)html을 사용하고 있는가?

Valid code will render faster than code with errors. Valid code will render better than invalid code. Browsers are becoming more standards compliant, and it is becoming increasingly necessary to write valid and standards compliant HTML

More:

1.4 유효한 CSS를 사용하고 있는가?

You need to make sure that there aren’t any errors in either your HTML or your CSS, since mistakes in either place can result in botched document appearance.

Help! My CSS Isn’t Working!

More:

1.5 어떠한 CSS을 핵을 사용하고 있지 않은가?

Basically, hacks come down to personal choice, the amount of knowledge you have of workarounds, the specific design you are trying to achieve.

Standard Hacks?

More:

1.6 불필요한 class나 id를 사용하고 있지 않은가?

I’ve noticed that developers learning new skills often end up with good CSS but poor XHTML. Specifically, the HTML code tends to be full of unnecessary divs and ids. This results in fairly meaningless HTML and bloated style sheets.

Markup tactics

1.7 코드가 구조적으로 짜여져 있는가?

Semantically correct markup uses html elements for their given purpose. Well structured HTML has semantic meaning for a wide range of user agents (browsers without style sheets, text browsers, PDAs, search engines etc.)

More:

1.8 사이트에 깨진 링크는 없는가?

Broken links can frustrate users and potentially drive customers away. Broken links can also keep search engines from properly indexing your site.

More:

1.9 속도와 문서 크기의 사이에서 사이트가 어떻게 실행되는가?

Don’t make me wait… That’s the message users give us in survey after survey. Even broadband users can suffer the slow-loading blues.

Speed Up Your Site: Web Site Optimization

1.10 자바스크립트 에러는 없는가?

Internet Explore for Windows allows you to turn on a debugger that will pop up a new window and let you know there are javascript errors on your site. This is available under ‘Internet Options’ on the Advanced tab. Uncheck ‘Disable script debugging’.

2. 내용(구조)과 표현의 분리 정도

2.1 사이트의 모든 표현적인 외관을 위해 CSS를 사용하고 있는가? (글꼴, 색상, padding, borders 등)?

Use style sheets to control layout and presentation

Web Content Accessibility Guidelines 1.0 – checkpoint 3.3

2.2 장식적인 모든 이미지가 CSS안에 있는가, 아니면 (X)HTML에 나타나 있는가?

The aim for web developers is to remove all presentation from the html code, leaving it clean and semantically correct.

3. 사용자를 위한 접근성

3.1 설명을 위한 이미지에 “alt” 속성을 사용하고 있는가?

Provide a text equivalent for every non-text element

Web Content Accessibility Guidelines – checkpoint 1.1

3.2 글자 크기에 절대적인 단위 보다는 상대적인 단위를 사용하고 있는가?

Use relative rather than absolute units in markup language attribute values and style sheet property values’

Web Content Accessibility Guidelines – checkpoint 3.4

More:

3.3 폰트 크기를 키웠을때 레이아웃의 외형이 깨지는 곳이 있는가?

Try this simple test. Look at your website in a browser that supports easy incrementation of font size. Now increase your browser’s font size. And again. And again… Look at your site. Does the page layout still hold together? It is dangerous for developers to assume that everyone browses using default font sizes.

3.4 눈에 보이는 바로가기 메뉴를 제공하는가?

A method shall be provided that permits users to skip repetitive navigation links.

Section 508

Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group

Web Content Accessibility Guidelines – checkpoint 13.6

…blind visitors are not the only ones inconvenienced by too many links in a navigation area. Recall that a mobility-impaired person with poor adaptive technology might be stuck tabbing through that morass.

Keep them visible!

3.5 접근하기 쉬운 폼(form)을 사용하는가?

Forms aren’t the easiest of things to use for people with disabilities. Navigating around a page with written content is one thing, hopping between form fields and inputting information is another

Accessible forms

More:

3.6 접근하기 쉬운 테이블(table)을 사용하는가?

For data tables, identify row and column headers… For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.

Web Content Accessiblity Guidelines – checkpoint 5.1

More:

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

Ensure that foreground and background colour combinations provide sufficient contrast when viewed by someone having colour deficits

Web Content Accessibilty Guidelines – checkpoint 2.2

More:

3.8 중요한 정보에 컬러만을 사용하고 있지는 않은가?

Ensure that all information conveyed with colour is also available without colour, for example from context or markup

Web Content Accessibilty Guidelines – checkpoint 2.1

There are basically three types of colour deficiency; Deuteranope (a form of red/green colour deficit), Protanope (another form of red/green colour deficit) and Tritanope (a blue/yellow deficit- very rare).
More:

3.9 드롭다운 메뉴를 위해 지체된 응답이 있지는 않은가? (지체에 장애가 있는 사용자를 위하여)

Users with reduced motor skills may find dropdown menus hard to use if responsiveness is set too fast.

3.10 모든 링크가 설명적인가? (시력에 장애가 있는 사용자를 위하여)

Link text should be meaningful enough to make sense when read out of context – either on its own or as part of a sequence of links. Link text should also be terse.

Web Content Accessibility Guidelines 1.0 – checkpoint 13.1

4. 장치를 위한 접근성

4.1 최근의 브라우저와 구형의 브라우저에게 받아들여지도록 동작하는가?

Before starting to build a CSS-based layout, you should decide which browsers to support and to what level you intend to support them.

4.2 CSS를 끄거나 지원하지 않아도 내용에 접근이 가능한가?

Some people may visit your site with either a browser that does not support CSS or a browser with CSS switched off. In content is structured well, this will not be an issue.

4.3 이미지를 끄거나 지원하지 않아도 내용에 접근이 가능한가?

Some people browse websites with images switched off – especially people on very slow connections. Content should still be accessible for these people.

4.4 Lynx같은 텍스트 브라우저에서도 동작하는가?

This is like a combination of images and CSS switched off. A text-based browser will rely on well structured content to provide meaning.

More:

4.5 인쇄하였을때 잘 보여지는가?

You can take any (X)HTML document and simply style it for print, without having to touch the markup.

Going to print

More:

4.6 휴대 장치에서 잘 동작하는가?

This is a hard one to deal with until hand held devices consistently support their correct media type. However, some layouts work better in current hand-held devices. The importance of supporting hand held devices will depend on target audiences.

4.7 상세한 메타데이터를 포함하고 있는가?

Metadata is machine understandable information for the web

W3C – Metadata and Resource Description

Metadata is structured information that is created specifically to describe another resource. In other words, metadata is ‘data about data’.

4.8 브라우저 창 크기의 범위 안에서 사이트가 잘 작동하는가?

It is a common assumption amongst developers that average screen sizes are increasing. Some developers assume that the average screen size is now 1024px wide. But what about users with smaller screens and users with hand held devices? Are they part of your target audience and are they being disadvantaged?

5. 기본적인 사용성

5.1 깔끔한 시각적 계층구조인가?

Organise and prioritise the contents of a page by using size, prominence and content relationships

Create a Clear Visual Hierarchy

5.2 헤딩 레벨을 구분해 내기 쉬운가?

Use header elements to convey document structure and use them according to specification

Web Content Accessibility Guidelines 1.0 – checkpoint 3.5

5.3 이해하기 쉬운 네비게이션인가?

Your navigation system should give your visitor a clue as to what page of the site they are currently on and where they can go next.

Design Tutorial – Navigation

5.4 일관적인 네이게이션을 사용하고 있는가?

If each page on your site has a consistent style of presentation, visitors will find it easier to navigate between pages and find information

Juicy studios – Navigation

5.5 링크에 밑줄이 쳐져있는가?

The use of clear and simple language promotes effective communication. Trying to come across as articulate can be as difficult to read as poorly written grammar, especially if the language used isn’t the visitor’s primary language.

Clear language

5.6 일관적이고 적당한 언어를 사용하고 있는가?

Most site maps fail to convey multiple levels of the site’s information architecture. In usability tests, users often overlook site maps or can’t find them. Complexity is also a problem: a map should be a map, not a navigational challenge of its own.

Site Map Usability

5.7 사이트맵 페이지와 연락할 수 있는 페이지를 가지고 있는가? 그리고 찾기 쉬운 곳에 있는가?

While search tools are not needed on smaller sites, and some people will not ever use them, site-specific search tools allow users a choice of navigation options.

5.8 규모가 큰 사이트인 경우에 검색 툴이 있는가?

Some users like to go back to a site’s home page after navigating to content within a site. The home page becomes a base camp for these users, allowing them to regroup before exploring new content.

5.9 사이트의 모든 페이지에 홈으로 갈 수 있는 링크가 있는가?

To maximise the perceived affordance of clickability, colour and underline the link text. Users shouldn’t have to guess or scrub the page to find out where they can click.

Guidelines for Visualizing Links

5.10 방문했던 링크는 특별한 색으로 확실하게 정의되어 있는가?

Most important, knowing which pages they’ve already visited frees users from unintentionally revisiting the same pages over and over again.

Change the Color of Visited Links

6. 사이트 관리

6.1 사이트의 모든 곳에서 작동하는 의미있고 도움되는 404에러 페이지가 있는가?

You’ve requested a page – either by typing a URL directly into the address bar or clicking on an out-of-date link and you’ve found yourself in the middle of cyberspace nowhere. A user-friendly website will give you a helping hand while many others will simply do nothing, relying on the browser’s built-in ability to explain what the problem is.

The perfect 404

6.2 친화적인 URL을 사용하고 있는가?

Most search engines (with a few exceptions – namely Google) will not index any pages that have a question mark or other character (like an ampersand or equals sign) in the URL… what good is a site if no one can find it?

Search Engine-Friendly URLs

One of the worst elements of the web from a user interface standpoint is the URL. However, if they’re short, logical, and self-correcting, URLs can be acceptably usable

How to make URLs user-friendly

More:

6.3 “www”를 빼도 작동하는 URL인가?

While this is not critical, and in some cases is not even possible, it is always good to give people the choice of both options. If a user types your domain name without the www and gets no site, this could disadvantage both the user and you.

6.4 파비콘이 있는가?

A Favicon is a multi-resolution image included on nearly all professionally developed sites. The Favicon allows the webmaster to further promote their site, and to create a more customized appearance within a visitor’s browser

Favicon.com

Favicons are definitely not critical. However, if they are not present, they can cause 404 errors in your logs (site statistics). Browsers like IE will request them from the server when a site is bookmarked. If a favicon isn’t available, a 404 error may be generated. Therefore, having a favicon could cut down on favicon specific 404 errors. The same is true of a ‘robots.txt’ file.

이 목록에 대한 추가 정보

This checklist was first outlined in a rough form on the Web Standards Mail list in May 2004. It was presented to the Sydney Web Standards Group on 5 August 2004. It is also available as a downloadable pdf checklist for developers.