25. 웹 접근성 기초

이 강좌는 Dev.Opera의 ' 25: Accessibility basics'을 번역한 문서입니다. 번역과 관련된 안내는 여기에서 확인해 주세요.

• 역자들 : 아쿠아테라

사람들이 웹사이트를 만들 때에 접근성 (접근성은 사용하는 이가 장애인이든 아니든 모든 이에게 해당 웹을 사용하기 쉽도록 도와주는 것이다.)을 가장 중요하게 고려하게 된다. 비록 알아 채지 못했더라도 지금까지 보았던 모든 사례들은 접근성에 관한 내용을 담고 있으며, 이번 장에서는 접근성이라는 주제를 더욱 표면적으로 보면서 그것이 무엇인지 왜 중요한지 어떻게 확실하게 접근성을 높일 수 있는지에 관하여 이야기 하고자 한다.

• 접근성이란 무엇인가?
• 왜 접근성은 중요하게 고려되어야 하는가?
  • 접근성에 관한 법적 의무
  • 접근성에 관한 잠재적 시장
  • 검색엔진
  • 윤리적인 측면과 브랜드화
• 접근성을 고려한 디자인
• 정보처리 상호운용에 관련된 요구사항
• 접근성이 좋은 웹페이지의 특징
  • 시맨틱 구조
  • 대체 콘텐츠
  • 상호작용 정의
  • 접근성을 위한 표준
  • 웹 콘텐트 가이드라인 1.0
  • 웹 콘텐트 가이드라인 2.0
  • Section 508
  • 다른 기준들
• 결론
• 연습문제

웹 상의 접근성을 구체적으로 살펴 보기 전에 접근성이라는 단어에 대하여 일반적인 관점에서 즉 웹사이트라는 틀에서 벗어난 관점에서 생각해 보고자 한다. 접근성은 사실 대부분의 서비스 객체 혹은 기술적인 측면에서 고려되고 있으며 당신의 삶의 전반에서 쉽게 찾을 수 있다. 이에 관련하여 WAI ARIA는 한 번쯤 살펴볼만하다. 웹 접근성의 시작은 고급(Rich) 인터넷 어플리케이션의 시작으로 다가가기 쉬우며 이는 기본적으로 접근성이 있는 Ajax와 자바스크립트와 같은 강력한 어플리케이션이 나타날 수 있도록 하게 한 방법론이다. dev.opera.com 에서 ARIA에 관한 매우 좋은 글을 읽어 볼 수 있다.

주위를 둘러보면 사람들을 쉽게 볼 수 있다. 주변에 사람이 없다고 할지라도 조금만 더 걸어나가 본다면 어떨까? 당신은 아마 그 상황을 즐길 것이며 그 상황은 당신에게 흥미로울 것이다. 길에서 당신이 볼 수 있는 수많은 사람들 가운데 똑 같은 사람은 아마 한 명도 없을 것이며 그 가운데 몇 몇 사람들은 머리 색이 갈색일 것이다. 몇 몇은 파란 눈동자를 가지고 있을 것이며 그렇지 않은 사람들도 있을 것이다. 몇 몇은 안경을 쓰는 사람들도 있을 것이며 그렇지 않은 사람들도 있을 것이다. 이렇듯 정확히 동일한 사람이란 있을 수 없는 것이다. 머리카락의 색이나 눈동자의 색상은 표면적인 것이며 이러한 차이점들이 삶을 살아 가는데 있어서 의미 있는 영향을 미치지는 않는다. 하지만 안경을 착용하는지의 여부의 경우에는 우리의 삶에 의미 있는 영향을 미치기도 한다. 접근성이란 이렇듯 간단한 것이다. 이는 비록 몇 몇 국가에서는 단지 철학적인 측면에 머무르고 있을지 모르지만 다른 어떤 국가들에서는 법의 일부이기도 하다.

접근성은 그들의 장애 여부를 떠나서 모두를 동등하게 대한다라는 의미이다.

나는 이러한 문장을 접근성을 설명하기 위한 서두로 내 놓는다. 대부분의 접근성에 관한 토론들을 살펴보면 대부분이 장애에 대한 이야기로 시작된다. 이는 장애가 있는 사람들은 특별한 대우를 받아야 한다라는 말을 함축한다. 이는 실제 접근성의 의미와는 좀 동떨어진 의미이며 접근성이란 사실 사람들이 전통적으로 건물을 짓거나 웹사이트를 만드는 등 꽤나 많은 세상 만사에서 사람들이 겪을 수 있는 일들과 같은 것이다.

사람들은 건물 건축하면서 건축업자는 세상의 모든 사람들이 자신과 동일하다고 생각하며 이런 문제로 인하여 자신과 다른 수많은 사람들은 자연스럽게 틀린 사람으로 생각하기 쉽다. 이처럼 사회전반적으로 새롭게 나타나는 접근성의 의미가 명확하기 때문에 사람들은 접근성이란 장애가 있는 사람들을 도와주는 것이라고 생각한다. 예를 들어서 이제 막 들어오기 생겨나기 시작한 건물의 경우 싸구려에 못생긴 램프를 설치하기 시작했다. 하지만 접근성이란 오랜 시간 내려온 군대식 디자인과 같은 것이다. 왜냐하면 이는 생존과 너무나도 밀접한 관련이 있기 때문이다. 왜냐하면 비행기 파일럿의 경우도 그가 땅에서는 쉽게 할 수 있었던 행동들을 높은 공중(g-force)에 있는 환경에서는 할 수 없어서 종종 위험에 처할 수 있기 때문이다. 이러한 점들을 비행기 디자이너가 간과하게 된다면 지상과 하늘의 중력 차이로 인하여 많은 더욱 많은 비행기 사고가 나게 될 것이다.

그렇다면 이러한 것들이 웹사이트 개발자들에게 어떤 의미를 줄 수 있을까? 한 마디로 이야기 하자면 만들고자 하는 웹사이트를 보게 될 모든 사람들의 요구사항에 대해서 더 많이 알아보아야 한다는 것이다. 더 길게 이야기 하자면 각각 다른 장애의 정도를 가지고 있는 사람들에 대하여 좀더 알려고 노력을 해야 하며 그들이 어떻게 컴퓨터를 사용하는 가에 대하여 알아야 할 것이다. 이 커리큘럼 및 접근성에 관련된 다른 기사들에서 나오는 기술들을 적용하여 당신은 많은 상호작용의 형태를 고려한 사이트를 만들 수 있을 것이다. 또한 그렇게 만들어진 웹사이트는 다음과 같은 사람들에게 매우 유용하게 쓰일 수 있을 것이다.

