위키백과:스타일/접근성 설명서

웹 접근성은 웹 페이지를 더 쉽게 탐색하고 읽을 수 있게 하는 것을 목표로 한다. 이것은 주로 장애를 가진 사람들을 돕기 위한 것이지만, 모든 독자들에게 도움이 될 수 있다. 당사는 다음의 제안이 근거한 Web Content Accessibility Guideline 2.0(ISO/IEC 40500:2012라고도 함)을 준수하는 것을 목표로 한다. 그 페이지들에 붙어있는 페이지는 모든 사람들을 위해 읽고 편집하기 더 쉽다.

2006년 1월 14일 위키미디어 재단 이사회는 다음과 같은 차별금지 결의안을 통과시켰다. "위키메디아 재단은 인종, 색깔, 성별, 종교, 국적, 나이, 장애, 성적 지향 또는 기타 법적으로 보호되는 특성에 기초하여 현재 또는 미래의 사용자와 고용인에 대한 차별을 금지하고 있다. 위키미디어 재단은 특히 '고용, 급여관리, 직원육성, 승진, 전보 직원관계의 모든 측면에서 기회균등 원칙에 충실한다'는 것이다. WMF는 자사의 정책이 "위키메디아 재단의 임원이나 직원이나 어떤 위키미디어 프로젝트의 지역 정책을 우회하거나, 침식하거나, 무시되지 않을 수 있다"고 주장한다.

기사구조

표준화된 기사 구조는 사용자들이 페이지의 특정 부분에 있는 내용을 기대할 수 있게 해주기 때문에 접근성을 향상시킨다. 예를 들어 시각장애 사용자가 설명 링크를 검색하고 있지만 페이지 상단에 없는 경우, 해당 정보를 찾기 위해 페이지 전체를 읽을 필요가 없다는 것을 알게 될 것이다.

표준화는 이미 위키백과의 습관이다. 따라서 따라야 할 지침은 단순히 위키백과일 뿐이다.스타일/레이아웃위키백과 설명서:Lead 섹션 § Lead의 요소들

표제목

표제는 형식 매뉴얼에 정의된 대로 서술적이고 일관된 순서로 작성되어야 한다.

레벨 2부터 시작하여 머리글을 순차적으로 중첩(Nesting heading==(), 그 다음 레벨 3 ()===) 등. (레벨 1은 자동 생성된 페이지 제목이다.) 강조하기 위한 수준 선택과 같은 시퀀스의 일부를 건너뛰지 마십시오. 이것은 헤딩의 목적이 아니다.

중첩된 표제의 올바른 사용 및 잘못된 사용 예제
맞아요. 랜덤/차오틱 수준 건너뛰기

[여기에 기사 단서]
==Section== [레벨 2]
===Sub-section=== [3]
==Section== [2]
===Sub-section=== [3]
====Sub-sub-section==== [4]
==Section== [2]

[여기에 기사 단서]
====Section?==== [4]
===Section?=== [3]
==Section?== [2]
==Section?== [2]
====Section?==== [4]
===Section?=== [3]

[여기에 기사 단서]
[레벨-2 섹션 누락]
===Section?=== [3]
==Section== [2]
[레벨-3 하위 섹션 누락]
====Sub-section?==== [4]
==Section== [2]

세미콜론 마크업을 남용하여 유사 제목을 만들지 말고(설명 목록에 예약) 굵은 마크업을 사용하지 않도록 하십시오. 화면 판독기와 기타 보조 기술은 항법용 머리글 표시가 있는 머리글만 사용할 수 있다. 목차(TOC)의 크기를 줄이려면 {{}를 사용하십시오.대신 TOC 제한}. {{인 경우TOC limit}은(는) 기사의 다른 곳에서는 하위 제목 때문에 사용할 수 없으며, 하위 하위 하위 제목에 굵은 글꼴을 사용하면 화면 판독기 사용자에게 가장 덜 불편함을 야기한다. 사이비 헤딩을 사용하는 것은 다른 모든 선택사항들을 다 써버렸다는 것을 의미한다. 그것은 희귀한 것으로 여겨진다.

의사 표제 및 설명 목록의 허용 및 잘못된 사용 예제
허용됨 틀렸다

[여기에 기사 단서]
==Section== [레벨 2]
===Sub-section=== [3]
'''Pseudo-heading'''
==Section== [2]
===Sub-section=== [3]
====Sub-sub-section==== [4]
;A term followed by
:a definition is a description list

[여기에 기사 단서]
==Section== [레벨 2]
===Sub-section=== [3]
;Pseudo-heading
==Section== [2]
===Sub-section=== [3]
<small>==Sub-sub-section==</small> [2]

부동요소

Wikicode에서 부동 요소(이미지 포함)는 자신이 속한 섹션 에 배치되어야 하며, 이전 섹션의 끝에 이미지를 배치해서는 안 된다.(플랫폼에 따라, 상대적으로 적은 양의 텍스트와 함께 여러 이미지를 "스택"하면 특정 이미지가 이후 섹션으로 내려갈 수 있다. 그러나 화면 판독기는 항상 각 이미지의 내용을 읽으므로 이것은 접근성 문제가 아니다. alt= 영상이 코딩되는 지점까지)

해상도

위키백과 기사는 작은 화면이 있는 장치를 사용하는 독자들이나 해상도가 낮은 모니터를 사용하는 독자들이 접근할 수 있어야 한다. 다른 사용자에게 부정적인 영향을 주지 않고 지원할 수 있다고 간주되는 최저 해상도는 1024×768이며, 모든 기사는 과도한 수평 스크롤 없이 이 해상도에서 허용 가능한 것으로 보아야 한다. 이것은 때때로 화면 양쪽에 여러 개의 이미지가 있는 기사에서 문제가 된다. 낮은 해상도는 문단을 수직으로 확장하여 그 방향으로 이미지를 이동시키지만, 화면 양쪽에 이미지나 다른 부동 콘텐츠를 동시에 추가하지 않도록 주의한다. 큰 테이블과 이미지 또한 문제를 일으킬 수 있다; 때때로 수평 스크롤은 피할 수 없지만 수평이 아닌 수직으로 확장되도록 넓은 테이블을 재구성하는 것을 고려한다.

텍스트

기본적으로 대부분의 화면 판독기는 현재 텍스트 속성(볼드, 기울임꼴, 언더라인, 모노스페이스, 취소선)이나 의미 텍스트 속성(강조, 중요도, 텍스트 삭제)을 표시하지 않으므로 다른 텍스트와 함께 삼진 텍스트가 정상적으로 읽힌다.(Wikipedia 정책에 참여하는 화면 판독기와 삭제 디바트를 사용하는 편집자)es는 입력된 텍스트가 위키백과 내부 토론에서 매우 일반적이기 때문에, 그렇게 할 때 텍스트 속성에 대한 알림을 켜는 것이 좋다.)

