Cross Browsing 이란??

2.1 Cross Browsing의 정의

웹페이지의 상호 호환성(Cross Browsing) 구축에 대해 이야기하면 기본적인 오해가 있다. 그것은 바로 이것이 모든 웹브라우저에서 100% 똑 같이 보이도록 만드는 것이라는 생각이다. 작게는 1990년대 후 반 Netscape사와 Microsoft사의 Browser War 기간 동안 일어난 브라우저의 비호환성을 억지로 끼워 맞 추려는 기법 정도로 치부되는 것이다.

[그림.2 역사 속의 다양한 웹브라우저]

그러나 OS가 다르고 글꼴이 다르며, HTML을 렌더링(Rendering)하는 엔진이 다르기 때문에 모든 웹브라 우저에서 100% 똑같이 보이게 하는 것은 가능하지 않다. Cross Browsing이란 적어도 표준 웹기술을 채 용하여 다른 기종 혹은 플랫폼에 따라 달리 구현되는 기술을 비슷하게 만듦과 동시에 어느 한쪽에 최적 화되어 치우지지 않도록 공통 요소를 사용하여 웹페이지를 제작하는 기법을 말하는 것이다. 또한, 지원 할 수 없는 다른 웹브라우저를 위한 장치를 구현하여 모든 웹브라우저 사용자가 방문했을 때 정보로서 의 소외감을 느끼지 않도록 하는 방법론적 가이드를 의미하는 것이다. 이는 인터넷 환경 자체가 일반 테스크톱 웹브라우저 뿐만 아니라 모바일, 임베디드 기기, 홈네트워킹용 장비 등 아주 다양한 인터넷 환경이 존재하며, 일반인, 장애자, 노약자, 어린이 등 다양한 사용자가 존재하기 때문이다.

즉 웹 서비스의 모든 잠재 사용자들이 사이트에 접근할 수 있어야 한다는 것은 매우 중요한 요소라는 것이다. 웹 개발자나 디자이너는 이러한 권고를 적용하지 않을 필요가 있는지 신중히 고려해야 한다. 적용하지 않는 경우에는 포괄적인 접근을 허용할 수 있도록 디스플레이 기능 옵션을 제공해야 한다.

2.2 접근성 향상

Cross Browisng의 범주에는 레이아웃 및 기술적 공통성을 추구하는 면이 있는 가 하면, 일반적이지 않 는 웹사용자에 대한 지원이라는 포괄적인 의미도 함축하고 있다. 예를 들어, 청각 장애자나 시각 장애 자가 웹페이지를 보기 위해 필요한 것들이나 어린이 노약자를 위한 배려 같은 것들이 그것이다.

이러한 기능 옵션에 대한 중요한 사항은 웹 사이트를 기획 운영하는 웹마스터와 웹디자이너 및 개발자 들이 http://www.w3.org/TR/WAI-WEBCONTENT/ 에 제시되어 있는 "W3C web accessibility initiatives"의 규정한 지침에 유의해야 한다.

1) 텍스트
핵심 정보는 반드시 텍스트/HTML 포맷으로 제공되어야 한다. 특히 Flash 같은 것으로 전체화면을 구성 하거나 메뉴를 구성하는 것은 피해야 한다. 만약 꼭 사용해야 한다면 비 Flash 버전을 만들어야 한다.

텍스트는 반드시 사용된 배경색에 대해 뚜렷이 대비되는 색으로 표시되어야 한다. (다양한 환경의 256 COLOR 지원 그래픽 카드에서 식별 가능여부가 테스트 되어야 한다)

텍스트 색상은 텍스트를 표시하는 곳에서 사용자가 원하는 색상을 선택할 수 있으므로, 색상별로 별도 의 의미를 함축하지는 않는다.

2) 폰트 설정(Font)
글자에 대한 형식은 <font> 태그를 사용하기 보다는 CSS을 통해 지정해서 사용한다. HTML4.0에서는 FONT를 사용하는 것을 추천하고 있지 않다. CSS에는 일반적으로 사용 가능한 글자꼴을 Face 속성에서 지정해야 한다. 예를 들면, 굴림, 굴림체, 돋 움, 돋움체 등 Arial, Helvetica, Times New Roman등이 있다. 또한, 가변폭과 고정폭의 글꼴 선택에 있 어 글자의 크기를 사용자가 임의로 조정할 수 있도록 가변폭 글꼴을 우선한다.

