위키백과:편집 지침/접근성

독자들이 웹 페이지를 쉽게 찾고 읽으려면 웹 접근성이 꼭 필요합니다. 장애인들이 웹 페이지를 읽을 때 웹 접근성은 매우 중요하지만, 모든 독자에게 웹 페이지 접근성은 문서를 찾고 읽는 데 도움이 됩니다. 우리는 WCAG 가이드라인 2.0(ISO/IEC 40500:2012)에서 제안한 내용을 기반으로 이를 준수하는 것을 목표로 합니다. 이 접근성을 도입한 글은 누구든지 쉽게 읽고 편집할 수 있습니다.

문서 구조

표준화된 문서 구조는 독자가 페이지의 특정한 부분의 내용을 예상할 수 있게 하며 페이지 접근성도 올려 줍니다. 예를 들어 시각장애인 사용자가 동음이의 문서를 검색하고 있다고 합시다. 만약 페이지 맨 위에 아무 것도 없다면, 사용자는 그 문서엔 자기가 찾을 내용이 없다고 생각하고 문서를 읽지 않을 것입니다.

표준화는 위키백과 내에서 이미 자리잡은 것 중 하나입니다. 구조 관련해서 따라야 할 지침으로는 위키백과:문단 구성 및 위키백과:편집 지침/도입부 단 둘 뿐입니다.

문단 제목

문단 제목은 문단의 내용을 잘 나타내고 있어야 할 뿐만 아니라 일관되게 정리되어 있어야 합니다.(같이 보기-각주-외부 링크)

또한 문단 제목은 2단계(==)부터 차례대로 있어야 하며 3단계(===)등도 하위 주제를 나타낼 때 쓰일 수 있습니다. 비연속적으로 아무렇게나 문단 제목을 쓰면 안되며, 한 단계를 건너뛰어도 안됩니다.

굵기 효과나 쌍반점을 사용하여 가짜 문단 제목을 만들지 마세요. 스크린 리더와 같은 접근성 보조 기계는 올바른 문단 제목에서만 잘 작동합니다. 만약 목차의 크기가 너무 커서 이를 줄이고 싶다면 {{목차숨김}}을 대신 사용하세요.

문단 제목의 올바른 예와 잘못된 예

올바른 예	혼란스러움	한 단계를 건너뜀	가짜 제목
[개요 자리] ==2단계 문단 제목== [2단계] ===3단계 문단 제목=== [3] ==2단계 문단 제목== [2] ===3단계 문단 제목=== [3] ====4단계 문단 제목==== [4] ==2단계 문단 제목== [2]	[개요 자리] ====4단계 문단 제목==== [4] ===3단계 문단 제목=== [3] ==2단계 문단 제목== [2] ==2단계 문단 제목== [2] ====4단계 문단 제목==== [4] ===3단계 문단 제목=== [2]	[개요 자리] [2단계 문단 제목이 사라짐] ===3단계 문단 제목=== [3] ==2단계 문단 제목== [2] [3단계 문단 제목이 사라짐] ====4단계 문단 제목==== [4] ==2단계 문단 제목== [2]	[개요 자리] ==2단계 문단 제목== [2단계] ===3단계 문단 제목=== [3] '''4단계 문단 제목''' [가짜 문단 제목] ==2단계 문단 제목== [2] ===3단계 문단 제목=== [3] ;4단계 문단 제목 [가짜 문단 제목] ==2단계 문단 제목== [2] ===3단계 문단 제목=== [3]

플로팅 요소

위키 코드에서, 플로팅 요소는 소속 문단 내부에 배치해야합니다. 이미지를 그 전 문단 맨 끝에 삽입하는 등의 일을 하지 마십시오. For example, an image may be displayed under a header due to other floating elements pushing it down, while in the wikisyntax it is placed at the top of the page. Images should be inserted inside the section they belong to.

해상도

