9. 부록 : 실험적 해결책 및 논의

9. 부록 : 실험적 해결책 및 논의

앞 장에서 HTML의 접근성을 향상시키는 접근법을 제시하였다. 우리가 실험 또는 정보를 수집하고 있는 몇몇 접근법은 지침에 포함시키지 않았다. 아이디어와 해결책, 풍부한 논의를 위해 이 실험적 접근법에 대한 현재의 우리 생각을 여기에 제시한다.

가. D-Link

D-Link, 즉 Description Link는 ALT-Text 보다 그래픽 Image를 더욱 온전히 설명하기 위하여 WGBH에 의해 주창되어 왔다. D-Link는 Image 옆 또는 아래에 나타나는 대문자 "D" Text Anchor이다. "D"는 Image에 대한 온전한 설명과 함께 페이지에 연결된다. D-Link의 설명은 자신의 페이지에 나타나기 때문에 작성자가 원하는 만큼 길게 할 수 있다. 따라서, 사용자는 ALT-Text가 허용하는 것보다 더 많은 그래픽 Image에 대한 물리적인 설명 정보를 얻을 수 있다.

아래의 논의는 최악의 시나리오를 살펴보면서 제기된 것이다. 모범적으로 보이는 페이지도 화면 읽기 프로그램을 사용하여 보면 전혀 알아볼 수 없는 경우가 종종 있다. D-Link를 사용할 경우 본래의 Image Map 페이지가 복잡하게 구성되고, D-Link 페이지와 Image Map 페이지를 번갈아 이동해야 하며, Web Site를 유지하기 위한 추가적인 노력 등이 문제가 된다. 우리는 사용자 및 제작자 모두의 입장에서 해결책을 찾으려고 노력하고 있다.

<Image Map과 함께 D-Link를 사용하기 위한 가능한 전략>

D-Link 페이지를 위한 가장 이상적인 형식은 현재 없다. 가능한 5 가지 형식이 예제와 함께 아래에서 논의된다.

(1) 사용자가 D-Link를 누를 때, Image Map에 있는 링크들뿐만 아니라 Image Map에 대한 설명도 제시될 수 있다. 이 경우 Image Map에 포함되지 않은 그 페이지의 링크들은 D-Link 페이지에서 접근할 수 없게 된다.

예제 : Only Image Map Links in D-Link page

http://trace.wisc.edu/text/guidelns/htmlgide/htmlgide.pcs/dlinks/type1.html

(2) 사용자가 D-Link를 누를 때 Image Map에 대한 설명, Image Map 자체에 있는 링크들, Image Map에 포함되어 있지 않은 그 페이지의 모든 링크들이 제시될 수 있다. 이런 방식에 의해 Image Map을 이해하는 사용자는 정안인이 그래픽 페이지에 접근하듯이 접근할 수 있다. 그러나 이 방법은 Web Site의 유지에 필요한 노력을 증가시킨다.

예제 : All Links included in D-Link page

http://trace.wisc.edu/text/guidelns/htmlgide/htmlgide.pcs/dlinks/type2.html

(3) 접근성을 증가시키는 또 다른 방법은 그 페이지에 있는 Image Map 링크, 모든 다른 링크들에 ALT-Text, D-Link, Text-Anchor들을 제시하는 것이다. 그러나 이 방법은 Image Map 페이지를 복잡하게 보이게 만들 수 있다.

예제 : One page with ALT-Text, D-Links, Text Anchors

http://trace.wisc.edu/text/guidelns/htmlgide/htmlgide.pcs/dlinks/type3.html

(4) Web Site의 유지에 드는 노력을 감소시키기 위해서 사용자가 그래픽 페이지로 돌아갈 수 있는 링크를 D-Link 페이지에 포함시킬 수 있다. 다른 모든 링크들은 그래픽 페이지에서 접근할 수 있다. 그러나 이 방법은 Image Map의 시각적 특성만을 설명하기 위하여 추가적인 링크를 만들어야 한다.

예제 : Only a return Link in D-Link page

http://trace.wisc.edu/text/guidelns/htmlgide/htmlgide.pcs/dlinks/type4.html