• 시각능력이 없거나 이외의 시각적인 장애를 가지고 있는 사람 그리고 스크린 리더를 이용하여 웹사이트를 듣는 사람 또는 점자 디스플레이를 이용하는 사람
• 근시가 있으며 글자 크기를 2배 이상 키워서 보는 사람
• 근육 질환이 있어서 마우스를 조작하는데 어려움이 있거나 그로 인해 포인팅 스틱을 이용하여 키보드를 조작하거나 웹사이트를 보기 위하여 아이 포인터(Eye Pointer)를 이용하는 사람
• 트랙볼을 이용하거나 이외에도 다른 일반적이지 않은 형태를 이용하여 컴퓨터를 사용하는 사람

이런 상호작용에 관한 세부사항에 대하여 걱정하지 않아도 된다. 이제부터 차근차근 알아볼 것이다.

접근성은 대표적인 하나의 이유와 많은 작은 이유들로 인해서 매우 중요하게 여겨진다. 대표적인 이유는 사람들이 모두 같은 사람들이 하나도 없다는 것이며 모든 사람들이 웹사이트를 사용할 수 있는 동일한 권리를 가지고 있다는 것이며 웹사이트를 구축함에 있어서 접근성을 고려해야 하는 수많은 다른 이유들도 존재한다.

• 몇몇 국가에서는 법적으로 명시되어있다.
• 사이트를 방문할 수 있는 잠재적인 고객들을 외면하지 않기 위하여 접근성을 고려하여야 한다.
• 접근성이 좋은 사이트의 경우 검색 엔진에서 높은 순위로 검색된다.
• 고객들이 가치 있게 생각하는 윤리에 관한 측면에서도 매우 좋다.
• 웹 표준을 준수하게 되면 접근성을 높이기 위해서 별다른 큰 노력을 들이지 않아도 되며, 이러한 점이 크게 이롭게 다가올 것이며, 표준을 준수하게 됨으로 인해서 단순히 데스크톱 환경뿐만 아니라 모바일 환경에서도 쉽게 적용이 가능할 것이다. 실제로 접근성을 고려하지 않은 환경의 경우에는 여러 가지 다른 이유에도 불구하고 웹사이트를 사용하는데 어려움이 생길 수 있다. 실제로 웹 접근성과 모바일 웹 사이트 구축에 관한 좋은 사례에 관한 분석 등이 이루어 지고 있으며 WAI ” Web Content Accessibility and Mobile Web“와 같은 곳을 통하여 이에 관한 더 많은 정보를 얻을 수 있다.
• 장애가 있는 사람들에게 도움이 되는 기술이 모든 사용자를 이롭게 한다.

좀더 자세한 부분들을 살펴보도록 하자.

당신이 변호사가 아님에도 불구하고 법적인 내용들의 기초를 이해해는 것은 매우 중요하며, 법적인 내용에 관하여 대화를 나누는 것에 대해서 알아야 하며 이런 이슈에 대하여 의견을 특별한 주의를 기울여야 한다.

영국에서는 DDA(장애인 차별법)에 따라, 사람들을 고용하고 서비스를 제공하거나 교육을 받는데 있어서 장애인을 차별하지 못하도록 되어있다. 차별이란 장애 여부에 관계 없이 모든 대상에게 ‘적절한 조치’를 취하지 않는 것으로 정의 된다. 이와 같은 법률은 물론 웹사이트를 통해 제공되는 교육이나 서비스에서도 적용된다.

미국이나 유럽연합에서도 정부에 관련된 웹사이트를 위한 요구사항들이 존재한다. 미국의 경우 연방 정부 (혹은 몇몇의 주정부)의 웹사이트들이 Section 508에 따라 만들어 져야 한다. Section 508은 접근성을 위한 최소한의 요구사항이 무엇인지를 정의 하고 있는 문서이다. Section 508은 단지 웹사이트에 관한 내용만을 포함하고 있는 것이 아니라 정부에 의해 연방 노동자들이 사용하는 다른 기술적인 측면에도 적용되는 내용이 포함된다. 유럽에서는 the European Commission W3C의 WAI에 대해서 인식하고 있으며 유럽 연합의 국가들에게 이를 사용할 것을 추천하고 있다.

WAI는 웹사이트와 웹 브라우저에 관한 가이드라인을 만든다. (예를 들어 WCAG와 같은 경우를 이야기 하며 추후에 다시 살펴 보도록 하자.)

당신이 오직 특정한 하나의 대상을 목표로 하는 웹사이트를 만들고 있을 때, 만약에 당신이 미처 알지 못한다고 하더라도 대부분의 다른 대상들을 고려의 대상에서 제외되며 이처럼 제외된 대상들은 주류는 될 수 없다고 하더라도 분명 의미 있는 시장이 될 가능성이 있는 존재이다.

2000년 영국의 슈퍼마켓 체인인 Tesco는 시각적인 장애인들을 목표로 하는 특별한 식품 판매 온라인 사이트를 몇몇 가지 버전으로 만드는 프로젝트를 시작하였다. RNIB의 Julie Howell는 “시각장애인의home grocery service의 접근성을 높이기 위해 Tesco.com에서 수행한 업무의 경우 연간 £13m이라는 장애인이 접근할 수 없었던 시절에는 회사가 가질 수 없었던 이익을 제공하였다. 그러므로 테스코가 만일 이러한 시각 장애인들을 고려하지 않았더라면 이런 장애인을 대상으로 한 £13 million이라는 시장은 드러나지 않았을 것이다. 여기에서 알 수 있는 가장 큰 내용은 장애 여부와 관계없이 영화, 음악, 술집과 같은 일상에서 즐길 수 있는 것과 전기, 택시, 식료품가게와 같은 서비스는 동일하게 필요하다라는 것이다.

어떤 사람의 삶에 있어서 처해있는 그들의 상황이 장애상태 혹은 사회의 모든 면에 있어서 참여하고자 하는 욕구를 바꾼다고 가정하면 이는 몇 번이고 실수로 판명 날 것이다.

검색 엔진은 사람이 아니다. 종종 사람들은 웹사이트를 만들면서 그들이 만든 웹사이트 들이 구글이나 야후와 같은 검색 사이트에서 어떻게 찾아질 것인가에 대하여 고려하지 않는 경우가 있다. 검색엔진은 단지 컴퓨터 프로그램으로써 웹사이트 상에 있는 인덱스를 통하여 해당 웹사이트를 이해한다. 이러한 점 때문에 검색엔진이 더욱 시각 장애가 있는 사람들이 사용하는 스크린 리더와 비슷하게 여겨질 수 있다.