영문의 경우 모두 대문자로 표기하거나 이탤릭체를 과도하게 사용하는 것은 피해야 한다. 밑줄 친 글 자는 하이퍼링크와 혼동될 우려가 있으므로 사용을 피한다. 색상 속성은 인쇄 시 나타나지 않으므로 흰색이나 지나치게 밝은색으로 설정하지 않으며, 쉽게 읽을 수 있도록 배경색과 대비가 되어야 한다. 특히, "Color"가 특정 의미 부여의 유일한 방법이어서는 안 된다. 어떤 정보가 특정 글꼴로 표현되어야 한다면, 해당 정보는 이미지로 표현되어야 하고 텍스트 형식의 ALT 값을 제공해야 한다. 정보를 표현하는데 이미지를 사용하는 것은 최소화해야 한다.

3) 테이블 (TABLE)
브라우저에 따라, 특정 사용자의 경우에는, 복잡한 테이블을 생성하는 것이 어렵거나 레이아웃이 틀려 보이는 경우가 매우 많다. 따라서, <TABLE> 태그 방식의 레이아웃 보다는 <DIV>와 CSS과 접목된 레이아웃 방식으로 변경하도록 노력한다. 웹페이지 내에 테이블을 아예 사용하지 않는다는 정책을 고집하는 것은 현실적으로 불가능하므로, 최소 한 디자이너는 복잡한 테이블 사용 시 일어날 수 있는 문제에 대해 인식하고 있어야 한다. 컬럼 수는 최소로 효과적으로 유지해야 하고, 중첩 테이블은 가능한 한 피하고, 다른 대안이 없는 경우 사용한다.

테이블 내의 정보는 가능하면 수평으로 읽혀져야 하며, 서로 다른 웹 브라우저에 따라 가능한 동일하게 표현되어야 하고 호환성이 확인되어야 한다. Ending 태그는 절대 생략해서는 안 되며, 셀 내의 배경 이미지는 구버전의 브라우저에서는 지원되지 않 으므로 피해야 한다.

4) 대안 TAG의 정의
<img>, <applet>, <input> ,<object>, <applet> 태그 등에는 이미지를 보지 않거나 볼 수 없는 사용자나 검색 엔진 위치설정에 매우 유용한 ALT나 LONGDESC, TITLE 같은 텍스트 정의를 반드시 삽입한다.

웹사이트는 그래픽을 연결시키지 않은 상태로도 사용이 가능해야 하며, 이미지를 볼 수 없는 사람들의 비용과 이익간의 균형을 반드시 고려해야 한다. 대안 태그는 항상 포함되어야 하며, 이미지의 외관뿐만 아니라 기능을 설명해야 한다. 내용은 100 문자 를 초과하지 않아야 한다. 중요한 로고가 처음으로 사용되는 곳에는(예를 들면 웹사이트 상에), 완전한 공식적인 설명("X 정보컨 텐츠 팀 로고 : ....을 나타내는 로고" 등)을 제공하는 것이 권장된다. 이후 로고가 반복될 때는 ALT 텍스트 내에 "X 정보컨텐츠 팀 로고"로 명명할 수 있다. 때때로 중요 정보(예를 들면, 차트, 테이블 또는 다이어그램)를 나타내는 어떤 이미지의 내용에 대해 자세한 설명이 제공될 필요가 있다. 이 설명은 주요 웹 페이지 내에 텍스트로 포함되거나, IMG 요소의 LONGDESC 속성에 의해 링크된 웹 페이지에 위치시킬 수도 있다.

IMG와 A에서 사용 실례


<img src="access.gif" alt="[Description]"
longdesc="imgdesc_a.html"><a href="w.htm" title="Description of
Accessbility">[D]</a>

OBJECT에서의 사용 실례