(5) D-Link들은 Image Map 페이지에 전혀 나타나지 않을 수 있다. 그 대신 D-Link가 사용될 때마다 그 페이지의 Text 버전이 제시될 수 있다. Image Map에 대한 설명은 Text 페이지에 나타날 것이다. Text 페이지는 그 안에 링크들을 가지고 있거나 그렇지 않거나 하는, 똑같은 선택 사항을 가질 것이다. 그러나 이 방법은 다른 방법에서는 필요로 하지 않는 Text 페이지들을 만들어야 한다.

예제 : Text version instead of D-Link

http://trace.wisc.edu/text/guidelns/htmlgide/htmlgide.pcs/dlinks/type5.html

<Site의 분위기 유지>

D-Link들이 Image Map 페이지에 나타날 때 가능한 한 눈에 거슬리지 않도록 할 필요가 있다.

(1) 한 가지 제안으로는 매우 작은 폰트를 사용하는 것이다. 그러나 몇몇 화면 읽기 프로그램들은 갑작스럽게 폰트 크기가 변할 경우 제대로 대처하지 못한다. 따라서 D-Link의 크기는 화면 읽기 프로그램이 읽을 수 있을 만큼 충분히 커야 한다. 이 분야에 대해서는 더 많은 연구가 필요하다.

(2) 다른 제안으로는 여건상 가능하다면 시각적으로 겹처진(nested) 링크를 만드는 것이다. 장래에는 ALT-Text 링크에 D-Link를 포함시킬 수 있게 되기를 바란다. 이 경우에는 Image를 켰을 때 D-Link의 복잡함 없이 그래픽 페이지를 볼 수 있다.

(3) 세번째 제안으로는 그래픽 Image에 대한 지식을 극대화하는 것이다. 이것은 ALT-Text에 상세한 내용을 붙여 해결할 수 있다. 예를 들어 그래픽이 "수리 요망"이라는 표지가 붙은 맨홀 뚜껑이라면, ALT-Text는 "수리 표지가 붙은 맨홀 뚜껑"이 될 것이다. 그래픽은 ALT-Text에서 완전히 정의되어 D-Link는 필요하지 않게 될 것이다. 뿐만 아니라 이 방법은 그래픽을 켜지 않더라도 그 그래픽에 첨부된 링크를 따라갈 것인가 아닌가를 결정하는데 있어서 더 많은 지식을 제공해 준다. 그러나 복잡한 그래픽은 이런 방식으로는 처리될 수 없다.

<Text 버전 페이지 또는 Site 전체>

사용자들이 Text 버전 페이지를 선택하는 데는 많은 이유가 있다. 그 이유 중의 하나는 그래픽 페이지에 접근할 수 없기 때문이다. 이 경우 Text 버전은 접근성 있는 대안을 제공한다. 두번째 이유는 화면 읽기 프로그램이 다른 형식으로는 정안인이 한번에 볼 수 있는 모든 정보를 제공하지 못하기 때문이다. 세번째 이유는 불필요한 그래픽 없이 빠르게 Text를 읽을 수 있기 때문이다.

(1) Site 작성자가 Text 버전 페이지를 만들 때 그 페이지에 D-Link를 포함시켜야 하는가? 문제는 어떤 사람들은 불필요한 그래픽 정보 없이 Text를 빠르게 읽을 수 있기 때문에 Text 페이지를 선택한 반면에, 다른 사람들은 그 접근성 때문에 Text 페이지를 읽는 것이다. 또한 D-Link를 Text 페이지에 넣는다면, 접근성 때문에 Text 버전을 사용하는 사람들에게 페이지의 어느 부분에 그래픽이 나타나는지를 알리기 위해 그래픽이 있는 자리에 "D"를 위치시켜야 한다. 그러나 이 방법은 Text만 읽기를 원하는 사람들에게는 오히려 복잡함을 가중시킨다.

(2) Site의 일부분이 Text 버전인 경우, Text 페이지에서 다른 Text 페이지 또는 그래픽 페이지 중의 어느 곳으로 이동하는지 사용자가 어떻게 알 수 있는가? 작성자는 Text 페이지가 Site의 나머지 페이지들과 같은 분위기를 가지도록 하여 Site의 일관성을 유지하려 할 수도 있다. 다시 말해 순수한 Text 대신에 그 페이지에 상징, D-Link, 본래의 그래픽 페이지에 나타나는 Image와 관련된 Reference들을 포함시킬 수 있다. 이런 방법은 사용자가 Text 페이지가 아닌 페이지에서 종료할 때 차이점을 느끼지 않도록 만든다. 그러나 이것은 순수한 Text 사용자들이 그 페이지를 이해하기 어렵게 만들며, 그것을 필요로 하는 사람들을 위한 진정한 Text 페이지는 아니다.