웹사이트 디자인에 영향을 미치는가에 대한 가장 좋은 예는 이미지이다. 컴퓨터는 모니터에 정보를 뿌리는 과정에서 각 줄, 각 픽셀마다 어떠한 색상을 뿌리는가를 결정함에 따라 이미지가 완성된다. 만약 예를 들어 로고와 같이 텍스트를 포함하고 있는 웹 페이지 상에서 이미지를 올리려고 하는 경우에 컴퓨터는 해당 텍스트가 의미하고 있는 바가 무엇인지 전혀 모를뿐더러 해당 이미지가 텍스트를 포함하고 있는지 조차 알 수가 없다.

HTML상에서 이미지 요소는 이미지 또는 알트 속성의 내용을 담은 텍스트를 묘사하기 위한 방법을 포함한다. 당신은 웹사이트 상에서 단순히 장식을 위해 넣은 이미지를 제외한 모든 이미지에 텍스트를 제공해야 하며, 이미지로서의 텍스트의 전체 문단을 나타내지 말아야 한다.-시력을 잃은 고객이나 검색엔진은 해당 텍스트가 무엇을 말하는지 알 수 없을 것이다. 결과적으로 검색 엔진 랭킹은 대가를 치르고 당신은 가치 있는 시장을 놓치게 될 것이다. (구글과 같은 검색엔진을 이용해서 당신의 웹사이트를 쉽게 찾을 수 있을 것이다.)

모두가 접근성을 지원해야 한다는 것은 모두가 접근성을 지원하고 있다는 의미와 동일하지는 않다. 접근성을 지원함으로 인해서 커뮤니티의 가장 큰 이익을 만들어낼 수 있다. 접근성을 고려함은 집단 내에 있는 모든 이의 상황을 고려한다라는 것을 보여줌으로 인해 자부심을 가질 수 있으며 브랜드 이미지를 높일 수 있다.

전문가로서 산출물이 최고의 품질을 가질 수 있도록 함과 이를 위해 도전하는 것이 바로 우리의 임무이다. 단지 요구사항이 다르다는 이유만으로 그들을 외면하는 것은 잘못된 일이며 조직내의 개개인이 모두 가치 있음을 알아야 한다. 정책에 있어서 책임감 있는 선택을 하고 성실하게 이러한 정책을 수행하게 된다면 당신은 매우 좋은 브랜드 이미지를 구축할 수 있을 것이다.

회사가 고객에 대해서 신경 쓰는 모습을 보이게 되면 이는 그렇지 않았을 경우에 비해서 더 높은 충성도로 돌아 오게 되어있다.

접근성에 있어서 가장 핵심적인 사항은 문제에 대해서 생각하는 것과 이러한 문제점을 한 가지 종류의 사용자를 위해서 해결하는 것이 아니라 더 많은 사용자를 위한 해답을 찾는 것이 중요하다. 만약 당신이 접근성을 마지막 부분에 덧붙이는 것에 불과한 존재로 여긴다면 그야말로 쓸모 없는 존재가 될 것이다. 이는 시간도 더 오래 걸릴뿐더러 제대로 구현되지도 않을 것이며 보기에도 좋아 보이지 않을 것이다.

가장 좋은 방법은 처음 웹사이트를 구상하는 단계부터 접근성에 관련된 모든 요소를 머리 속에 고려하여 디자인하며 해법을 얻는 것이다.

이는 당신이 가지고 있던 계획을 전반적으로 변경하거나 놓쳤던 점을 추가하는 것을 의미하는 것이 아니라 당신이 디자인 하는 과정에 있어서 문제점이 무엇인지 알기 위해서 노력하는 것이다 웹사이트의 사례에서 이는 모니터, 키보드, 마우스를 사용하지 못하는 고객들을 포함한 당신의 모든 고객이 사용 가능한 대안을 만들어 내는 것을 의미한다.

정보처리 상호운용에 관한 요구사항은 상황상황에 따라서 다르게 나누어진다. 종종 새로운 기술이 접근성을 위한 지원이 없는 상태에서 공개되기도 한다. 예를 들어서 마이크로 소프트의 새로운 실버라이트 플러그인은 향후에 접근성에 관련된 기능들을 지원할 예정에 있음에도 불구하고 스크린 리더에 의해 사용되는 접근성 APIs의 정보를 공개하지 않으며 다른 보조 공학들도 공개하지 않고 있다.

이처럼 접근성을 위한 지원들이 이론적으로 공개될 때, 보조공학을 적용하기 위한 시간이 추가적으로 소요될 수 있다. 예를 들어 최신의 스크린 리더는 HTML 오래된 스크린 리더에 비해서JavaScript의해서 생겨나는 업데이트를 더욱 잘 수행한다.

비록 오랜 시간에 걸쳐 생겨난 경우라고 할 지라도 접근성에 관련된 지원은 플랫폼을 따라서 다르게 적용된다. 예를 들어 어도비 플래시 플레이어 플러그인의 경우 윈도우 접근성API에 오랫동안 노출되어있었으나, 애플이나 GNOME환경에서는 그렇지 못했다.

또한 기술적인 지원의 선행되어 우선적으로 지원할 것인가 아니면 더 많은 플랫폼에 지원하게 할 것인가에 사이에서 고민도 있기 마련이다. 반면에 최근 브라우저와 플러그 인은 무료화 되고 있으나 메인스트림에서 지원하는 보조 공학의 경우 무척 비싸다.

예를 들어 윈도우에서 지원하는 가장 유명한 스크린 리더는 Freedom Scientific사의 JAWS이다. JAWS Professional 의 소비자 판매 가격은 $1,095이며, 다음 두 버전의 소프트웨어 유지 보수를 위해서만 $200를 써야 하며 업그레이드를 위해서는 $500 이상의 돈을 써야 한다 결과적으로 이런 비싼 비용으로 인해 가장 최근에 출시된 버전이 9일지라도 여전히 예전의 버전을 사용하는 사용자들이 너무나도 많다.

그렇기 때문에 공공의 웹사이트를 개발하기 위해서는 매우 다양한 클라이언트 단의 사용자와 기술 조합에 따른 정보 처리 상호운용에 따른 비용이 필요하다. 다음과 같은 네 가지 접근법이 있다.

• 점진적으로 웹사이트를 강화시키며 이에 따른 지원을 위한 테스트를 진행한다. .
• 문제가 되는 부분을 사용자가 사용하지 않을 수 있도록 한다.
• 동일한 내용 혹은 기능을 가지고 있는 대안이 되는 버전을 제공한다.
• 고객을 대상으로 이를 지원하기 위하여 어떠한 기술이 적합한지 조언하며 이러한 기술을 지원하는 회사의 예를 제공한다.

