26. 접근성 테스트

소개

Introduction

웹에서 접근성 테스트라는 것은 웹 사용에 영향을 미치는 장애를 가지고 있는 사람들을 고려하는, 사용성 테스트의 한 분과입니다. 사용성과 접근성 모두의 최종적인 목표는, 사람들이 웹을 쉽게 사용할 수 있도록 하는 방법을 찾아내고, 그렇게 찾아낸 것들을 이용해서 이후의 디자인과 구현들을 발전시키는 것입니다.

Web accessibility testing is a subset of usability testing where the users under consideration have disabilities that affect how they use the web. The end goal, in both usability and accessiblity, is to discover how easily people can use a web site and feed that information back into improving future designs and implementations.

일반적으로, 접근성 평가는 사용성의 그것보다 좀 더 정형화되어 있습니다. 법률과 사회의 공통적인 인식들이 장애를 가진 사람들에게 죄를 짓는(불편하게 만드는) 것을 금하고 있습니다. 모든 이들에게 공정하게끔, 정부와 기타 조직체들은 다양한 웹 접근성 표준을 수립하고자 시도하고 있습니다. 그러한 표준에는 미 연방정부의 제 508조, 그리고 W3C의 웹 컨텐츠 접근성 가이드라인(WCAG) 등이 있습니다.

Accessibility evaluation is more formalized than usability testing generally.
Laws and public opinion frown upon discriminating against people with disabilities. In order to be fair to all, governments and other organizations try to adhere to various web accessibility standards, such as the US federal government’s Section 508 legislation and the W3C’s Web Content Accessibility Guidelines (WCAG).

그렇긴 하지만, 표준을 준수하는 것과 웹 사이트의 접근성을 최대한 향상시키는 것에는 차이가 있습니다. 이상적으로는 그 두가지가 동일해야 하겠지만, 표준이라는 것은 다음의 항목들에서 부족한 점이 있을 수 있습니다:

However, it is important to distinguish between complying with a standard and maximizing the accessibility of a web site. Ideally, the two would be the same, but any given standard may fail to:

  • 장애를 가진 사람들의 모든 니즈를 알아내는 것
  • address the needs of people with all disabilities.
  • 서로 다른 장애를 가진 사람들의 니즈 사이에서 균형을 잡는 것
  • balance the needs of people with differing disabilities.
  • 그러한 니즈에 알맞는 기술을 만드는 것
  • match those needs to optimal techniques.
  • 그러한 니즈와 기술들을 명확한 언어로 표현하는 것
  • use clear language to express needs or techniques.

이러한 약점들은 좋은 의도들을 흐릿하게 만들 수 있으며, 또한 빈곤한 접근성을 가진 사이트가 그저 통과 도장을 받기 위해 악용될수도 있습니다.

Such weaknesses can lead those with good intentions astray and may be exploited by those seeking to rubberstamp inaccessible products.

더군다나, 웹에서 접근성이라고 하는 것은 목표인 것이지, 예/아니오로 선택하는 것이 아닙니다. 접근성은 인간이 필요로 하는 것과 기술을 결합하는 것입니다. 사람들이 필요로 하는 것들에 대해 우리가 더욱 잘 알게 되고, 기술들이 그러한 요구들에 적합하게 되어 감에 따라, 접근성에 관련된 요구 사항들 역시 변할 것이며 현재의 표준은 낡게 될 것입니다. 서로 다른 웹사이트와 서로 다른 웹들은 모두 다른 기술을 가지고 다른 요구에 부응합니다. Skype 같은 보이스 채팅은 맹인들에게 매우 적합한 반면, 수화로 소통하는 사람들은 비디오 채팅을 필요로 할 것입니다.

Moreover, web accessibility is a goal, not a yes/no setting. It is a nexus of human needs and technology. As our understanding of human needs evolves and as technology adapts to those needs, accessibility requirements will change as well and current standards will be outdated. Different websites, and different webs, serve different needs with different technology. Voice chat like Skype is great for the blind, whereas video chat is a boon for sign language users.

장애를 가진 사람들이 뭔가를 얼만큼 쉽게 쓸 수 있을지 알아내는 것은 매우 도전적인 일인데, 왜냐하면 그것을 평가하는 사람과, (장애를 가진)실 사용자 사이에 경험의 격차가 생기기 때문입니다. 접근성을 평가할때는 서로 다른 감각/인식 능력을 가진 사람들, 그리고 특정 장애를 가진 사람들이 웹을 이용할 수 있도록 하는 특별한 소프트웨어들의 매우 다양한 설정 옵션들이 웹을 이용하는 것이 어떠한 것인지를 반드시 고려해야 합니다.

Disabilities pose special challenges when working out how easy a product is to use, because they can introduce additional experience gaps between users and evaluators. Accessibility evaluation must take account of what it is like to experience the web with different senses and cognitive abilities and of the various unusual configuration options and specialist software that enable web access to people with particular disabilities.

당신이 운영하는 웹 사이트의 사용성이나 접근성을 평가하고자 할 때는, 영화광인 10대, 혹은 사이트 이용에 어려움을 느끼는 50대의 은행가의 입장이 되어 보아야 합니다 – 이러한 것은 장애에 대한 고려보다도 우선하는 것입니다. 만약 영화광인 10대가 청각 장애를 갖고 있어서 영화를 볼 때 자막이 꼭 필요하다면 어떻게 하겠습니까? 50대의 은행가가 맹인이어서, 사이트 평가자가 익숙하지 않은 특별한 기술(스크린 리더 같은)을 필요로 한다면 어떻게 하겠습니까?

If you are trying to evaluate the usability or accessibility of your web site, putting yourself in the place of a film-loving teenager or a 50-year old bank manager using your site is difficult, even before disabilities are considered. But what if the film-loving teenager is deaf and needs captions for the films she watches? What if the 50-year old bank manager is blind and uses special technology (like a screen reader) which is unfamiliar to the evaluator in order to interact with his desktop environment and web browser?

접근성 가이드라인은 이와 같은 경험의 간극을 좁히는데 도움을 줄 수 있습니다. 하지만, 그러한 것은 어디까지나 도움을 주는 것이지, 당신을 대신해서 감성을 전달하고 기술을 설명하며 사용자와 대화하는 것은 아닙니다.

Accessibility guidelines and tools help bridge these experience gaps. However, they are a supplement, not a replacement, for empathic imagination, technical ingenuity, and talking to users.

이 글에서는 웹 접근성을 평가하는 방법을 다루려고 합니다. 정형화된 준수사항을 만족한다는 관점과, 접근성을 최대한 높인다는 관점 두가지에서 볼 것입니다. 이 글의 구조는 다음과 같습니다.

In this article, I will discuss approaches to evaluating web accessibility, both from the perspective of establishing formal compliance and from the perspective of maximizing accessibility. The article’s structure is as follows:

  • 테스트를 할 시점
  • When should testing be done?
  • 당신이 필요로 하는 것들에 대해 이해하는 것
    • 외부적인 요구사항
    • 준수사항의 상세
    • 예상을 넘는 것
    • 사용자 인터페이스의 중요성
    • 장애를 가진 사람들의 인격
    • 접근성 표준의 선택
    • 법의 정신
  • 누가 테스트를 해야 하는가?
  • 전문가의 테스트
    • 반자동화된 접근성 검사기
    • 구조 검사
    • 최종 사용자가 사용하는 보조 기술
    • 자세한 검사
      • 지각정도
      • 이용성
      • 이해도
      • 충실도
  • 사용자 테스트
    • 테스터 모집
    • 현실적인 고려사항
    • 테스트 모델 선정
    • 결과 해석
  • 소통: 접근성 테스트 결과
  • 요약
  • 연습문제

언제 테스트해야 하는가?

When should testing be done?

“일찍 테스트하고, 자주 테스트하라” 는 것은 소프트웨어 공학의 오래된 격언입니다. 개발의 마무리 단계에서 테스트에 돌입하는 것은 두가지 면에서 위험합니다:

“Test early, test often” is an old software engineering saying. Tacking on testing at the end of the development process has two risks:

  1. 프로젝트라는 것은 항상 마감을 넘기고, 예산을 초과합니다. 이러한 압박 속에서 테스트를 진행하면 종종 급박해지고, 뭔가를 생략하거나, 아예 무시되기도 합니다.
  2. Projects tend to run over-time and over-budget. Testing is often rushed, omitted, or ignored thanks to such pressures.
  3. 늦게 발견된 문제를 해결하는 것은 처음부터 올바르게 하는 것보다 더 많은 작업을 필요로 합니다.
  4. It is more work to fix problems discovered late in a process than to do things right from the start.

따라서 품질을 보장하고 시간과 비용을 절약하려면, 접근성 평가는 디자인을 시작하는 즉시 함께 시작해야 하며, 최종 단계까지 반복되어야 합니다.

So to ensure quality and save time and money, accessibility evaluations should start right at the beginning of product design and be included in subsequent development iterations through to final delivery.

당신이 필요로 하는 것들에 대해 이해하는 것

Understanding your requirements

프로젝트의 접근성을 평가하기 전에, 먼저 핵심적인 요구사항에 대해 판단해야 합니다. 그러한 판단은 환경, 대상 사용자, 자원들을 고려해서 내려야 합니다. 일부 요구사항은 정부나 고객이 지정할 수도 있으며, 일부는 당신이 스스로 선택해야 할 것입니다.

Before you begin to evaluate a project for accessibility, you need to determine what the key requirements are for that project, given its environment, intended audience, and resources. Some requirements will be set by third parties like governments and clients; some you may be able to choose for yourself.

외부적인 요구사항

External requirements

종종 요구사항들은 외부의 것인 경우가 많습니다:

Often requirements come from external sources, such as:

  • 정부. 이러한 것은 보통 정밀하게 수량화되는 준수 요구사항이나 특정 표준을 요구한다기 보다는, 장애인 차별 금지법과 같은 형태를 띕니다. 중요한 예외가 있는데, 법 조항에서 공적인 부분에 대해 특정 표준을 강제하는 경우입니다. 예를 들어, 508조는 미 연방법률의 한 부분이며, 연방 정부의 웹사이트를 만들 경우 반드시 특정한 요구사항들을 준수할 것을 지시하고 있습니다. WAI의 웹 접근성과 연관된 정책들 페이지는 비슷한 법 조문의 목록을 제공하고 있습니다. 하지만 이에 관해 당신이 관할하는 부분에서 권한 있는 설명을 얻으려면 법률가의 조언을 들어야 할 것입니다.
  • Governments. This typically takes the form of general legislation against discriminating against people with disabilities, rather than mandating a particular standard or enumerating precise conformance requirements. An important exception is when legislation enforces a particular standard for public sector. For example, Section 508 is a piece of US federal legislation, which mandates that websites produced for federal agencies must conform to at least a specific set of defined requirements. WAI’s Policies Relating to Web Accessibility page provides a partial list of similar legislation. But to get an authoritative statement of the obligations in your jurisdiction, consult a lawyer.
  • 고객 정책. 예를 들어, Shell 에서는 자신들의 웹 사이트가 WCAG 1.0 의 준수사항 “AA” 등급을 얻도록 하고 있습니다. 따라서, 만약 당신이 Shell의 웹사이트를 개발하고 있다면 (최소한) 그 표준을 만족해야 할 것입니다.
  • Customer policies. For example, Shell currently try to ensure their websites conform to the “Double-A” conformance level of WCAG 1.0, so if you were developing a website for Shell you would need to meet (at least) the same standard.
  • 마케팅. 508조 같은 특정 표준을 준수한다면, 접근성에 관심이 있는 고객에 대한 매출이 증대할 수 있습니다.
  • Marketing utility. Compliance with a particular standard, such as Section 508, might help sell a project to clients concerned about accessibility.
  • 근무하는 회사 내부의 접근성 정책. 예를 들어, BBC에서 게제하는 모든 페이지들은 BBC 접근성 가이드라인 1.3을 준수해야 합니다.
  • Internal accessibility policies at your organization. For example, projects produced by the BBC need to comply with the BBC’s Accessibility Guidelines v1.3.

준수사항의 상세

The details of conformance