(3) Site 전체를 Text 버전으로 제시하는 것이 화면 읽기 프로그램과 Text Browser를 사용하는 사람들과 그래픽이 필요하지 않다고 느끼는 사람들에게 유용하다. 그러나 이 문제에 대해서는 더 많은 조사가 필요하다.

<결론>

우리는 어떤 접근법들이 쉽게 페이지를 유지할 수 있게 하고, 또 매력적으로 보이게 하면서 효과적이고 능률적인 접근을 제공해 주는지를 결정하기 위하여 주의 깊게 다른 D-Link 시나리오들을 살펴 보아야 한다. 뿐만 아니라 사용자의 요구를 최대한 충족시키기 위해 D-Link를 필요로 하는 사람들을 더 잘 이해해야 한다.

나. Text (ALT-Text와 Text Anchor)

우리는 4 가지 문제점과 그 해결책에 대해 논의한다.

<문제점 1>

화면 읽기 프로그램들은 종종 Image Anchor들의 ALT-Text나 Text Anchor들을, 그것들 사이에 빈 칸이 없으면 하나의 링크로 읽는다.

예제

페이지 하단의 Menu Bar는 하나의 Image Anchor와 2 개의 Text Anchor로 구성되어 있다. 이 경우 Image의 ALT-Text와 첫번째 Text Anchor는 하나로 읽혀진다.

<A HREF="/pathname/link1.html"><IMG SRC="/pathname/Image.gif"

ALT="link1"></A>

<실험적 해결책>

이 문제를 확실히 해결하기 위하여 Text Anchor들 사이에 1 개 또는 그 이상의 빈 칸을 위치시킨다. 이것은 또한 정안인들을 위해서도 링크를 분리시킬 것이다.

주의사항

사용되는 화면 읽기 프로그램에 따라서는 빈 칸을 추가하는 것만으로는 문제가 해결되지 않을 수 있다. 우리가 사용한 모든 화면 읽기 프로그램은 빈 칸을 만날 때 링크들 사이에서 일관되게 멈추었다. 다른 부호도 마찬가지로 작용할 것이다. 빈 칸을 사용하는 것은 화면 읽기 프로그램에 의한 접근성을 증가시켜 줄뿐만 아니라, Text를 시각적으로도 분리시켜 준다.

<문제점 2>

ALT-Text는 때때로 중심에 수직으로, Image Icon 옆에 배치되어 있어서 다른 줄에서 읽혀진다.

예제

<A HREF="/pathname/link2.html"><IMG SRC="/pathname/Image.gif"

ALT="link2">"link2"</A> |

이것은 다음과 같이 읽혀질 것이다.

link2, link1, link3

<실험적 해결책>

가능한 전략으로는 Image를 문장에서 빼내어 문단 또는 문장의 앞이나 뒤에 놓는 것이다. 작성자들은 Image를 끄고 ALT-Text의 배치를 볼 수 있지만, 사용자가 선택한 제각기 다른 Browser에 따라 글자의 폭과 크기가 다르게 나타날 수 있다.

<문제점 3>

때때로 문장에 ALT-Text가 포함되어 있을 때 그것이 어디에서 끝나고 문단의 Text가 어디에서 시작하는지를 구별하기 어렵다.

<실험적 해결책>

ALT-Text 문자열의 앞과 뒤에 "an x"와 같은 문자를 위치시킬 수 있다. 이것은 모든 화면 읽기 프로그램으로 읽을 수는 있지만, 문제를 혼란스럽게 만든다. 예를 들어 "x see Links below x"가 Image Map의 ALT-Text였다면, "x"는 "icon x" 또는 "x distance of miles to go" 등의 것과 혼동될 수 있다. 이것은 또한 ALT-Text 각 항목에 두 음절을 추가시킨다.

