좌충우돌 웹퍼블리셔 일기

원본 : https://www.wah.or.kr:444/Participation/consultingView.asp?cType=&seq=9207&page=1?cType=&FindTxt=타이틀&cMail=

[질문]

안녕하세요.

1) 레이블 제공에 대해 문의드립니다.
입력서식에는 레이블을 제공하도록 되어 있는데 타이틀을 제공하는 것과 비교한다면 사용자 입장에서 어떤 차이가 있는지 알고 싶습니다.
접근성 보조도구로 입력서식에 접근하면 똑같이 읽어주는 것 같습니다.

2) 새 창에 대해 target을 blank로 지정해 놓으면 접근성 보조도구에서 정상적으로 새창이라고 리딩해 주는 것으로 알고 있습니다. 지침에 따라 title 속성을 써서 새 창 알림 정보를 제공하면 중복해서 읽어주게 되는데요..그래도 입력해 주는 것이 좋다면 어떤 면에서 도움이 되는지 알고 싶습니다.

감사합니다.




[답변]

안녕하세요.

1) 레이블 제공 방법에 대해 안내해 드립니다.

입력서식을 이해할 수 있는 1:1 대응하는 레이블을 제공하여야 합니다.
문의 주신 것처럼 <label>요소를 연결하여 제공하는 방법과 title 속성을 이용하여 제공하는 방법이 있습니다.

레이블을 연결할 텍스트가 있다면 <label>요소로 제공하는 것이 권장됩니다.
<label> 요소를 제공하지 않은 경우에는 체크박스나 라디오버튼을 직접 클릭해야만, 텍스트와 입력서식이 1:1로 연결하면 <label>요소내 텍스트를 클릭하면 입력서식도 체크됩니다.
이는 정밀하게 선택이 어려운 사용자에게 많은 도움이 됩니다. 이러한 경우 <label>요소로 제공하는 것이 바람직합니다.

우편번호나, 전화번호처럼 여러개의 입력서식을 받아야 하는 경우처럼 레이블으로 연결할만한 텍스트가 화면상에 제공되지 않거나, 시각적으로 보이지 않는 경우 처럼 레이블이 1:1으로 대응하기 어려운 경우에는 title 속성을 이용하여 제공하는 것이 바람직합니다.

국내에서 가장 많이 사용되는 센스리더의 경우, <label> 요소나 title 속성 중 하나만 제공되면 편집창 접근시 레이블을 읽어줍니다. 단, <label> 요소와 title 속성을 같이 사용한 경우, <label>요소이 우선권을 같습니다.

<label> 요소와 title 속성을 용도나 상황에 맞게 고려하여 레이블을 제공하는 것이 권장됩니다.

2) 새창 열림 미리 알림 방법에 대해 안내해 드립니다.

새창 페이지를 제공할 때는 target="_blank" 속성을 제공하는 것이 바람직합니다.
_blank로 제공하면 센스리더를 포함한 대부분의 스크린리더는 새창을 미리 알려줍니다.
예) 센스리더
(링크텍스트) 새창 링크, (이미지 alt) 새창 그래픽 링크

window.open 메소드를 이용하여 새창을 여는 방법과 같이 스크립트를 통해 새창 페이지를 여는 경우, title 속성으로 새창을 미리 알리는 방법이 권장되고 있습니다. 이는 스크립트로 열리는 경우, 새창여부를 알 수 없기 때문입니다.

title 속성으로 새창을 알리는 경우, 스크린리더에 따라 옵션을 켜야만 듣게되거나, 읽어주지 않을 수 있습니다.
그러므로 특별한 경우가 아니라면 target속성을 통해 새창을 미리 알수 있도록 합니다. 즉, target 속성으로 제공하는 것이 보조기기 환경과 관계없이 새창임을 구분할수 있으므로 사용자 입장에서 더 도움이됩니다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

즉

1) 기본은 label 과 폼 요소 연결, 레이블에 여러개의 폼요소가 연결되거나 시각적으로 보이지 않을 경우 title 사용

2) 새창은 기본적으로 target="_blank" 로 사용. window.open 시 title을 사용하나 이는 기기에 따라 옵션 설정이 있을수 있으므로 비권장

접근성 툴

http://www.accesslint.com/

N-WAX  크롬 부가기능

OPEN-WAX  크롬, 파이어폭스 부가기능

K wah4.4 카도와프로그램

http://jos39.tistory.com/119