외부의 제약 조건에 대해 가능한 한 명확히 아는 것이 중요합니다. 일부 접근성 표준들은 가능한 수준 또는 형태의 준수 이상의 것을 요구하므로, 요구되는 것을 일부 낮추는 것이 중요할 수 있습니다. 예를 들어, WCAG 1.0은 세가지의 준수 레벨을 갖고 있습니다:

It is important to get as much clarity about external requirements as possible. Some accessibility standards have more than one possible level or type of conformance, so it is particularly important to nail down which is required. For example, WCAG 1.0 has three conformance levels:

  1. 일정정도의 장애를 가진 사람들이 “정보에 접근하는 것이 불가능하다고 느낀다면” 레벨 A를 통과할 수 없습니다.
  2. People with some disabilities “will find it impossible to access information” in a document that does not pass level “A”.
  3. 일정정도의 장애를 가진 사람들이 “정보에 접근하는 것을 어렵다고 느낀다면” 레벨 AA를 통과할 수 없습니다.
  4. People with some disabilities “will find it difficult to access information” in a document that does not pass level “Double-A”.
  5. 일정정도의 장애를 가진 사람들이 “정보에 접근하는 것이 어느정도 어렵다고 느낀다면” 레벨 AAA를 통과할 수 없습니다.
  6. People with some disabilities “will find it somewhat difficult to access information” in a document that does not pass level “Triple-A”.

WCAG 2.01 역시 3가지 레벨을 정하고 있지만, 준수 가능성은 좀 더 복잡합니다. 어떤 자원이 시리즈의 일부분이라면, 그중 가장 낮은 준수 레벨을 가진 것으로 시리즈 전체의 레벨이 평가됩니다.

Draft WCAG 2.0 has three levels too, but the conformance possibilities are more complicated. Where a resource is part of a series of resources presenting a process (eg product discovery, selection, checkout, and purchase confirmation for an online store), the conformance level for all resources in the series is that of the resource with the lowest level.

준수사항을 만족했다고 주장하려면, “접근성을 지원하는” 컨텐츠 기술에 근거를 두어야 합니다. 어떤 기술이 접근성을 지원한다고 말하려면, 다음의 요건을 반드시 만족해야 합니다:

Conformance claims must be based on “accessibility-supported” content technology. To be an accessibility-supported content technology, a technology must:

  • 사용자의 보조 기술과 호환됨을 증명했어야 합니다.
  • Have been demonstrated to work with users’ assistive technology.
  • 사용자의 보조 기술과 호환되는 사용자 에이전트(브라우저, 플러그인 등)을 가져야 하며, 장애를 가진 사람들이 그것을 이용하기 위해서 장애가 없는 사람에 비해 추가적인 비용이 필요해서는 안됩니다.
  • Have user agents (browsers, plugins, etc.) that work with the users’ assistive technology and are available to users with disabilities at no cost above that for a user without a disability.

“월드 와이드” 한 웹에서는 보장할 수 없더라도, 인트라넷 세팅에서는 보장할 수 있는 것들이 있습니다. 예를 들어, 어떤 프로그램에 접근하는데는 아무런 상용 기술을 구입할 필요가 없지만, 스크린 리더기의 사용자가 그 프로그램을 사용하려면 상용 플러그인이 반드시 필요하며, 회사에서 그 플러그인을 모든 직원이 이용할 수 있도록 라이선스 계약을 맺은 상황입니다. 이 프로그램은 회사의 인트라넷에 배포되었을때는 WCAG 2.0을 준수할 수 있지만, 공개적인 웹에 배포되었을 때에는 그렇지 못할 수 있습니다.

Note that within an intranet setting, you might be able to guarantee that such user agents would be available to users whereas you cannot guarantee the same thing on the World Wide Web. For example, an application might be usable without any commercial technology, but only be accessible to screen readers with a commercial plugin for which the organization has a site licence. That application could conform to WCAG 2.0 when deployed on the organization’s intranet, but not when deployed on the public Web.

WCAG 2.0은 또한 더 축소된 준수 요강을 허용하고 있습니다. 접근할 수 없는 자원에, 접근 가능한 대체가 제공된다면 그러한 자원은 요구사항을 준수한다 할 수 있습니다. 다른 소스에서 가져온 컨텐츠를 제공하는 경우, 부분적인 준수를 하고 있다고 주장할 수 있습니다.

WCAG 2.0 also allows more limited statements of conformance. An inaccessible resource can conform if an accessible alternative is provided. Publishers can make a statement of partial conformance where content is aggregated from other sources.

예상을 넘는 것

Exceeding expectations

외부적인 요구사항들을 분석하는 것은 시작일 뿐입니다. 그러한 것은, 접근성을 최대한 보장하려는 목표를 위한 최소한의 조건으로 간주해야 합니다. 당신이 사이트의 전문가이므로, 다른 사람이 접근성을 평가하려고 할 때에 더 많은 배려를 하는 것이 당신의 역할입니다.

Determining external requirements should only be the beginning of the process; they should be treated as a minimum set of requirements to which further goals should be added to maximize accessibility. As the person evaluating accessibility, it is your role to raise additional accessibility concerns, as you are the subject expert.

최종적인 보고서를 작성할 때 두가지를 구분해야 할 필요가 있을 수 있습니다. 예를 들어, 온라인 슈퍼마켓에 고객이 보낸 요청에 맹인도 사용할 수 있게 해달라는 요청이 있다고 가정합니다. 이러한 사용자를 상정했다고 하더라도, 다른 형태의 장애를 가진 사람들 역시 슈퍼마켓을 이용할 수 있도록 만들어야 하는 것입니다.

You may need to distinguish the two when delivering a final report. For example, a customer brief for an online supermarket might mention that they want a store accessible to blind users. Given the intended audience, you should also evaluate whether the store is accessible to users with other disabilities.

특정한 표준을 준수할 것을 요구하는 외부의 주문이 있다고 해서, 현재 적용하고 있는 최상의 사례에 관한 가이드라인을 어길 이유는 없습니다. 예를 들어, 성인이 이용하게 될 연방 기관의 웹사이트를 평가하고 있는 상황에서, 508조를 준수할 것을 요구받고 있다고 가정합니다. 508조에서는 다음과 같이 규정하고 있습니다:

Note that external requirements for compliance with a particular standard do not necessarily prevent best practice guidelines from other standards being applied. For example, you might be evaluating a website for a web federal agency intended for use by senior citizens and be required to comply with Section 508. Section 508 stipulates that:

§ 1194.22 (c) 웹 페이지에서 색상을 통해 전달되는 모든 정보가 색상을 통하지 않고서도 전달되도록 해야 한다. 예를 들어서 문맥이나 마크업으로 그러한 정보를 전달하여야 한다.