Wikipedia articles should be accessible to readers using devices with small screens, or to readers using monitors with a low resolution. The lowest resolution that it is considered possible to support without adversely affecting other users is 1024×768; all articles should look acceptable at this resolution without excessive horizontal scrolling. This is sometimes an issue in articles with multiple images on both sides of the screen; although lower resolutions will tend to stretch paragraphs vertically, moving images apart in that direction, be careful not to add images or other floating content on both sides of the screen simultaneously. Large tables and images can also create problems; sometimes horizontal scrolling is unavoidable, but consider restructuring wide tables to extend vertically rather than horizontally.

글

 위키백과:편집 지침/서식 문서를 참고하십시오.

In articles, do not use strikethrough to remove objectionable text. Either comment it out with "<!--" and "-->" or remove it entirely. By default, most screen readers do not indicate presentational text attributes (bold, italic, underline) or even semantic text attributes (emphasis, importance, text deletion), so struck-out text is read normally along with any other text. (Editors who participate in Wikipedia policy and deletion debates are advised to turn on the sounding of text attributes when doing so, as struck text is very common in Wikipedia-internal discussions.)

Screen readers without Unicode support will generally read a character outside Latin-1 and Windows-1252 as a question mark, and even in JAWS, the most popular screen reader, Unicode characters are very difficult to read.

1. Provide a transliteration for all text in a non-Latin writing system where the non-Latin character is important in the original context such as names, places, things etc.
2. Do not use unpronounceable symbols such as ♥ (a heart symbol); use images with alt text instead.
3. Symbols that cause problems for screen readers may already have templates created to produce an image and alt text. An example is {{†}}; see Category:Image insertion templates for more.

Do not use techniques that require interaction to provide information, such as tooltips or any other "hover" text. Abbreviations are exempt from these requirements, so the {{abbr}} template may be used to indicate the long form of a word.

Do not insert line breaks within a sentence, since this makes it harder to edit with a screen reader. A single line break may follow a sentence, which may help some editors.

The use of reduced font sizes should be used sparingly. Avoid using smaller font sizes in elements that already use a smaller font size, such as infoboxes, navboxes and reference sections. In no case should the resulting font size drop below 85% of the page fontsize (or 11px).

다른 언어

 이 부분의 본문은 틀:Lang/설명문서 § 이점입니다.

 위키백과:편집 지침/텍스트 서식 설정 § Foreign terms 및 분류:다언어 지원 틀 문서를 참고하십시오.

한국어가 아닌 언어의 단어 및 어구는 ISO 639 언어 코드를 사용하는 {{lang}}을 이용해 표기되어야 합니다. 따라서:

{{lang|fr|Assemblée nationale}}

위와 같이 입력하면

Assemblée nationale

위와 같이 표시됩니다.

설명: {{lang}}은 음성 출력기가 글을 올바른 언어로 발음할 수 있게 해줍니다. 그 외에도 많은 쓰임새가 있으며, 이 틀의 사용으로 인한 이점은 틀:Lang/설명문서#이점을 참고하십시오.

링크

1. 링크가 어떤 링크인지 (특히 외부 링크) 알기 쉽게 기술해주세요. ("여기를 눌러주세요!", "여기"같은 표현은 지양할 것).
2. 아이콘과 같은 유니코드 문자는 피해주시고 대신에 아이콘을 대체할 수 있는 글을 써주세요. 예를 들어 "→"와 같은 문자는 스크린 리더에선 보이지 않고 물음표로 나올 수 있습니다.

색

 위키백과:색상 사용하기 및 위키백과:링크 색상 문서를 참고하십시오.

이 문서는 문서에서의 색 사용에 관한 것입니다. the civility essay dealing with colors에 대해서는 위키백과:틀의 색을 가지고 편집 분쟁하지 마세요 문서를 참고하십시오.

가독성에 있어서 적녹 색맹의 영향을 보여주는 스크린샷

색은 위키백과 틀과 표에서 흔하게 볼 수 있습니다. 색을 적용하는 법을 알고 싶다면 백:색 이용을 참고하십시오.

문서와 틀에 색을 쓰려면 아래와 같이 접근성을 염두에 두어야 합니다:

• 색은 중요한 정보를 전달하는 유일한 방법이 아님을 숙지하십시오. 특히 색이 지정된 텍스트나 배경은, 범례와 일치하는 접근성 심볼(accessible symbol)이나 각주 표시와 같은 방법을 사용하여 상태가 표시되지 않는 한 사용하지 마십시오. 그렇지 않으면 화면 표시기가 없는 기기나 인쇄물을 통해 위키백과를 이용하는 시각 장애 사용자는 해당 정보를 제공받지 못합니다.
• 링크는 어느 페이지로 링크되는지 독자가 확실하게 알 수 있게 보여야 합니다.
• 전맹인이나 전색맹인도 위키백과를 이용할 수 있으므로 문자색과 배경색의 명암비는 최소한 WCAG 2.0의 AA 단계, 그리고 가능하면 AAA 단계에 도달해야 합니다. 흰 바탕의 텍스트에 색명으로 CSS 색상을 적용하고 싶다면 위키백과:편집 지침/접근성/흰 배경의 문자에 맞는 CSS 색상에서 추천하는 색을 참고하십시오. 다음은 WCAG 2.0을 준수하고 대비가 올바른지 확인하는 도구입니다:
  • TPGi의 색 대비 분석도구
  • Snook의 색 대비 분석도구
  • WebAIM의 색 대비 검사도구
  • 후캔유즈 (WhoCanUse)
  • 위키백과:편집 지침/접근성/색: 문서에 있는 표는, 검정 문자와 흰 문자, 링크된 텍스트, 방문한 적이 있는 링크된 텍스트에 대비해 AAA를 준수하는 가장 어둡거나 밝은 14가지 색조 결과를 보여줍니다.
  • 구글 크롬에 내장된 색 대비 디버거 (영어 소개글)
• 아래의 도구는 색 대비 접근성을 검토하기엔 정확하지 않지만, 지도 등에 쓰이는 도표나 색상표 만들기와 같은 특정 작업을 수행할 수 있습니다.
  • 팰레톤 (Paletton)은 도표에 적합한 색 집합(color set) 선정에 도움을 줍니다.
  • Color Brewer 2.0은 지도에 맞는 적절한 색상표를 제공합니다.
  • 밝은 색상표