1.레이어 팝업이 다른 콘텐츠를 가려서 레이어를 닫아야만 하는 경우 마우스 초점을 정밀하게 다룰 수 없는 장애 영역(주로 상지 장애 -팔이 없거나 움직이기 어려운-)의 접근을 어렵게 합니다. 심사 가이드에 따라 심사를 할 것입니다. 다른 콘텐츠를 가리지 않는 레이어라면 문제가 없습니다.

2. 폼 콘트롤 요소의 선택 또는 입력 행위만으로 폼이 자동으로 전송되는 경우에만 문제가 됩니다. 체크박스, 라디오 버튼, 콤보박스가 선택될 때 폼을 전송하는 것이 아니라 단지 하위 콘텐츠의 내용이 변경되는 것은 문제가 되지 않습니다.

[질문]

안녕하세요~~

[질문 1]
테이블의 td 속성이지만 제목의 역할을 하는 셀에는 scope 속성을 넣어 표현하게 되어있는데요.
html5 경우 td에 scope 속성을 쓰지 못하게 되어 있습니다.

이경우~
제목의 역할을 하는 td는 th로 변환하는 것이 방법일까요?


[질문 2]
간혹 th에 scope와 ID 두개 다 적용하는 경우가 있는데요
이런 경우
둘 중 하나를 쓰게 하는 것이 맞는지요?
(현재 심플한 테이블은 scope를 사용하고 복잡한 구조에는 id를 사용하고 있음.)

[질문 3]
scope와 id를 섞어서 사용하는 경우
예) 세로열의 th에는 id를 사용하고, 가로형의 th에는 scope="row"로 사용
해당 셀에는 headesr="세로열 th의 id"만 제공하는 경우
이런 부분은 어떻게 하는 것이 좋을까요?

경우의 수가 많아서 좀 복잡하고 사용하고 있습니다.



[답변]

질문 1: 네, 제목의 역할을 하는 셀은 <th>로 마크업하시는 것이 바람직합니다.

질문 2: th에 id를 명시하고 td에 headers로 th와 연결시키는 경우 말씀이신가요? 맞다면 말씀하신 대로 하시면 충분하다고 판단됩니다.

질문 3: scope와 headers를 혼용하는 경우 이 마크업을 해석하는 보조 기기별로 해석 결과가 다를 수 있기 때문에(headers에 명시된 제목셀과 scope의 제목 셀 중 어떤게 먼저인지에 대한 해석, 두가지를 다 제목으로 사용자에게 전달할지 여부에 대한 해석 등) headers를 사용하시면 headers만으로 제목 셀과의 연결을 구현하시기를 추천드립니다.

디자인

■ 디자인에 앞서 반드시 숙지해야 할 사항

1 . 색상으로 표현된 정보는 색상을 배제하여도 원하는 내용을 전달할 수 있어야 한다.

2 . 전경색과 배경색은 충분한 대비를 가지고 있어야 한다.

3 . 텍스트는 쉽게 읽을 수 있도록 충분한 크기로 제공되어야 한다. KADO의 품질마크 인증 기준에 의하면 판독하기 쉬운 텍스트의

충분한 최소 크기는 12px로 정의하고 있음.

4 . 이용에 시간제한이 있는 콘텐츠의 경우 경고 및 시간조절 기능을 제공하여야 한다.

5 . 팝업창을 불필요하게 사용하지 않아야 한다.

6 . 각 링크의 목표 위치를 명확하게 하여야 한다.

■ 색상으로 표현된 정보는 색상을 배제하여도 원하는 내용을 전달 할 수 있어야 함.

도형의 모양을 달리 하여 색 뿐만 아니라 도형의 모양으로 구분이 가능하게 함.

■ 텍스트는 쉽게 읽을 수 있도록 충분한 크기로 제공되어야 함.

KADO의 품질마크 인증 기준에 의하면 판독하기 쉬운 텍스트의 충분한 크기는 12px로 정의하고 있음.

위 그림은 텍스트 크기가 11px이므로 12px로 조정이 필요함.

■ 명도 대비는 최소 4.54:1을 유지해야 함.

배경색이 #ffffff 일 때 글자색은 최소 #767676보다 어두워야 4.54:1의 명도대비가 나옴.

■ Flash에서 텍스트가 포함된 버튼 심불과 무비클립 심볼에는 Accessibility Panel을 이용

하여 설명력 있는 대체 텍스트를 제공해야 함.

버튼 심볼이 존재하는 경우 탭의 이동순서를 고려하여 Tab index를 지정하도록 함. 로그인을 위한 인풋상자에는 ‘L’을 접긴키로 지정함.

http://www.colorsontheweb.com/colorcontrast.asp

 #333 정도가 #FFF와 딱 명도대비 4.5대1

명도 대비는 최소 4.54:1을 유지해야 함.