취소선은 일반적으로 화면 판독기에 의해 무시되기 때문에, 글에서 드물게 사용(예: 텍스트 분석에서 변경사항을 보여주기 위해)이 유일한 표시인 경우 접근성 문제와 노골적인 혼란을 야기할 것이다. 이는 두 가지 모두에 적용된다. <s> 그리고 <del> 요소(해당 요소와 함께) <ins>, 일반적으로 밑줄로 시각적으로 렌더링됨), 그리고 이를 사용하는 템플릿. [under discussion as of December 2020] 부적절하거나 잘못되었다고 생각하는 내용에 대해 이의를 제기하기 위해 취소선을 사용하지 마십시오. 대신, 코멘트를 해줘. <!-- 그리고 -->완전히 제거하거나 인라인 정리/수정 템플릿을 사용하여 토크 페이지에서 문제를 제기하십시오.

화면 판독기는 라틴어-1Windows-1252 이외의 문자에 대한 지원이 매우 다양하며 이러한 범위에서 주어진 문자의 발음을 어떻게 할 것인지 가정하는 것은 안전하지 않다. 스크린 리더나 스피치 신디사이저에 의해 인식되지 않으면 물음표로 발음하거나 스피치 출력에서 완전히 생략할 수 있다.

  1. 이름, 장소, 사물과 같은 원래 맥락에서 비 라틴 문자 문자가 중요한 비 라틴 문자 시스템에서 모든 텍스트에 대해 반역을 제공하십시오. 이 기능은 비 라틴 스크립트 언어를 나타내는 템플릿에서 사용할 수 있으며 {{transl}}과 같은 템플릿에서도 사용할 수 있다. 이러한 템플릿에는 다른 접근성 혜택도 있다(아래 "기타 언어" 섹션 참조).
  2. ♥(심장 기호)와 같이 발음할 수 없는 기호를 사용하지 마십시오. 대신 alt 텍스트가 있는 이미지를 사용하십시오.[1]
  3. 화면 판독기에 문제를 일으키는 기호는 이미 이미 이미지 및 alt 텍스트를 생성하기 위해 만들어진 템플릿을 가지고 있을 수 있다. 단도 템플릿 {{ template}}을(를) 예로 들 수 있다(카테고리:추가 기능을 위한 단일 이미지 삽입 템플릿).

문자 순서는 텍스트의 의미론적 측면(그리고 가급적 유사한 형태의 다른 내용)을 전달하기에 충분해야 한다. CSS 속성이나 위키 마크업만으로 구별할 수 있는 사용자 정의 "특수 기호"에 의존하는 것은 허용되지 않는다.

툴팁 또는 기타 "호버" 텍스트와 같은 정보를 제공하기 위해 상호작용이 필요한 기법을 사용하지 마십시오. 약어는 이러한 요건에서 면제되므로, {{abbr}} 템플릿(용 래퍼 <abbr> 원소)는 약어의 긴 형태(약어 또는 이니셜리즘 포함)를 나타내기 위해 사용할 수 있다.

화면 판독기로 편집하기 더 어려워지므로 문장 내에 줄 바꿈을 삽입하지 마십시오. 한 줄씩 끊기면 문장이 따라올 수 있는데, 이것은 일부 편집자들에게 도움이 될 수 있다.

글꼴 크기

글꼴 크기를 줄이거나 확대하여 사용할 수 있으며, 일반적으로 머리글, 표 머리글, 표준화된 템플리트와 같은 자동화된 페이지 요소로 한다. 크기 변경은 픽셀 또는 포인트 크기에서 절대 크기가 아닌 원래 글꼴 크기의 백분율로 지정된다. 이것은 큰 기본 글꼴 크기를 사용하는 시각 장애인 사용자의 접근성을 향상시킨다.

이미 infobox, navbox참조 섹션 내의 대부분의 텍스트와 같이 더 작은 글꼴 크기를 사용하는 페이지 요소 내에서 더 작은 글꼴 크기를 사용하지 마십시오.[a] 라는 뜻이다. <small>...</small> 태그 및 템플릿(예: {{small}} 그리고 {{smaller}}는 해당 요소 내의 일반 텍스트에 적용해서는 안 된다. 어떤 경우에도 텍스트의 결과 글꼴 크기가 페이지의 기본 글꼴 크기의 85% 미만으로 떨어지면 안 된다(예: 벡터 스킨의 경우 11.9 px 또는 모노북의 경우 10.8 px). HTML에 주의하십시오. <small>...</small> 태그는 미세한 인쇄의 의미적 의미를 가지고 있으므로 스타일론적 변경에 사용하지 마십시오.

다른 언어

비영어 단어 또는 구문은 ISO 639 언어 코드를 사용하는 {{lang}}에 감싸야 하므로 다음과 같다.

{{lang fr Assemblée nationale}}

로서 렌더링되는.

콰슬레

또는 {{lang-fr Assemblée nationale}}

로서 렌더링되는.

프랑스어: assembleée nationale.

근거: {{lang}} 음성 신디사이저가 텍스트를 올바른 언어로 발음할 수 있도록 한다.[2] 다른 용도가 많다. 템플릿:Lang/doc § 종합적인 유익성 목록에 대한 근거.

이러한 구조물을 이탤릭체 마크업으로 포장할 필요는 없고 바람직하지도 않다. {{lang}} 그리고 {{lang-xx}} 템플릿이 이미 자동 초기화됨.

번역기는 대신 {{transl}}을 사용하고 발음은 {{ternal}을 사용해야 한다는 점에 유의하십시오.IPA}, {{respell}} 또는 관련 템플릿 {{PI}}}은 프로토-인도-유럽어를 위한 것이다.

링크

  1. 특히 외부 링크에 대해 좋은 링크 설명을 만드십시오("여기를 클릭!", "이것"[3][4]은 제외).
  2. 유니코드 문자를 아이콘으로 사용하지 마십시오. 대신 Alt 텍스트가 있는 아이콘을 사용하십시오. 예를 들어, "→"와 같은 문자는 일부 화면 판독기에 의해 유용한 텍스트로 복제될 수 없다.

Two screenshots of the same highly textual user interface. The top one uses red, green, and blue; the bottom one uses nearly the same color for red and green, so that the red text becomes nearly invisible in its green background.
빨간색/녹색 색맹이 가독성에 미치는 영향을 보여주는 스크린샷 한 쌍