• 색이 남용된 문서를 고치기 힘들다면 다른 편집자에게 도움을 청할 수 있습니다. ({{Overcolored}}를 문서의 상단에 놓으세요.

웹 안전 색상과, 흑백 또는 그 반대의 명암비. 3에는 적색, 4.5에는 초록색, 7에는 청색 구분선이 있음.

블록 구성요소

목록

 위키백과:편집 지침/목록 문서를 참고하십시오.

Do not separate list items, including items in a description list (a list made with leading semicolons and colons) or an unordered list, by leaving blank lines or tabular column breaks between them, since this causes MediaWiki to end one list and start a new one. This results in screen readers announcing multiple lists when only one was intended. Lists are meant to group elements that belong together, and breaking these groups will mislead and confuse a screen-reader user. Improper formatting can also more than triple the length of time it takes to read the list. Likewise, do not switch between list marker types (e.g. asterisks and colons), unless embedding lists starting at the highest level.

들여쓰기

 위키백과:토론 시 들여쓰기에 대한 안내 문서를 참고하십시오.

줄의 시작 부분에 있는 콜론은 줄을 들여씁니다. 예를 들어, 토론 문서의 스레드된 토론에 응답을 표시하는데 사용됩니다. 이 들여쓰기는 HTML 정의 목록을 사용하여 수행됩니다. 이것은 접근성이나 의미론에 이상적이지 않지만, 현재 널리 실용화되고 있습니다. 빈 줄은 목록의 끝과 새 줄의 시작으로 현재 랜더링되어 있으므로, 들여쓴 줄 사이에 사용하면 안됩니다. 공백이 필요한 경우, 동일한 수의 콜론으로 구성된 추가 행을 삽입하세요.

수직 목록

글 머리 기호 수직 목록

글 머리 기호가 있는 수직 목록의 경우, 항목 사이에 빈 줄을 두어 구분하지 않기를 바랍니다. 목록 항목이 2개 이상의 줄 바꿈으로 구분된 경우, 줄 바꿈 전에 HTML 목록이 끝나고 줄 바꿈 후에 다른 HTML 목록이 열립니다. 이것은 화면 판독기를 사용하는 사람을 위해 하나의 목록을 여러개의 작은 목록으로 효과적으로 구분합니다. 예를 들어, 코딩:

* White rose
* Yellow rose

* Pink rose

* Red rose

소프트웨어가 줄 공백을 억제하므로 다음과 같이 보입니다:

• White rose
• Yellow rose

• Pink rose

• Red rose

but will be read by a screen reader as: "List of 2 items: (bullet) White rose, (bullet) Yellow rose, list end. List of 1 items: (bullet) Pink rose, list end. List of 1 items: (bullet) Red rose, list end."

Do not separate list items with line breaks (<br>). Use one of the following methods.

구분 점 수직 목록

For unbulleted lists running down the page, the templates {{plainlist}} and {{unbulleted list}} are available, to improve accessibility and semantic meaningfulness by marking up what is clearly a list rather than including <br /> line breaks, which should not be used—see above. Alternatively, in templates such as Navboxes and the like, or any suitable container, such lists may be styled with the class "plainlist", thus:

| listclass = plainlist or

| bodyclass = plainlist

In infoboxes:

| rowclass = plainlist or

| bodyclass = plainlist

may be used. See also Manual of Style: Lists § Unbulleted lists. See WP:NAV for more details on Navigation templates.

수평 목록

For lists running across the page, and in single rows in infoboxes and other tables, the templates {{flatlist}} and {{hlist}} ("h[orizontal]list") are available to improve accessibility and semantic meaningfulness. This feature makes use of the correct HTML markup for each list item, rather than including bullet characters which, for example, are read out (e.g., "dot cat dot dog dot horse dot...") by the assistive software used by people who are blind.

또한, 둘러보기 상자와 같은 틀 또는 임의의 적합한 내용에서 그러한 목록은 종류 "hlist"로 지정할수 있습니다. 따라서:

| listclass = hlist 또는

| bodyclass = hlist가 사용될수 있습니다.

정보상자에서:

| rowclass = hlist 또는

| bodyclass = hlist가

사용될수 있습니다. 둘러보기 틀에 대한 자세한 내용은 위키백과:둘러보기를 참조하세요.

표

화면 판독기와 다른 웹 브라우징 도구는 특정 표 태그를 사용하여 사용자가 포함된 데이터를 탐색할수 있도록 도와줍니다.

Use the correct wikitable pipe syntax to take advantage of all the features available. See meta:Help:Tables for more information on the special syntax used for tables. Do not solely use formatting, either from CSS or hard-coded styles, to create semantic meaning (e.g., changing background colour).

Many navboxes, series templates, and infoboxes are made using tables.

Avoid using <br /> tags in adjacent cells to emulate a visual row that isn't reflected in the HTML table structure. This is a problem for users of screen readers which read tables cell by cell, HTML row by HTML row, not visual row by visual row. WikiProject Accessibility/Infobox accessibility has been addressing this problem.

데이터 표

{|
|+ [본문 설명]
|-
! scope="col" | [column header 1]
! scope="col" | [column header 2]
! scope="col" | [column header 3]
|-
! scope="row" | [row header 1]
| [normal cell 1,2] || [normal cell 1,3]
|-
! scope="row" | [row header 2]
| [normal cell 2,2] || [normal cell 2,3]
...
|}

Caption ( |+ )

A caption is a table's title, describing its nature.

Row & column headers ( ! )

Like the caption, these help present the information in a logical structure to visitors. The headers help screen readers render header information about data cells. For example, header information is spoken prior to the cell data, or header information is provided on request.

Scope of headers ( ! scope="col" | and ! scope="row" | )

This clearly identifies headers as either row headers or column headers. Headers can now be associated to corresponding cells.

Wikipedia:Manual of Style/Accessibility/Data tables tutorial provides detailed requirements about:

1. Correct table captions
2. Correct headers structure
3. Images and color
4. Avoiding nested tables

레이아웃 표

레이아웃 용도로만 표를 사용하는 것을 피하세요. 최선의 방법은 융통성을 제공하기 때문에 HTML의 <div> 블록 및 스타일 속성을 사용하는 것입니다.

For simple layouts tables can be an option. Especially if the only point of the table is to get a floating effect, then align="right" etc. will work with some browsers not supporting CSS at all. This is in fact a verbose approximation of <div> plus CSS, and not the design sin known as (nested) "table layout".

However, to avoid accessibility barriers, when using tables for layout purposes do not use any caption, row, or column headers, and also no summary attribute. These structural table elements should be used only for data tables. Do not use structural elements for presentation purposes, use style sheets. For Wiki table markup this means to avoid "!" (= <th> in XHTML) in such cases:

{| class="toccolours" style="width:94%"
| style="text-align: center; background-color: #ccf;" | '''Title'''
|-
| [normal cell] || [normal cell]
|-
| [normal cell] || [normal cell]
|}

이미지

 위키백과:그림 사용 정책 문서에 이 부분의 추가 정보가 있습니다.

1. Images should include an alt attribute, even an empty one, that acts as a substitute for the image for blind readers, search-spiders, and other non-visual users. If additional alt text is added it should be succinct, or should refer the reader to the caption or adjacent text: see WP:ALT for more information.
2. In most cases, images should contain a caption, either using the built in image syntax or a secondary line of text. The caption should concisely describe the meaning of the image, the essential information it is trying to convey.
3. Where possible, any charts or diagrams should have a text equivalent, or should be well-described so that users who are unable to see the image can gain some understanding of the concept.
4. Detailed image descriptions, where not appropriate for an article, should be placed on the image description page, with a note saying that activating the image link will lead to a more detailed description.
5. Images should be inside the section they belong to (after the heading and after any links to other articles), and not in the heading nor at the end of the previous section, otherwise screen readers would read the image (and its textual alternative) in a different section; as they would appear to viewers of the mobile site. See Wikipedia:Picture tutorial for more information.
6. 그림을 왼쪽이나 오른쪽으로 참조하는 것을 피하세요. Image placement is different for viewers of the mobile version of Wikipedia, and is meaningless to people having pages read to them by assistive software. Instead, use captions to identify images.
7. This guideline includes alt text for LaTeX-formatted equations in <math> mode.

애니메이션, 비디오 및 오디오

 위키백과:미디어 도움말 및 위키백과:미디어 파일 생성과 사용 문서에 이 부분의 추가 정보가 있습니다.

애니메이션

To be accessible, an animation (GIF – Graphics Interchange Format) should either:

• not exceed a duration of five seconds (which results in making it a purely decorative element), or
• be equipped with control functions (stop, pause, play).

This requires GIFs with animations longer than five seconds to be converted to video (to learn how, see the tutorial converting animated GIFs to Theora OGG).

In addition, animations must not produce more than three flashes in any one second period. Content that flashes more than that limit is known to cause seizures.

비디오

Subtitles can be added to video, in Timed Text format. There is a corresponding help page at commons:Commons:Video#Subtitles and closed captioning. Subtitles are meant for the transcription of speech.

There is a need for closed captions for the hearing impaired. As of November 2012 this is not possible, but this feature could be easily added and has been requested in bugzilla:41694. Closed captions are meant to be viewed instead of subtitles. Closed captions provides a text version of all important informations provided through the sound. It can include dialogues, sounds (natural and artificial), the setting and background, the actions and expressions of people and animals, text or graphics. Guides in the following references can be used to create closed captions.

A text version of the video would also be needed for the blind, but as of November 2012 there is no convenient way to provide alt text for videos.

오디오

Subtitles for speech, lyrics, dialogue, etc. can easily be added to audio files. The method is similar to that of the video: commons:Commons:Video#Subtitles and closed captioning.

스타일 마크업 옵션

우수 사례: 위키문법 및 CSS 종류를 대안에 우선적으로 사용하세요

In general, styles for tables and other block-level elements should be set using CSS classes, not with inline style attributes. The site-wide CSS in MediaWiki:Common.css is more carefully tested to ensure accessibility (e.g. sufficient color contrast) and compatibility with a wide range of browsers. Moreover, it allows for users with very specific needs to change the color schemes in their own style sheet (Special:MyPage/skin.css, or their browser's style sheet). For example, a style sheet at Wikipedia:Style sheets for visually impaired users provides higher contrast backgrounds for navboxes. The problem is that when the default site-wide classes are overridden, it makes it far more difficult for an individual to choose his/her own theme.

It also creates a greater degree of professionalism by ensuring a consistent appearance between articles, and conformance to a style guide.

Regarding accessibility, deviations from standard conventions may be tolerated so long as they are accessible. Members of the accessibility project ensured that the default style is accessible. If some template or specific color scheme deviates from the standard, its authors should make sure that it meets accessibility requirements such as providing enough color contrast. For instance, the infoboxes and navigational templates relating to The Simpsons use a yellow colour-scheme, to tie in with the dominant colour in the series. In this case, blue links on yellow provides enough color contrast, thus it is accessible.

In general, articles should use wikimarkup in preference to the limited set of allowed HTML elements. In particular, do not use the HTML style tags <i> and <b> to format text; it is preferable to use Wiki markup '' or ''', or logical style tags. Of course there are natural exceptions: it may be beneficial to use <u> tags to indicate something like an example of an unclickable link. The <font> tag should also be avoided in article text; use logical style tags like <em>, <code>, or <strong> to emphasise semantic differences. Use the <small> semantic tag and the {{big}} template to change font size, rather than setting it explicitly with the font-size= style attribute.

제한된 CSS 또는 자바스크립트를 지원하는 사용자

위키백과 문서는 자바스크립트 또는 CSS에 대한 지원이 제한되거나 지원되지 않는 브라우저 장치를 사용하는 독자가 접속할수 있어야합니다. At the same time, it is recognised that it is impossible to provide the same quality of appearance to such users without unnecessarily avoiding features that would benefit users with more capable browsers. As such, features which would cause content to be hidden or corrupted when CSS or JavaScript is unavailable must not be used. This includes techniques such as the hiddenStructure method for hiding table content—which produces incomprehensible output without CSS—and some implementations of the NavFrame collapsing code—which can make content inaccessible without JavaScript support. However, consideration for users without CSS or JavaScript should extend mainly to making sure that their reading experience is possible; it is recognised that it will inevitably be inferior.

To accommodate these considerations, test any potentially disruptive changes with JavaScript or CSS disabled. In Firefox or Chrome, this can be done easily with the Web Developer extension; JavaScript can be disabled in IE in the "Options" screen. Be particularly careful with inline CSS effects, which are not supported by several browsers, media, and XHTML versions.

더 보기

• 웹 접근성 이니셔티브 (WAI)
• 위키백과:기술적인 문서를 이해할수 있게 만들기
• 위키백과:JAWS 사용하기

각주

서지

• Clark, Joe (2003). 《Building Accessible Websites》. New Riders Press. ISBN 0-7357-1150-X. 2011년 1월 1일에 확인함. 
• Pilgrim, Mark (2002). “Dive Into Accessibility: 30 days to a more accessible web site”. 2013년 12월 26일에 확인함. 

외부 링크

• 웹 사이트의 접근성을 높이는 10가지 방법 - WAI
• 웹 페이지 색맹 필터
• 웹 접근성의 필수 구성 요소 - WAI
• 웹 접근성 소개 - WAI
• 미디어위키 버그 367: 마크업 접근성 문제 (트래킹)