인트라넷 상에서는 하위호환성과 다양성이 비교적 덜 문제가 된다. 조직은 모든 조직원들이 DHTML을 통한 적절한 보조 공학을 제공한다고 보장할 수 있기 때문이며 예를 들어 이러한 환경에서는 보조공학이 지원되는 적절한 테스트를 위한 기준으로서 자바스크립트를 다루게 될 것이다.

하위 호환성과 플랫폼 호환성은 여전히 이슈가 되지만 그렇기에 표준 기술은 비 표준 기술에 비해서 독점적으로 선호되어야 한다.

예를 들어 당신이 대기업용 intranet training application 을 개발한다고 하면 대기업은 해당 어플리케이션이 접근성이 있어야 한다고 이야기 할 것이지만 구체적으로 어떠한 측면을 표준과 맞추어야 하는지는 이야기 하지 않을 것이다. 당신은 해당 기업의 IT부서에 이야기 하고 모두가 자바스크립트를 지원하는 익스플로러의 최근 버전을 가지고 있고 사용가능한지를 확인하며 플래시가 깔려 있고 사용한지를 확인하고 이러한 최신의 보조공학을 지원하는지를 확인해야 한다. 지금 만약 회사가 유닉스 기반의 플랫폼으로 플랫폼을 변경한다고 하여도, 자바스크립트를 지원하는 보조공학은 있지만 플래시 텍스트나 컨트롤은 오직 윈도우상에서만 접근이 가능할 것이다.

당신은 어플리케이션을 위한 기본적인 요소로 플래시와 스크립팅을 안전하게 만들 수 있을 것이다. 플래시 컨트롤은 윈도우 플랫폼에서만 보조공학으로 접근이 가능하기 때문에 플래시를 비디오를 틀기 위해서만 사용하고 웹 표준으로부터 플래시 비디오를 위한 컨트롤 셋을 개발할 것인지 결정해야 한다. 이렇게 되면 만일 회사가 유닉스로 시스템을 바꾸게 되는 경우가 있더라도 어플리케이션은 여전히 접근 가능하게 된다.

조직적인 IT정책은 변하게 되어 있으며, 자바스크립트 기능을 사용할 수 있도록 하는 최고의 시도와 플러그인의 접근성에 관련 기능 세트는 실패할 것이다.

그러므로 진보적으로 향상된 기술적인 기반을 가지고 있다고 하더라도HTML 레이어가 여전히 좋은 방법이라고 할 수 있다.

이번 장에서 웹사이트의 다른 접근측면 즉 접근 가능한 웹사이트는 어떠한 요소를 가져야 하는가에 대해서 알아본다. 각각에 대해서 자세히 설명하도록 한다.

웹 표준의 기초가 되는 것 중의 하나가 HTML상에 있는 시멘틱 구조의 사용이다. 시멘틱 구조는 접근성에 있어서도 매우 중요하다. 시멘틱 구조가 접근성에 있어서 중요한 이유는 바로 시멘틱 구조가 웹 페이지 상에서 정보를 다루는 프레임워크를 제공하기 때문이다. 사용자가 웹 페이지의 시각적인 스타일을 볼 수 없을 때 시멘틱 구조는 시각적 구조를 나타내기 위한 많은 것들을 도와준다. 이는 문서의 수직적 구조상에서 그들의 위치를 나타내며 올바른 위치에 있는 텍스트 내용의 강조를 제공하는 것과 마찬가지로 페이지의 다른 요소들과 상호작용할 수 있는 방법을 나타낸다.

문서의 시멘틱 구조가 어떻게 접근성에 있어서 중요한지에 관한 좋은 예는 네이게이션이다. 잘 만들어진 네이게이션 메뉴는 아이템의 리스트이다. 당신은 HTML을 이용하여 이와 같은 것을 만들 수 있다.

<ul>
  <li>Menu Item 1</li>
  <li>Menu Item 2</li>
  <li>Menu Item 3</li>
</ul>

리스트처럼 구조화된 형태의 네비게이션 메뉴를 가지게 됨으로 인해서 리스트를 볼 수 없거나 그것이 리스트인지 알 수 없는 사람이 스크린리더를 사용하기 쉽게 된다. 이는 스크린 리더가 리스트 상에 있는 것들이 무엇인지 말해 줄 것이기 때문이다. 만일 리스트 마크업을 사용하지 않는다면 스크린 리더는 이것이 리스트인지 사용자에게 이야기를 해 주어야 하는지를 알 수 없을 것이다.

당신은 앞장에서 특히HTML을 다루고 있는 장에서 다루었던 내용들을 통하여 HTML상에서 올바른 시멘틱 을 사용할 수 있는 방법에 관한 정보를 더 많이 찾아 볼 수 있을 것이다.

검색엔진에 관한 부분에서 언급했던 것과 같이 콘텐츠나 네비게이션의 접근성 대안에 대한 확인은 필수적이다. 당신이 아래에서 보게 될 것처럼 텍스트는 하나의 단서와 함께 내용을 나타내기 위한 국제 공통적인 전달방법이다. 텍스트는 스크린 리더에 의해서 큰 소리로 읽혀질 수 있으며, 그 크기를 크게도 작게도 만들 수 있으며 명암대비를 높이는 등 다양한 많은 변형의 형태를 가질 수 있다. 이렇게 텍스트는 쉽게 다루어질 수 있기 때문에 더욱 이국적인 형태를 가진 콘텐츠의 경우 그들을 대신하기 위하여 텍스트 기반의 형태를 가져야 한다. 새로운 버전의 플래시와 같은 몇몇 포맷은 텍스트를 이용하여 접근할 수 있으며, 이로 인하여 다른 번거로운 과정 없이 텍스트로 이루어진 콘텐츠만으로 접근이 가능해 졌다.

텍스트를 이용한 방식으로 도움을 줄 수 없는 장애 그룹은 인지적 장애를 가지고 있는 사람들이다. 인지적 장애를 가지고 있는 사람들을 지원해주는 어려움은 종종 그들이 같은 콘텐츠를 다른 방식을 통해서 전달 받기를 원하기 보다는 다른 콘텐츠를 원하는 경우이다. 그 사람들에게 그 부분을 보려고 하지 말라고 할 수는 없는 것이다. 당신의 웹사이트에서 사용되는 언어와 용어를 간단하게 만드는 것은 모두에게 큰 도움이 될 것이다. Plain Language Commission과 같은 그룹은 법적인 요구사항이나 용어 및 상태와 같은 중요한 정보를 사용자에게 알려주기 위해 회사가 “plain speech”와 같은 방법을 사용하는 것을 장려한다. 그들은 가능한 간결한 형태의 언어를 사용해서 효과적으로 의사 소통할 수 있도록 도와주는 용어를 포함한 plain english lexicon 을 제공한다.