<object data="accessbrdlogo.gif" type="image/gif"> The Access
Board"s <a href="projected.html">projected budget</a> for Fiscal
2005 is ... </object>

IMAGE MAP에서의 사용 실례


<OBJECT data="navigation.gif" type="image/gif" usemap="#mapnav">
<MAP name="map1"><P>Navigate the Access Board site.
[<A href="guidelines.html" shape="rect" coords="0,0,118,28">Access
Guide</A>]
[<A href="news.html" shape="rect" coords="118,0,184,28">Go</A>]
[<A href="search.html" shape="circle" coords="184.200,60">Search</A>]
</MAP>
</OBJECT>

TABLE에서 사용 실례


<TABLE border="1" summary="This table charts the number of webpages
analyzed by each agency head, what kind of media the pages contain,
and whether or not the page is part of the Executive Branch.">
<CAPTION>Web pages Analyzed by Agency Heads</CAPTION>
<TR>
<TH id="header1">Agency Head</TH>
. . .
</TR>
</TABLE>

5) 접근성 시험
웹사이트 접근성은 Website garage (http://www.websitegarage.com) 혹은 Bobby (http://www.cast.org/bobby) 등에서 테스트해 볼 수 있다. 좋은 방법은 텍스트 브라우저인 Lynx를 활 용하여 웹사이트를 시범적으로 조사해 보는 방법도 있다.


[그림.3 텍스트 기반 Lynx 브라우저의 실행 모습 (http://www.lynx.org)]

2.3 웹브라우저간 특이성

끊임없이 새로운 브라우저가 출현함에 따라 표준과 호환성에 대한 중요도가 점점 증대되고 있다. 그러 나 많은 웹브라우저들은 여전히, HTML, CSS, 자바스크립트 등의 표준안을 충분히 지원하지 못하고 있다. 그러나 표준을 지키려는 노력들이 진행되고 있기 때문에 보다 빠른 속도록 브라우저간 웹 호환성이 이 루어 지고 있다.

모든 웹브라우저가 같은 형태의 페이지를 출력할 것으로 예상하지만 <표 >에서 보 이는 것 처럼 1999년 이전에 나온 오래된 웹브라우저들은 자바스크립트, CSS, HTML4의 기능들을 구현하 지 못하고 있다. 따라서 Cross Browsing의 목표는 완벽한 호환성에 두는 것이 아니라 이종 웹브라우저 에서 사용되는 비호환 및 비표준 구현 방식과 기법들을 가능한 표준안에서 수용할 수 있는 방법을 찾는 것이다.

브라우저

프레임

테이블

플러그인

font 크기

font색상

JScript

자바

CSS

gif89

DHTML

IFRAME

테이블색

IE6.0

V

V

V

V

V

V

V

V

V

V

V

V

IE5.5

V

V

V

V

V

V

V

V

V

V

V

V

IE5.0

V

V

V

V

V

V

V

V

V

V

V

V

IE4.0

V

V

V

V

V

V

V

V

V

V

V

V

IE3.0

V

V

V

V

V

V

V

V

V

V

V

NS7.0

V

V

V

V

V

V

V

V

V

V

V

V

NS6.1

V

V

V

V

V

V

V

V

V

V

V

V

NS6.0

V

V

V

V

V

V

V

V

V

V

V

V

NN4.7

V

V

V

V

V

V

V

V

V

V

V

NN4.5

V

V

V

V

V

V

V

V

V

V

V

NN3.0

V

V

V

V

V

V

V

V

V

MZ1.3

V

V

V

V

V

V

V

V

V

V

V

V

MZ1.0

V

V

V

V

V

V

V

V

V

V

V

V

OP7

V

V

V

V

V

V

V

V

V

V

V

V

OP6

V

V

V

V

V

V

V

V

V

V

V

V

OP5

V

V

V

V

V

V

V

V

V

V

V

V

OP4

V

V

V

V

V

V

V

V

V

V

OP3.6

V

V

V

V

V

V

V

V

[표.1 윈도우에서 주요 웹브라우저 별 지원 웹기술 내역]

대부분의 사용자들은 NN4와 IE5 이상의 브라우저를 사용하고 있다. 그러나 IE가 다른 웹브라우저와 확 연히 다른 점은 HTML태그의 시작과 끝이 명확하지 않을 때도 적당히 해석해서 표시를 해 준다는 것이다. 마크업(Markup) 언어의 특징은 시작과 끝의 태그가 명확하여야 하는데도, 다른 브라우저와 달리 IE가 적당히 해석해 줌으로서 개발자나 웹디자이너들이 표준적인 코딩에 비해 실수할 가능성을 높다. 또한, 이것들이 다른 브라우저에서 다르게 보이게 하는 결정적인 요인이 되기도 한다.

또한, 각 웹브라우저에 따라 지원하는 HTML 태그가 다를 수 있다. 이중에는 표준 HTML4에 포함된 것들도 있다. 대표적으로 <col>과 <colgroup>의 span, width만 NS지 원하나 IE가 지원하는 align, valign은 하지 않음 또한 <iframe>의 align도 NS는 지원하지 않는데 이는 align, valign 같은 속성들이 앞으로 CSS로 합쳐질 예정이기 때문이다. 따라서 align 혹은 valign 같은 것은 쓰지 않고 CSS에서 설정하여 사용하는 것이 좋다. <legend>의 경우 IE만 지원하며 <table>의 hspace, vspace는 HTML3에 있는 기능이나 IE에서는 지원하지 않는다.

HTML 표준은 아니나 지원이 다른 경우를 살펴보면, <body> marginwidth, marginheight는 NS에서 지원하고 topmargin, leftmargin은 IE에서 각각 다르게 지원하므로 같이 설정해 주어야 한다. <hr>의 color와 <frame>의 framespacing, <table>의 bordercolor-light, bordercolordark 그리고 배경음악을 들려주는 <bgsound>, <script>의 id는 IE만 지원되는 것이므로 가급적 사용하지 않거나 대체되는 자바스크립트 기능을 이용하는 것이 팔요하다. 특히 <bgsound>의 경우 <object>를 사용하여 활용 가능하다.

NS와 IE의 브라우저 시장경쟁 당시에 각 사의 대표적인 비교 태그인 <blink>, <marquee>는 글자를 깜박이거나 흐르는 기능을 해주는 것들로 이들은 요즘 자바스 크립트로 충분히 구현 가능하다. IE만 지원하는 기능 중에는 <comment>, <xml>등의 태그가 있으며, <spacer>은 NS에서만 지원하는 등 차이가 있다. 이러한 웹브라우저 사이의 특이성은 테이블(table)에서 표시하는 방식에서 확연히 다른 결과를 보여준다. <그림4>은 <table>중 </td>태그를 마지막에 사용하지 않았을 때 보여주는 결과의 차이이다.

[그림.4 Table td 태그를 완결하지 않은 경우]

또한, <그림5>는 테이블에 background 이미지 파일을 설정하였을 때 달리 나타나는 현상을 표현한 것이다.

[그림.5 Table에 background 이미지를 지정한 경우]

다음 <그림6>은 테이블에서 cellspacing과 cellpadding을 설정한 경우 달리 나타나 는 현상을 표현한 것이다.

[그림.6] table의 cell 설정을 한 경우]

테이블 뿐만 아니라 <form>의 경우도 input type이나 submit 버튼 형식들이 브라우 저에 따라 다른 모양으로 나타나는 것을 발견할 수 있다.

[그림.7. form 속성들의 다른 형태의 표시]

브라우저들 간에 나타나는 이러한 차이점은 HTML 태그의 속성을 각기 다른 렌더링 엔진을 통해 표현하 기 때문에 생기는 문제들로 디자인을 달리 보이게 하는 요소들로서 지적되고 있다. 이러한 속성을 같게 보이게 하기 위해서는 요즘에는 CSS를 사용하는 방법이 추천되고 있다. 브라우저의 특이성은 당연히 존 재하는 것이며 이러한 특징들을 알아두고 확인하여 최대한 표현하고자 하는 컨텐츠 형태로 출력하는 것 이 중요하다.

2.4 표준이란 무엇인가?

웹사이트에 적용하는 HTML, CSS, Javascript 같은 것은 어디에서 정해져서 사용되는 것일까? 이 같은 승인된 개방형 인터넷 표준은 즉 World Wide Web Consortium (W3C)에서 만들어 진다. W3C는 1994년 10 월 미국의 MIT 컴퓨터 과학 연구소(MIT LCS), 유럽의 정보수학유럽연구컨소시움(ERCIM), 그리고 일본의 게이오 대학이 연합하여 만들어진 국제적인 웹 기술 표준 기구이다.

언뜻 보기에는 연구 기관으로만 이루어진 것 같으나 웹과 관련된 510여개의 국제적인 다국적 IT 기업체 가 참여하여 자사의 하드웨어와 소프트웨어에 웹 표준기술을 탑재하거나 자사의 기술을 표준화 하고자 하는 치열한 전투장 이기도 하다. 또한, W3C는 각국의 W3C 사무국인 지역 조직과의 파트너 프로그램을 가지고 있다. W3C의 역할은 정보, 의견 교환, 아이디어 창출, 독립적 사고, 그리고 공동의 이해를 위하 여 명세, 가이드 라인, 소프트웨어, 그리고 도구 및 규칙등의 표준안을 제정함으로써 웹의 모든 잠재력 을 이끌어 내는 것이다. 즉, 개발자, 설계자, 그리고 표준 전문가 들에게 W3C 권고안을 채택을 촉진하 게 하고, 향후 권고안을 만들 수 있도록 장려해 주는 강제 기관이기도 하다.

웹에 관련한 표준에는 우리가 흔히 말하는 표준(Standard)은 존재하지 않으며, W3C의 토론을 통해 나온 권고안(Recomendation)이 가장 최상위 이다. 표준의 종류에는 제안된 표준(Draft), 작업하는 표준 (Working Draft, WD), 확정될 권고안(Candidate Recommendation, RC), 확정된 권고안(Recommendation) 이 있다.

권고안을 제정하는 방법은 1) 어떤 기능을 Draft로서 제안하고, 2) 드래프트를 실제로 적용할 수 있게 기술적인 작업을 하고(Working Draft), 3) 이를 다시 논리 오류가 없는지, 실제 하드웨어에서 지원이 가능한지를 살피고, 4) 정식 권고안이 되기 전에 기업체에 공개하여 토론을 거친 후(Recommendate Candidation), 5) 마지막으로 권고안(Recommendation)을 확정한다.