배경색이 #ffffff 일 때 글자색은 최소 #767676보다 어두워야 4.54:1의 명도대비가 나옴

예전에 링크해놨던 글인데 다시 읽어봐도 많은걸 생각하게 한다.
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ



지금 만들고 있는 사이트 (오픈해야 url을 연결할..텐... OTL) 마무리단계에서 시각장애인 실제 사용성 테스트를 맡기고 검사 결과에 대해 이야기하기 위해 시각장애복지관에 다녀왔었습니다.

스크린리더기는 현재 이슈 된 장차법과 연관되어 테스트를 해보고 싶어하는 분들이 많을꺼라 생각되어, 사이트에도 내용 정리해서 올라가지만 먼저 블로그에 짧게 리포팅 해봅니다.

그 전에 시각장애인의 웹 이용에 대해 이해를 위해 http://www.iabf.or.kr/ 사이트 메인에 보면 "웹 접근성 동영상, 시각장애인의 컴퓨터 활용-전맹, 시각장애인의 컴퓨터 활용- 저시력인" 동영상 3가지 있는데 보시면 도움이 많이 됩니다. (백문이불여일견! 있는 자료들을 최대한 활용해 보아요) /*  명함사이트로 바뀌었네요.. */

위 영상과 중복되는 내용도 조금있을 수 있으며, 기본적으로 시각장애가 있는 경우 웹 이용시 바라는 점에 대해 적고 있는 부분도 있으니 그 부분에 대해 양해를 먼저 바랍니다.

1. 테스트한 스크린리더 프로그램: 센스리더 프로페셔날 (옵션은 기본 설정) 
   주로  테스트한 부분은 메인, 회원가입, 게시판 글 남기기, 검색
   브라우저의 타이틀부터 읽어 내려갑니다.
   페이지내 이동은 키보드 방향키로 동작. (상하좌우)
   참고: 스크린리더가 브라우저 전체를 쭉 읽는 것과 키보드로 위치 이동할 때 읽는 방법이 약간 차이 납니다.
   (title과 label 읽는 것이 틀려짐)
   
2. h을 어떻게 읽을까? 
   - <h2><img src="h2_title.gif" alt="회사소개"></h2> : ♪ 헤딩이 회사소개 이미지
   - <h2>회사소개</h2> : ♪ 회사소개 헤딩이
   위와 같이 이미지와 텍스트인 경우 읽는 순서가 틀리므로, 헤딩들끼리의 규칙성 등을 염두하여 문서 구조화 알기 쉽게 헤딩을 이미지 또는 텍스트로 통일하였으면 하셨음. (한 페이지내 헤딩이 너무 많은 경우도 좋지 않다고 함)  개인적인 의견으론 센스리더 제작사에 통일 요청을 드리는 것이 좋겠다는 생각을 합니다. 개발하는 입장에서도 이용하는 입장에서도 약간 혼동의 소지가 있는 것 같습니다.
   
3. alt와 title의 혼재 시
   <a href="notice.html" title="공지사항"><img src="moer.gir" alt="더보기"></a>: ♪ 공지사항 그래픽 링크
   이전 버젼에서는 a태그 내의 타이틀을 처리하지 않았으나, 접근성에서 타이틀의 비중이 높아집에 따라 타이틀의 처리 순서를 상위로 배치 하면서 이미지의 alt 태그를 읽어주지 않는 현상이 있었음. 이 부분도 h와 같이 의견을 드려보는 것이 좋을 것 같다는 생각입니다. 다른 문제가 없다면요.
   
4. 스크린리더의 옵션들에 대해
   - ctrl + F6키의 조합으로 헤딩간 이동 가능 (시멘틱마크업의 필요성을 다시 한번!)
   - display 속성을 읽거나  읽지 않도록 선택 가능
      (디자인적으로만 안보이게 하는 경우는 display: none 아닌 visibility: hidden 속성을 이용하도록 하자)
   - 프로그램 실행시 포커스가 안 보이나, 옵션에서 가상커서 보이게 하면 나타남.
   - 링크는 띄어 읽음. (키보드로 한줄 내려야 인식)
     예)  네이버바로가기<a href="http://naver.com">네이버</a> :  ♪ 네이버바로가기 (멈춤) 네이버 링크
   - 특수기호 및 부호들은 옵션에서 읽기 설정해 주어야지 인식.
     예) 처음 -> 끝 :  ♪ 처음 끝 (중간에 있는 기호들은 기본 설정은 안 읽게 되어 있음)
   