그러나 당신의 사이트에서 텍스트의 대체하기 위해서 어떤 일들을 수행해야만 할까? 첫 번째 단계는 아직 텍스트로 되지 않은 것들을 확인한다. HTML안에는 아직 텍스트로 되지 않은 많은 것들이 있다. 이미지들은 대부분 알아보기 쉬운 것들이다. 여기에 이미지를 사용해서 접근성이 좋아진 예가 있다.

<p>An interesting piece of art is Michelangelo’s “God creates Adam”
<img src="images/adam.jpg" alt="A painting of a man reaching up to touch God’s hand
reaching down. It is cracked with age." longdesc="adam.html">.</p>

위의 이미지는 콘텐츠의 완벽한 형태의 예이다. 알트 속성은 이미지를 정확하게 볼 수 없는 사람들 혹은 검색 엔진을 위한 이미지에 관한 짧은 설명을 포함한다. Longdesc 속성은 이미지의 전체 설명을 포함하는 HTML페이지의 링크를 허용하는 속성이다. 이는 일반적으로 중심적인 내용으로 사용되는 복잡한 이미지를 나타내기 위해 사용된다. 이러한 속성 또한 브라우저 상에서 제대로 지원되지 않는다. 대부분의 경우 당신은 알트 속성만의 사용이 가능할 것이다.

이미지가 내용을 나타내기 위해 사용되는 것이 아니라. 네비게이션이나 순수하게 시각적인 데코레이션과 같은 것으로 사용되는 경우 당신은 이러한 이미지들을 내용을 나타내기 위한 이미지와는 다르게 다루어야 한다. 버튼이나 페이지 네비게이션을 나타내기 위한 이미지들은 해당 이미지 내에 매칭되는 텍스트를 보여주는 알트 속성과 같은 요소들을 가지게 됨으로써 더욱 매력적으로 노출되어야 한다. 알트 속성은 이미지 내에 포함되어있는 텍스트를 읽을 수 있게 함으로서 더욱더 쉽게 기능을 단순화 시킬 수 있다. (그리고 스크린 리더의 사용자들도 읽을 수 있다.)

완전히 데코레이션을 위해 사용되는 이미지들의 경우 이미지가 트래킹을 위한 용도로 사용되어야 하며 이외에 사용자가 별 기대하지 않거나 관심이 없는 이미지인 경우에는 알트 값을 넣지 말아야 한다. 이는 객체를 생략하는 것을 의미하는 것이 아니라 alt=””를 넣는 것을 의미한다. 이는 촉각을 이용한 스크린 리더를 통해 접근 불가능한 페이지를 접근하는 사용자를 돕기 위해 사용되기 때문이다.

이미지가 알트 속성을 가지고 있지 않을 때, 특히 링크의 일부라면 스크린 리더는 이미지의 URL을 사용자에게 읽어줄 것이다. 이를 통해 사용자는 add_to_cart.gif 라고 명명된 이미지의 예와 같이 해당URL에 어떤 이미지가 있는지 추측할 수 있을 것이다. 또한 당신은 사용자가 관심을 가지지 않을 것이라고 생각되는 이미지에 alt=””를 놓아 스크린리더가 스크린리더 사용자에게 혼란을 줄 우려가 있는 모든 URL의 이미지를 읽어오는 일을 방지한다.

하지만 모든 콘텐츠의 형태가 이미지와 같이 단순하지는 않다. 플래시와 같은 경우 더욱 복잡하며 영상의 경우 더욱 복잡한 서술이 필요하다. 가장 최근 버전의 플래시는 (플래시 파일은 그 자체만으로 웹사이트 전체가 될 수 있다.) HTML과 같이 플래시 무비 내에서 사용자가 아이템으로서 텍스트 대체를 제공할 수 있도록 허용할 수 있다.

최근에 생겨나는 웹사이트의 경우에는 HTML뿐만 아니라 다른 많은 기술들이 적용된다. CSS같은 기본적인 기술들조차 페이지를 만드는 방법 중에 하나이며, 그렇지 않은 경우에는 상호작용에 있어서 접근성이 떨어진다 상호작용에 있어서 접근성을 높이는 핵심은 상호작용을 단순화 시키며 이런 단순화된 상호작용을 이용하여 마치 빌딩을 짓기 위한 벽돌과 같은 역할로써 이를 쌓아가 더 복잡한 상호작용을 만들어 내는 것이다.

이런 점들을 염두 하면 각 웹 페이지마다 다르게 가지고 있는 역할들에 대해서 생각해 보게 될 것이다. 해당 웹사이트들의 접근성에 대해서 확신을 가지기 위해서 HTML요소와 시각적 메타포를 사용하는 식으로 의미 있게 확인되어야 한다.만일 이러한 혼란을 느낀다면 사례를 몇 차례 다시 읽어보고 또한 몇 개의 메뉴와 웹 페이지 컴포넌트를 살펴보고 올바른 HTML이 사용되었을 경우만 생각하지 말고 컴포넌트의 느낌과 어울림이 그 자체의 기능과 조화를 이루는지에 대해서도 생각해 보아야 한다. 당신은 “뉴스레터를 받아 보기 위한 귀하의 이메일 주소를 입력하십시오.”라는 글씨가 적혀 있는 텍스트 박스를 사용해서 웹 페이지를 방문한 사람이 검색을 수행할 것이라고 생각하지 않을 것이며 만일 이와 같이 시력을 잃은 사용자가 만일 모든 제목들이 일반적인 텍스트와 동일한 스타일이라면 시각 장애가 없는 일반인의 경우도 흥미로운 내용을 찾아낼 것이라고 기대하기 힘들다. (이처럼 시각장애가 있는 사용자가 CSS를 이용하거나 폰트를 이용하여 크게 만들어진 도표만으로 모든 “제목”들이 기술되어있다면 어떠한 내용이 흥미로운 내용인지 알 수 없을 것이다.)

이에 대한 좋은 예는 일반적으로 자주 사용되는 탭의 시각적인 메타포이다. 탭의 메타포는 링 바인더로부터 착안되었다. 이런 링 바인더의 모습은 단일 모니터를 가지고 있는 컴퓨터 환경 안에서 탭을 이용하여 많은 내용 가운데 자신이 원하는 내용을 가장 위로 끌어 올려 주기 위한 방법으로 적용되었다. - dev.opera.com 에서 좋은 사례를 확인할 수 있다. 지금까지는 이런 탭 방식이 매우 단순하며 좋다.