§ 1194.22 (c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.

이러한 규정은 웹 컨텐츠의 표현을 자신에게 맞도록 설정하는 법을 아는 사용자에게는 도움이 될 것입니다만, 색상들 사이에 충분한 대비가 있도록 해서 대상 사용자들의 접근성을 최대화하지는 못하고 있습니다. 다행히도, 이 요구사항을 준수한다고 해서 WCAG 2.02에서 제시하는 다음의 사항과 충돌하는 것은 아닙니다:

This provision helps users who know how to customize the presentation of web content, but doesn’t maximize the accessibility of the default presentation of that content to the target audience by ensuring that there is sufficient contrast between suggested colors. Fortunately, there’s nothing stopping a web site from fulfilling this requirement but also meeting the following Level provisions from the Web Content Accessibility Guidelines 2.0 draft:

1.4.3 대비 (최소): 텍스트와, 이미지로 표현된 텍스트는 다음의 경우를 제외한다면 최소 4.5:1 3 의 대비를 가져야 합니다: (등급 AA)

1.4.3 Contrast (Minimum): Text and images of text have a contrast ratio of at least 5:1, except for the following: (Level AA)

  • 큰 글씨와, 큰 이미지로 표현된 텍스트는 최소 3:1의 대비를 가져야 합니다.
  • Large Print: Large-scale text and large-scale images of text have a contrast ratio of at least 3:1;
  • 순수하게 장식적인 목적으로 사용된 것, 비활성 상태인 사용자 인터페이스의 일부인 것, 이미지의 부수적인 텍스트, 아무에게도 보이지 않는 것 들은 이러한 최소 대비 요구사항을 준수하지 않아도 됩니다.
  • Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are incidental text in an image, or that are not visible to anyone, have no minimum contrast requirement.

노트: 1.4.3과 1.4.6은 페이지에 있는 대비 컨트롤을 통해 준수할 수 있습니다.

Note: Success Criteria 1.4.3 and 1.4.6 can be met via a contrast control available on or from the page.

1.4.6 대비 (향상된): 텍스트와, 이미지로 표현된 텍스트는 다음의 경우를 제외한다면 최소 7:1의 대비를 가져야 합니다: (등급 AAA)

1.4.6 Contrast (Enhanced): Text and images of text have a contrast ratio of at least 7:1, except for the following: (Level AAA)

  • 큰 글씨와, 큰 이미지로 표현된 텍스트는 최소 4.5:14의 대비를 가져야 합니다.
  • Large Print: Large-scale text and large-scale images of text have a contrast ratio of at least 5:1;
  • 순수하게 장식적인 목적으로 사용된 것, 비활성 상태인 사용자 인터페이스의 일부인 것, 이미지의 부수적인 텍스트, 아무에게도 보이지 않는 것 들은 이러한 최소 대비 요구사항을 준수하지 않아도 됩니다.
  • Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are incidental text in an image, or that are not visible to anyone, have no minimum contrast requirement.

노트: 1.4.3과 1.4.6은 페이지에 있는 대비 컨트롤을 통해 준수할 수 있습니다.

Note: Success Criteria 1.4.3 and 1.4.6 can be met via a contrast control available on or from the page.

대비 컨트롤을 이용해서, 높은 대비를 갖는 다른 색상 세팅으로 교체해서 볼 수 있는 방법을 제공해야 합니다. Juicystudio의 색상 대비 분석기 를 통해 색상 스키마의 대비를 시험해볼 수 있습니다.

By contrast control, the criteria means that you should provide a way of changing the colours to a high-contrast variation. To test the contrast of colour schemes, you can use the colour contrast analyser from Juicystudio.

WCAG 2.0은 하위 호환성에 역점을 두고 설계되었으며, 특히 WCAG 1.0 및 508조와 잘 호환됩니다.

WCAG 2.0 is being designed to have a high degree of backwards compatibility with other standards, especially WCAG 1.0 and Section 508.

사용자 인터페이스의 중요성

The importance of the user interface

 

사이트의 인터페이스를 접근성있게 만드는 것이 중요합니다. 접근성있는 인터페이스는 내용이 걸맞는 형태로 표현되지 않았더라도, 사용자가 자신이 관심있는 것을 찾아내고, 자기에게 알맞는 형태로 바꿀 수 있도록 외부의 도움말을 찾아볼 수 있게 합니다. 예를 들어, 잘 듣지 못하는 사용자가 캡션이 없는 비디오 공유 사이트에서 대화가 포함된 비디오를 보려고 하는 경우입니다. URL이 그 비디오를 정확하게 식별해 주므로, 사용자는 써드파티 플레이어 – Project readOn 같은 무료 서비스를 통해서 그 비디오를 캡션과 함께 볼 수 있습니다.

Consider the special importance of making the user interface of a web site accessible. Even if content is not available in a suitable form, an accessible user interface may help users identify content of interest and seek external help in converting it to a form they can use. For example, a hard-of-hearing individual might be pointed to a video of a talk on a video-sharing site without captions. Because the URL uniquely identifies that video and because they can still use the player to see the video however they could submit it to a third party, such as the free Project readOn service, for captioning.

장애를 가진 가상인격persona

Personas with disabilities

가상 인격을 통해 프로젝트에서 테스트해볼 주요 장애들을 만들어보는 접근방법이 이상적입니다. 가상 인격이란, 사이트를 사용할 사람들의 타입을 분류하는 가상의 사용자를 말합니다. 비디오 공유 사이트에서 사용할 가상 인격을 다음과 같이 만들어서 테스트한다고 해봅시다.

An ideal approach is to build key disabilities for your project right into your other user personas: fictional users that act as archetypes for how particular types of users would use a web site. Let us say you are evaluating prototypes for a video sharing site and your personas include:

  • 23세의 제임즈 스미스. 풋볼을 아주 좋아하며, 스포츠 하이라이트들을 친구들과 공유하고 싶어합니다.
  • 23-year-old James Smith, who is football-mad and especially wants to share sporting highlights with friends.
  • 34세의 사라 메디슨. 직장에 다니면서 아이를 키우는 어머니이고, 비디오 공유 사이트에 시간을 내기는 어렵습니다만, 3살 먹은 딸아이는 비디오를 좋아하며 사라는 딸이 보고 싶어하는 비디오를 찾을 수 있도록 도와주길 원합니다.
  • 34-year-old Sarah Maddison is a working mom who might not normally have time for a video sharing site. But her three-year old daughter is really keen on watching videos, and Sarah wants to sit and help her find suitable videos she wants to watch.

이러한 가상 인격들을 통해서 다음과 같은 장애들을 테스트할 수 있습니다.

You can take these personas and incorporate disabilities including (for example):

  • 난시
  • Impaired vision.
  • 색맹
  • Colorblindness.
  • 눈멈
  • Blindness.
  • 귀먹음
  • Deafness.
  • 난청
  • Hard-of-hearing.
  • 볼 수 없고 들을 수 없음
  • Deafblindness.
  • 간질
  • Epilepsy.
  • 난독증
  • Dyslexia.

예를 들어서, 제임스는 청각장애를 갖고 있어서 캡션이 포함된 비디오 해설을 원하고, 사라는 시력이 나빠서 꾸며진 글씨나 작은 텍스트를 읽기 힘들다고 가정할 수 있습니다. 이러한 가상 인격을 통해 테스트를 하면 사이트의 프로토타입을 만들면서 클로즈드 캡션이 없는 것이나, 이미지를 필요로 하는 정교한 제목들을 제거하기 쉽습니다.

For example, you might decide that James is also deaf and wants commentary on match videos to be captioned, and Sarah has poor eyesight and struggles to read fancy fonts and tiny text. These personas guide your rejection of prototypes that fail to include the facility for closed captions in the video player, or use elaborate text headings that would require images.

장애를 가진 사람들이 웹을 이용하는 법 (WAI), 디자인 과정 전체에서 접근성을 통합하는 방법 (Shawn Lawton Henry) 에 장애를 가진 가상 인격의 예제가 더 있으니 참고할 수 있을 것입니다.

The WAI’s How People with Disablities Use the Web and Shawn Lawton Henry’s Just Ask: Integrating Accessibility Throughout Design contain some more example disability-inflected personas to get you started.

말할 필요도 없는 일이지만, 사람들이 가진 장애는 모두 유일한 것입니다. 장애는 믿을 수 없을 정도로 다양하며, 장애인의 성별, 나이, 취향, 가치, 컴퓨터 활용 능력 역시 장애를 가지지 않은 사람들의 그것만큼 다양합니다.

It shouldn’t need saying, but don’t assume people with disabilities are interchangeable. Disability is an incredibly varied phenomenon, and on top of that people with disabilities have all the variety that people without disabilities have, differing (for example) in gender, age, interests, values, and skills (perhaps most relevantly, in their computing expertise).

접근성 가이드라인을 이용하면 준비한 가상 인격이 커버하지 못하는 부분을 찾아낼 수 있습니다. 예를 들어, 준비 중인 비디오 공유 사이트에 WCAG 2.0을 적용하려고 하지만 가상 인격 중에는 간질에 관한 것이 포함되지 않았을 수 있습니다. 가이드라인 2.3(발작을 초래할 수 있도록 컨텐츠를 디자인해서는 안됩니다) 을 읽어보면 업로드된 비디오에서 번쩍임을 방지할 수 있는 시스템이 필요한지 결정할 수 있을 것입니다.

Again, comparing products against accessibility guidelines can help fill in the gaps that your personas do not cover. For example, perhaps you’re following WCAG 2.0 with the video sharing site, but your personas don’t include a user with epilepsy. Nonetheless, you read Guideline 2.3 (“Seizures: Do not design content in a way that is known to cause seizures”) and decide that the system needs to be able to screen uploaded videos for flashing before displaying them.

접근성 표준의 선택

Choosing an accessibility standard

접근성에 관한 사항들을 조절하기 위해 표준을 선택해야 한다면, WCAG 2.0을 추천합니다. 다음과 같은 이유에서입니다.

If you need to choose an accessibility standard in order to manage web accessibility concerns across a team or in simply to guide you while testing, I’d advise looking at WCAG 2.0 because it:

  • HTML이나 CSS가 아닌 기술(플래시 같은)에 적용되어야 할 요구사항들에 대해 디자인되었습니다.
  • is designed around core human needs that are applicable to technologies other than HTML and CSS (such as Flash).
  • 각각의 준수 기준들이 필요한 이유를 섬세하게 문서화했습니다.
  • carefully documents the reasoning for each conformance criterion.
  • 최근의 기술들을 사용하면서 준수 기준을 만족하는 현실적인 테크닉들을 추천합니다.
  • suggests practical techniques for meeting conformance criteria using current technologies.
  • 모든 기준들을 테스트할 수 있습니다.
  • ensures each provision is testable.
  • 최근 사용되는 대체수단들보다 더 새로운 연구결과들을 포함합니다.
  • incorporates more recent research than current alternatives.
  • 현존하는 접근성 표준들과 널리 호환되도록 디자인되었습니다.
  • is designed to be broadly compatible with existing accessibility standards.
  • 국제 표준이 될 것입니다.
  • will be an international standard.

판촉을 위해서 WCAG 2.05중 일부를 준수하고 있다고 인용해도 되지만, 508조나 WCAG 1.0 같은 완성된 표준 역시 준수하는 것이 가장 좋습니다.

You can cite compliance with a specific draft of WCAG 2.0; for marketing purposes however it is best to also seek compliance with finished standards like Section 508 and WCAG 1.0 as well as that draft.

법의 정신

The spirit of the law

가이드라인에 따라 테스트할때는, 조문들 밑에 깔려 있는 생각들을 읽어야 합니다. 법의 글자를 따르는 것이 아니라, 그 정신을 따라야 합니다.

When testing against guidelines, it’s important to keep in mind the underlying rationale for any specific technical guidance: to comply with the spirit, not just the letter, of the law.

한가지 경구를 들어 보겠습니다. 508조의 § 1194.22 항목에는 텍스트가 아닌 모든 요소들에 대해서 동질의 텍스트를 alt, longdesc를 통하거나 요소의 내용 내부에서 제공해야 한다는 조문이 들어 있습니다. WCAG 1.0에도 다음과 같은 점검항목이 있습니다.

Here’s a cautionary tale. Section 508 (§ 1194.22) includes a requirement that says: “A text equivalent for every non-text element shall be provided (eg, via alt, longdesc or in element content).” Likewise WCAG 1.0 includes a checkpoint that reads:

텍스트가 아닌 모든 요소들에 대해서 동질의 텍스트를 alt, longdesc를 통하거나 요소의 내용 내부에서 제공해야 합니다. 텍스트가 아닌 모든 요소에는 이미지, 텍스트의 그래픽 표현(심볼을 포함합니다), 이미지 맵, 애니메이션, 애플릿, 프로그램된 객체, 아스키 아트, 프레임, 스크립트, 불릿으로 사용된 이미지, 공간을 띄우는 이미지, 그래픽 버튼으로 사용된 이미지, 사운드(사용자가 트는 것이든, 아니든), 독립적인 오디오 파일, 비디오의 오디오 트랙, 비디오 가 포함됩니다.

Provide a text equivalent for every non-text element (eg, via alt, longdesc, or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (eg, animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video.

불행히도, 많은 사람들이 위의 가이드를 오해해서, 공간을 띄우는 이미지나 장식을 위해 사용된 요소들에도 적합한 동질의 텍스트를 제공하는 마크업을 작성해야 한다고 생각하며, 실제로 아래와 같이 마크업하고 있습니다:

Unfortunately, many people reading such guidance misunderstand what a genuine text equivalent for a spacer and decorative elements should be, and produce markup like this:

<img alt="fancy border" src="fancy-border.gif" border="0">

그러한 이미지들은 정보를 전달하는 것도 아니고 어떤 기능이 있는 것도 아니므로, 그러한 것에 대한 동질의 텍스트는 빈 문자열(alt="")이 되어야 맞는 것입니다. 이렇게 하면 스크린 리더들이 alt 속성을 건너뛰고, 아무것도 읽지 않을 것입니다. 스크린리더가 유용한 정보는 전혀 전달하지 않으면서 “예쁜 테두리” 라고 반복해서 읽고 있는 것을 들으면 아주 짜증이 날 것입니다.

In fact, since these images convey no new information and have no functionality, the right text equivalent for those images would be an empty string (alt=""), which causes the screenreader to just skip over the alt attribute and not read it out. It is very annoying for a screenreader user to have to listen to text such as “fancy border” read out over and over again, when it does not provide them with any useful information.

WCAG 2.0은 좀 더 명확하게 하고 있습니다. 동질의 대체 가이드라인 에는, “다음의 경우를 제외하면 텍스트가 아닌 모든 컨텐츠에 대해서 동일한 정보를 제공하는 대체 텍스트를 제공해야 합니다” 라고 쓰고 있습니다. 다음의 경우라 함은 “장식, 틀을 잡는, 보이지 않는 – 순수하게 장식적인 목적이거나, 시각적인 형태를 잡는 용도로만 쓰고 있거나, 사용자에게 표현되지 않는 것이라면 보조 기술에서 무시할 수 있는 방법으로 구현되어야 합니다” WCAG 2.0에서는 동일한 중요도를 가지고 가이드라인 의 이유를 상세히 설명합니다.

WCAG 2.0 tries to be clearer. The equivalent guideline says: “All non-text content has a text alternative that presents equivalent information, except for the situations listed below”. One of those situations is: “Decoration, Formatting, Invisible: If it is pure decoration, or used only for visual formatting, or if it is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.” Equally importantly, WCAG 2.0 tries to detail the reasoning behind the guideline:

이 가이드라인의 목적은 텍스트가 아닌 모든 컨텐츠가 텍스트로도 제공되도록 하는 것입니다. 텍스트 라 함은 전기적 텍스트를 말하며, 텍스트의 형태를 띈 이미지를 말하는 것이 아닙니다. 텍스트는 표현적으로 중립이기 때문에 독특한 장점을 갖게 됩니다. 독특한 장점이라 함은, 시각적으로, 청각적으로, 점자로, 혹은 어떠한 조합으로도 표현될 수 있다는 것입니다. 따라서 텍스트로 전달된 정보는 사용자에게 가장 적합한 방법으로 표현될 수 있습니다. 쉽게 확대할 수 있고, 알아듣기 쉬운 목소리로 읽어줄 수 있으며, 사용자에게 가장 적합한 점자 표시기에서 표시할수도 있습니다.

The purpose of this guideline is to ensure that all non-text content is also available in text. “Text” refers to electronic text, not an image of text. Electronic text has the unique advantage that it is presentation neutral. That is, it can be rendered visually, auditorily, tactilely, or by any combination. As a result, information rendered in electronic text can be presented in whatever form best meets the needs of the user. It can also be easily enlarged, spoken in a voice that is easy to understand, or rendered in whatever tactile form best meets the needs of a user.

누가 테스트를 해야 하는가?

Who should test?

간단히 말하면 전문가와 사용자 입니다.

There are basically two groups who conduct testing: experts and users.

전문가들은 배후의 웹 기술들이 어떻게 작동하는지 이해하고 있으며, 서로 다른 사용자그룹의 지식을 명확히 해 줄 수 있고, 전문적인 테스팅 도구의 사용법을 배우려는 의지도 가지고 있습니다. 전문가의 테스트를 거치는 것은 중요합니다.

Expert testing is important because experts understand how the underlying web technologies interact, can act as a clearing house for knowledge about different user groups, and have the inclination to learn dedicated testing tools.

각각의 사용자들은 자신의 능력과 자신이 사용하는 보조 기술에 대해서 정확히 알고 있습니다. 또한 사용자 테스트를 통해서, 사용자들의 기술적 수준의 차이로 인한 사용성 편차를 알아낼 수 있습니다. 논의중인 사이트에 친숙한 사람과 그렇지않은 사람들 사이의 사용성 편차도 알아낼 수 있습니다. 사용자 테스트는 반드시 해야 하는 것입니다.

User testing is crucial because users are the real experts in their own abilities and their own assistive technology. User testing can also reveal usability gaps between more and less technical users, and between people who are familiar with the web site in question (such as the expert testers themselves) and people who aren’t (new users).

스크린 리더의 사용법을 알고 있는 웹 개발자가 실제로 그 스크린 리더를 항상 사용하는 사람과 같은 방식으로 사이트를 이용하지는 않을 것입니다. 자신만의 스크립트를 작성할 줄 아는 사람과, 이메일을 쓴다거나 하는 정도만 쓰는 사람의 스크린 리더 사용법은 매우 다를 것입니다.

A web developer who knows how to use a screen reader is unlikely to explore a site the same as a regular screen reader user; screen reader users who program their own scripts are unlikely to explore the site using the same strategies as screen reader users who just do ordinary computing tasks like writing emails.

사용자 테스트를 통해 알게 된 지식은 전문가 테스트로 피드백되어 다음 테스트를 수행할 때 도움이 될 수 있습니다. 사용자 테스트에는 강점이 하나 더 있습니다. 개발자와 최종 사용자들이 함께 작업함으로서, 접근성 있는 사이트를 만들겠다는 동기를 더 강하게 부여할 수 있는 것입니다.

Knowledge gained in user testing is fed back into the expert testing process the next time testing is performed (either in another testing iteration on the same project, or a different project entirely). User testing also has a more subtle advantage. By humanizing accessibility and bringing developers together with end users, it can increase the motivation to build accessible websites.

전문가 테스트

Expert testing

네가지 요소가 있습니다.

There are four components to expert testing:

  • 도구를 사용한 평가: 접근성 문제들을 찾아내서 평가자에게 보여주는 도구를 사용합니다. 접근성 체크 도구와 코드 유효성 검사기를 포함할 수 있습니다.
  • Tool-guided evaluation: where a tool looks for accessibility problems and presents them to the evaluator (this would include accessibility checkers and code linters).
  • 모사: 전문가가 최종 사용자의 경험을 흉내내는 것입니다. 종종 가까이에서 문제를 찾아낼 수 있습니다. 페이지를 브라우저에서 보는 것 만으로도 텍스트를 읽기가 매우 어렵다는 것을 느낄 수 있습니다.
  • Screening: where the expert simulates an end-user experience of the web site. Often you don’t need to look very far to find accessibility problems. You might do no more than load the page in your browser and notice the text is very hard to read.
  • 도구 기반의 검사: 사이트의 여러 요소들이 어떻게 상호 동작하는지 검사하는 도구를 사용합니다.
  • Tool-based inspection: where the evaluator uses a tool to probe how the various bits of a web site are working together.
  • 코드 검사: 코드를 직접 살펴보면서 문제가 있을 부분을 찾아냅니다.
  • Code review: where the evaluator looks directly at the code and assets of a web site to scour for problems.

초보자의 경우 도구에 좀 더 많이 의존할 수 있지만, 위의 모든 요소들이 도움이 됩니다. 초보자들이라 하더라도 img 요소에 대체 텍스트가 포함되지 않은 것을 알아낼 수 있으며, 이런 테스트의 경험이 쌓이게 되면 좀 더 빠르게 문제점들을 찾을 수 있게 됩니다. 큰 프로젝트에서는 전문가라 할지라도 클라이언트 사이드의 모든 코드들을 검사할 수는 없겠지만, 도구를 사용하면 어떤 부분들을 더 유심히 살펴보아야 하는지 쉽게 알 수 있습니다. 프로그램에서 찾아낼 수 있는 것을 사람은 못보고 지나치는 경우도 있을 것입니다.

While beginners may be especially dependent on tool-guided evaluation, evaluators of all levels of experience can benefit from each component. Even beginners can spot img elements without text equivalents in HTML markup, and as you get more experienced, you will get quicker at spotting problems before you progress to more rigorous testing. For experts on larger projects, it may not be feasible to manually review all client-side code or inspect all parts of a website, but a tool-guided evaluation can find areas of particular trouble that deserve a closer look. Also, human evaluators may overlook things that a machine evaluation would have caught.

많은 접근성 평가 도구들이 있지만, 불행히도 그들 대부분은 조금씩의 결함을 가지고 있습니다. 문서에 포함된 제목들을 나열하는 도구가 img 요소에 alt 텍스트가 없는 문제를 발견하지 못할 수도 있는 것입니다. 도구를 사용할 때 역시 법과 표준 이면의 정신을 염두에 두어야 합니다. 접근성 문제에 대해 누군가에게 불평을 늘어놓기 이전에, 그것이 도구의 에러가 아니라 일반적인 문제임을 확실히 해야 합니다.

Unfortunately, although there are lots of accessibility tools, most of them are flawed in one way or another. For example, one tool that lists headings in HTML documents makes the error of not including alt text from img elements. Just as you should keep the spirit of the law in mind with standards compliance, so you should keep it in mind when using tools. Before complaining to someone about an accessibility problem, make sure it is a genuine issue not a tool error.

반자동화된 접근성 검사기

Semi-automated accessibility checkers

쉽게 찾을 수 있는 문제들을 해결하고 나면, 반자동화된 접근성 검사기를 이용하는 것이 좋습니다. 준수하기로 한 표준에 걸맞게 디자인된 도구가 필요할 것입니다.

Once the first-glance problems have been fixed, a good next step is to throw the page at a semi-automated accessibility checker tool. If you are evaluating compliance with a particular standard, you will probably want to pick one that is designed for use with that standard.

WCAG 1.0이나 508조에 대한 준수 정도를 평가하고 있다면, Cynthia Says 가 괜찮습니다. 독일의 BITV 1.0 Level 2 나 이탈리아의 Stanca Act, WCAG 2.06에 맞게 검사하고자 한다면, 현재 사용할 수 있는 것은 ATRC 웹 접근성 검사기 (완전하지 않습니다) 밖에 없습니다.

If you’re evaluating compliance with Section 508 or WCAG 1.0, Cynthia Says is a reasonable choice. If you’re testing against German BITV 1.0 Level 2, the Italian Stanca Act, or the WCAG 2.0 draft, the only current option is the experimental ATRC Web Accessibility Checker.

이러한 도구들에는 분명한 한계가 있습니다. 완전히 자동화된 접근성 검사 같은 것은 있을 수 없습니다. 간단한 예를 들면, 현재의 인공지능으로는 사진을 텍스트로 설명할 수 없습니다. 이론적으로는 완전하게 자동화할 수 있는 영역이라 하더라도, 프로그램에는 에러가 있을 수 있으며 법 조문에 얽매여서 그 이면을 놓쳤을 수 있습니다.

Such tools have significant limitations. There is no such thing as fully automated accessibility testing. For example, given the primitive nature of current artificial intelligence, a computer program cannot have the final say in whether some text is a genuine equivalent for a photograph in context. Even with areas that can theoretically be fully automated, checker programmers may err in their interpretation of accessibility guidelines and lose the spirit of the law amongst its letters.

좋은 도구라 함은, 페이지에서 에러라고 판단하는 부분과, 에러인것 같지만 사람이 최종 결정해야 하는 것을 분리해 줍니다. 예를 들어서 Cynthia Says 도구로 페이지를 분석했을 때 alt=”” 이라는 것을 발견하면, 주의(에러가 아닙니다)를 주면서 이 이미지가 단순한 장식이나 사이띄개로 쓰인 것이고 실제 의미는 없는 것을 확인해달라고 합니다. 정확한 대체 텍스트가 실제로 빈 문자열이라면, 그 주의를 건너뛰고 다음것을 보면 됩니다.

Good tools inspect the page for accessibility problems and produce a list of things they judge to be errors and other things they judge worth human investigation. For example, if Cynthia Says finds an img element with alt="", it will issue a warning (not an error!) instructing the user to “verify that this image is only used for spacing or design and has no meaning.” If the correct text equivalent for that image is an empty string, you should move on to the next error or warning.

접근성 평가 도구의 가장 큰 장점이라면, 아마도 방대한 페이지들을 보는 것입니다. TAW 3 같은 도구는 여러개의 URL을 검사해서, 사람이 꼼꼼히 들여다봐야 할 것 같은 페이지들을 찾아줍니다.

Perhaps the biggest advantage of accessibility checkers is that if you choose one, such as TAW 3, that can be run against multiple URLs, you can find pages in large collections that are likely to require closer inspection.

구조 검사

Structural inspectors

많은 검사기들이 웹 컨텐츠의 구조를 검사합니다. 구조란 것은 간단히 말하자면 사이트에 어떤 부속들이 있고, 그 부속들이 어떻게 연관되었는지를 정의하는 것입니다. 예를 들어, HTML 문서 객체 모델(DOM)에서 텍스트는 label 요소롤 통해 폼 필드의 레이블이 될 수 있습니다. 브라우저는 요소들에 다양한 행동을 부여합니다. 예를 들어서 체크박스의 레이블을 클릭하면 보통 체크박스가 체크됩니다.

Many inspection tools are designed to probe structures of web content. Structures, in simple terms, define what the components of a web site are and how they relate to one another. For example, in the HTML document object model (DOM), text can be designated as a label for a form field using the label element. Browsers parse the HTML into a document object model. The browser associates various behaviour with particular components. For example, if you click the label of a checkbox, it will normally get checked.

데스크탑 소프트웨어들은, 눈으로 보는 것에 적용되는 것과 흡사한 내용과 기능을 나타내는 구조를 제공함으로서 스크린 리더, 음성 인식기, 기타 보조 기술들과의 상호 운용성을 지원합니다. 윈도우 환경에서는 이러한 시스템을 Microsoft Active Accessibility (MSAA), 비스타에서는 UI Automation 이라 부릅니다. 예를 들어서 대화상자에는 타이틀, 필드, 버튼, 레이블과 같은 관련된 자손 요소들이 있습니다.

Desktop environments and applications support interactivity with screen readers, speech recognition software, and other assistive technology by providing a similar structure that represents the content and functionality available in the visual presentation. On Windows, the main structural system is called Microsoft Active Accessibility (MSAA), or UI Automation on Vista. For example, a dialog has a series of related children, such as its title, its fields, its buttons, and their labels.

일반적인 보조 기술들은, 위에서 언급한 구조를 브라우저와 플러그인에서 나타내는 컨텐츠에 의존하며, 웹 문서의 DOM과 직접 소통하지는 않습니다.

Typical assistive technology mostly deals with the browsers’ and plugins’ representation of web content in terms of these structural systems rather than processing web document object models directly.

OS X 에는 Accessibility InspectorAccessibility Verifier 가 포함되어 있습니다. 마이크로소프트에서는 Microsoft Active Accessibility 2.0Microsoft Active Accessibility 1.3 을 제공합니다. GNOME의 보조 기술 API에 대해서는 Accerciser 를 사용할 수 있습니다.

There are inspectors for both desktop-level structures and web-level object models. On the desktop-level side of things, OS X comes with Accessibility Inspector and Accessibility Verifier. Microsoft provides inspector tools for Microsoft Active Accessibility 2.0 and Microsoft Active Accessibility 1.3. Accerciser is available for the GNOME assistive technology-SPI API.

(X)HTML DOM을 다루는 도구에는 Opera Dragonfly, Firebug 같은 것이 있으며, 접근성 관련 도구에는 Web Accessibility Toolbar for Internet Explorer and Opera, ICITA Firefox Accessibility Toolbar 가 있습니다.

Tools for poking at the (X)HTML document object model include DOM Inspectors as seen in Opera Dragonfly and Firebug and accessibility tool bundles like the Web Accessibility Toolbar for Internet Explorer and Opera and the ICITA Firefox Accessibility Toolbar.

접근성 검사기들은 특정한 부분이나 관계들만을 추출해서 보여주며, DOM 검사기는 (X)HTML에서 요소, 텍스트, 속성들로 구성된 트리를 보여줍니다.

DOM inspectors show you the tree of elements and attributes and text constructed out of the (X)HTML serialization, whereas web accessibility inspectors abstract particular components or relationships and list them. For example, they might list all fields with their labels or all headings or all links.

(X)HTML의 접근성 모델로 파고 들어가야 하는 것은 아닙니다. 물론, 브라우저가 보조 기술에게 보내주는 (X)HTML 구조가 부정확하다고 생각한다면 면밀히 검토해 보아야 할 수 있지만, 일반적으로는 (X)HTML 구조를 직접 보게 될 것입니다.

Digging into the accessibility model should not normally be necessary for (X)HTML, though you might also want to investigate that layer if you think a browser is representing a correct (X)HTML structure incorrectly to assistive technology. Instead, you will normally be checking (X)HTML structures directly.

DOM 검사기나 접근성 검사기를 통해 모든 내용을 검사할 수 있는 것은 아닙니다. 미디어 플레이어, 플래시 컨텐츠, 자바 애플릿 같은 플러그인 컨텐츠들 중 어떤 것이 보조 기술에 전달되고 있는지 볼 때는, 어떠한 것이 데스크탑 레벨의 접근성 구조에 전달되는지를 검사하는 것이 중요합니다.

Not all content can be inspected with DOM or web accessibility inspectors. Inspecting what is exposed to the desktop-level accessibility structures is important for checking what plugin content (media players, Flash content, and Java applets) is being exposed to assistive technology that uses those accessibility models.

컨트롤의 역할과 필요한 속성들 모두가 접근성 모델에 제대로 전달되고 보아야 합니다.

In general, you should check that all controls are exposed in the model with the appropriate role (eg text boxes are text boxes, buttons are buttons), and the necessary properties.

최종 사용자가 사용하는 보조 기술

Screening and using end-user assistive technology

스크리닝screening 과정에는 장애를 가진 사람들의 경험을 모방하는 것이 포함됩니다. 보조 기술을 이용해서 사이트를 사용하는 것, 혹은 특정한 방법으로 행동에 제한을 가하는 것 등입니다.

Screening involves emulating the experiences of people with disabilities while testing. This might take the form of using assistive technology to interact with a site or attempting to restrict one’s abilities in some manner. For example:

  • 키보드 접근성을 테스트하면서 mouthstick 을 이용해서 키를 누르는 것
  • Using a mouthstick to press keys while testing keyboard accessibility.
  • 다양한 형태의 색맹을 가진 사람에게 보이는 색상을 모방해주는 Vischeck simulator 를 이용해서 페이지를 보는 것
  • Viewing a page with the Vischeck simulator, which attempts to present the page, images included, as people with different forms of colorblindness see it.
  • 모니터를 끈 채 스크린 리더로 페이지를 이용해 보는 것
  • Turning off a monitor while using a screen reader in conjunction with a browser.

스크리닝을 거치게 되면 개발자들이 장애를 가진 사람들에게 필요한 것을 더 잘 알게 되고, 디자인에 있었던 기초적인 결함들을 찾아낼 수 있습니다. 보조 기술을 직접 사용해 보면, 그러한 기술이 실제로 어떻게 동작하고, 표준에서 어떠한 점들을 어기고 있는지 명확하게 알 수 있습니다. 예를 들면 많은 스크린 리더들이 CSS 미디어 타입에서 aural, 혹은 braille 에 제시된 스타일이 아니라 screen에 제시된 스타일을 사용합니다.

Screening can help build developer appreciation for the needs of people with disabilities and can reveal fundamental design flaws. Use of assistive technology can clear up certain misconceptions about how they do and don’t support and interact with web standards. For example, popular screen readers do not use styles suggested for the aural or braille CSS media types, instead attempting to represent the screen type presented by the visual browsers with which they interact.

보조 기술을 사용해서 테스트하는 것을 가볍게 보아서는 안됩니다. 이러한 시스템을 제대로 사용하려면 훈련이 필요합니다. 잘못 테스트한다면, 새로운 오해를 초래할 위험도 있습니다. 개발자가 악전고투 끝에 스크린리더의 잘못이라고 결론을 내린 것이, 사실은 그가 스크린리더를 제대로 사용할 줄 몰랐기 때문일수도 있습니다. 실제 사용자들은 관심있는 것을 찾아서 제목이나 기타 특정한 요소들만 읽으면서 건너뛸 수 있는데, 개발자는 그걸 몰라서 페이지 전체를 순서대로 읽어 내려갈수도 있는 것입니다. 화면을 통해서 볼 수 있는, 혹은 이미 익숙한 사이트를 스크린리더로 읽는 것과, 완전히 처음 가보는 사이트를 스크린 리더로 읽는 것은 완전히 다른 문제입니다.

Using assistive technology is not a task to be taken lightly, since a good understanding of how to use such systems may require a degree of immersion and training. There’s a serious risk of creating new misconceptions. Developers might struggle to do something with a screen reader and assume that reflects a failing in the screen reader, when it really reflects their inexpertise with the tool. They might try to use the tool the wrong way, for example trying to read a page in sequence where a real screen reader user would hop around it using headings and other elements looking for points of interest. Or alternatively, they might fail to read the screen properly. Reading through a page you can see or know well with a screen reader is very different from exploring a brand new site you cannot see.

보조 기술을 사용해서 테스트해보려면, 그것을 매일같이 사용하는 사람이 어떻게 사용하는지, 그리고 그러한 이용에서 얻어진 결론들은 전문가의 확인을 거쳐야 합니다. 전반적으로, 초보자들은 보조기술을 이용한 테스트를 하지 말고 실제 사용자에게 넘기는 것이 좋을 것입니다.

Use of assistive technology needs to be accompanied by experience of how everyday users employ the technology and conclusions drawn from such use should ideally be confirmed with expert users. On the whole, beginners are better off leaving use of assistive technology to user testers.

자세한 검사

Detailed inspection

일반적인 문제들을 모두 수정했다면, 이제 손으로 테스트하고, 검사하고, 살펴보아야 합니다.

Once all genuine problems identified by your chosen checker tool have been fixed, you can move on to manual testing, probing, and review of the project.

WCAG 2.0은 최상의 사례 기준을 4개의 원칙으로 나누고 있습니다. 내용과 기능들은 다음을 만족해야 합니다.

WCAG 2.0 splits its best practice criterion into four principles. Content and functionality must be:

  • 인식할 수 있고(예를 들어, 이미지에는 대체 텍스트가 있어야 합니다),
  • Perceivable (for example, images should have text equivalents).
  • 조작할 수 있고(예를 들어, 마우스 없이 사이트를 이용할 수 있어야 하며 스크린 리더로 살펴볼 수 있어야 합니다),
  • Operable (for example, it should be possible to interact with a web site without a mouse and navigate it with a screen reader).
  • 이해할 수 있고(예를 들어, 필요 이상으로 복잡한 텍스트를 사용하지 말아야 하며, 예측 가능한 방법으로 사이트를 이용할 수 있어야 합니다),
  • Understandable (for example, copy should not be more complicated than it needs to be and the web site should operate in a predictable manner).
  • 견고해야 합니다(예를 들어, 브라우저간의 상호 운용성이 있어야 하고 내비게이션은 일관되어야 합니다).
  • Robust (for example, web sites should work interoperably with different user agents and navigation should be consistent).

이 섹션에서는 내용이 위에서 제시한 원칙들에 얼마나 잘 들어맞는지 평가하는 예제를 들 것입니다. 이 섹션이 WCAG 리뷰를 대체할 목적을 갖고 있지 않다는 점을 양해 바랍니다.

In this section, I shall present some examples of how expert testers can evaluate how far content matches up to these principles. Please note this section is not intended as a substitute for a review of WCAG and its techniques.

인식성

Perceivability

인식성의 문제는 다양한 형태의 대체 미디어를 제공함으로서 해결할 수 있습니다. 브라우저에서 이미지와 멀티미디어를 끄고 페이지를 보면 대체 텍스트를 테스트해볼 수 있습니다. img 요소와 input 요소에는 특히 주의해야 합니다. 일반적으로는, 순수하게 장식적 목적으로 사용된 모든 이미지들에는 alt=”” 을 사용해서 스크린 리더들이 건너뛸 수 있도록 하는 것이 좋습니다. 하지만 다음의 경우에는:

One subset of perceivability problems revolves around the provision of alternative media of various types. You can test for text equivalents by turning off images and multimedia in your browser and looking at the page. But you’ll need to take special care with the img and input elements. Normally, you are advised to give all purely decorative images blank alt attributes (alt="") so that the screenreader will just skip them. However, in the case of:

  • 이미지가 링크의 유일한 내용인 경우
  • Images that are the sole content of links
  • 폼 버튼
  • Form buttons

이러한 경우에 alt 속성의 값이 빈 문자열이라면, 스크린 리더는 보통 그 이미지 또는 버튼에 alt 속성이 없는 것으로 취급하여, 뭔가 다른 것(예를 들어, 이미지의 URL)을 읽어주려고 합니다.

When these elements are given alt="" attributes, screen readers will commonly treat the image or button as if the alt="" atribute is missing, and attempt to provide one (for example, by reading out the URL of the image).

따라서 이러한 경우에는 링크의 목적지 또는 버튼을 눌렀을 때 일어날 것을 대체 텍스트로 제공해야 합니다. 설령 이렇게 함으로서 약간의 중복이 발생하더라도 그렇게 해야 합니다.

Therefore in these particular circumstances you must ensure that images inside links or buttons have an alt attribute that describes the link destination or button action, even though this is slightly repetitive.

캡션이나 음성 설명과 같은 동기화된 대체 미디어를 테스트하고자 할 경우, 미디어 플레이어에서 접근성 세팅을 켜 두어야 할 것입니다.

Testing for equivalents synchronized with multimedia, such as captions and audio descriptions, can be done by digging into the preferences for your media player to turn on accessibility settings.

다른 문제는 페이지의 스타일과 관련된 것입니다. 3가지 경우를 살펴보아야 합니다.

Another group of perceivability problems concerns the styling of the page. There are three areas to investigate here:

  • 페이지의 표현이 충분히 접근성 있는가? 예를 들면, 색상들 사이에 충분한 대비가 있는지, 텍스트의 크기는 충분한지 하는 것이 이 범주에 속합니다. 페이지를 직접 살펴볼수도 있지만, Juicy Studio CSS Analyser 같은 도구를 사용하면 전경색과 배경색 사이에 충분한 대비가 있는지 검사해볼 수 있습니다.
  • Is the suggested presentation of the page reasonably accessible? For example, is there sufficient color contrast? Is the text comfortably large? In addition to squinting at the page yourself, you can use a tool such as Juicy Studio CSS Analyser to check background and foreground color combinations against formulae that purport to measure legibility.
  • 편집자가 제안하는 것이 가독성 향상을 위한 일반적인 선택과 잘 들어맞는가? 이러한 것에는 폰트 크기를 키우는 것, 확대하는 것, 기본 색상을 다양하게 갖는 것 등이 있습니다. 텍스트의 크기를 2-5 단계 정도 키워 보십시오. 텍스트를 확대해도 픽셀 단위로 정확하게 맞을 필요는 없습니다. 내용을 읽기 힘들 정도로 레이아웃이 심하게 왜곡되지만 않으면 됩니다. 색상을 바꾼 후에 어떻게 달라지는지 확인해 보십시오. 편집자가 작성한 CSS에서 색상을 정의한다면, 반드시 배경색과 전경색 모두를 명시적으로 지정해야 합니다. 배경색만 지정했다면, 사용자가 선호하는 전경색과 충분한 대비를 이루지 못해서 텍스트를 읽기 힘들거나, 심지어는 보이지 않는 경우가 생길 수도 있습니다. 유명 브라우저들은 사용자가 자신이 선호하는 색상을 강제하고, CSS에서 지정하는 배경 이미지를 끄도록 하는 기능을 제공합니다. 이러한 테스트를 직접 해 보면, 이미지가 로드되지 않았는데도 텍스트를 볼 수 없는 경우를 통해서 IR 기법7을 잘못 적용한 것을 발견할 수 있을 것입니다.
  • Can publisher suggestions for presentation be safely mixed with common user preferences aimed at making content more legible, like increased font size, zoom, and different default colors? Try increasing the text size by about 2–5 steps; don’t worry if the results are not pixel perfect but do worry if the layout is so broken it renders the content hard to read. Try changing your color preferences and see what happens. If publisher CSS sets colors, it should explicitly set background and foreground together to ensure that the combination of unusual preferences and publisher styles do not result in unreadable or invisible text. Popular browsers allow users to enforce their own color preferences and turn off CSS background images. When you try this yourself, it can reveal misconceived CSS image replacement techniques that hide text off-screen, since the image will not be loaded but the text will still be invisible.
  • 편집자의 스타일링을 사용하지 않을 경우, 사용자 에이전트의 기본 스타일이 적용되어도 모든 정보들이 잘 전달되는가? CSS를 끄고 DOM을 살펴보면서 제목이 제목으로 전달되는지, 테이블이 레이아웃이 아니라 표 형태의 데이터를 표시하기 위해 사용되고 있는지 확인해볼 수 있습니다.
  • If publisher suggestions for presentation are discarded, is all the information communicated by such suggestions preserved in the web content for use by the default stylings of the user agent or user styling? Try turning off CSS and inspecting the document object model to check that headings are marked as headings and tables are used for tabulated data not layout.

운용성

Operability

종종 간과하고 있지만, 건강과 안전에 관한 문제는 웹 사이트의 운용성을 말할 때 빼놓을 수 없는 요소입니다. 번쩍이는 컨텐츠들은 광과민성 발작을 일으킬 위험이 있습니다. 사이트의 화면을 캡쳐해서 무역센터 광과민성 발작 분석 도구 에 보내면 번쩍이는 컨텐츠들이 위험한 수준인지 확인할 수 있습니다. 비디오 공유 사이트를 만들고 있다면 이러한 문제는 정말로 중요합니다. 업로드시에 필터링을 적용할 것인지 디자인 과정에서부터 고려해볼 수 있습니다.

Health and safety is a crucial, though rarely considered, part of making a website operable. But flashing content risks triggering fits in photosensitive epileptics. You can take a screen capture of your website in use and feed it into the Trace Center Photosensitive Epilepsy Analysis Tool (PEAT) to test if it has flashing content likely to pose a danger to your users. Obviously, this is an especially big concern if you are creating a video sharing website. At the product design stage, you might look at including an automated screening process for uploads.

위의 문제가 해결되었다면, 사이트의 운용성을 테스트하는 것은 서로 다른 장치들에서 모든 중요한 내용과 기능들을 이용할 수 있는지 보는 것으로 충분합니다.

Beyond that, a good way to test the operability of websites is simply to try to see if you can access all essential content and functionality with different devices:

  • 키보드만으로 사이트를 이용해 보십시오. 쉽게 포커스를 확인할 수 있습니까? 모든 기능들을 키보드만으로 이용할 수 있습니까?
  • Try using your site with just the keyboard. Is current focus always clearly indicated? Can all functionality be accessed by keyboard?
  • 터치스크린 장치로 사이트를 이용해 보십시오.
  • Try using your site with a touchscreen device.
  • 오페라 브라우저에서 음성 애드온을 켜거나, 윈도우 비스타의 음성 인식을 켠 채로 익스플로러에서 음성으로 페이지를 이용해 보십시오. (노트: 최근 맥 OS X에서 받아쓰기 수준의 음성 인식을 지원하는 MacSpeech Dictate(상용 프로그램입니다)가 발표되었습니다. 무료인 *nix 플랫폼에서는 아직 사용할 수 있는 것이 없습니다)
  • Try navigating your webpage with voice commands using Opera for Windows and its Voice add-on, or Windows Vista Speech Recognition and Internet Explorer. (Note: dictation-quality commercial speech recognition has recently been introduced to Mac OS X in the form of MacSpeech Dictate, but there is currently no equivalent on the free *nix platforms.)

스크린 리더와 기타 보조기술들은 HTML의 의미적 구조를 이용해서 컨텐츠들을 연결하고 이용할 수 있습니다. 예를 들어, 스크린 리더들은 다음의 제목 요소로 이동하는 기능이 있고, 특정한 타입의 요소들을 모두 나열하는 기능도 있습니다. label 요소와 legend 요소를 정확하게 사용하면 보조 기술에서 폼 필드에 정확한 레이블을 연결할 수 있습니다. th요소와 header, scope, axis 속성을 정확하게 사용하면 테이블의 헤딩을 데이터 셀과 연결할 수 있습니다. 오페라 드래곤플라이 같은 도구를 사용해서 의미적 구조들을 평가해볼 수 있습니다. 파이어폭스의 접근성 확장기능 같은 것을 이용하면 몇몇 작업들을 좀더 쉽게 할 수 있습니다. 예를 들어, 페이지의 제목들을 나열한다거나, 폼 필드의 속성들을 나열(이렇게 하면 레이블이 없는 필드를 빠르게 찾을 수 있습니다)하는 등입니다. 그림 1에 예제가 있습니다.

Screen readers and other assistive technology can make use of the semantic structure of (X)HTML to correctly associate content and to enable navigation of content. For example, screen readers can allow users to jump to the next occurrence of headings or other element type, or they can list all occurrences of a certain type. Correct use of label and legend elements allows assistive technology to associate labels with the correct form fields; correct use of th elements and header, scope, and axis attributes allows it to associate table headings with table data cells. Semantic structure may be evaluated with a document object model (DOM) inspector like the one found in Opera Dragonfly. Accessibility inspection tools like the Firefox Accessibility Extension can make such tasks easier by, for example, listing the headings on the page, or listing the attributes of form fields (quickly showing which ones are missing associated labels). See Figure 1 for an example.

 

그림 1. 파이어폭스의 접근성 확장 기능을 이용해서 BBC 홈페이지의 폼에 관한 정보를 보고 있습니다.

Figure 1: Screenshot of Firefox Accessibility Extension’s forms information window with the new BBC homepage.

이해도

Understandability

페이지를 얼만큼 이해할 수 있는가 하는 것은, 글자들을 얼마나 잘 읽을수 있는가 하는 문제보다 더 중요합니다. 평가자가 프로젝트에 대해 전혀 모르거나, 아니면 전문가일 경우에만 텍스트가 얼만큼 읽기 쉬운지 올바르게 평가할 수 있습니다. Juicy Studio’s Readability Test tool 같은 것을 이용하면, 텍스트가 얼마나 간결하게 씌어졌는지 어느정도는 알 수 있습니다 .8

Assessing comprehensibility is even more subjective that testing legibility. Unless an evaluator is new to a project or is a professional editor, they are probably not the best person to evaluate whether copy is as understandable as possible. You can however use Juicy Studio’s Readability Test tool to get a rough idea of how simple your site’s copy is.

몇몇 부분들은 강한 목적의식을 가지고 테스트할 수 있습니다. 예를 들면 스크린 리더나 음성 브라우저에서 적합한 언어를 선택하도록, 언어에 관한 메타데이터가 제공되는지 같은 것입니다. HTML에서는 DOM 검사기를 사용해사 문서에 lang 속성이 있는지, 사용하는 언어가 바뀔때마다 lang 속성이 명시되는지 검사해 볼 수 있습니다.

Some aspects are highly objectively testable however, such as whether content has language metadata that allows (for example) screen readers and voice browsers to read content with the correct pronunciation. With HTML, you could use a DOM inspector to check for the presence of a lang attribute for the document and each change of language.

사이트에는 일관성이 있어야 합니다. 사이트 내부에서의 일관성은 물론이고, 보편적인 인식으로 예측할 수 있어야 합니다. 화면 확대기를 사용하는 사람들은 그러한 일관성에 크게 의존합니다.

Keep an eye out for inconsistencies in web sites, both in terms of internal consistency and predictability from common web conventions. Screen magnifier users who only see part of a page at a time rely heavily on such consistency in order to know where to look to find given content and functionality.

견고함

Robustness

사용하고 있는 기술(HTML 같은)이 정확하게 사용되고 있는지 점검하는 것은 내용이 견고하게 만들어져있는지 체크하는 과정의 일부입니다. 아주 기초적인 수준에서, 다음과 같은 유효성 검사기를 사용해서 마크업과 코드를 점검해볼 수 있습니다.

Testing whether content is robust involves checking that technologies are being correctly used. At a very basic level, you can run markup and code through linters such as:

다음으로 코드를 직접 검토하면서 기능들이 정확하게 사용되었는지 점검할 수 있습니다. 예를 들면, 아무 의미 없는 요소들에 자바스크립트를 연결하여 기능을 구현하는 것 보다는, HTML의 네이티브 컨트롤을 사용해야 합니다. 또한 자바스크립트가 브라우저 확인을 하지 않고, 기능을 확인하는지 점검해 볼 수 있습니다.

Next, you can review code in depth to check that features are used correctly. For example, you can check that HTML native controls are used rather than faking controls with meaningless elements and JavaScript, and that JavaScript uses feature detection rather than browser sniffing where possible.

이제 다양한 브라우저와 보조 기술에서 내용이 인식 가능하고, 사용 가능하고, 이해할 수 있도록 제공되는지 확인할 차례입니다. CSS, 자바스크립트, 플러그인의 어떠한 조합에서도 문제가 없어야 합니다.

Then you can test in multiple user agents and assistive technologies, checking the site is perceivable, operable, and understandable whatever combination of publisher CSS, JavaScript, and plugins are enabled or disabled.

가장 흔한 문제는 겸손하지 않은 자바스크립트와 결부되어 있습니다. 앵커나 버튼들이 자바스크립트에 의존하는 것입니다. 더 큰 문제는, 자바스크립트와는 다른 계층에서 동작하는 기술들을 자바스크립트에 결부시키는 것입니다. 예를 들어, 자바스크립트를 가지고 CSS의 display: none; 을 적용할 수 있습니다만, 편집자가 적용한 CSS가 차단되었을 경우 복잡한 문제가 발생할 것입니다.

The most common problem is probably obtrusive JavaScript, like anchors and buttons that are in the unscripted markup of the page but depend on JavaScript to actually do anything. But there are more subtle problems that arise from overly close coupling of JavaScript with other layers in the technology stack. For example, JavaScript might apply CSS display: none; to hide content, but what happens when publisher CSS is not applied?

다른 예는 멀티미디어 컨트롤입니다. 종종, 플러그인 컨텐츠를 사용하면서 그 플러그인에서 제공하는 인터페이스를 무시하고 자바스크립트를 사용한 HTML 위젯으로 컨트롤하는 경우가 있습니다. 자바스크립트로 플러그인의 지원여부를 검사한 후, 내용을 자바스크립트로 불러 온다면 별 문제는 되지 않습니다. 하지만 자바스크립트가 실행되기도 전에 컨텐츠가 페이지에 삽입되는 경우도 많습니다. 이러한 경우, 플러그인을 사용할 수 없는 경우에 대비해서 폴백 컨텐츠를 제공할 뿐만 아니라, 자바스크립트를 사용할 수 없는 경우에는 플러그인의 네이티브 인터페이스를 차단하지 않도록 해야 합니다. 후자를 제대로 하지 않는다면, 사용자는 플러그인을 볼 수 있지만 거기에 대해서 어떤 행동도 취할 수 없게 될 것입니다.

Another example is multimedia controls. Often, when plugin content is included, the plugin’s native user interface is disabled and the plugin is instead controlled by scripted HTML widgets. When the plugin content is only added via JavaScript after JavaScript-based plugin detection, this is fine. But sometimes plugin content is included in the pre-scripted state of the page. In such cases, it is worth checking not only that a fallback has been included in case a handling plugin is not available, but also that the native user interface of the plugin is not disabled unless JavaScript is available. If the former is not the case, then users will not see the fallback content at all; if the latter is not true then users will see the plugin but not be able to control it.

사용자 테스트

User testing

개발자가 아무리 열심히 테스트를 한 들, 사용자와 사이트 사이의 충돌을 완전히 막을 방법은 없습니다. 웹 컨텐츠와 보조 기술이 상호작용하는 방법들을 전부 이해하는 것은 어려운 일이며, 장애를 가진 사람들이 웹을 어떻게 이용할 것인지 예상하는 것도 어렵습니다. 이러한 어려움은 장애를 가진 사람들에게 중첩되어 나타납니다. 가능하기만 하다면, 장애를 가진 실제 사용자와 함께 사이트를 테스트해야 합니다. 이러한 것은 비용이 많이 들고 큰 규모의 사이트가 아니라면 어렵기는 하겠지만, 작은 규모라도 테스트하는 것의 효과를 과소평가해서는 안됩니다.

No amount of developer inspection and screening can substitute for the raw clash between a user and a web site. Given the difficulties of understanding all the subtle interactions between web content and assistive technology and the difficulties of approximating the experience of users with disabilities, this goes double for users with disabilities. If at all possible, you should test your site with real users with disabilities. This can be done on a large and expensive scale, but do not underestimate the benefits of doing even small-scale user testing.

참가자 모집

Recruiting testers

사용성 테스트 참가자를 찾는 것과 마찬가지로, 광고를 하거나 이런 일을 대행해주는 에이전시를 통해서 참가자를 찾을 수 있습니다. 근방의 장애인 단체에서 참가자를 모집할만한 포럼을 소개해 줄 수도 있을 것입니다.

Testers can be found in the same way as you find candidates for usability testing generally (eg through advertising and recruitment agencies). Your local disability organizations should be able to suggest appropriate forums for recruiting test subjects.

테스트는 실제 업무이며, 적합한 투자가 필요합니다. 시간당 70불 정도의 비용이 일반적입니다.

Testing is real work and should ideally be compensated as such. A rate of around 70 USD for an hour’s testing is fairly common for user testing.

작은 프로젝트를 테스트하는 경우라면 무료로 해 줄 사람들을 찾을 수도 있을 것입니다. 친구, 지인, 동료들 사이에 장애를 가진 사람이 있을 수도 있습니다. 아래에 나열하는 그룹들은 모두 소프트웨어 접근성을 주로 토론하는 그룹들입니다.

Having said that you may be able to find people who will test smaller projects for free. There will be people with disabilities among your friends, relatives, and colleagues. In addition, there are online discussion groups dedicated to software accessibility issues, such as:

이런 그룹에서는 사이트의 접근성, 혹은 좀 더 상세한 테크닉들에 대한 개발자들의 질문을 환영하는 편입니다.

Such groups typically welcome questions from web developers about the accessibility of their sites or particular techniques.

현실에 관한 고려

Practical considerations

테스트 환경 자체가 접근성있어야 한다는 점을 염두에 두어야 합니다. 예를 들어서 테스트 대상을 출력해 두었다면, 다른 형태로도 제공할 수 있어야 한다는 뜻입니다. 사용자의 웹 이용 환경을 그대로 모방하기는 어려울 것이므로, 사용자의 집에서 테스트한다면 좀 더 현실에 밀접할 것입니다. 이렇게 할 수는 없더라도, 원격으로 테스트하는 것도 충분한 가치가 있습니다.

Remember that the test environment itself needs to be accessible. For example, if you are preparing written test materials, you need to be prepared to offer these in alternative forms. The logistics of replicating the user’s browsing environment at your normal testing location are complicated, so it may be more realistic to test at the user’s home. Failing that, even completely remote testing can be valuable.

장애를 가진 사람들에게는, 어떤 도구에 익숙해져 있는가가 다른 사용자들보다 더 중요할 수 있습니다. 보조 기술을 사용하게 되면, 컴퓨터를 이용하는 환경에 많은 복잡함이 더해집니다. 따라서 장애를 가진 사람들은 초보자와 전문가의 차이가 더 크게 나타나곤 합니다. 또한 특정 도구에 충분히 익숙해진 사람은 다른 도구를 전혀 이용하지 않는 경향이 있습니다. (컴퓨터 사용에 영향이 있는 장애를 전혀 갖지 않았다 하더라도, 맥을 쓰다가 PC로, 혹은 그 반대로 이동하는 것이 얼마나 어려운지 생각해 보십시오)

One particular consideration that is probably even more important for users with disabilities than other users is what technology they are familiar with. Assistive technology can add many layers of complexities to their computing experience, creating a big divide between novice computer users and old-hands, and dividing users into communities who might be very adept with their own setup but highly disorientated by unfamiliar technology. (Think of how hard users without disabilities that affect their use of computers find it to switch between Mac and PC!)

Window-Eyes 스크린 리더를 오랫동안 사용해 온 사람을 JAWS 스크린 리더가 설치된, 익숙하지 않은 테스트 환경에 초청해서 사이트를 테스트해볼 것을 요청한다면 아마 잘 대답하지 못할 것입니다. 버전 사이의 차이도 크고, 사용자가 자신의 도구를 설정하는 것에도 차이가 있기 때문에, 심지어는 같은 Window-Eyes 스크린 리더를 설치했다 하더라도 같은 문제가 발생할 수 있습니다.

If you take a longtime user of the Window-Eyes screen reader, sit him in front of an unfamiliar machine with the JAWS screen reader installed and ask him to test a website, it’s going to be very difficult to distinguish his problems with JAWS from his problems with your website. Given the significant differences between versions and given how users often customize their setup, it may be difficult even if you provide Window-Eyes! For this reason, unless you are specifically testing how well your website’s accessibility will hold up in unfamiliar settings (eg in libraries or friends’ computers), it is best to allow users to test with their own setup or something as close as possible to it.

이러한 이유로, 특별히 초보 사용자나 전문가를 대상으로 테스트하려는 목적이 있는 것이 아니라면, 테스트 참가자는 현재의 세팅으로 1년 정도 웹을 사용해 본 사람들로 선정하는 것이 좋습니다. 보조 기술도, 웹의 경향들도 배우기가 쉽지만은 않습니다. 초보자들과 함께 테스트한다면, 발생하는 문제들이 사이트의 문제인지 아니면 참가자의 무지에서 비롯된 것인지 알기 어려울 것입니다. 전문가와 테스트한다면, 남들은 모르는 테크닉을 알고 있을 가능성이 있으므로 역시 정확하기 어렵습니다.

Likewise, unless you specifically want to test novice users or expert users, you should aim to select users who have around a year’s familiarity with using their current setup to access the web. Both assistive technology and the conventions of the web itself are non-trivial to learn. With novice users you will not know whether problems arise from your site or are intrinsic to the learning process, and experts may have tricks up their sleeves that others don’t.

모델 선정

Choosing tasks

믿기 어렵겠지만, 사용자가 단순히 사이트를 둘러보는 것을 관찰하는 것 조차 정확한 지침을 다라야 합니다. 다른 사용자 테스트와 마찬가지로:

It’s incredibly instructive even to observe users simply exploring a website. As with any other user testing:

  • 사용자가 완수해야 할 과제를 만들고,
  • Try setting the users some specific tasks to accomplish.
  • 사용자가 생각했던 것을 들어보고,
  • Ask them what they think and listen to what they say.
  • 사용자가 실제로 무엇을 하는지에 주의를 기울여야 합니다. 말하는 것과 실제 하는 것은 다르기 때문입니다.
  • Pay attention to what they do, because that may differ from what they say: stated preference is a poor guide to performance.

사이트를 디자인할 때는, 특정한 컨트롤에 집중할 것이 아니라 사용자가 사이트에서 하고자 했던 일을 할 수 있는지에 집중해야 합니다. 마찬가지로, 접근성을 테스트하려면 사이트의 방문자가 실제 하고자 했을 일을 반영해아지, 특정 컨트롤이 접근성있는가 하는 것에 매몰되어서는 안됩니다. 그리고 그러한 “일”은, 장애를 가진 사람과 그렇지 않은 사람 사이에 차이는 없기 마련입니다.

When you design a site, you need to focus on the transactions users want to make with your site rather than the particular controls they need to use. Likewise, when accessibility testing, the tasks you set should (at least initially) reflect the real goals of a visitor using the site, rather than being focused on their interactions with particular controls. These transactions will typically be similar for people with and without disabilities.

비디오 공유 사이트의 접근성을 테스트한다고 해 봅시다. 특정한 컨트롤을 사용할 수 있는지 묻는(“볼륨 조절기입니다. 볼륨을 조절할 수 있나요?”) 것이 아니라, 수행해야 할 과제를 제시하는 것입니다. 그러한 과제의 예를 들면:

For example, if you are testing a video sharing site for accessibility, do not begin by asking them if they can use particular controls (“That’s the volume slider. Can you adjust the volume?”). Instead, give them scenarios and ask them to achieve key user tasks. For example:

  • 비디오들을 둘러보고, 시청할 것을 하나 선택하십시오.
  • Browse videos and choose one to play.
  • 원하는 비디오를 검색해 보십시오.
  • Search for a video.
  • 업로드해 보십시오.
  • Upload a video.
  • 일시정지, 재생, 음소거, 되감기 등을 해 보십시오.
  • Pause the video, play the video, mute the video, unmute the video, rewind the video and play it again.
  • 등급을 매겨 보십시오.
  • Rate a video.
  • 친구와 공유해 보십시오.
  • Share a video with a friend.

이렇게 하면, 미처 생각하지 못했던 문제점들을 많이 발견할 수 있을 것입니다. 예를 든다면 스크린 리더 사용자가 검색 박스나 비디오 컨트롤을 찾지 못하는 문제가 있을 수 있습니다. 반대로, 스크린 리더에 익숙하지 않은 개발자가 생각하지 못했던 내비게이션 방식을 사용자가 알고 있을 수도 있는 것입니다.

This way, you are likely to uncover lots of problems you had not anticipated. For example, a screen reader user might not be able to find the search box or the controls for the video. Conversely, users might have navigational strategies for dealing with the web you do not even know about.

결과 해석

Interpreting the results

가능한 모든 조합들을 테스트하고, 모든 사용자에게서 피드백을 받는다면 이상적일 것입니다. 하지만 현실에서는 시간과 비용 문제로 사용자 테스트가 제한됩니다. 즉 사용자의 피드백은 양날의 검이 될 수 있습니다. 사용자 테스트를 통해 많은 것을 알 수 있지만, 반대로 대상 사용자 전체를 대변하지는 못할 한가지 의견에 너무 기대게 될 위험도 있는 것입니다. 일부 스크린 리더 사용자는 맹인에게 알맞도록 선형화된 사이트 구조를 선호할수도 있겠지만, 반대로 친구나 동료를 통해 사이트에 대해서 잘 알고 있을 수도 있습니다.

In an ideal world, we could test every possible combination and get feedback from everybody. But in reality, time and money will limit user testing. Given this, feedback can be a double-edged sword. While it can teach you an enormous amount, there is a real danger of attaching too much weight to one person’s view, which may not be representative of the greater target audience. For example, some screen reader users tend to be looking for an experience streamlined for blind users; others are keen to know everything about the site that their sighted friends and colleagues see.

이러한 경우가 WCAG 같은 접근성 표준이 도움이 되는 경우입니다. 그러한 가이드라인을 따라감으로서, 직접 테스트해볼수 없는 사용자 층의 접근성을 확보할 가능성이 더 커질 수 있습니다.

This is where accessibility standards like WCAG really come into their own. By following such guidelines, you can increase your chances of getting a foundation of accessibility even for user groups you are not able to test.

문제를 관찰할 때는 그 이유를 분석해야 합니다. 예를 들어, 비디오 공유 사이트에서 유명한 비디오들을 테이블의 형태로 표현한다고 해 봅시다. 테이블의 열 에는 스틸 이미지, 제목, 업로드된 날짜, 마지막 플레이된 날짜, 전반적인 평점이 표시되고, 행 으로는 그 비디오의 분류에 따라서 나열되어 있습니다. 사용자 테스트를 해 본 결과 스크린 리더 사용자가 그 테이블을 이용하기가 어렵다는 의견을 냈습니다. 그러한 이유로는 다음과 같은 것이 있을 수 있습니다.

When you do observe a problem, analyse its causes. For example, your video sharing site includes a page showing popular videos in a data table, with columns including a still, a title, uploaded date, last played date, and overall rating, and arranged in row groups by category of video. In user testing, a screen reader user has trouble using the data table. This could reflect:

  • 마크업의 문제입니다. 개발자가 여기에 적합한 테이블 마크업을 사용하지 않고, 의미없는 div 들을 나열해서 테이블의 모양만을 만들어 놓았을 수 있습니다. 적합한 해결책은 테이블을 사용해서 다시 마크업하는 것입니다.
  • A problem with the site code. For example, maybe the developers constructed a data table from meaningless div elements rather than using proper data table markup. Here the appropriate action would be to recode the table.
  • 사용자의 기술 부족입니다. 예를 들어 JAWS 스크린 리더를 사용하지만, 그것이 데이터 테이블을 읽는 방식에 친숙하지 못한 경우 같은 것입니다. 적합한 해결책은, 기술이 부족한 사용자를 위해 추가적인 문서 혹은 힌트를 제공하는 것입니다. 전문적인 사용자들은 테스트에는 적합하지 않지만, 이러한 부분에서는 큰 도움을 줄 수 있습니다.
  • Inexpertise on the part of the user. For example, a JAWS user might be unfamiliar with JAWS’s features for navigating and reading data tables. Here an appropriate action might be to provide additional documentation or hints for less expert users. If expert users do not make ideal test subjects, they make great consultants on points such as this.
  • 브라우저의 문제입니다. 예를 들어, 사파리는 데이터 테이블을 읽으면서 애플 접근성 모델에 데이터들의 관계를 전달하는 것이 아니라 레이아웃 박스들을 전달합니다. 적합한 해결책은 브라우저 개발자 혹은 판매자에게 버그 리포트를 전달하거나, 그 브라우저에서 사용할 수 있는 테크닉을 연구해보거나, 브라우저의 한계를 문서화하고 사용자에게는 다른 브라우저로 사이트를 이용할 것을 권할 수 있습니다.
  • A problem with the user agent. For example, Safari exposes data tables to the Apple accessibility model as a series of layout boxes rather than as a set of data relationships. Here appropriate actions would include reporting the bug to the user agent vendor or developers, researching a technique that does work in the user agent, or noting the limitation in documentation and suggesting alternative user agents that do work with your web site.
  • 스크린 리더의 문제입니다. 예를 들어, 테이블 헤더가 너무 길어서 abbr 속성을 이용해서 단축했지만, 스크린 리더가 이러한 약어를 읽어주지 못하는 경우 등이 있을 수 있습니다. 적합한 해결책은 스크린 리더의 개발자 혹은 판매자에게 버그 리포트를 전달하고, 그 스크린 리더에서 사용할 수 있는 테크닉을 연구하거나, 스크린 리더의 한계를 문서화하고 사용자에게는 다른 스크린 리더로 사이트를 이용하거나 다른 이용방법을 찾아볼 것을 권할 수 있습니다.
  • A problem with the screen reader. For example, the developers might have shortened long table headers using the abbr attribute, but the screen reader might not provide a user interface for reading the shortened version. Here appropriate actions would include reporting the bug to the screen reader vendor or developers, and might be to find a technique that does work in the screen reader, or to note the limitation in documentation and suggest an alternative tool or navigation strategy that does work.

소통: 접근성 테스트 결과

Communicating the results of accessibility testing

접근성 평가 결과를 논의할 때에는 어떠한 점들을 평가했는지 정확하게 문서화해야 합니다. 특정한 표준에 맞춰서 테스트했다면, 정확히 어떤 요구사항을 준수했고 어떤 것을 만족하지 못했는지 밝혀야 합니다. 발견된 모든 문제들을 실제 문장으로 기록하고, 그 문제가 사용자에게 어떤 영향을 끼치는지 설명해야 합니다. 문제를 다시 만들어내는 방법을 설명하고, 그 해결책을 어떻게 테스트할 수 있는지 남겨야 합니다. 요구사항을 준수하거나 접근성을 개선할 수 있는 현실적인 방안을 권해야 합니다.

When communicating the results of accessibility evaluation, document precisely what was evaluated. If you tested conformance with a particular standard, be specific about exactly where conformance has succeeded and failed. Whenever raising a problem, make sure to put it in real, human terms and explain how the problem might adversely affect users. Describe how to reproduce the problem and test for its resolution. Suggest practical techniques for achieving conformance or improving accessibility.

비디오 공유 사이트에서 다음과 같은 문제들을 발견했다고 가정합니다.

For example, you might report a problem with the video sharing website like this:

    < ! dl 구조가 더 낫지 않을지? –> 

  • 발견된 문제: 마우스로 화면 맨 위를 지나가지 않으면 드롭다운 메뉴가 열리지 않는다. 탭을 사용해서 메뉴를 이용하려고 하면 키보드 포커스가 화면 밖으로 나가버린다.
  • Problem: The dropdown menu cannot be opened without using a mouse to hover over top menu items, and the keyboard focus disappears off-screen as you tab through the menu.
  • 문제 재현 방법: 브라우저에서 페이지를 열고, 키보드만을 사용해서 서브메뉴를 사용해본다.
  • How to reproduce: Open the page in your browser and attempt to reach a subitem of the menu using the keyboard alone.
  • 설명: 시각에 문제가 있거나 팔 관절에 문제가 있는 사람들도 이용할 수 있도록, 내비게이션은 장치와 무관하게 이용할 수 있어야 한다. 현재로서는 그러한 사용자들이 서브메뉴를 이용할 수 없으며, 시각에 문제가 없는 사용자라고 해도 키보드를 이용하다 보면 포커스가 사라지는 것 때문에 혼란스러울 수 있다.
  • Explanation: Web navigation should be device-independent, so that users using devices other than mice—such as blind users or users with motor disabilities—can access content and functionality. Currently, such users can not access the items in submenus and sighted users using the keyboard may be confused when the focus indicator disappears.
  • 관련된 표준: 키보드 접근성은 WCAG 1.0과 WCAG 2.0의 “A” 등급(최소한의) 요건이다. (WCAG 1.0 가이드라인 9 와 WCAG 2.0 가이드라인 2.1을 참고하라)
  • Conformance implications: Keyboard operability is a requirement for WCAG 1.0 and WCAG 2.0 Level “A” compliance (see WCAG 1.0 Guideline 9 and WCAG 2.0 Guideline 2.1).
  • 권장사항: 자바스크립트를 사용할 수 없을 경우, 내비게이션 링크 목록들로 이동할 수 있는 서브페이지를 사용한다. 자바스크립트를 사용할 수 있다면, 스크립트를 사용해서 DOM 으로부터 서브페이지 링크를 삭제한 후 메뉴 항목 각각의 click 이벤트에 연결한다. click 이벤트는 키보드, 마우스, 음성인식, 터치스크린 모두를 통해 호출된다.
  • Suggested remedies: When JavaScript is not available, use a simple list of links to subpages for each sublist of navigation. On sub pages, present the main navigation followed by the sublist. When JavaScript is available, remove the sublist from the DOM and add sublists for each menu item on the click event, which can be triggered by keyboards, mice, speech recognition, and touch screens alike.
    • 마우스를 사용하지 않고 복잡한 사이트를 이용해 보십시오. 어떤 어려움이 있습니까? 당신이 개발자라면 어떻게 해결하겠습니까?
    • Try navigating a complex site of your choice without using the mouse. What difficulties do you encounter? How could the developers of the site help you?
    • 하루동안 CSS를 끄고 웹을 이용해 보십시오. 어떤 문제들이 있습니까?
    • Turn off CSS and do your normal browsing for a day. What problems do you encounter?
    • 하루동안 자바스크립트를 끄고 웹을 이용해 보십시오. 어떤 문제들이 있습니까?
    • Turn off JavaScript and do your normal browsing for a day. What problems do you encounter?
    • 즐겨 찾는 사이트를 하나 골라서, 몇가지 가상 인격을 만들고, 전문 테스터의 입장에서 WCAG 1.0과 일반적인 접근성 문제들을 평가해 보십시오. 그 사이트에서 사용자 테스트를 할 모델을 만들어 보십시오. 이러한 과정을 통해 사이트의 접근성을 어떻게 증진시킬 수 있는지 적어 보십시오.
    • Pick a favourite site, design some personas for the site, then evaluate its conformance with WCAG 1.0 and general accessibility as an expert tester. Design a user testing plan for a site, and include recruit requirements and tasks to test. Write up a report on how it could improve its accessibility.
  • 요약

    Summary

    모든 웹페이지를 전문가가 평가하고, 정당한 비용을 지불하면서 사용자 테스트를 거치게 할 수는 없습니다. 하지만 모든 개발자들이 접근성의 원칙들을 배울 수 있고, 그러한 원칙들을 코드에 구현할 수 있으며, 자신이 노력한 결과를 메일링 리스트에 등록해서 다른 문제들에 대해 알아보고, 이후 개발 과정에서는 새롭게 알게 된 지식들을 활용할 수 있을 것입니다.

    Not every webpage will receive an accessibility evaluation by experts and a suite of paid test subjects. But any web developer can learn the principles of accessibility, attempt to implement those principles in their code, and submit the results of their labours to user mailing lists to learn of further problems, and so feed new knowledge back into future development.

    연습문제

    Exercise questions

    저자 소개

    About the author

    Benjamin Hawkes-Lewis 는 대학에서 중세의 왕들, 18세기의 과학자들 같은 역사 공부를 한 후, 이유는 모르겠지만 야후! 에 웹 개발자로 입사했습니다. 그가 좋아하는 것은 친구들과 함께 식사하는 것, 극장에서 좋은 영화를 보는 것, 따사로운 햇살을 받으며 풀밭에서 게으름을 피는 것, 원칙과 실증에 의거해서 어려운 문제들을 해결하는 것입니다.

    After studying a selection of medieval kings, eighteenth-century scientists, and other historical eccentrics at university, Benjamin Hawkes-Lewis somehow ended up working as a Web Developer at Yahoo!, much to his ongoing delight. His favourite things include a decent meal shared with friends, a good film in the cinema, lazing on the grass in the sunshine, and solving difficult problems by reference to primary sources, first principles, and empirical evidence.

  1. 역주:원문에서는 초안으로 표기되어 있습니다. 현재(2008.12.11)는 권고안으로 승격되어 번역문에서는 WCAG 2.0으로 표기합니다.
  2. 역주:원문에서는 초안으로 표기되어 있습니다. 현재(2008.12.11)는 권고안으로 승격되어 번역문에서는 WCAG 2.0으로 표기합니다.
  3. 역주: 원문에서는 2008.11.03 버전을 따라 5:1로 표기되어 있습니다. 번역문에서는 최종 권고안의 값으로 변경했습니다.
  4. 역주: 원문에서는 2008.11.03 버전을 따라 5:1로 표기되어 있습니다. 번역문에서는 최종 권고안의 값으로 변경했습니다.
  5. 역주:원문에서는 초안으로 표기되어 있습니다. 현재(2008.12.11)는 권고안으로 승격되어 번역문에서는 WCAG 2.0으로 표기합니다.
  6. 역주:원문에서는 초안으로 표기되어 있습니다. 현재(2008.12.11)는 권고안으로 승격되어 번역문에서는 WCAG 2.0으로 표기합니다.
  7. 역주:Image Replacement – 텍스트를 화면 표시 영역으로 밀어내는 것을 말합니다.
  8. 이 내용에 관해서 좀 더 쉽고 자세하게 씌어진 글이 있습니다. 한글로 번역되어 있으므로 관심있으신 분은 읽어보시길 권합니다.
이 글을 다 읽어주셨다면, 댓글을 남겨주세요. 좋았다라는 격려도 좋고, 잘못된 부분을 지적해 주시는 것도 좋습니다. 마음에 드셨다면 아래 Like 버튼을 눌러서 페이스북과 트위터로 소개해 주시면 더욱 좋겠습니다.
  • Koo

    구조 검사의 MS툴은 연결이 안되네요..그냥 메인페이지로 넘어가 버립니다.