5. 대체 텍스트, 테이블에 대한 설명은 간단, 명료하게.
   - 게시판 설명은 굳이 필요없게 느껴진다는 의견.
   - 게시판 버튼의 경우 일반 링크와 input 버튼 속성이 혼재되어 사용하였는데, 하나로 통일하는 것이 좋을 듯.
   - 대체텍스트가 굳이 필요없는 경우는 (텍스트와 중복 설명이 되는 경우가 간혹 발생할 수 있음) alt="" 이런 식으로 처리하는 것이 도움이 나음.
   - 첨부파일이 만약 3개인 경우 첨부파일하고 한 영역에 3개의 첨부파일폼을 넣는 것 보다, 첨부파일1 -첨부파일 입력폼1 이런식으로 각각 매칭시켜주는 것이 인식에 더 용이.
   
6. alert?
   - 접근성 항목 중 자바스크립트 부분에 대해 예민하게 고려하게 되너 alert를 거의 배제 하고 작업 진행 함.
   - 로그인 성공 시 자동으로 로그아웃으로 설정이 바뀌는 것 외에 추가로 로그인 되었다고 알려주는 정보가 없음.
   - alert 같은 경고창으로 소리와 함께 로그인 되었다는 상태를 안내해 주는 것이 직관적으로 로그인 되었음을 느낄 수 있음.
   
7. 추가 이야기들.
   - 시각장애인 전용 사이트는 본 웹사이트와 동일한 정보 제공 및 업데이트가 이루어지지 않는다면 있어도 도움을 직접적으로 받기 어렵다고 합니다. 개인적으로도 시각장애인 전용 사이트를 두고 있는 곳들을 보아도 정보의 차별과 업데이트의 문제점을 가지고 있는 경우가 많았습니다. 그리고 TTS 솔루션을 이용하여 편의를 높였으나 스크린리더와 충돌을 막지 못하는 경우도 있었고요.
   
   - 브라우저 어떤 버젼을 많이 사용하시는지 여쭈어 보니 IE 6을 주로 사용한다고 합니다.
   IE7 등의 화면확대 등 부가 기능과 IE 6의텍스트 확대 기능을 쓰시는지에 대해서도 이야기를 나누었는데, 새로운 운영체제의 발표와 실제 스크린리더기의 업데이트 기간의 차이에 대해 이야기를 주신후 손에 익은 부분도 있어 쉽게 업데이트하기 어렵다는 이야기를 하셨습니다. 이 부분은 보편적인 사용자들도 큰 혜택등을 느끼지 못하면 업데이트를 하지 않기도 하죠 ^^; 웹 개발자를 살려주세요! 캠페인 생각도 잠깐 났습니다 :)
   
   - 웹사이트 내에서 글자색, 배경색, 크기를 조절할 수 있는 기능을 제공하는 것이 도움이 된다고 합니다.
   테스트를 하여주신 분은 약시로 흰색바탕에 검은 글씨는 눈이 부셔서 보기 어렵다고 합니다. 외국의 화면확대 프로그램에서 화면 반전모드를 이용하여 보는데, 그런 경우 일반 사진들도 반전 된 칼라로 나와 아쉽다고 하네요.
   
   - 이용하기 좋았던 웹사이트가 있었는지에 대한 물음에는 먼저 이용할 수 있는 사이트들이 제한적이며 네이버, 다음 같은 경우 많이 좋아졌다는 이야기를 주셨습니다. (모두 화이팅!)

음.. 몇가지 더 메모한 것들이 있는데 수첩을 회사에 두고 와서 -_-;; 잘못 된 내용이 있으면 정정해 놓겠습니다;;

일단 여기까지 정리해 보겠습니다.

시각장애인복지관 엘레베이터안 교육일정 안에는 스크린리더 교육도 있었습니다.

국내 시각장애인 분들 중 컴퓨터를 이용하시는 분들은 소수입니다. 그 중에서도 웹에 접속하고 시각장애인 전용 사이트가 아닌 일반 웹을 서핑하시는 분들은 얼마나 될까요? 대략 천여명 안팎일꺼란 이야기들 들었습니다.

'에이. 이 소수의 사람들 때문에 (일명)크로스브라우징 맞추기도 힘든데 우리가 이런 고생을 해야해?' 이런 생각보단

'최소한의 접근성이라도 보장되는 사이트들이 많이 늘어나서, 사이트 이용에 두려움 없이 자유롭게 웹을 이용할 수 있는 환경을 만들어야 겠구나' 란 생각을 해 보는 것은 어떨까 합니다. 웹의 탄생과 기본 배경을 생각해 보는 것도 좋겠죠 ^^

개인 공간이니 사족이 길어졌지만, 모두 힘내서 좀 더 나은 웹을 만들어 봅시다~ 아자