문제는 탭을 만들기 위해서 사용되는 기술에 있으며 이는 종종 자바 스크립트에 의해서 수행된다.탭은 사용자에게 정보를 선택하기 위한 방법으로 허용되지만 더 복잡한 상호작용을 위한 방법으로 사용되며 이런 탭을 나타내기 위하여 종종 동일한 코드가 사용으로 인해서 기존의 메타포는 깨어진다. 아래의 HTML은 정보를 보여주기 위한 탭 컨트롤이 어떻게 생겼는지 보기 위한 사례이다.

<div class="tabcontrol">
  <div class="hd">
    <ul>
      <li><a href="#dogs" class="selected">Dogs</a></li>
      <li><a href="#cats">Cats</a></li>
      <li><a href="#fish">Fish</a></li>
    </ul>
  </div>
  <div class="bd">
    <p id="dogs" class="selected">Some information about dogs. The dogs tab is the default tab.</p>
    <p id="cats">Some information about cats.</p>
    <p id="fish">Some information about fish.</p>
  </div>
</div>

위의 예에서 선택된 클래스는 어떤 탭이 “tab to the front” 그래픽을 보여줄 때 필요한 것인지에 대해서 확실히 하기 위하여 사용되며, 예를 들어서 이런 방법을 사용하는 이 페이지의 상단의 “Articles” 탭을 확인한다. 이와 같은 구조는 국제적인 내용을 위해 좋다.

이 예에서 선택된 클래스는 어떤 탭이 활성화되었는지 알려주기 위해 사용된다. 열려있는 탭이 해당 탭의 정보를 나타내며 다른 탭의 경우 해당 탭에 연결되어있는 링크가 클릭 될 때까지 닫혀 있다. (닫혀있는 탭의 도표는 숨겨진다.) 도표 1과 같이 강아지의 탭은 기본 활성화된 탭으로 되어있다. 탭 컨트롤은 기본 컨트롤 탭으로 활성화 되어있음을 보여준다.

한번 다른 링크가 클릭되게 되면(그림 2) 자바스크립트는 재빠르게 class=“selected” 로 이동하게 되며 포인트 스타일이 해당 내용을 나타내기 위한 탭에 적용되며 지금까지 나와있었던 내용은 숨겨지게 된다 새로운 탭을 보여주기 위한 탭 컨트롤이 클릭된다.

곧 나오게 될 자바스크립트에 관한 부분에서 실제로 작동하는 이와 같은 컨트롤의 사례에 대해서 다시 볼 수 있을 것이다.

또한 각자 다른 종규의 검색을 고르기 위해 사용자가 탭을 사용하는 경우도 일반적이다. 이런 경우 기존의 사례에서 나왔던 코드의 스타일을 다시 사용하려고 한다면 컨셉은 쪼개는 것으로부터 시작된다.

<div class="tabcontrol">
  <div class="hd">
    <ul>
      <li><a href="#dogs" class="selected">Dogs</a></li>
      <li><a href="#cats">Cats</a></li>
      <li><a href="#fish">Fish</a></li>
    </ul>
  </div>
  <div class="bd">
    <form id="dogs" class="selected" action="search.html" method="GET"><div><label for="dogsearch"><input type="text" name="dogsearch" id="dogsearch"><input type="submit" value="Search for Dogs"></div></form>
    <form id="cats" action="search.html" method="GET"><div><label for="catsearch"><input type="text" name="catsearch" id="catsearch"><input type="submit" value="Search for cats"></div></form>
    <form id="fish" action="search.html" method="GET"><div><label for="fishsearch"><input type="text" name="fishsearch" id="fishsearch"><input type="submit" value="Search for fish"></div></form>
  </div>
</div>

동일한 코드 구조를 가져오는 것은 더 이상 의미가 없다.— 이와 같은 경우에는 콘텐트를 대체하는 컨셉에 맞추기 위하여 동일한 형태의 요소를 반복적으로 넣는 것은 마크 업 낭비이다. 시각적으로 생각하는 것 대신 이 경우에는 상호작용 그 자체에 대해서 생각하는 것이 중요하다. 이 예의 경우 탭을 나타내기 위해 새로운 정보를 선택하는 것보다 검색 창에서 사용자가 하게 될 상호작용을 바꾸어 볼 필요가 있다.

사실상 탭이 수행해야 하는 단 하나의 일은 사용자가 찾는 동물의 종류를 선택하는 것이다. 만약 이러한 것을 당신이 연습을 하면서 넣게 된다면 당신은 마크 업을 깔끔하고 더 쉽게 유지하며 사이트상의 모든 고객들과 더욱 효과적인 상호작용을 할 수 있을 것이다.

<form action="search.html" method="GET">
  <fieldset>
    <legend>Search within:</legend>
      <ul>
        <li><label for="dogs">Dogs</label><input id="dogs" type="radio" name="animal" value="dog" checked></li>
        <li><label for="cats">Cats</label><input id="cats" type="radio" name="animal" value="cat"></li>
        <li><label for="fish">Fish</label><input id="fish" type="radio" name="animal" value="fish"></li>
      </ul>
    </fieldset>
  <input type="text" id="searchfield" name="search">
  <input type="submit" value="Search">
</form>

처음 상호작용을 만들게 되면 마크 업이 더욱 깔끔해지며 사이트의 모든 사용자가 최적의 환경에서 사용할 수 있게 된다. 우리가 시각적인 메타포를 확장하였을 때 우리는 상호작용을 쉽게 버린 채로 이전의 사례의 가정만을 기반으로 한 끔찍한 마크 업을 만들었다. 콘텐트를 추가하기 위하여 새롭게 페이지를 만드는 것을 대체하기 위해 에이젝스를 사용한다면 이처럼 오히려 더 좋지 않은 결과를 낳았다. 자바스크립트가 없을 때 고양이나 물고기와 같은 검색 어를 검색하기 위한 검색 양식을 얻기 위해 페이지 전체를 다시 읽어와야 했다 처음 상호작용에 관하여 생각함에 따라 아마 문제는 단순화 될 수 있을 것이다. 지금 우리는 검색을 위하여 하나의 동일한 형태를 할 때 만이 탭 메타포는 유지가 가능하다. 이는 접근성에 대한 상호작용을 어떻게 할 것인가를 이해하기 위한 핵심적인 내용이다.