웹브라우저 중 Mozilla, Netscape 등은 문서로서 확정된 추천안(Recomendation)이나 표준의 수정본 가 운데 역시 확정된 표준을 지원한다. 다시 말해 모질라는 HTML 4.0도 지원하지만, HTML4.01을 더 잘 지 원해 준다. 특히 W3C 전용 브라우저인 Amaya 브라우저가 했던 표준의 기술 지원 시험을 요즘에는 모질 라에서 하고 있어 더욱 빠르게 표준 기술이 적용되고 있다.

오페라도 비슷한 정도로 표준을 지원해 주지만, 빠른 속도를 유지하기 위해 MathML 등을 제대로 해석하 지 못하기도 한다. IE는 지원하는 표준의 종류만을 보자면, 다른 두 가지 브라우저보다 더 뛰어납니다. 그러나, 지원하는 표준이 Recomendation이 아니라는 데 문제가 있다. IE는 Microsoft가 제안했던 내용 만을 지원하는데, Recomendation에 자신들이 제안했던 내용이 적고, RC나 WD 또는 Draft에 자신들이 제 안한 내용이 많다면 그것을 지원한다. 대표적인 예가 HTML 4.0과 XHTML 1.0/1.1이다. HTML 4.0은 거의 모든 부분에서 MS의 의견이 반영되어 있다. 그럼에도 불구하고 HTML4.0의 후속 버전인 XHTML 1.0/1.1은 제대로 지원하지 않고 있다. 왜냐 하면, HTML을 모듈화하면서 MS의 의견이 상당 부분 표준에 채택되지 못했기 때문이다. 또한 CSS Level 2(흔히 CSS2) 지원도 미흡하다. 브라우저가 W3C의 권고안을 지원하는 데는 이러한 복잡한 관계가 얽혀 있다.