색상가장 흔하게 위키백과 기사에서 템플릿과 표에 수록되어 있다. 색 사용 방법에 대한 기술 지원은 도움말을 참조하십시오.색상을 사용한다.

색상을 사용하는 기사(및 기타 페이지)는 다음과 같이 접근성을 염두에 두어야 한다.

  • 색상이 중요한 정보를 전달하는 데 사용되는 유일한 방법이 아닌지 확인하십시오. 특히 범례와 일치하는 접근 가능한 기호각주 레이블과 같은 다른 방법을 사용하여 상태가 표시되는 경우가 아니면 색칠된 텍스트나 배경을 사용하지 마십시오. 그렇지 않으면, 시각장애인 사용자나 독자들이 컬러 스크린이 없는 인쇄물이나 장치를 통해 위키피디아에 접속하는 것은 그 정보를 받지 못할 것이다.
  • 링크는 우리의 독자에 대한 링크로서 분명히 식별될 수 있어야 한다.
  • 위키피디아의 일부 독자들은 부분적으로 또는 완전히 색맹이거나 시각장애가 있다. 배경과 텍스트의 대비가 최소한 Web Content Accessibility Guideline(WCAG) 2.0의 AA 수준 및 가능한 경우 AAA 수준에 도달하도록 한다(WCAG의 "SC 1.4.3: 대비(최소) 이해" 참조). 흰색 배경에 있는 텍스트에 명명된 CSS 색상을 사용하려면 위키백과를 참조하십시오.권장 색상에 대해 흰색 텍스트에 대한 스타일/접근성/CSS 색상 설명서 다른 용도의 경우 대조가 올바른지 확인하는 데 사용할 수 있는 도구를 선택하십시오.
    • 색상 대비 분석기를 사용하면 페이지에서 색상을 선택하고 색상의 대비를 철저히 검토할 수 있다. 단, 구식인 "색 밝기/차이"가 아닌 최신의 "조도" 알고리즘만 사용해야 한다.
    • 2015년 1월 11일 현재 최신 제품인 스누크 컬러 콘트라스트 체크도 사용할 수 있다.
    • Wikimedia Foundation Design 팀은 AA 준수를 향해 표시된 색상을 가진 색상 팔레트를 제공했다. 그것은 제품 전체와 주요 위키미디어 테마인 데스크탑과 모바일에서 모든 사용자 인터페이스 요소에 사용된다. 그러나 링크된 텍스트는 고려하지 않는다.
    • 위키백과의 표:Manual of Style/Accessibility/Colors는 검정색 텍스트, 흰색 텍스트, 링크된 텍스트 및 방문한 링크된 텍스트에 대해 AAA와 호환되는 가장 어둡거나 가장 가벼운 배경을 찾는 14가지 색상의 결과를 보여준다.
    • 구글 크롬은 비주얼 가이드와 컬러 픽커가 탑재된 컬러 콘트라스트 디버거를 탑재했다.
    • 웹에는 몇 가지 다른 도구가 있지만 사용하기 전에 해당 도구가 최신인지 확인하십시오. 몇 가지 도구는 WCAG 1.0 알고리즘에 기초하고 있으며, 현재 참조는 WCAG 2.0 알고리즘이다. 도구에 WCAG 2.0을 기반으로 한다고 명시되어 있지 않은 경우, 구식이라고 가정하십시오.
  • 지도 등에 대한 그래픽 차트 및 색상표를 작성하는 데 도움이 되는 추가 도구를 사용할 수 있다. 이러한 도구는 대조 접근성을 검토할 수 있는 정확한 수단이 아니지만 특정 작업에 유용할 수 있다.
    • Paletton(이전의 Color Scheme Designer)은 그래픽 차트에 적합한 색상 세트를 선택하는 데 도움을 준다.
    • Color Brewer 2.0은 지도와 상세한 설명을 위한 안전한 색상표를 제공한다.
    • 가벼운 질적 색채 배색은 색맹 사용자를 위해 검정색 텍스트 라벨(다른 팔레트 중)과 함께 작동하는 9가지 색상의 세트를 제공한다.
    • 색맹 시각 시뮬레이션을 위한 몇 가지 도구가 있다. Toptal ColorFilter(웹 페이지 분석) 및 Coblis Color-blindness Simulator(로컬 파일 분석) 또한 웹 페이지 분석을 위한 브라우저 확장 기능: 컬러블링(크롬) 노코피(크롬) 노코피(불꽃)
    • 대비되는 색상을 선택하는 데 도움이 될 수 있는 매우 간단한 오픈소스 툴은 "Windows, Mac, Linux를 위한 무료 색맹 시뮬레이터인 Color Oracle"이다. 그것은 세 가지 유형의 색맹이나 회색 눈금을 가진 사람이 볼 수 있는 것처럼 화면에 있는 모든 것을 볼 수 있게 해준다.
  • 만약 어떤 기사가 색상을 너무 많이 사용하고, 당신은 그것을 스스로 고칠 줄 모른다면, 당신은 다른 편집자들에게 도움을 요청할 수 있다. 기사 상단에 ({{Overcolor}} 또는 {{Overcolored})를 놓으십시오.
등고선이 3(빨간색), 4.5(녹색), 7(파란색)인 웹 세이프 색상 대 검은색(맨 위 행) 및 흰색(하단)의 대비 비율

블록 요소

목록

빈 줄이나 표 형식의 열 구분을 놓아 목록 항목을 분리하지 마십시오. 여기에는 설명 목록(대부분의 대화 페이지 토론 형식인 세미콜론 또는 콜론으로 작성된 목록) 또는 순서 목록 또는 순서 없는 목록이 포함된다. 목록은 함께 속하는 요소들을 그룹화하는 것을 의미하지만, 미디어위키는 빈 줄을 하나의 리스트의 끝으로 해석하고 새로운 리스트를 시작할 것이다. 과도한 이중 줄 바꿈은 화면 판독기를 교란시키기도 하는데, 이는 한 줄만 의도했을 때 복수의 목록을 발표하게 되어 이러한 프로그램 사용자들을 오도하거나 혼란스럽게 할 수 있다. 이러한 부적절한 서식은 또한 목록을 읽는 데 걸리는 시간의 3배 이상을 차지할 수 있다.

마찬가지로, 하나의 목록에서 초기 목록 마커 유형(컬론, 별표 또는 해시 기호) 간에 전환하지 마십시오. 콜론과 별표, 그리고 때때로 해시 부호가 혼합된 글자로 시작하는 글자에 회신할 때, 위에서 사용된 글자의 모든 시리즈를 복사하고, 그러한 문자를 하나 더 추가해야 한다. 또는, 간단히 의견을 제시하고 새로운 토론(즉, 새로운 HTML 목록)을 시작하십시오.

예를 들어, 토론에서 do checkY 이 모범 사례:

* 지지. 나는 이 아이디어가 마음에 든다. —사용자:예: ** 질문: 뭐가 마음에 드니? —사용자:예2 **** 위키백과의 정신에 맞는 것 같다. —사용자:예: 

또는 checkY, 글머리 기호 없는 토론에서:

: 지지. 나는 이 아이디어가 마음에 든다. —사용자:예:: 질문: 뭐가 마음에 드니? —사용자:예2 ::: 위키백과의 정신에 맞는 것 같다. —사용자:예: 

이것 checkY도 허용 가능한 관행(회신에서 탄환을 억제하는 것):

* 지지. 나는 이 아이디어가 마음에 든다. —사용자:예: *: 질문: 뭐가 마음에 드니? —사용자:예2 *:: 위키백과의 정신에 맞는 것 같다. —사용자:예: 

그렇지만 ☒N 이 작업을 수행하지 않음(게시판 목록에서 설명 목록으로 유형 전환):

* 지지. 나는 이 아이디어가 마음에 든다. —사용자:예:: 질문: 뭐가 마음에 드니? —사용자:예2 

아닌 ☒N 이 값(게시판 목록에서 설명 목록으로 전환 유형):

* 지지. 나는 이 아이디어가 마음에 든다. —사용자:예:* 질문: 뭐가 마음에 드니? —사용자:예2 

아닌 ☒N 표시(목록 항목 사이에 빈 줄 유지):

* 지지. 나는 이 아이디어가 마음에 든다. —사용자:예: ** 질문: 뭐가 마음에 드니? —사용자:예2 

아닌 ☒N 이 값(둘 이상의 점프):

* 지지. 나는 이 아이디어가 마음에 든다. —사용자:예: *** 질문: 뭐가 마음에 드니? —사용자:예2 

이것은 일반적으로 낙담한다. ☒N:

: 지지. 나는 이 아이디어가 마음에 든다. —사용자:예:* 질문: 뭐가 마음에 드니? —사용자:예2 

이러한 탄환 주입은 불필요하게 목록 복잡성을 가중시키고 추가 탄환을 완전히 새로운 내포 목록으로 취급하는 화면 판독기의 토론을 더 어렵게 만든다.

목록 항목 내의 여러 단락

Normal MediaWiki 목록 표시는 유감스럽게도 일반 MediaWiki 단락 표시와 호환되지 않는다.

목록 항목에 여러 단락을 넣으려면, checkY로 구분한다. {{pb}}:

* 이것은 하나의 아이템이다.{{pb}}이 항목 내의 또 다른 단락이다. * 이것은 다른 아이템 입니다.  

이것 또한 할 수 있다. check문단에 대한 명시적 HTML 마크업이 있는 Y(마감참고) </p> 태그:

* 이것은 하나의 아이템이다.<p>이 항목 내의 또 다른 단락이다.</p> * 이것은 또 다른 항목이다.  

두 경우 모두 이 작업을 수행해야 한다. check단일 코드 라인에서 Y. 그러나 코드 줄 바꿈을 HTML 설명(출력 줄 바꿈으로 표시)으로 포장하여 코드 보기에서 더 나은 문단을 구분하는 방법을 선택적으로 사용할 수 있다.

* 이것은 하나의 아이템이다.<!- -->이것은 이 항목 내의 또 다른 단락이다.</p> * 이것은 또 다른 항목이다.  

이 기법은 사용할 수 있다. check목록 항목 내의 다양한 형태의 블록-폐쇄에 대한 Y(목록 항목은 기술적으로 다른 블록 요소를 포함할 수 있는 블록 요소이기 때문에):

* 이것은 하나의 아이템이다.<!- -->이것은 이 항목 안에 있는 또 다른 단락으로, 우리는 누군가를 인용할 것이다:</p><!-->{{토크 인용 블록 지구상의 모든 모든 사람에게 모든 인간 지식의 합계를 자유롭게 접할있는 세상을 상상해보자. 짐보}<!--->.이것은 같은 목록 항목 내의 닫는 단락이다.</p> * 이것은 또 다른 항목이다.  

모든 화려한 템플릿이 이러한 방식으로 사용될 수 있는 것은 아니라는 점에 유의하십시오(예: 일부 장식적인 인용 템플릿은 테이블 기반이며, MediaWiki 파서는 목록 항목 안에 있는 것과 같은 마크업을 처리하지 않는다).

위키백과를 참조하십시오.복잡한 설명/화질/관련 목록의 풍부하지만 접근하기 쉬운 표식을 위한 스타일/광택 매뉴얼.

하지마 ☒N은 문단을 시뮬레이션하기 위해 줄 바꿈을 사용한다. 왜냐하면 문단은 다른 의미론을 가지고 있기 때문이다.

* 이것은 하나의 아이템이다.<br />이 같은 단락인데, 앞에 줄 바꿈이 있다.*이것은 또 다른 항목이다.  

줄 바꿈 태그는 시의 선이나 소스 코드 블록과 같은 단락 에서 포장을 위한 것이다. 및 MediaWiki 태그를 참조하십시오.

절대 안 돼 ☒N은 (위에서 언급한 바와 같이) 세 개의 별도 목록을 생성하기 때문에 들여쓰기 레벨에 맞추기 위해 콜론을 사용하려고 한다.

* 이것은 하나의 항목이다. : 이것은 완전히 별개의 목록이다. * 이것은 세번째 목록이다.  

또는, 당신은 할 수 있다. checkYHTML 목록 템플릿 중 하나를 사용하여 그룹화를 보장한다. 이는 다음 목록에 형식 코드와 같은 블록 요소를 포함할 때 가장 유용하다.

{{벌룬 리스트 1=이것은 하나의 항목 : <프리> 이것은 어떤 코드다. </준비> 이것은 여전히 같은 품목이다.  2=이것은 제2품목이다. }} 

그러나 이 기술은 토크 페이지에서는 사용되지 않는다.

들여쓰기

들여쓰기에 대한 접근 가능한 접근방식은 템플릿이다. {{block indent}} 다중 회선 콘텐츠의 경우, CSS를 사용하여 재료를 들여씁니다. 단일 라인의 경우 다음을 포함한 다양한 템플릿이 존재한다. {{in5}} (모든 Wikimedia 사이트에서 동일한 이름을 가진 범용 템플릿), 공백 문자를 포함한 들여쓰기. 을 남용하지 마십시오. <blockquote>...</blockquote> 이를 사용하는 요소 또는 템플릿(예: {{blockquote}} AKA {{quote}}시각적 들여쓰기의 경우, 직접 인용한 자료에만 해당된다.{{block indent}} 일반 대안이 이러한 비반복 사례에 대해 작성되었으므로 이를 사용하십시오.

결장(A colon):줄의 시작 부분에 MediaWiki 파서의 해당 줄을 <dd> HTML 설명 목록의 일부(<dl>대부분의 웹 브라우저에서 시각적 효과는 선을 들여쓰는 것이다.[b] 예를 들어, 이것은 대화 페이지의 줄무늬 토의에서 응답을 나타낼 때 사용된다. 그러나 이 마크업만으로는 필요한 항목이 누락되어 있다. <dt> (용어) 설명 목록의 요소로서, 이 요소에는 <dd> (직접/정의) 관련 사항. 브라우저로 전송된 코드를 검사함으로써 알 수 있듯이, 이로 인해 HTML이 손상된다(즉, 유효성[5] 검사에 실패함). 스크린리더 등 보조기술이 존재하지 않는 설명 목록을 발표하게 돼 위키피디아의 깨진 마크업(markup)에 익숙하지 않은 방문객이라면 누구나 헷갈릴 수밖에 없는 결과다. 이는 접근성, 의미론 또는 재사용에는 적합하지 않지만, 화면 판독기의 사용자에게 야기되는 문제에도 불구하고 현재 일반적으로 사용되고 있다.

특히 기사 내용에서 콜론 인텐트 텍스트사이에 빈 줄을 배치해서는 안 된다. 이것은 소프트웨어에 의해 목록의 끝과 새로운 목록의 시작을 표시하는 것으로 해석된다.

공간이 필요한 경우 두 가지 접근법이 있는데, 이는 화면 판독기의 결과가 다를 것이다.

첫 번째는 빈 줄 위와 아래에 텍스트 앞에 있는 것과 동일한 수의 콜론이 그려진 빈 줄을 추가하는 것이다. 이것은 두 편집자가 동일한 들여쓰기 수준에서 서로 바로 직후에 의견을 내고 있을 때 적절하다. 예를 들어,

: 전적으로 동의한다. —사용자:예: : 납득할 수 없다. 더 좋은 자료가 있을까? –사용자:예2 

이렇게 하면 화면 판독기에 이 항목이 두 가지 목록 항목(빈 항목은 무시됨)임을 알 수 있다.

두 번째 접근방법은 자료가 단일 주석(또는 기타 목록 항목(예: 기사 텍스트)일 경우)에 대해 동일한 출력 라인에 새로운 단락 마크업을 사용하는 것이다(이러한 고급 기법은 복잡한 내용 블록을 포함하기 위해 이전 섹션 참조).

: 여기 문자.{{pb}}문자 더보기. —사용자:예3 

수학 공식이나 식을 자신의 선에 표시하려면 다음과 같이 하는 것이 좋다. <math display="block">1 + 1 = 2</math> 대신에 사용되다 :<math>1 + 1 = 2</math>.

수직 리스트

글머리표 수직 리스트

글머리표 수직 목록의 경우 항목 사이에 빈 줄을 남겨서 항목을 구분하지 마십시오. 목록 항목을 둘 이상의 줄 바꿈으로 구분하면 줄 바꿈 이전에 HTML 목록이 종료되고 줄 바꿈 후 또 다른 HTML 목록이 열린다. 이것은 화면 판독기를 사용하는 사람들을 위해 하나의 목록으로 보이는 것을 몇 개의 작은 목록으로 효과적으로 깨뜨린다. 예를 들어, 코딩의 경우:

*흰장미 *노란장미 *핑크장미 *붉은장미 

소프트웨어는 라인 공간을 부분적으로 억제하므로 다음과 같이 보인다.

  • 흰장미
  • 노란장미
  • 핑크 로즈
  • 붉은 장미

화면 리더는 다음과 같이 읽는다: "2개 항목 목록: (불렛) 흰 장미, (불꽃) 노란 장미, 목록 끝. 1개 항목 목록: (불렛) 핑크 로즈, 목록 끝. 1개 품목 리스트 : (불렛) 붉은 장미, 목록 끝."

줄 바꿈이 있는 목록 항목을 구분하지 마십시오.<br />) 목록을 수직으로 유지하려면 {{plainlist}} / {{unbulleted list}}을 사용하고, 다음 두 절에서 설명한 대로 목록을 수평으로(인라인) 더 잘 렌더링할 수 있다면 {{flatlist} / {{hlist}}}을 고려하십시오.

글머리 기호 해제된 수직 목록

페이지 아래로 실행 중인 글머리표 없는 목록의 경우, 템플릿 {{plainlist} 및 {{글머리표 목록}을(를) 사용할 수 있어, 다음을 포함하지 않고 명료하게 목록인 것을 표시하여 접근성과 의미적 의미성을 향상시킨다. <br /> 사용해서는 안 되는 줄 바꿈. 위 참조. 그들은 목록을 만드는 데 사용되는 위키 마크업에서만 다르다. 이들은 템플릿이기 때문에 각 목록 항목의 텍스트에는 세로 막대 기호를 포함할 수 없다는 점에 유의하십시오. (로 대체되지 않는 한) {{!}} 또는 안에 포함되어 있다. <nowiki>...</nowiki> 태그. 이와 유사하게 등호(등호)를 포함할 수 없다.=), 로 대체되지 않는 한 {{=}} 또는 안에 포함되어 있다. <nowiki>...</nowiki>파라미터의 이름을 지정하면 바이패스할 수 있지만( 1=, 2= 등). 이것이 너무 번거로워지면 대신 {{endplainlist}}}를 사용하여 변종을 사용할 수 있다. 참고문헌에는 대신 {{unbulleted list citterbundle}이(가) 필요할 수 있다.

일반 목록 예제
위키텍스트 렌더링:
{{plainlist*흰 장미 *노란 장미 *핑크 장미 *빨간 장미}}}}}
  • 흰장미
  • 노란장미
  • 핑크 로즈
  • 붉은 장미
글머리 기호 표시 안 함 목록 예제
위키텍스트 렌더링:
{{unbulleted list White Rose Yellow Pink Rose Red Rose}}}}
  • 흰장미
  • 노란장미
  • 핑크 로즈
  • 붉은 장미