HTML이 가장 좋은 점 가운데 하나는 HTML상에서 어떻게 상호작용에 관련된 부분을 만들 것인가 하는 것이며 이 어려운 부분에 대해서 이미 많은 부분이 완료되었다는 것이다. 그러므로 메타포를 무너뜨리기 위해 HTML의 매우 높은 단계에 있는 어려운 기술을 사용하지 않을수록 당신은 노력을 덜 들이고 많은 사람들을 위할 수 있는 작업들을 수행할 수 있을 것이다.

이번 장에서는 웹 접근성을 정의 하고 있는 몇몇 표준과 가이드라인을 살펴보도록 하겠다 대부분의 이런 표준과 가이드라인들은 체크리스트와 유사한 시스템들 포함하여 이를 이용해서 개발자들은 자신의 사이트와 표준 혹은 가이드라인이 다른 점이 무엇인지 확인해 볼 수 있다.

W3C는 인터넷 상에서 가장 근본적인 표준으로 꼽힌다. W3C의 WAI 는 1999년 웹 사이트를 접근성 있도록 하기 위하여 만들게 된 첫 번째 버전이다. WCAG 는 지금도 웹 상에서 접근성에 관련되어 사용되는 가장 보편적인 가이드라인이다. WCAG 1.0의 사용하는 것은 EU와 이탈리아를 포함해서 몇몇 정부 기관에서 의무적으로 사용해야 함을 제안하고 있다.

WCAG 1.0는 접근성있는 페이지를 얻어내기 위한 목표를 요약하기 위한 14개의 가이드라인 세트이다. 각각의 가이드라인에는 문서에서 실제로 의미하는 바를 나타내는 체크포인트들로 이루어져 있다.

가이드라인이 해당 표준의 컨셉에 대해서 설명한다면 체크포인트는 이런 것들이 일치함을 입증하기 위하여 사용된다. 각각의 체크포인트는 1에서 3점으로 매겨지며 각각의 체크포인트들이 얼마만큼 중요한가를 나타낸다. WCAG 1.0을 확인하기 위해서 모든 체크포인트에 점수를 체크해야 한다 모든 체크포인트가 1점을 받으면 ‘A’등급을 받으며, 모두가 2점을 받으면 ’AA’등급을 받으며, 모든 체크포인트가 1,2,3을 모두 받으면 최고 점수인 ‘AAA’등급을 받게 된다.

사실 WCAG 1.0는 좀 오래된 표준이다. 많은 회사들이 A등급 혹은 AA등급으로 시작하며 이후 RNIB’s 와 같은 또 다른 가이드라인을 살펴본다. WCAG 1.0은 시작으로는 좋지만 결국 다른 새로운 표준을 찾아야 하며 특히 WCAG 1.0 가 출시된 1999년 이후 출시된 자바스크립트 등의 다양한 언어를 사용하는 경우에는 다른 표준을 찾아 보아야 한다.

WCAG 1.0 표준에 대해 기술된 다른 중요한 점은 이 표준이 3개의 문서의 부분으로 디자인되어있다는 것이다. 다른 하나는 “User Agents”라는 이름으로 나와 있으며, 오페라와 같은 웹 브라우저에 대한 내용을 담고 있고 사용자가 웹을 사용하며 필요한 여타의 특별한 기술(스크린 리더와 같은)에 관해서도 기술하고 있다. 세 번째 부분은 드림위버나 콘텐트 관리 시스템과 같은 툴에 대한 내용을 담고 있다.—이는 접근성 있는 페이지를 만들기 위한 작업을 할 수 있도록 도와주는 것이 목적이다. 불행하게도 이런 비전은 널리 퍼지지 않았으며 셋 가운데 널리 퍼지게 된 것은 WCAG 1.0뿐이다.

이것은 WCAG 1.0의 기대는 종종 사용자의 기대에 미치지 못하며 툴을 사용하여 웹사이트 접근성을 만드는데 있어서 작은 짐을 줄 것이다.

이는 당신이 WCAG 1.0을 사용해서는 안 된다는 것을 의미하지는 않는다.; 간단히 이야기해서 이는 단지 접근성의 일부분에 관한 것이므로 절대 완전한 해답이 아니라는 것이다.

WCAG 1.0가 나온 이후 W3C는 WCAG 2.0 위에서 진행되어 왔다. 이 표준의 업데이트 버전은 여전히 기술되고 있다. W3C의 프로세스 진행 상황을 미루어 보았을 때 WCAG 2.0은 2009년 초에 출간 될 것으로 예상된다.

WCAG 2.0이 다른 점은 WCAG 1.0보다 좀 더 기술불가지론적이라는 것이며 그렇기 때문에 HTML, CSS, Flash, 등등에 적용이 가능하다.

WCAG 2.0 은 다음과 같은 4가지 원칙을 기반으로 한 접근성을 지원한다.

Perceivable

사람들은 그들에게 허용된 매체를 통하여 내용을 인식한다. 예를 들어 사람들이 볼 수 없는 경우에는 해당 콘텐트를 들어서 인식해야 한다.

Operable

사람들은 웹 어플리케이션 또는 콘텐트 내에서 상호작용한다.

Understandable

콘텐트와 사용자 인터페이스는 사용하는 사람들에게 이해가 가능해야 한다.

Robust

어떠한 솔루션이던 시스템 혹은 플랫폼을 구분하지 않고 널리 적용이 가능해야 한다 이는 사람들이 기능이 제한 되어있거나 터무니 없이 비싼 하드웨어나 소프트웨어 이기 때문에 사용하지 않게 될 솔루션을 개발하는 일을 방지할 수 있다.

웹사이트는 이런 모든 요구사항을 모두 충족시킬 필요가 없다라는 사실을 아는 것은 중요하다. 또한 사용자가 가지고 있는 기술은 수행해야 할 일이 있다. 예를 들어 스크린 리더는 사용자가 필요한 페이지를 읽어야 하는 것이지, 모든 페이지의 내용을 음성 버전으로 제공할 필요는 없다. 하지만 웹사이트는 이를 가능하게 하기 위하여 일반적인 스크린 리더를 사용해서 읽을 수 있는 페이지를 제공하길 기대한다. 이 차이는 “접근성이 있는 위젯”을 사용하는 웹사이트(폰트를 조금 더 크게 만들기 위한 버튼과 같은)와 각각 다른 많은 상황에 따라 작동하게 되는 웹 페이지(예측 불가능할 정도로 다양한 브라우저와 디바이스)의 차이와 같이 이런 차이점은 중요하다.