2.5 W3C 표준의 내용

지금부터는 W3C에서 제공하는 웹사이트 제작을 위한 각종 권고안에 대한 특성을 살펴본다.

HTML(Hypertext Markup Language)는 웹페이지를 표시하는데 기본 언어로서 사용된다. 웹 컨텐츠의 내용 은 표준 HTML 포맷으로 적용해야 하며 정보가 독점적인 고유 포맷으로 제공되는 경우, HTML 포맷도 제 공되어야 한다. 브라우저 호환성은 모든 경우에 있어 고려되어야 하며, 웹사이트는 단일 웹 브라우저에 맞추어 제작되어서는 안되며, 클라이언트 그룹에 의해 빈번하게 사용되는 웹 브라우저에서 올바르게 작 동해야 한다. 최신의 HTML 표준은 4.01이며, HTML을 XML과 결합한 XHTML이 권고안으로 나와 있다.

CSS(Cascading Style Sheets)는 템플리트를 생성함으로써, 비 전문 설계자도 웹 페이지를 손쉽게 제작 관리 할 수 있게 한다. CSS는 HTML을 비롯하여 사용자 정의의 디자인 속성, 즉 글꼴, 크기, 색상, 이벤 트 등을 지정할 수 있으며 CSS를 사용한 모든 페이지는 기존 버전과의 호환성 되게 어떤 브라우저에서 도 내용을 열람할 수 있다. CSS를 이용하여 설계자는 서로 다른 화면 해상도와 브라우저 상에서, 테이 블 없이도 동일하게 보여질 수 있는 페이지를 생성할 수 있다. 단 IE4.0 이하와 NN4이하의 오래된 웹브 라우저에서는 CSS를 지원하지 못한다. CSS를 사용하여 생성한 페이지와 템플리트는 다양한 브라우저, 화면 해상도 및 액세스 기술을 사용하여 테스트하여야 하며, 최신 시스템 사용자가 아니더라도 적합한 접근이 보장되어야 한다. CSS의 최신 표준안은 CSS2 이다.