또는, Navbox와 같은 템플릿 또는 적절한 컨테이너에서 이러한 목록은 클래스 "로 스타일링될 수 있다.plainlist", 따라서:

  • listclass = plainlist 또는
  • bodyclass = plainlist

infobox의 경우:

  • rowclass = plainlist 또는
  • bodyclass = plainlist

사용될 수 있다.

또한 Manual of Style: Lists Unbulleted 목록을 참조하십시오.

수평 목록

페이지 전체에서 실행 중인 목록과 infobox 및 기타 테이블의 단일 행에 대해서는 {{flatlist}, {{hlist}}('수평 목록'의 경우) 템플릿을 사용하여 접근성과 의미적 의미성을 개선할 수 있다. 이 기능은 각 목록 항목에 대해 올바른 HTML 마크업을 사용하며, 예를 들어, 읽혀지는 글머리 문자를 포함하지 않는다(예: "점묘 도트 도트 말 점").") 시각장애인이 사용하는 보조 소프트웨어에 의해. 템플릿은 목록을 만드는 데 사용되는 위키 마크업에서만 다르다. 텍스트가 이러한(또는 다른) 템플릿으로 전달될 때 세로 막대 문자( )는 {{!}}.

플랫리스트의 예
위키텍스트 렌더링:
{{플랫리스트 *흰장미*빨간장미*핑크장미*노란장미}}}}
  • 흰장미
  • 붉은 장미
    • 핑크 로즈
  • 노란장미
