접근성?
- 접근성의 의미와 웹 개발에 접근성을 적용하는 방법을 학습합니다.
- 모든 사용자가 웹사이트에 액세스할 수 있고 유용하게 활용할 수 있도록 하는 방법을 학습합니다.
- 개발에 미치는 영향을 최소화하면서 기본적인 접근성을 포함하는 방법을 학습합니다.
- 사용 가능한 HTML 기능과 이런 기능을 사용하여 접근성을 개선하는 방법을 학습합니다.
- 세련된 접근성 환경을 만들기 위한 고급 접근성 기법에 대해 학습합니다.
접근성을 한마디로 설명하긴 어렵지만
구현하기 어렵게 만들 필요없음을 알면 된다.
원활한 엑세스, 강력한 인터페이스. 장애가 있는 사용자뿐 아니라
모든 사용자가 더욱 즐거운 마음으로 간편하게 사용할 수 있는 인터페이스의 제작.
접근성이란?
어떤 사이트가 접근가능하거나 엑세스 가능하다고 할때 그 사이트의 콘텐츠를 사용할 수 있고 제공하는 기능을 조작할 수 있음을 의미한다. 개발자는 모든 이용자가 자신과 똑같은 방식으로 웹페이지와 상호작용할 수 있을꺼라 생각해서는 안된다.
접근성이란 '전형적인' 사용자라는 좁은 범위에서 벗어난 곳의 사용자를 고려하는 것.
- 특정 지역에서 서비스가 제한된다거나
- 태블릿기기에서는 메뉴가 나타나지 않는다거나
이 양식에는 여러 가지 접근성 문제가 있습니다.
- 텍스트의 명암비가 낮아 시력이 약한 사용자는 제대로 읽기 힘듭니다.
- 왼쪽에 레이블을 배치하고 오른쪽에 입력란을 배치할 경우 많은 사람들이 이 두 가지 요소의 관련성을 쉽게 알아차리지 못합니다. 심지어 페이지를 이용하기 위해 확대 기능을 사용해야 하는 사용자에겐 거의 불가능한 일입니다. 휴대폰 화면에 이런 식으로 배치되어 있다고 상상해 보세요. 아마 어떤 요소가 어떤 요소와 연관되어 있는지 알아내느라 화면상에서 이리저리 이동해야 할 것입니다.
- 'Remember details?' 레이블은 체크박스와 연관되어 있지 않으므로 레이블을 그냥 클릭하는 것이 아니라 작은 사각형을 찾아 그 위에서만 정확히 탭하거나 클릭해야 하므로 너무 불편합니다. 또한, 스크린 리더를 사용하는 사람은 둘 사이의 연관성을 알아내는 데 애먹을 것입니다.
이제 접근성 문제를 해결하고 이 문제를 해결한 뒤의 형식을 살펴보겠습니다. 레이블을 표시하는 대상과 레이블이 유사해지도록 텍스트를 어둡게 하고 디자인을 수정한 다음, 레이블을 클릭해서 전환할 수 있도록 레이블과 확인란을 연결할 것입니다.
어느 쪽을 사용하고 싶으신가요? '접근성 버전'이라고 답했다면 이 가이드의 주요 전제를 대략 이해하고 있는 것입니다. 일부 사용자들이 엄청난 불편이라고 생각하는 부분은 다른 사용자에게도 불편을 야기하는 경우가 많습니다. 그러므로 접근성 문제를 해결하면 모든 사람의 경험이 개선됩니다.
웹 콘텐츠 접근성 가이드라인
웹 콘텐츠 접근성 가이드라인 (WCAG) 2.0을 참조할 것입니다. 이 문서는 접근성 전문가들이 방법론적으로 '접근성'의 의미를 고심하여 모은 가이드라인과 모범 사례의 집합입니다. 실제로 여러 국가에서 웹 접근성 법적 요구사항에 이 가이드라인을 사용합니다.
WCAG는 네 가지 원칙으로 구성되며 주로 POUR라는 약자로 표현됩니다.
- 인지 가능(Perceivable): 사용자가 콘텐츠를 인지할 수 있나요? 시각과 같이 어떤 감각으로 인지할 수 있다고 해서 모든 사용자가 인지할 수 있다는 뜻은 아니라는 점을 떠올리는 데 도움이 됩니다.
- 작동 가능(Operable): 사용자가 UI 구성 요소를 사용하고 콘텐츠를 탐색할 수 있나요? 예를 들어 마우스 오버 상호작용은 마우스나 터치스크린을 사용할 수 없는 사람은 작동시킬 수 없습니다.
- 이해 가능(Understandable): 사용자가 콘텐츠를 이해할 수 있나요? 사용자가 인터페이스를 이해할 수 있고 인터페이스는 혼란을 피할 수 있을 만큼 일관적인가요?
- 안정적(Robust): 다양한 사용자 에이전트(브라우저)로 콘텐츠를 사용할 수 있나요? 지원 기술과 호환되나요?
WCAG는 콘텐츠 접근성의 의미에 대한 종합적 개요를 제공하지만 이는 다소 소화하기 어려울 수 있습니다. 이런 어려움을 줄이기 위해서 WebAIM (Web Accessibility in Mind) 그룹이 WCAG 가이드라인을 웹 콘텐츠를 대상으로 하는 따라 하기 쉬운 목록으로 간결히 작성했습니다.
WebAIM 검사 목록은 구현해야 할 것에 대해 간결하고 높은 수준의 정보를 제공하고 상세한 정의가 필요할 경우에 대비하여 기본적인 WCAG 표준과 링크되어 있습니다.
이 도구를 사용하면 접근성 작업 방향을 정할 수 있고, 프로젝트가 지정된 기준을 충족하는 한 콘텐츠에 액세스하는 사용자에게 긍정적인 경험을 제공한다는 확신을 가질 수 있습니다.
사용자 다양성 이해
접근성에 대해 학습할 때는 전 세계의 다양한 사용자 범위와 이러한 사용자가 영향을 미치는 다양한 종류의 접근성 주제에 대해 이해하면 도움이 됩니다.
사용자는 어떤 장애가 있나요?
콘텐츠 액세스가 어려운 장애라고 하면 보통 사람들은 저와 같이 시각 장애가 있는 사용자를 바로 떠올립니다. 사실, 맞습니다. 시각 장애는 웹사이트를 사용할 때 정말 좌절스러울 뿐만 아니라, 심지어 아예 사용이 불가능할 수도 있습니다.
많은 현대적 웹 기술이 등장하면서 시각 장애인 사용자가 웹 액세스 시 사용하는 도구와 호환되지 않는 사이트가 제작되는 안타까운 부작용이 생겨났습니다. 그러나 접근성 문제는 그뿐이 아닙니다. 장애를 4가지(시각, 운동, 청각, 인지)로 분류하면 유용합니다.
하나씩 살펴볼까요? 시각 장애의 예를 알려주실 수 있나요?
시각 장애는 두 가지 범주로 나뉩니다. 저처럼 앞이 전혀 보이지 않는 사람은 스크린 리더나 점자를 사용하고, 또는 그 두 가지를 혼용해서 사용합니다.
점자 판독기
정말로 앞이 전혀 보이지 않는 것은 상당히 드문 일이지만 여러분이 앞이 전혀 보이지 않는 사람을 최소 한 명 이상 알거나 만나보았을 가능성이 큽니다. 그러나 저시력 사용자는 그 수가 훨씬 많습니다.
각막이 없는 제 아내와 같은 사람을 포함하여 저시력 사용자는 범위가 넓습니다. 참고로, 제 아내는 기본적으로 사물을 볼 수는 있지만 활자를 읽는 것은 어려워하고 법적으로는 시각 장애인으로 간주됩니다. 또는, 저시력 사용자에는 시력이 낮아서 매우 도수가 높은 처방 안경을 써야 하는 사람도 포함됩니다.
범위가 매우 넓기 때문에 이 범주의 사람들이 사용하는 보조 기구도 천차만별입니다. 어떤 사람은 스크린 리더나 점자 디스플레이를 사용합니다. (인쇄된 텍스트를 보는 것보다 쉽다는 이유로 화면에 표시된 점자를 읽는 여성도 있다고 들었습니다.) 어떤 사람은 전체 화면 판독 기능은 없는 문자 음성 변환 기술을 사용하거나 화면의 일부만 확대하는 화면 돋보기를 사용하기도 합니다. 아니면 브라우저 확대/축소 기능으로 모든 글꼴을 확대하기도 합니다. 운영체제의 고대비 모드나 고대비 브라우저 확장, 고대비 웹사이트 테마처럼 대비를 높인 옵션도 사용합니다.
고대비 모드
많은 사용자가 이런 도구를 복합적으로 사용합니다. 제 친구 Laura는 고대비 모드와 브라우저 확대/축소, 문자 음성 변환 기능을 전부 사용합니다.
저시력은 많은 사람과 관련이 있는 장애입니다. 우선 우리는 모두 나이가 들면서 노안을 경험합니다. 그러므로 여러분이 저시력을 경험한 적이 없다고 해도 부모님이 불평하는 말은 들어보셨을 것입니다. 그러나 햇빛이 비치는 창가에서 노트북을 사용할 때 갑자기 아무것도 읽을 수 없게 되는 불편한 경험을 하는 사람이 많습니다. 아니면 레이저 시술을 받았거나 방 건너편에 있는 무언가를 읽으려는 사람도 제가 말씀드린 보조 도구를 사용합니다. 그래서 개발자들이 저시력 사용자에게 쉽게 공감할 수 있으리라 생각합니다.
아, 깜빡 잊을 뻔했는데 색각에 이상이 있는 사람도 있습니다. 남성의 약 9%가 일종의 색각 결함이 있다고 합니다! 여성은 약 1%입니다. 이런 사람은 빨간색과 녹색, 노란색과 파란색을 구분하기 어려울 수도 있습니다. 다음에 인증 양식을 디자인할 때는 이 점을 기억하세요.
운동 장애는 무엇인가요?
네, 운동 능력 장애 또는 운동 장애라고 합니다. 이 집단은 RSI가 있거나 통증이 있어서 마우스를 사용하고 싶어하지 않는 사람에서부터 신체적 마비가 있어서 특정 신체 부위의 운동 능력이 제한된 사람까지 다양합니다.
안구 추적 기기
운동 장애가 있는 사용자는 키보드, 스위치 기기, 음성 제어를 사용하거나 심지어 안구 추적 기기로 컴퓨터와 상호작용합니다.
시각 장애와 마찬가지로 운동 장애는 일시적이거나 상황적 문제일 수 있습니다. 마우스를 사용하는 쪽의 손목이 골절되었을 수도 있고, 노트북의 트랙패드가 고장났거나 흔들리는 기차를 타고 있을 수도 있습니다. 사용자의 운동 능력이 저하되는 상황은 여러 가지가 있습니다. 우리는 이런 상황을 배려함으로써 영구적 장애가 있는 사람뿐만 아니라 일시적으로 포인터 기반 UI를 사용할 수 없는 사람까지 전반적으로 사용자 환경을 개선할 수 있습니다.
좋습니다. 청각 장애에 대해 이야기해볼까요.
이 집단은 청각 장애가 심한 사람부터 난청인 사람까지 다양합니다. 시각과 마찬가지로 청각은 나이를 먹으면서 감퇴합니다. 많은 사용자가 보청기와 같은 일반적 보조 도구를 사용하여 도움을 받습니다
화면 자막
청각 장애가 있는 사용자를 위해 소리에 의지하지 말아야 합니다. 영상 자막을 사용하고 소리가 인터페이스에 포함된다면 다른 대안을 마련해야 합니다.
시각 장애와 운동 장애에서 보았듯이 청각에 이상이 없는 사람도 이런 보조 도구의 도움을 받을 수 있습니다. 제 친구들은 대부분이 동영상에 자막이 있는 것이 좋다고 말합니다. 개방형 사무실에서 일할 때 헤드폰을 가져오지 않아도 동영상을 볼 수 있으니까요!
알겠습니다. 인지 장애에 대해 설명해주시겠어요?
ADD, 난독증, 자폐증처럼 여러 가지 인지 장애가 있습니다. 이런 사람들은 다른 방식으로 액세스하고 싶어 하거나 그래야 할 필요가 있습니다. 물론 이 집단을 위한 보조 도구가 매우 다양하지만 다른 영역과 겹치는 부분도 있습니다. 예를 들어, 확대/축소 기능을 사용해서 글을 읽거나 집중력을 강화합니다. 또한, 이런 사용자는 산만한 요소와 인지 부하를 최소화하기 때문에 최소한의 디자인이 가장 좋습니다.
누구나 인지 과부하의 스트레스와 관련될 수 있다고 생각합니다. 인지 장애가 있는 사람에게 효과적으로 만든다면 모든 사람에게 쾌적한 경험을 제공할 수 있습니다.
그렇다면 접근성을 간단히 말하면 뭐라고 생각하시나요?
사람들의 다양한 능력과 장애를 살펴보면 완벽한 시각과 청각, 운동 능력, 인지 능력을 가진 사람을 대상으로만 제품을 디자인하고 제작하는 것은 매우 한정적이라는 것을 알 수 있습니다. 오히려 문제를 키우는 것에 가깝습니다. 모든 사람에게 더욱 스트레스를 주면서도 사용성은 낮은 경험을 제공하고 어떤 사람은 아예 사용하지 못하게 배제됩니다.
이 인터뷰에서 Victor는 장애의 종류를 시각, 운동, 청각, 인지*의 네 가지 범주로 분류하였습니다. 또한, 각각의 장애 유형은 *상황적, 일시적 또는 영구적일 수 있다고 지적했습니다.
접근 장애의 실제 예시를 살펴보고 이 범주와 유형 중에 어디에 속하는지 알아보겠습니다. 일부 장애는 하나 이상의 범주/유형에 포함될 수 있습니다.
| 상황적 | 일시적 | 영구적 | |
|---|---|---|---|
| 시각 | 뇌진탕 | 시각 장애 | |
| 운동 | 아기를 안고 있을 경우 | 팔 골절, RSI* | RSI* |
| 청각 | 소음이 심한 사무실 | ||
| 인지 | 뇌진탕 |
*반복성 긴장성 장애: 예를 들어 수근골 증후군, 테니스 엘보, 탄발지가 있음
비장애인이 웹상에서 제공되는 텍스트와 이미지, 영상 등을 접했을 경우, 한눈에 재빨리 내용 파악이 가능하지만, 장애인은 그렇지 않습니다. 그림이나 사진들을 제공할 때 눈으로 볼 수 없는 경우를 대비하여 그림이나 사진을 대신 할 수 있는 설명을 텍스트로 제공해야 하며, 동영상이나 오디오의 경우 청각장애인을 위한 음성정보를 문자로 제공해야 합니다. 또한, 마우스를 사용할 수 없는 사용자를 위하여 키보드만으로도 모든 콘텐츠에 접근하여 이용할 수 있도록 해야 하며, 움직임이 느린 사용자를 위해 시간조절기능을 제공해야 합니다.”
정보통신 환경의 이해
| 장애유형 | 특징 | 보완대책 | |
|---|---|---|---|
| 시각장애 | 전맹 | 모니터를 볼 수 없음 | 스크린리더 |
| 저시력 | 모니터 사용이 일부 가능함 | 화면확대/고대비 | |
| 색맹 | 색을 구별할 수 없음 | 색상에만 의존하지 않기/고대비 | |
| 청각장애 | 사운드, 오디오 등을 창취할 수 없음 | 수화, 시각정보 제공 | |
| 지체장애 | 상지장애 | 손을 사용할 수 없음 | 마우스 대체 방법, 키보드만 사용 |
| 기타 | 움직임이 어려움 | 충분한 시간 제공 | |
| 언어장애 | 복잡한 용어, 어려운 용어의 이해 불가능 | 쉬운 용어 사용 |
다음 단계
벌써 상당히 많은 내용을 배웠습니다! 지금까지 알게 된 내용은 다음과 같습니다.
- 접근성의 정의와 모든 사람에게 접근성이 중요한 이유
- WCAG 및 WebAIM 접근성 검사 목록
- 고려해야 할 다양한 유형의 장애
나머지 가이드에서는 접근성 있는 웹사이트 제작의 실무적 측면을 살펴보겠습니다. 이 내용은 크게 세 가지로 구성됩니다.
- 포커스: 마우스 대신 키보드로 작동하게 만드는 것이 왜 중요한지 살펴볼 것입니다. 물론 운동 장애가 있는 사용자에게도 중요하지만 모든 사용자에게 좋은 UI를 만드는 데도 중요합니다.
- 의미 체계: 다양한 지원 기술과 호환되고 안정적으로 작동하는 사용자 인터페이스를 표현하는지 확인할 것입니다.
- 스타일 지정: 시각적 디자인을 고려하고 인터페이스를 최대한 유연하고 사용하기 좋게 해주는 시각적 요소에 대해 살펴볼 것입니다.
각 주제만으로도 한 강좌를 모두 채울 수 있으므로 접근 가능한 웹사이트 제작의 모든 측면을 들여다보지는 않을 것입니다. 하지만 처음 시작하기 충분한 정보를 제공하고 각 주제에 대해 자세히 배울 수 있는 좋은 곳을 알려드리겠습니다.
웹 접근성 지침(한국형)
한국형 웹 콘텐츠 접근성 지침 2.1은 4가지 원칙과 각 원칙을 준수하기 위한 13개 지침 및 해당 지침의 준수여부를 확인하기 위해 24개의 검사항목으로 구성되어 있습니다.
※방송통신발전 기본법 제 33조 및 방송통신발전 기본법 시행령 제 30조에 의거하여 2015년 3월 31일 KWCAG 2.1 개정
한국형 웹콘텐츠 접근성 지침 2.1 주요 내용 (24개 검사 항목)
| 원칙 1 | 인식의 용이성 (Perceivable) : 모든 콘텐츠는 사용자가 인식할 수 있어야 한다. |
|---|---|
| 1.1.1 | (적절한 대체 텍스트 제공) 텍스트 아닌 콘텐츠는 그 의미나 용도를 이해할 수 있도록 대체 텍스트를 제공해야 한다. |
| 1.2.1 | (자막 제공) 멀티미디어 콘텐츠에는 자막, 원고 또는 수화를 제공해야 한다. |
| 1.3.1 | (색에 무관한 콘텐츠 인식) 콘텐츠는 색에 관계없이 인식될 수 있어야 한다. |
| 1.3.2 | (명확한 지시사항 제공) 지시사항은 모양, 크기, 위치, 방향, 색, 소리 등에 관계없이 인식될 수 있어야 한다. |
| 1.3.3 | (텍스트 콘텐츠의 명도 대비) 텍스트 콘텐츠와 배경 간의 명도 대비는 4.5대 1 이상이어야 한다. |
| 1.3.4 | (자동 재생 금지) 자동으로 소리가 재생되지 않아야 한다. |
| 1.3.5 | (콘텐츠 간의 구분) 이웃한 콘텐츠는 구별될 수 있어야 한다. |
| 원칙 2 | 운용의 용이성(Operable) : 사용자 인터페이스 구성요소는 조작 가능하고 내비게이션 할 수 있어야 한다. |
|---|---|
| 2.1.1 | (키보드 사용 보장) 모든 기능은 키보드만으로도 사용할 수 있어야 한다. (PC웹) |
| 2.1.1 | (누르기 동작 지원) 터치(touch) 기반 모바일 기기의 모든 컨트롤은 누르기 동작으로 제어할 수 있어야 한다. (모바일웹) |
| 2.1.2 | (초점 이동) 키보드에 의한 초점은 논리적으로 이동해야 하며 시각적으로 구별할 수 있어야 한다. |
| 2.1.3 | (조작 가능) 사용자 입력 및 컨트롤은 조작 가능하도록 제공되어야 한다. |
| 2.2.1 | (응답시간 조절) 시간제한이 있는 콘텐츠는 응답시간을 조절할 수 있어야 한다. |
| 2.2.2 | (정지 기능 제공) 자동으로 변경되는 콘텐츠는 움직임을 제어할 수 있어야 한다. |
| 2.3.1 | (깜빡임과 번쩍임 사용 제한) 초당 3~50회 주기로 깜빡이거나 번쩍이는 콘텐츠를 제공하지 않아야 한다. |
| 2.4.1 | (반복 영역 건너뛰기) 콘텐츠의 반복되는 영역은 건너뛸 수 있어야 한다. |
| 2.4.2 | (제목 제공) 페이지, 프레임, 콘텐츠 블록에는 적절한 제목을 제공해야 한다. |
| 2.4.3 | (적절한 링크 텍스트) 링크 텍스트는 용도나 목적을 이해할 수 있도록 제공해야 한다. |
| 원칙 3 | 이해의 용이성(Understandable) : 콘텐츠는 이해할 수 있어야 한다. |
|---|---|
| 3.1.1 | (기본 언어 표시) 주로 사용하는 언어를 명시해야 한다. |
| 3.2.1 | (사용자 요구에 따른 실행) 사용자가 의도하지 않은 기능 (새 창, 초점 변화 등)은 실행되지 않아야 한다. |
| 3.3.1 | (콘텐츠의 선형화) 콘텐츠는 논리적인 순서로 제공해야 한다. |
| 3.3.2 | (표의 구성) 표는 이해하기 쉽게 구성해야 한다. |
| 3.4.1 | (레이블 제공) 사용자 입력에는 대응하는 레이블을 제공해야 한다. |
| 3.4.2 | (오류 정정) 입력 오류를 정정할 수 있는 방법을 제공해야 한다. |
| 원칙 4 | 견고성(Robust) : 웹 콘텐츠는 미래의 기술로도 접근할 수 있도록 견고하게 만들어야 한다. |
|---|---|
| 4.1.1 | (마크업 오류 방지) 마크업 언어의 요소는 열고 닫음, 중첩 관계 및 속성 선언에 오류가 없어야 한다. |
| 4.2.1 | (웹 애플리케이션 접근성 준수) 콘텐츠에 포함된 웹 애플리케이션은 접근성이 있어야 한다. |
모바일 웹 접근성 지침
모바일 애플리케이션 접근성 지침은「국가정보화기본법」제32조제5항에 따라 모바일애플리케이션 서비스 제공자가 장애인과 고령자 등의 접근성을 보장하기 위해 애플리케이션 제작 시 지켜야 할 사항을 규정함을 목적으로 제정되었습니다.
| 구분 | 검사 항목 |
|---|---|
| 준수사항 | 1. (대체텍스트) 텍스트 아닌 콘텐츠는 대체 가능한 텍스트와 함께 제공되어야 한다. |
| 2. (초점) 모든 객체에는 초점(focus)이 적용되고, 초점은 순차적으로 이동되어야 한다. | |
| 3. (운영체제 접근성 기능 지원) 운영체제가 제공하는 접근성 기능 및 속성이 사용되어야 한다. | |
| 4. (누르기 동작지원) 터치 기반 모바일 기기의 모든 컨트롤은 누르기 동작으로 제어할 수 있어야 한다. | |
| 5. (색에 무관한 인식) 화면에 표시되는 모든 정보는 색에 관계없이 인식할 수 있어야 한다. | |
| 6. (명도 대비) 화면에 표시되는 모든 정보는 전경색과 배경색이 구분될 수 있도록 최소 대비 이상으로 제공되어야 한다. | |
| 7. (자막, 수화 등 제공) 멀티미디어 콘텐츠에는 동등한 내용의 자막, 원고 또는 수화가 제공되어야 한다. | |
| 권고사항 | 8. (기본 사용자 인터페이스 컴포넌트) 운영체제에서 제공하는 기본 사용자 인터페이스 컴포넌트(Native UI Component)를 최대한 이용하는 것이 바람직하다. |
| 9. (컨트롤간 충분한 간격) 컨트롤은 충분한 간격으로 배치하는 것이 바람직하다. | |
| 10. (알림 기능) 사용자에게 알림을 제공할 때에는 진동, 시각, 소리 등 최대한 다양한 방법으로 사용자가 선택할 수 있도록 제공하는 것이 바람직하다. | |
| 11. (범용 폰트 이용) 폰트의 크기 조절, 확대 기능을 제공하거나 운영체제에서 제공하는 관련 기능을 활용할 수 있는 방법을 제공하는 것이 바람직하다. | |
| 12. (사용자 인터페이스의 일관성) 사용자 인터페이스 요소들의 배치를 일관성 있게 제공하는 것이 바람직하다. | |
| 13. (깜박거림의 사용 제한) 광과민성 발작을 일으킬 수 있는 콘텐츠를 제공하지 않는 것이 바람직히다. | |
| 14. (배경음 사용 금지) 자동으로 재생되는 배경음을 사용하지 않는 것이 바람직하다. | |
| 15. (장애인 등 사용자 평가) 애플리케이션 개발 시 다양한 모바일 기기에서의 이용 가능 여부를 점검해야 하며, 장애인 사용자 평가를 수행하는 것이 바람직하다. |
참고: http://www.websoul.co.kr/accessibility/WA_guide21.asp
웹 호환성(웹 표준)
웹 표준은 월드 와이드 웹의 측면을 서술하고 정의하는 공식 표준이나 다른 기술 규격을 가리키는 일반적인 용어이다. 최근에 이 용어는 웹 사이트를 작성하는 데 중요도가 높아지고 있으며 웹 디자인, 개발과 관계가 있다.
수많은 상호 의존성이 있는 표준들과 규격들 가운데 일부는 단지 월드 와이드 웹으로만 끝나는 것이 아니라, 인터넷의 관리 측면이기도 하다. 이러한 표준들은 직간접적으로 웹 사이트, 웹 서비스 개발과 관리에 영향을 주고 있다. 이러한 것들 모두 "웹 표준"이라고 부르지만 웹 표준으로 이동하는 것을 찬성하는 사람들은 사용성과 접근성에 직접 영향을 미치는 더 높은 수준의 표준에 초점을 두는 경향이 있다. 더 넓은 뜻의 웹 표준은 다음을 이룬다:
- W3C (World Wide Web Consortium)[1]
- 국제 인터넷 표준화 기구 (IETF)가 출판한 인터넷 표준 (STD) 문서
- 국제 인터넷 표준화 기구 (IETF)가 출판한 RFC (Request for Comments) 문서[2]
- 국제 표준화 기구(ISO)가 출판한 표준들[3]
- Ecma 인터내셔널 (이전 이름은 ECMA)이 출판한 표준들[4]
- 유니코드 컨소시엄이 출판한 유니코드 표준과 다양한 유니코드 기술 보고서 (UTR)[5]
- 인터넷 할당 번호 기관 (IANA)이 운영하는 이름과 번호 레지스트리[6]
일반적인 이용[편집]
웹 사이트나 웹 페이지가 웹 표준을 준수한다는 것은 일반적으로 올바른 HTML, CSS, 자바스크립트를 사이트나 페이지가 가지고 있다는 것을 뜻한다. HTML은 접근성과 시맨틱 HTML의 가이드라인을 충족해야 한다.
웹 표준을 논할 때 일반적으로 다음의 것들이 중요성이 있는 것으로 보인다:
- HTML, XHTML, SVG, XForms와 같은 마크업 언어의 W3C 권고
- 스타일시트, 특히 CSS의 W3C 권고
- 흔히 자바스크립트나 ECMA스크립트로 불리는 Ecma 인터내셔널 표준
- 문서 객체 모델의 W3C 권고
웹 접근성은 일반적으로 W3C의 Web Accessibility Initiative가 출판한 웹 콘텐츠 접근성 가이드라인[7]에 기반을 두고 있다.
외부 링크[편집]
전자정부서비스 웹 호환성이란?
「전자정부법」제50조에 따라 행정기관 및 공공기관(이하 "행정기관등"이라 한다)이 전자정부서비스의 호환성 확보를 위해 지켜야 할 사항을 규정하여 시행하도록 하고 있습니다
전자정부서비스 웹 호환성 진단표
| 구분 | 진단지표 | 진단기준 | 진단방법 |
|---|---|---|---|
| 1.웹 표준 문법 준수 | 1-1 표준 (X)HTML 문법 준수 여부 | W3C Markup Validator에서 출력된 오류를 <심각>, <위험>, <보통>으로 나누어 오류 발생시마다 오류 유형별로 차등을 두어 감점 | W3C Markup Validator |
| 1-2 표준 CSS 문법 준수 여부 | W3C CSS Validator에서 출력된 오류를 <심각>, <위험>, <보통>으로 나누어 오류 발생시마다 오류 유형별로 차등을 두어 감점 | W3C CSS Validator | |
| 2.웹 호환성 확보 | 2-1 동작 호환성 확보 여부 | 브라우저 부가 기능을 이용해서 해당 페이지 내에 사용된 Javascript 오류 및 DOM 경고 발생시 감점Javascript가 의도한 기능이 정상적으로 동작되는지 점검하여 비정상적 동작에 대해 감점 | 브라우저 부가 기능,크로스 브라우징 테스트 |
| 2-2 레이아웃 호환성 확보 여부 | 3종 이상의 브라우저에서 동등한 레이아웃으로 구현되었는지 여부 확인- 브라우저별 특성에 의한 차이(폰트, 픽셀 등)는 예외로 함 | 크로스 브라우징 테스트 | |
| 2-3 플러그인 호환성 확보 여부 | 사용자 화면에 영향을 미치거나 로그인 및 동작에 관련된 다음과 같은 플러그인에 한하여 3종 이상의 브라우저에서 정상적으로 동작되는지 조사- 보안, 구간암호화, 공인인증- 영상, 멀티미디어(플래시, 실버라이트,그래프, 리포트 등)- 파일 송수신브라우저별 대체 수단을 제공할 경우에는 예외로 함 | 플러그인 동작 테스트,크로스 브라우징 테스트 |
모바일 전자정부서비스 웹 호환성 진단표
| 구분 | 진단지표 | 진단기준 | 진단방법 |
|---|---|---|---|
| 1.웹 표준 문법 준수 | 1-1 표준 (X)HTML 문법 준수 여부 | W3C Markup Validator에서 출력된 오류를 <심각>, <위험>, <보통>으로 나누어 오류 발생시마다 오류 유형별로 차등을 두어 감점 | W3C Markup Validator |
| 1-2 표준 CSS 문법 준수 여부 | W3C CSS Validator에서 출력된 오류를 <심각>, <위험>, <보통>으로 나누어 오류 발생시마다 오류 유형별로 차등을 두어 감점 | W3C CSS Validator | |
| 2.웹 호환성 확보 | 2-1 동작 호환성 확보 여부 | 브라우저 자체 오류 콘솔이나 원격 디버깅 기능을 이용해서 해당 페이지 내 사용된 Javascript의 오류 및 경고 발생시 감점Javascript가 의도한 기능이 정상적으로 동작 되는지 점검하여 비정상적 동작에 대해 감점영상, 멀티미디어 등의 기능이 3종 이상의 모바일 브라우저에서 정상작동 하는지 확인 | 크로스 브라우징 테스트 |
| 2-2 기능 호환성 확보 여부 | 3종 이상의 모바일 브라우저에서 레이아웃 오류 등으로 인한 기능상 문제가 없는지 확인- 브라우저 및 운영체제 특성에 따른 차이(폰트나 픽셀 등)는 예외로 함 | 크로스 브라우징 테스트 |
웹 개방성
웹 개방성(Web Openness)이란?
웹에 공개된 정보에 이용자가 아무런 제약 없이 접근하여 이용할 수 있는 것을 의미하며 웹사이트의 정보를 자유롭게 공개·공유하여 정보의 투명성과 개방성이 향상되는 것을 말합니다.
웹 개방성 지수(Web Openness Index, WOI)란?
웹 개방성 지수랑 웹 개방성을 평가하기 위해 웹발전연구소에서 최초로 개발한평가모형으로서 웹사이트의 검색엔진 접근 차단, 특정 페이지 접근 차단, 페이지 별 정보 수집 거부 등을 평가해 점수화한 것
| 항목(가중치) | 구분 | 내용 |
|---|---|---|
| 검색엔진 접근차단 (25) | 평가방법 | 크롬이나 파이어폭스 브라우저에서 제공하는 Use Agent Switcher를 통해 검색엔진 문자열 입력 후 출력화면 확인 |
| 차단현상 | 웹 방화벽이나 웹서버의 운영정책에 따라 특정 검색엔진의 접속이나 특정 콘텐츠에 대한 접근 및 열람을 필터링을 통해 차단검색로봇이 웹사이트 접속 시 웹 방화벽이나 웹서버의 HTTP에 포함된 user-agent의 정보를 보고 검색엔진의 접속을 차단 | |
| 검색엔진 배제선언 (30) | 평가방법 | 웹브라우저 주소 입력창에 /robots.txt 입력을 통해 검색엔진 접근 차단 여부 확인 |
| 차단현상 | 웹 루트 디렉토리에 저장한 robots.txt 파일을 검색엔진 접근 거부에 대한 정책을 선언함으로써 거부 선언된 검색엔진이 방문 시 이를 통해 검색을 수행하지 않음robots.txt 파일에 user-agent, disallow 조건을 정의함으로써 접근 거부 의지 표현 | |
| 특정페이지 접근차단 (20) | 평가방법 | 웹사이트 초기 접속 시 ActiveX 실행 여부 확인 및 특정 콘텐츠 영역이나 링크 정보를 Flash, JavaScript, image 등 구현 확인 |
| 차단현상 | 웹사이트 초기 접속 시 ActiveX 외, JavaScript, Flash, image 등의 실행을 목적으로 하는 특정 웹페이지로 접속을 연결함으로써 검색엔진의 웹사이트 크롤링 불가 | |
| 페이지별 정보수집거부 (15) | 평가방법 | 와 사이에 유무 확인 |
| 차단현상 | 페이지 내 meta 태그에 noindex, nofollow를 설정하여 페이지의 정보 공유 제한웹 페이지 소스코드의 상단 와 사이에 <meta name=“robots” content=“인덱스 속성 검색 속성"/> 형태를 표현함으로써 검색엔진에 대한 접근 거부 의지 표현 | |
| 페이지별 URL차단 (10) | 평가방법 | 데이터베이스 기반 페이지의 URL을 다른 브라우저에 입력 후 콘텐츠 화면과 동일하게 나오는지 확인 |
| 차단현상 | 검색엔진이 웹서버의 구현 특성에 따라 웹사이트의 하부 웹 페이지 URL를 추출하지 못하여 발생하는 검색 중단 |
'webDeveloper' 카테고리의 다른 글
| [Web] Realtime Web이란? (0) | 2021.08.19 |
|---|---|
| [웹] 호스팅은 무엇인가? (0) | 2021.08.07 |
| 공식문서 모음 (0) | 2021.06.01 |
| Uncaught Error: The error you provided does not contain a stack trace. (0) | 2021.06.01 |