XML(eXtensible Markup Language)은 HTML이나 CSS로서 표현되지 못하는 영역을 DTD를 이용하여 정의하 여 사용자 정의의 태그를 생성하여 제작할 수 있는 메타 마크업 언어이다. XML 사용 분야를 검토하여 적절한 용도에 맞게 사용하여야 한다. XML이 고려되는 애플리케이션은 사용자가 필요한 정보를 얻기 위해 하나 이상의 데이터베이스와 상호 작용할 필요가 있는 경우, 작업이 사용자에게 전달되어 사용자 가 자신의 기록 혹은 문서에 액세스할 것이 예상되는 경우, 서로 다른 세트의 데이터가 서로 다른 사용 자에게 디스플레이 되어야 하는 경우, 정보 검색 및 디스플레이와 관련하여 사용자 선호 프로파일을 구 축해야 할 필요가 있는 경우, 각 개인이 스타일 시트를 사용하여 다양한 포맷으로 문서를 갱신해야 할 필요가 있는 경우에 사용 가능하다. XML은 다양한 인터넷 비즈니스 환경에 손쉽게 적응 가능하여 웹 표 준 분야에서 가장 활발한 표준 제정 활동이 이루어 지고 있다.

DOM(Document Object Model)은 웹페이지에 표현되는 모든 속성에 대해 객체화 하여 이를 자유 자재로 사용할 수 있도록 만든 것이다. document, from, window 등 각각의 속성을 객체화 하여 트리 구조로 형상화 하여 이에 대한 이벤트 처리 같은 것이 가능하다. DOM에는 크게 W3C DOM과 MS DOM이 있는데, IE6.0은 아직 MS DOM을 따른다. Mozilla나 Netscape6 이상 최신 버전들이 W3C DOM을 지원하고 있다. 이 로 인해 생기는 몇 가지 문제점이 Javascript 운영 상에 존재한다.