hlist의 예
위키텍스트 렌더링:
{{hlist 화이트 로즈 레드 로즈 핑크 로즈 옐로 로즈 }}}
  • 흰장미
  • 붉은 장미
  • 핑크 로즈
  • 노란장미

또는 Navbox와 같은 템플릿 또는 적절한 컨테이너에서 이러한 목록은 클래스에 따라 스타일링될 수 있다. hlist, 따라서:

  • listclass = hlist 또는
  • bodyclass = hlist

infobox의 경우:

  • rowclass = hlist 또는
  • bodyclass = hlist

사용될 수 있다.

표제목

목록 앞에 "가짜 제목"을 굵게 표시하기 위해 세미콜론을 부적절하게 사용하면 목록 공백이 생기고, 더 심해진다. 세미콜론 선은 설명 내용이 없는 단일 항목 설명 목록이며, 두 번째 목록이 뒤따른다.

대신 머리글 표시(그림 2)를 사용하십시오.

☒N 1. 부정확함

; 노블 가스 * 헬륨 * 네온 * 아르곤 * 크립톤 * 제논 * 라돈 

checkY 2. 헤딩

== 노블 가스 == * 헬륨 * 네온 * 아르곤 * 크립톤 * 제논 * 라돈 

테이블

화면 판독기와 다른 웹 검색 도구는 사용자가 화면 판독기에 포함된 데이터를 탐색하는 데 도움이 되는 특정 테이블 태그를 사용한다.

