3. 화면구성(Layout)
가. 일반적 문제점과 해결 전략들
HTML은 발전함에 따라, 새로운 유연성을 도입하기 시작했다. 각종 도표나 그밖의 구조들에 의해 Text는 나란히 배열된 문단 및 다른 형식으로 정렬될 수 있게 되었고, 그것은 화면 읽기 프로그램이 도표내의 한줄을 한 문장으로 인식하여 읽어버리는 난점들을 발생시켰다.
<현재 가능한 일반적 해결 전략들>
(1) 화면구성을 가능한 한 간단하고 평범하게 유지한다.
(2) 칼럼 형태로 Text를 정렬하는 것을 삼가한다.
(3) Web 페이지를 보다 조직적이고 구조적으로 만들기 위해 그래픽을 사용할 경우에는 시각적 Image에 상응하는 내용을 가지는 Text를 삽입해 준다.
(4) 위의 3번까지의 방법에도 불구하고 정보의 구현이 어려울 경우에는 같은 정보를 접근이 가능한 형식으로 보여주는, Text로만 된 Web 페이지가 사용될 수 있을 것이다. Text로만 된 Web 페이지로 연결하는 링크는 그래픽 페이지의 처음에 위치해야 하며 그 반대의 경우도 성립된다.
(5) 여러 다른 페이지에서 같은 기능을 수행하는 버튼들(예를 들어, "홈페이지로 돌아가기")은 페이지의 일정한 위치에 있어야 한다.
나. 도표
<문제점>
정보를 효과적으로 나타내기 위해 다양한 도표 사용 방법이 있다. 여기서는 간단히 네가지 도표 유형에 대해 언급하겠다.
● 스프레드시트 혹은 달력 양식: 숫자로 된 데이타를 구현하기 위한 양식
● 신문 양식: Text를 칼럼 형식으로 구현하기 위한 양식
● 그래픽 양식(Graphical Navigation): 메뉴 형식으로 image를 구현하는 것
● 혼합형: image 칼럼을 navigation bar로 Text 칼럼 옆에 위치시키는 것
이들 네 가지는 화면 읽기 프로그램에 각각의 상이한 문제를 야기시킨다. 위에서 지적한대로, 두개의 칼럼으로 구성된 Text가 있을 경우, 화면 읽기 프로그램은 우선 왼쪽 칼럼에 있는 Text를 다 읽고 난 후, 오른쪽 칼럼의 Text를 읽는다. 칼럼으로 된 Text를 읽을 수 있는 화면 읽기 프로그램을 사용하는 시각장애인들은 도표 내에서 자신들이 어떤 줄 어떤 칼럼에 있어야 할지를 모르는 경우, 큰 어려움에 직면하게 된다. 또한, Text를 구현하기 위해 도표를 사용하는 Web 페이지는 신중하게 다루어지지 않을 경우, 큰 혼란을 초래할 수 있다.
<현재 가능한 해결 전략>
현재 사용하는 도표의 종류에 따라 그 방법이 달라지게 된다.
(1) 많은 아이콘이 있는 경우 : 도표 내 각각의 Cell은 해당 내용을 대표해야 한다. 각각의 Image에 상응하는 Alt-Text가 한 Cell에 다 들어가지 않을지라도 이것은 접근이 가능해야 한다. 그 예로써 미국의 우편 서비스망인 WINGS 홈페이지(http://www.wings.usps.gov)를 참조하라.
(2) 칼럼 형식으로 된 Text나 수치 데이타로 된 도표 : 단일 칼럼으로 구성된 Text 버전을 마련해야 한다. 몇몇의 경우에는 이것이 불가능할 수도 있다. 예를 들어, 한 도시의 예산을 다루는 여러 개의 스프레드시트를 Text로 변형하는 데에는 수주일 이상의 시간이 소요될 것이다. 또 다른 해결책으로는 사용자가 도움을 요청할 수 있도록 연락처나 E-mail 주소를 표시해 주는 것이다.
<앞으로의 해결 전략>
● HTML 개선: 화면 읽기 프로그램을 사용하는 시각장애인들에게 도표내의 정보에 접근할 수 있도록 돕기 위해 두 가지 속성이 도표 내에 추가되어야 한다는 점이 제기되고 있다. AXIS와 AXES가 그것들로, 이들은 도표내의 각 Cell과 연관을 가질 것이다.
● Browser 개선: Browser가 도표 내 각각의 요소에 대해 모든 속성을 활용할 수 있도록 한다면, 도표내의 칼럼, 줄, Cell의 내용이 화면 읽기 프로그램으로 읽을 수 있을 것이다.
● 화면 읽기 프로그램 개선: 현재 사용되는 대부분의 화면 읽기 프로그램은 도표내의 칼럼을 읽을 수 있으나, 사용자들은 자신이 어느 줄 어느 칼럼에 위치해 있는지를 알 수는 없다. 이같은 정보는 화면 읽기 프로그램이나 Browser 둘 중 한 곳에서 해결되어야만 한다.
다. 목록
<문제점>
화면 읽기 프로그램을 사용하는 경우, 목록이나 내용이 어디서 시작하고 끝나는지를 알 수 없게 된다. 만일, 엔트리가 두줄로 시작되는 경우라면, 사용자는 이것을 두개의 상이한 아이템으로 착각할 수도 있다.
<해결 전략>
● 목록상에서 각각의 항목에 Bullet 또는 번호를 붙인다. 숫자가 항목들의 순서를 의미할지는 모르지만, 연속하여 들을 때 목록 내에서 어디쯤 있는지를 결정하는 것을 용이하게 해준다.
● 출력될 목록이 몇 개의 항목으로 되어있는지를 명시하는 것도 좋다. 예를 들어 "이 목록에는 6개의 소주제가 있다" 또는 "이 연구는 7개의 목적으로 구성되어 있다"와 같은 내용은 사용자가 앞으로 얼마나 많은 것을 읽어야 할지를 인식하는 데에 매우 큰 도움이 된다.
WINGS Access Page(http://www.trace.wisc.edu/wings/)는 이에 관한 좋은 사례이다. 한편 목록에 번호를 부여하면 인지적 장애를 극복할 수 있다. 번호가 붙은 목록들 및 페이지 구조에 대한 지시자를 가진 기관의 페이지는 Web 페이지에 대한 이해를 돕는다.
라. 프레임(Frame)
<문제점>
● 어떤 화면 읽기 프로그램들은 각각의 프레임들을 개별적 윈도우로 간주하는 경향이 있다. 이들 프로그램을 만드는 개발자들이나 Browser들은 프레임들간의 이동에 대한 문제를 해결하기 위해 더욱 용이하고 논리적으로 만들기 위한 문제를 논의해야 한다.
● 소형 모니터에 여러 개의 프레임들이 있는 경우에는 데이터를 보는 것이 불가능하거나, 어려워지게 될 것이다.
<현재의 해결 전략>
프레임에 상응하는 Text로 된 홈페이지를 만드는 것이 요구된다.
마. 자바 스크립트(Java Script)
<문제점>
자바 스크립트는 스크립트 방식의 언어로서, 제한된 방식으로 Web 페이지를 더욱 역동적으로 만드는 것을 돕는다. 이것은 주로 서식의 개선에 사용되며, HTML의 하위세트이므로 유사한 일련의 문제를 가지고 있다. 새로운 문제들은 한 프레임에서의 사용자의 행동이 다른 프레임의 변화를 일으킬 수 있다는 점과 관계가 있다. 이러한 문제들을 규명하기 위해 연구가 진행되고 있다.
바. 미리 포멧된 Text(Pre-formated Text)
<문제점>
현재 화면 읽기 프로그램들이 단일 칼럼으로 이루어진 화면들에서 잘 작동되고 있으나, 여러 개의 칼럼으로 되어 있거나 세로 방향으로 된 Text에서는 제대로 작동하지 못하고 있다. 현재의 화면 읽기 프로그램들은 시각적 측면에서 매우 뛰어난 양식을 보여주는 PDF파일을 읽도록 하는 도전에 직면해 있다.(PDF파일은 여러 개의 칼럼으로 구성되어 있거나, 세로 방향으로 된 Text, 잘 보이지 않는 Text를 포함하고 있기도 하다.)
<현재의 해결 전략>
PDF Access view는 읽기 능력의 향상을 위해 Text 문서를 제시함으로써 윈도우즈용 화면 읽기 프로그램과 협력하도록 고안되어 있다. 가령, Acrobat Access가 여러 칼럼으로 된 문서를 하나의 칼럼으로 구현하고 세로로 된 모든 Text를 가로방향으로 정렬시키는 방식을 참고하라. 이 방법의 활용이 어려운 경우에는 Text 중심 페이지의 구축을 시도할 수 있다.