Javascript는 표준으로 제정된 것은 아니다. 또한, 모든 웹브라우저 사용자가 JavaScript를 볼 수 있는 것은 아니다. 특정 방화벽은 JavaScript가 통과하는 것을 허용하지 않는다. 그럼에도 Javascript는 DOM 이 표준화 되면서 웹브라우저에 널리 쓰이고 있다. 주의할 점은 클라이언트측 스크립트는 여러 브라우 저에서 폭 넓게 검사되어야 한다. 핵심 기능은 JavaScript에 의해서만 제공되어서는 안 된다. 또 JavaScript는 주석 코드를 사용하여 비호환성의 웹 브라우저로부터 숨겨져야 한다. JavaScript는 HTML 문서의 Head 내에 위치해야 제대로 동작한다 따라서 문서의 body 내에 JavaScript를 위치시키는 것은 피해야 한다. mouseover는 브라우저의 검출 옵션과 함께 사용될 수 있을 뿐이다. JavaScript 변수는 부 적절하지 않는 한 논리적으로 이름 붙여져야 한다.

아래는 웹사이트 개발에 필요한 표준안들에 대한 목록이다.

• [CSS1] "CSS, level 1 Recommendation", B. Bos, H. Wium Lie, eds., 17 December 1996, revised 11 January 1999. CSS1 권고안: http://www.w3.org/TR/1999/REC-CSS1-19990111. CSS1 최신 버전: http://www.w3.org/TR/REC-CSS1.
• [CSS2] "CSS, level 2 Recommendation", B. Bos, H. Wium Lie, C. Lilley, and I. Jacobs, eds., 12 May 1998. CSS2 권고안: http://www.w3.org/TR/1998/REC-CSS2-19980512. CSS2 최신 버전: http://www.w3.org/TR/REC-CSS2.
• [DOM1] "Document Object Model (DOM) Level 1 Specification", V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, and L. Wood, eds., 1 October 1998. DOM1 권고안: http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001. DOM1의 최신 버전: http://www.w3.org/TR/REC-DOM-Level-1
• [HTML40] "HTML 4.0 Recommendation", D. Raggett, A. Le Hors, and I. Jacobs, eds., 17 December 1997, revised 24 April 1998. HTML 4.0 권고안: http://www.w3.org/TR/1998/REC-html40-19980424 HTML 4.0 최신 버전: http://www.w3.org/TR/REC-html40.
• [HTML32] "HTML 3.2 Recommendation", D. Raggett, ed., 14 January 1997. HTML 3.2 최신 버전: http://www.w3.org/TR/REC-html32.
• [RDF] "Resource Description Framework (RDF) Model and Syntax Specification", O. Lassila, R. Swick, eds., 22 February 1999. RDF 권고안: http://www.w3.org/TR/1999/REC-rdf-syntax-19990222 RDF 1.0 최신 버전: http://www.w3.org/TR/REC-rdf-syntax
• [XML] "Extensible Markup Language (XML) 1.0.", T. Bray, J. Paoli, C.M. Sperberg-McQueen, eds., 10 February 1998. XML 1.0 권고안: http://www.w3.org/TR/1998/REC-xml-19980210. XML 최신버전: http://www.w3.org/TR/REC-xml

아래는 웹사이트의 접근성을 높이기 위한 표준안들 이다.