올바른 위키 파이프 구문을 사용하여 사용 가능한 모든 기능을 활용하십시오. 메타 참조:도움말:테이블에 사용되는 특수 구문에 대한 자세한 정보를 보려면 . 의미적 의미(예: 배경색 변경)를 만들기 위해 CSS 또는 하드 코드 스타일 형식만 사용하지 마십시오.

많은 네비박스, 시리즈 템플릿, 인포박스는 테이블을 사용하여 만들어진다.

사용하지 마십시오. <br /> 또는 <hr /> HTML 테이블 구조에 반영되지 않은 시각적 행을 에뮬레이트하기 위한 인접 셀의 태그. 테이블 셀을 셀로, HTML 행을 HTML 행으로 읽는 화면 판독기 사용자들의 문제인데 비주얼 행으로 읽는 것이 아니다. 위키프로젝트 접근성/인포박스 접근성은 이 문제를 해결해왔다.

데이터 테이블

{ + + [cope text] - ! scope="col" [coll] ! scope="col" [coll] [열 헤더 3] - ! scope="row" [row 헤더 1] [정상 셀 1,3] [정상 셀 2,2] [정상 셀 2,3] ...  } 
캡션(자막) + )
자막은 표의 제목이며 표의 본질을 묘사한다.[WCAG-TECH 1] 데이터 테이블에는 항상 캡션이 포함되어야 한다.
행 & 열 헤더 ( ! )
캡션과 마찬가지로, 이것들은 방문자들에게 정보를 논리적인 구조로 제시하는데 도움이 된다.[WCAG-TECH 2] 헤더 도움말 화면 판독기는 데이터 셀에 대한 헤더 정보를 렌더링한다. 예를 들어, 헤더 정보는 셀 데이터 이전에 말하거나, 헤더 정보가 요청에 따라 제공된다.[6] 테이블 모드에서 이동할 때 각 셀의 데이터 앞에 행 머리글과 열 머리글을 말할 수 있으므로 열 머리글과 행 머리글이 각각 열과 행을 고유하게 식별해야 한다.[7]
헤더 범위(! scope="col" 그리고 ! scope="row" )
이것은 행 헤더 또는 열 헤더로 분명하게 헤더를 식별한다. 이제 헤더를 해당 셀에 연결할 수 있다.[WCAG-TECH 3]

위키백과:스타일/접근성/데이터 테이블 자습서에서는 다음에 대한 자세한 요구 사항을 제공한다.

  1. 올바른 표 캡션
  2. 올바른 헤더 구조
  3. 복합 테이블
  4. 이미지 및 색상
  5. 중첩 테이블 방지

레이아웃 테이블

표 이외의 내용을 시각적으로 배치할 때는 표를 사용하지 마십시오. 데이터 테이블은 콘텐츠에 논리적 행과 열 관계가 없을 때 혼동될 수 있는 추가 정보와 탐색 방법을 제공한다. 대신 의미론적으로 적절한 요소를 사용하거나 <div>s, 그리고 style 특성

표를 사용하여 표 이외의 내용을 배치하는 경우, 도움말 화면 리더는 표를 데이터 테이블이 아닌 레이아웃 테이블로 식별한다. 설정 a role="presentation" 테이블의 속성, 설정하지 않음 summary 기여하다 사용 안 함 <caption> 또는 <th> 표 내부 또는 내포된 표 내부 요소. wiki 테이블 마크업에서, 이것은 다음 항목을 사용하지 않음을 의미한다. + 또는 ! 접두사 내용의 판독 순서가 올바른지 확인하십시오. 스타일시트나 의미 요소를 사용하여 중심이나 굵은 서체와 같은 시각적 효과를 얻을 수 있다. 예를 들면 다음과 같다.