WCAG 2.0 는 기술에 접근하는 관점에서 WCAG 1.0 과 다르다. 표준은 더욱 더 기술불가지론이며 확실한 기술적인 세부사항보다는 접근성에 관한 컨셉에 더 비중을 높게 생각하기 때문에 표준에 관련된 주변 문서에 주의를 기울이는 것은 중요하다.

WCAG 2.0 의 표준 문서는 이해를 제공하지만 기술 문서는 개발자를 위한 단단하며 수행 가능한 정보를 제공한다. 이는 일반적인 기술(기술적 모호함)과 W3C 기술을 통한 구체적인 기술로 구분된다. W3C는 독점적인 기술을 위해 나오지 않았기 때문에 다른 소스로부터 플래시나 실버라이트와 같은 기술을 위한 기술을 찾아 낼 수 있을 것이다.

Section 508은 1973년도의 American Workforce Rehabilitation Act 의 확장된 형태이다. 1998년 법으로 제정된 Section 508은 미 정부의 지원에 따라서 지켜져야만 하는 프로세스가 되었다.

이는 연방정부의 돈을 사용하는 미국의 모든 정부 산하 기관들이 Section 508의 가이드라인과 프로세스를 지켜야 함을 의미한다. 이 가이드라인은 웹 접근성과 컴퓨터 및 전가 커뮤니케이션에 관련된 접근성에 관한 내용들을 다루고 있다. 위에서 명시되지 않은 조직들의 경우에는 Section 508을 지켜야 하는 법적인 의무는 없다. 그러나 몇몇 주정부와 회의는 자신들만의 프로세스로서 접근성을 정의하기 위하여 Section 508을 사용하고 있다.

웹 접근성에 관한 부분을 나타내는 Section 508의 부분은 Subpart B § 1194.22이다. Clause 1194.22는 a부터 p로 명명된 16개의 요구사항으로 나뉜다. a부터 k에 해당하는 첫 11개의 요구사항은 WCAG 1.0의 부분과 직접적으로 동등하게 언급된다.

이런 요구사항과 WCAG 1.0과 동등한 항목에 관해서는 section 508문서 상에서의 레퍼런스 테이블에 나와있다. Section 508 의 모든 다른 요구사항들은 하나의 기대 앞에서 WCAG 2.0와 만나게 되어야 한다. 요구사항들은 Section 508 Subpart B § 1194.21를 참조한다. 이러한 요구사항들은 WCAG 2.0의 규칙인 Robust와 부분적으로 동등하다.

이 글을 쓰고 있는 중에도 Telecommunications and Electronic and Information Technology Advisory Committee (TEITAC)에 의해서 새로운 버전의 section 508에 관한 조사가 진행 중이다. TEITAC는 2008년4월 Section 508을 위한 평가 위원회에게 조사 결과물을 발표한다.

W3C에 의해 나오게 된 또 다른 중요한 웹 표준은 WAI-ARIA이다. 이 표준은 Web Accessibility Initiative—Accessible Rich Internet Applications. 을 위한 것이다. 이 표준은 어떻게 HTML이나 자바스크립트 혹은 에이젝스와 같은 기술을 이용해서 복잡한 웹 어플리케이션을 만들 수 있을 것인가에 대한 방법을 정의하는 문서이다. 이 표준은 오페라 9.5,익스플로러 8 혹은 파이어폭스 3와 같은 대부분의 최근 버전의 웹 브라우저에서는 공식적으로 지원된다. 이외에도 모두 살펴보기에는 무리가 있을 정도로 많은 웹 표준 관련 표준들이 존재한다.

W3C에서는 웹 표준에 관련된 국제 정책의 리스트를 정리하고 있으며 이는 각 국가 혹은 지방 정부의 정책관련 문서를 찾는데 있어서 큰 도움이 될 것이다.

접근성은 경제적인 측면에서나 사회적인 측면에서나 매우 중요한 주제이다. 이는 웹사이트의 특징은 아니지만 당신이 만든 사이트의 품질을 측정할 수 있는 대상은 된다. 만약에 당신이 당신의 웹사이트를 사용하게 될 대상들을 고려하여 사이트를 구축하게 된다면 답신은 더욱 접근성이 좋은 페이지들을 만들 수 있을 것이며 이로 인한 이익들이 돌아오게 될 것이다. 일반적으로 잘 알려진 몇몇 가이드라인들을 보고 웹사이트를 만들게 되면 전문가의 기준에 따라 훌륭한 접근성을 가진 웹 페이지를 만들 수 있을 것이다.

• 웹 사이트를 구축함에 있어서 접근성이 왜 필요한지 3가지 이유를 말하라.
• 인터넷을 이용하여 당신의 국가의 접근성 관련 법률을 찾고 웹사이트에 적용해야 된다고 생각하는 법률들을 나열하라. WCAG 또는 Section 508와 같은 웹 표준에 관련된 질문들에 관한 질문을 받을 수 있다라는 점을 염두 하여라.
• 검색엔진의 최적화에 접근성이 왜 중요한지 설명하라
• 사진과 같은 자신만의 콘텐트를 이용한 대안이 되는 콘텐트를 이용하여 접근성을 높이는 예를 만들어 보아라.
• 플래시나 실버라이트와 같은 기술을 어떻게 접근성있게 만들 수 있는 가는 인터넷 검색을 통해 찾아 보고 플래시나 실버라이트를 접근성있게 만드는 것과 HTML을 접근성있게 만드는 것의 차이를 기술하라.
• 웹 페이지를 접근성 있게 하기 위해 상호작용을 어떻게 디자인해야 하는지 설명하여라. tree control을 만들기 위한 방법을 단계별로 만들어라. (실제로 만들 필요는 없다.)

Tom Hughes-Croucher는 인터넷 산업에 몸 담아왔다. 그는 W3C나 BSI 와 같은 작업의 표준 마련을 위한 웹 기술에 관련하여 많은 공헌을 해 왔다. 더욱 최근에는 Tesco, Three telecom과 Channel 4와 같은 잘 알려진 영국의 회사에 디지털 음악 솔루션을 제공하는 디지털 음악에 관한 사업을 진행 중이다.

Tom은 현재 야후에서 기술마케팅 담당자로서 근무 중이며 front-end 웹 기술 그리고 RESTful web service에 관하여 전문가로서 자신이 할 수 있는 한 많은 곳에 자신의 기술을 전파하려고 노력하고 있다.

이전에 European Frontpages를 관리할 때에는 매달 수백만 명의 유럽 사람들이 European Frontpages를 찾았으며 그는 더 이상 수치적인 측면에는 연연하지 않고 있다.