• [TECHNIQUES] "Techniques for Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, I. Jacobs, eds. 이 문서에서는 "웹 콘텐츠 접근성 지침 1.0"에서 정의한 체크포인트를 어떻게 구현하는지에 대해 설명하고 있다. 이 기술 문서의 최신 버전: http://www.w3.org/TR/WAI- WEBCONTENT-TECHS/
• [WAI-AUTOOLS] "Authoring Tool Accessibility Guidelines", J. Treviranus, J. Richards, I. Jacobs, C. McCathieNevile, eds. 저작 도구 접근성 지침에 대한 가장 최신 작업 초안(Working Draft): http://www.w3.org/TR/WAI-AUTOOLS/
• [WAI-UA-SUPPORT] 이 문서에서는 (보조 기술을 포함하여) 웹 표시 장치들이 여기에서 언급된 접근성 관 련 기능을 얼마나 지원하는지에 대해 언급하고 있다. 문서 있는 곳: http://www.w3.org/WAI/Resources/WAI-UA-Support
• [WAI-USERAGENT] "User Agent Accessibility Guidelines", J. Gunderson and I. Jacobs, eds. 접근성이 높은 웹 표시 장치를 설계하기 위한 이 지침에 대한 최신 작업 초안: http://www.w3.org/TR/WAI- USERAGENT/
• [WCAG-ICONS] 적합성 아이콘들에 대한 정보와 그것의 사용법: http://www.w3.org/WAI/WCAG1- Conformance.html
• [UWSAG] "The Unified Web Site Accessibility Guidelines", G. Vanderheiden, W. Chisholm, eds. 통합 된 웹 사이트 지침은 위스콘신 대학교의 Trace R & D Center에서 미 연방 교육부 산하 국립 장애 재활 연구소(National Institute on Disability and Rehabilitation Research, NIDRR)의 지원을 받아 만들었 다. 문서 있는 곳: http://www.tracecenter.org/docs/html_guidelines/version8.htm

W3C에서는 웹페이지가 표준안에 따라 만들어 졌는지, 접근성에 대한 고려가 이루어 졌는지 유효성 검사 (Validation)에 대한 정보를 제공하고 있다. 개발의 맨 첫 단계에서부터 여러 가지 검사를 시작하면, 초기에 식별한 접근성 관련 문제점은 더 수정하기 쉽고, 피해 갈 수 있다.

아래는 몇 개의 중요한 유효성 검사 방법으로 제시되는 것이다. 먼저 자동화된 접근성 검사 도구와 브 라우저 유효성 검사 도구(http://validation.w3c.org)를 사용한다. 소프트웨어 도구가 모든 접근성 관 련 문제점을 다룰 수는 없다는 점을 유의한다. 예를 들면 링크 텍스트의 의미가 적절한지 여부나, 대체 텍스트(text equivalent)의 적용 가능성(applicability) 등은 다룰 수 없다.

기초 적인 문법 검사를 하고 (예를 들면, HTML, XML 등), 스타일 시트의 문법 검사를 한다(예를 들면, CSS). 텍스트만 나오는 브라우저 또는 에뮬레이터로 시험하여 페이지의 레이아웃이 올바른지 살펴 보고 여러 개의 그래픽 브라우저를 써서, 소리와 그래픽을 모두 받는 설정, 그래픽을 받지 는 설정 , 소리를 받지 않는 설정, 마우스를 쓰지 않는 설정, 프레임, 스크립트, 스타일 시트, 애플릿을 사용하지 않는 설정 등을 통해 얼마나 접근도가 좋은지 체크해 볼 필요가 있다. 또한, 최근에 나온 것 뿐 아니라 오래 된 브라우저를 포함하여 여러 개의 브라우저로 시험해 본다면 더 좋을 것이다.

만약 가능하면 음성 브라우저(self-voicing browser), 화면 음성 변환기, 화면 확대 장치, 낮은 해상도 의 화면 등을 써보면 자신의 웹페이지 접근도에서 문제되는 점을 고칠 수 있다. 마지막으로 철자법과 문법 검사기를 사용한다. 음성 합성기를 통해 페이지를 읽는 사람들은 철자법이 틀린 단어에 대해서 합 성기가 읽어주는 것으로는 무슨 단어인지 추측할 수가 없을 것이다. 문법적인 오류도 없어야 이해하기 가 쉽다.

기본적인 접근도 검사가 수행되었다면 문서가 간단 명료하게 작성되었는지 다시 점검한다. 일부 워드 프로세서가 생성해 주는 가독성 통계치같은 것들이 명확성이나 간결성에 대한 좋은 지표로 쓰일 수 있 다. 그보다 더 나은 방법은 경험 있는 편집자에게 명료성을 검토해 주도록 부탁하는 것이다. 또한 경험 있는 편집자는 특정 언어(단어나 표현)나 아이콘 사용이 야기할 수도 있는 잠재적으로 민감한 문화적인 문제점을 가려내어 문서의 사용자 편의성(usability)을 높일 수도 있다.