다른 대안은 Slash(/)이다. 이 방법은 화면 읽기 프로그램 사용자에게 정확한 구둣점 수준을 설정할 수 있게 해 준다. 또한 ALT-Text의 시작과 끝을 듣고 싶어하지 않는다면 읽지 않도록 할 수도 있다. 몇몇 화면 읽기 프로그램에서는 "no punctuation"은 "구둣점을 전혀 읽지 않는 것"을 뜻하기 때문에, Slash를 듣기 위해서는 "some punctuation"으로 설정해야 한다. 그러나 이것은 또한 마침표(.), 쉼표(,), @, %, ^, &, \, # 등을 읽는다는 것을 뜻하며, 결국 한 페이지를 읽는데 걸리는 시간과 노력을 훨씬 더 증대시킨다. 한편 구둣점을 포함하는 것은 때때로 문장의 문맥을 혼란스럽게 만든다. 가령, "with some 화면 읽기 프로그램s (쉼표) no punctuation means no punctuation (마침표)" 이다.

<문제점 4>

Image의 폭과 높이가 정해져 있다면 ALT-Text는 줄이 바뀌어 계속될 것이다. 한 줄에 여러 개의 Image가 있고 그것들의 ALT-Text가 줄이 바뀌어 계속될 경우, 화면 읽기 프로그램 사용자는 화면 읽기 프로그램이 화면을 가로질러 읽기 때문에 전혀 그것을 이해할 수 없을 것이다. 예를 들어 3개의 Image의 ALT-Text가 "Trace logo", "Trace documents", "Trace calendar" 라면, 화면 읽기 프로그램은 Image들의 크기에 따라 그것을 "Trace Trace Trace logo documents calendar"라고 읽을 수도 있다. 이것은 또한 정안인이 ALT-Text를 읽을 수 없도록 만들 수도 있다.

<현재의 해결책>

작성자가 Image의 높이 및 폭을 조정하여 해결책을 찾을 수 없거나 Text의 줄이 바뀌지 않는 방식으로 그것들을 사용할 수 없다면, 현재는 Text만으로 된 버전만이 해결책인 것 같다. 그러나 Browser마다 각기 다른 폰트와 크기를 선택할 수 있기 때문에 실험은 거의 불가능하다.

다. 서식 및 편집 상자

<문제점>

화면 읽기 프로그램은 비어 있는 편집 상자를 무시한다. 따라서 사용자는 그것이 있다는 것을 알 수가 없다. 예를 들어 검색 내용을 입력받기 위한 편집 상자가 있다는 것을 안다 할지라도, 시각장애인이 정안인의 도움 없이 편집 상자에 마우스 Pointer를 위치시키기는 어려운 일이다.

<실험적 해결책>

(1) 편집 상자에 자리를 메우는(place holder) 문자를 위치시킨다.

- 자리를 메우는 문자가 사용자에 의해 우연히 지워졌다 할지라도 I-bar는 여전히 그 상자 안에 존재하고 있기 때문에 사용자는 그것을 다시 찾을 수 있다.

- 자리를 메우는 문자가 전자우편 주소나 검색 루틴 같은 것들을 방해하지 않도록 주의해야 한다. 사용자가 전자우편 주소 상자에서 자리를 메우는 문자를 지워야만 한다면, 그것은 매우 나쁜 경우이다. 별표(*)는 검색 조건을 입력하는 편집 상자에서 임의 문자(Wild Card)로 이용되어, 사용자가 검색하고자 하는 단어나 어구 입력을 가능하게 해 준다.

(2) '상자의 왼쪽'과 같이 상자를 중심으로 위치를 정해서 편집 상자 표시를 한다. 편집 상자에 자리를 메우는 문자가 있거나 I-bar가 있으면, 사용자는 그 표시를 찾아서 마우스 Pointer를 왼쪽으로 한 칸 옮겨 편집 상자를 발견할 수 있을 것이다.

(3) 편집 상자에서 정상적으로 발견되는 정보를 얻고, 그것을 조작하기 위해서 대안적 전략이 사용될 수 있다.

- Keyword 검색뿐만 아니라 Alphabet Index로도 검색할 수 있는 루틴이 제시될 수 있다.

- 사용자는 요청받은 정보를 반송할 수 있는 편지서식 또는 전자우편 주소을 내려받을 수 있다.