{role="presentation" class="toccolors" style="width:94%" - colspan="2" style="text-align:"중요색: #ccf;"중요 텍스트 &quot;강력함&quot; - 빠른 갈색여우는 게으른 개를 뛰어넘는다.  } 

이미지

  1. 순수하게 장식적이지 않은 이미지와 아이콘은 시각장애 판독기, 검색 스페이더 및 기타 비시각적 사용자의 이미지를 대신하는 역할을 하는 알트 속성을 포함해야 한다. 추가 alt 텍스트가 추가되면 간결하거나 독자에게 캡션 또는 인접 텍스트를 참조해야 한다. WP 참조:자세한 내용은 ALT를 참조하십시오.아이콘에 대한 추가 고려사항은 위키백과:스타일/아이콘 설명서 § 시각 장애인을 위한 접근성을 기억하라.
  2. 대부분의 경우 이미지는 내장된 이미지 구문을 사용하는 캡션을 포함해야 한다. 캡션은 이미지의 의미와 이미지 전달을 위해 필요한 정보를 간결하게 기술해야 한다.
  3. 테이블이나 차트 대신 이미지를 사용하지 마십시오. 가능한 경우, 차트나 도표는 텍스트와 동등해야 하며 이미지를 볼 수 없는 사용자가 개념을 어느 정도 이해할 수 있도록 잘 설명해야 한다.
  4. 반드시 필요하지 않은 경우 두 이미지 사이에 텍스트가 샌드위치되지 않도록 하거나 고정된 이미지 크기를 사용하십시오.
  5. 화면 크기와 브라우저 형식은 단편화된 이미지 표시로 인해 일부 독자의 접근성에 영향을 미칠 수 있으므로 무분별한 갤러리 섹션은 피하십시오.
  6. 텍스트에서 이미지를 왼쪽 또는 오른쪽에 표시하지 마십시오. 이미지 배치는 모바일 사이트의 시청자들에게는 다를 수 있으며, 보조 소프트웨어로 페이지를 읽는 사람들에게는 의미가 없다. 대신 캡션을 사용하여 이미지를 식별하십시오.
  7. 기사에 적합하지 않은 경우 자세한 이미지 설명은 이미지 설명 페이지에 배치해야 하며, 이미지 링크를 활성화하면 보다 자세한 설명이 제공된다는 메모가 첨부되어야 한다. 도움말 참조:파일 설명 페이지#이미지 요약
  8. 이미지는 (제목 후 및 다른 기사에 대한 링크 후) 관련 섹션 안에 있어야 하며, 제목 자체나 이전 섹션의 끝에 있어서는 안 된다. 이렇게 하면 화면 판독기가 올바른 섹션에 있는 이미지(및 텍스트 대안)를 읽고 모바일 사이트를 표시할 수 있다.
  9. 이 지침은 모드의 LaTeX 형식 방정식에 대한 alt 텍스트를 포함한다. 위키백과 참조:스타일/수학 설명서#Alt 텍스트
  10. 이미지를 머리글에 넣지 마십시오. 아이콘과 마크업이 여기에 포함된다. 그렇게 하면 섹션에 대한 연결이 끊어지고 다른 문제가 발생할 수 있다.

애니메이션, 비디오 및 오디오 콘텐츠

애니메이션

애니메이션(GIF – 그래픽 교환 형식)에 액세스하려면 다음 중 하나를 수행해야 한다.

  • 5초 이하의 지속시간(순전히 장식적인 요소로 만드는 결과)[8] 또는
  • 제어 기능 장착(정지, 일시 중지, 재생)[9]

이를 위해서는 5초 이상 애니메이션이 포함된 GIF를 비디오로 변환해야 한다(자습서 참조, 애니메이션 GIF를 Theora OGG로 변환하는 방법 참조).

또한 애니메이션은 1초 동안 3개 이상의 플래시를 생성해서는 안 된다. 그 한계보다 더 번뜩이는 내용물은 발작을 일으키는 것으로 알려져 있다.[10]

비디오

자막은 시간 제한 텍스트 형식으로 동영상에 추가할 수 있다. 커먼즈에는 해당하는 도움말 페이지가 있다.공용:비디오#부제목폐쇄 캡션. 자막은 말을 옮겨 적는 것을 의미한다.

청각 장애인을 위한 폐쇄적인 자막이 필요하다. 2012년 11월 현재 이것은 가능하지 않지만, 이 기능은 쉽게 추가할 수 있고 bugzilla:41694에서 요청되었다. 자막은 자막 대신에 보는 것을 의미한다. 폐쇄 캡션은 소리를 통해 제공되는 모든 중요한 정보의 텍스트 버전을 제공한다. 그것은 대화, 소리(자연적, 인위적), 배경과 배경, 사람과 동물의 행동과 표현, 텍스트나 그래픽을 포함할 수 있다.[11] 폐쇄 캡션을 만드는 방법은 오프위키피디아 가이드를 참조해야 한다.[12]

시각장애인을 위한 텍스트 버전도 필요하겠지만 2012년 11월 현재 비디오에 대한 텍스트는 제공할 수 있는 편리한 방법이 없다.

오디오

음성, 가사,[13] 대화 등의 자막은 오디오 파일에 쉽게 추가할 수 있다. 이 방법은 동영상의 방법과 유사하다: 공유:공용:비디오#부제목폐쇄 캡션.

스타일 및 마크업 옵션

모범 사례: 대안보다 Wiki 마크업 및 CSS 클래스 사용

일반적으로 테이블 및 기타 블록 레벨 요소의 스타일은 인라인 스타일 속성이 아닌 CSS 클래스를 사용하여 설정해야 한다. MediaWiki의 사이트 전체 CSS:Common.css는 접근성(예: 충분한 색상 대비)과 광범위한 브라우저와의 호환성을 보장하기 위해 보다 세심하게 테스트된다. 게다가, 그것은 매우 특정한 요구를 가진 사용자들이 자신의 스타일시트에서 색 구성표를 변경할 수 있게 해준다(특수:MyPage/skin.css 또는 해당 브라우저의 스타일 시트). 예를 들어, 위키백과의 스타일 시트:시각 장애인 사용자를 위한 스타일시트내비게이션 박스에 더 높은 대비 배경을 제공한다. 문제는 기본 사이트 전체 클래스가 재정의되면 개인이 자신의 테마를 선택하기가 훨씬 더 어려워진다는 점이다.

또한 기사 간의 일관된 외관을 보장하고 스타일 가이드를 준수함으로써 보다 높은 수준의 전문성을 창출한다.

접근성과 관련하여 표준 규약으로부터의 이탈은 접근 가능한 허용될 수 있다. 접근성 프로젝트의 구성원들은 기본 스타일에 접근할 수 있도록 보장했다. 일부 템플릿 또는 특정 색상표가 표준에서 벗어나는 경우, 작성자는 충분한 색상 대비 제공과 같은 접근성 요건을 충족하는지 확인해야 한다. 예를 들어, 스포츠 팀과 관련된 infoboxnavbox는 팀 리그의 색상과 연결하기 위해 노란색과 빨간색 배색을 사용할 수 있다. 이 경우 연한 노란색에 있는 진한 빨간색 링크는 충분한 색 대비를 제공하므로 접근할 수 있는 반면, 노란색에 흰색 또는 빨간색에 검정색 링크는 그렇지 않다.

일반적으로 기사는 제한된 HTML 요소 집합보다 위키 마크업을 사용해야 한다. 특히 HTML 스타일 요소를 사용하지 마십시오. <i> 그리고 <b> 텍스트 형식을 지정한다. Wiki-markup을 사용하는 것이 바람직하다. '' 또는 ''' 순수하게 활자화된 기울임꼴화 및 굵게 보이는 경우 각각 의미 있는 마크업 템플릿 또는 요소를 사용하여 보다 의미 있는 차이점을 확인하십시오.<font> 기사 텍스트에서도 요소 사용을 피해야 한다. {{em}}, {{code}}, {{var}}, 그리고 시각적 차이뿐만 아니라 논리적 차이를 강조하기 위해 필요한 다른 의미론적 마크업 템플릿. 다음과 같은 CSS 스타일 속성으로 명시적으로 설정하지 않고 {{resize}, {{small}, {{big}} 템플릿을 사용하여 글꼴 크기를 변경하십시오. font-size 또는 다음과 같은 사용되지 않는 스타일 요소 <big>. 물론 자연적인 예외도 있다. 예를 들어, 그 예외를 사용하는 것이 유익할 수 있다. <u>...</u> 실제로 클릭할 수 없는 예제 링크와 같은 것을 나타내기 위한 요소. 그러나 밑줄 긋기는 일반적으로 기사 텍스트에서 사용되지 않는다.

CSS 또는 JavaScript 지원이 제한된 사용자

기사 본문의 내용을 숨기기 위해 자동 충돌(사전 충돌) 요소를 사용해서는 안 된다.

위키백과 기사는 자바스크립트캐스캐이딩 스타일시트에 대한 지원이 제한되거나 없는 브라우저와 장치를 사용하여 독자들이 접근할 수 있어야 한다. 위키백과 내용은 우리가 예측할 수 없는 방식으로 자유롭게 재사용될 수 있을 뿐만 아니라 오래된 브라우저를 통해 직접 접근할 수 있다는 것을 기억하라. 동시에, 그러한 유저에게 더 유능한 브라우저를 가진 유저에게 이익이 되는 기능을 불필요하게 회피하지 않고서는, 그러한 유저에게 동일한 퀄리티를 제공하는 것이 불가능하다는 것을 인식한다. 이와 같이 CSS 또는 JavaScript를 사용할 수 없을 때 콘텐츠가 숨겨지거나 손상되는 기능은 사용하지 않아야 한다. 단, CSS나 자바스크립트가 없는 사용자에 대한 배려가 주로 자신의 독서 경험이 가능한지 확인하는 데까지 확대되어야 하며, 열등할 수밖에 없다는 인식이 있다.

이러한 고려사항을 수용하려면 JavaScript 또는 CSS를 사용하지 않도록 설정한 상태에서 운영 중단 가능성이 있는 변경 사항을 테스트하십시오. Firefox나 Chrome에서는 Web Developer 확장으로 쉽게 이 작업을 수행할 수 있으며, JavaScript는 "옵션" 화면의 다른 브라우저에서 비활성화할 수 있다. 여러 브라우저, 미디어 및 XHTML 버전에서 지원되지 않는 인라인 CSS 효과에 특히 주의하십시오.

2016년 위키백과 방문자의 약 7%가 자바스크립트 자원을 요청하지 않았다.[14]

참고 항목

참고 및 참조

특정

  1. ^ infobox와 navbox의 일반적인 글꼴 크기는 페이지 기본값의 88%이다. 참조 섹션의 일반 글꼴 크기는 페이지 기본값의 90%이다. 추가 값은 MediaWiki에서 찾을 수 있다.common.css.
  2. ^ HTML 설명 목록은 이전에는 정의 목록연결 목록이라고 불렸다.<dl><dt>...</dt><dd>...</dd></dl> 구조는 같다; HTML 명세서 버전 사이에 용어만 바뀌었다.
  1. ^ "F26: Failure of Success Criterion 1.3.3 due to using a graphical symbol alone to convey information". Techniques for WCAG 2.0. World Wide Web Consortium. Retrieved 1 January 2011.
  2. ^ H58: 언어 속성을 사용하여 인간 언어의 변화를 식별하는 방법, WCAG 2.0, W3C, 접근성 수준: AA.
  3. ^ "G91: Providing link text that describes the purpose of a link". Techniques for WCAG 2.0. World Wide Web Consortium. Retrieved 1 January 2011.
  4. ^ "F84: Failure of Success Criterion 2.4.9 due to using a non-specific link such as "click here" or "more" without a mechanism to change the link text to specific text". Techniques for WCAG 2.0. World Wide Web Consortium. Retrieved 1 January 2011.
  5. ^ "Markup Validation Service: Check the markup (HTML, XHTML, …) of Web documents". validator.w3.org. v1.3+hg. World Wide Web Consortium. 2017. Retrieved December 13, 2017. 보고된 검증자 장애는 "오류: 요소"입니다. dl 필수 하위 요소가 누락되어 있는 경우
  6. ^ "Table cells: The TH and TD elements". Techniques for WCAG 2.0. World Wide Web Consortium. Retrieved 1 January 2011.
  7. ^ "Tables with JAWS". Freedom Scientific. Retrieved 18 February 2021.
  8. ^ "Setting animated gif images to stop blinking after n cycles (within 5 seconds)". Techniques for WCAG 2.0. World Wide Web Consortium. Retrieved 1 January 2011.
  9. ^ "Allowing the content to be paused and restarted from where it was paused". Techniques for WCAG 2.0. World Wide Web Consortium. Retrieved 1 January 2011.
  10. ^ "Guideline 2.3 Seizures: Do not design content in a way that is known to cause seizures". Web Content Accessibility Guidelines (WCAG) 2.0. World Wide Web Consortium. 11 December 2008. Retrieved 28 May 2015.
  11. ^ "Providing an alternative for time based media". Techniques for WCAG 2.0. W3C. Retrieved 1 January 2011.
  12. ^ 폐쇄 캡션에 대한 빠르고 기본적인 참조, 상세 참조(PDF)폐쇄 캡션에 대한 모범 사례 목록을 참조하십시오.
  13. ^ "Providing an alternative for time-based media for audio-only content". Techniques for WCAG 2.0. World Wide Web Consortium. Retrieved 1 January 2011.
  14. ^ 파일:Browers, 지리 및 Wikipedia Portal의 JavaScript 지원.pdf파일:위키백과 포털 트래픽자바스크립트 지원 분석.pdf.

일반

기술

외부 링크