2007/08/08 13:19
요즘 웹 표준과 웹 접근성에 관심이 많아 지면서 NOSCRIPT 요소 사용을 많이 권장하고 있습니다.
하지만 대부분 NOSCRIPT 요소의 사용을 권장할 뿐, 제대로 사용되고 있는 곳을 보기가 힘드네요.
오히려 무분별한 남용으로 표준을 해치고 있는 경우가 대부분입니다.
제가 지적하고 싶은것은 NOSCRIPT 요소의 사용 범위입니다.
다음은 HTML 4.01의 모든 DTD와 XHTML의 모든 DTD에서 발췌하였습니다.
이렇게 정의 되어져 있습니다.
풀어서 말씀드리자면 NOSCRIPT 요소는 HEAD 요소의 자식 요소는 사용될 수 없는 엘리먼트 입니다.
따라서 HEAD 요소에 NOSCRIPT 요소의 사용은 원칙적으로 표준에서 어긋난 작성법인거죠.
이런 어긋난 방법이 대중화(?)가 되고 있는것은 잘못된 접근성 평가 도구들 때문입니다.
정보통신 접근성 향상 표준화 포럼에서 제공하는 KADO-WAH라는 접근성 평가 도구라든지 후지쯔의 Web Accessibility Inspector의 접근성 평가 도구에서 접근성 평가를 테스트 해본 결과 이러한 반표준을 권하고 있더군요.
테스트 결과에는 언제나 NOSCRIPT 요소의 사용 여부를 수동으로 검사를 해보라는 말뿐이지, 어디에도 HEAD 요소에서는 사용될수 없으며, BODY요소에서는 꼭 사용해야 한다는 안내 문구는 찾아 볼수 없었습니다.
이것은 접근성 평가 도구 자체가 접근성을 전혀 고려 하지 않았고, 오히려 혼란을 야기 시킬 뿐입니다.
아마도 충분한 준비없이 표준과 접근성의 대세에 떠밀려 어쩔수 없이 무분별한 도입을 해야 할 경우 모든 홈페이지는 이러한 도구에 의해서 출판되기 마련일겁니다.
웹 접근성을 사회전반으로 확산, 적용시키려는 노력은 충분히 좋은 흐름이라고 반길만한 것임이 분명합니다.
허나, 기본적인것부터 지켜지지 않는다면 그 노력은 사상누각처럼 언젠가는 허물어질것이고 다시 많은 비용과 시간을 들여야 할것입니다. 우리가 지금 표준과 접근성을 이야기하는 이유도 그 동안 잘못 알고 행하는 것들 때문임을 명심했으면 좋겠습니다.
하지만 대부분 NOSCRIPT 요소의 사용을 권장할 뿐, 제대로 사용되고 있는 곳을 보기가 힘드네요.
오히려 무분별한 남용으로 표준을 해치고 있는 경우가 대부분입니다.
제가 지적하고 싶은것은 NOSCRIPT 요소의 사용 범위입니다.
다음은 HTML 4.01의 모든 DTD와 XHTML의 모든 DTD에서 발췌하였습니다.
<!ENTITY % head.misc "SCRIPT|STYLE|META|LINK|OBJECT" -- repeatable head elements -->
<!ENTITY % head.content "TITLE & ISINDEX? & BASE?">
<!ELEMENT HEAD O O (%head.content;) +(%head.misc;) -- document head -->
<!ENTITY % block
"P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT |
BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS">
<!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) -- document body -->
<!ELEMENT NOSCRIPT - - (%block;)+
-- alternate content container for non script-based rendering -->
<!ATTLIST NOSCRIPT
%attrs; -- %coreattrs, %i18n, %events --
>
<!ENTITY % block
"P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT |
BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS">
이렇게 정의 되어져 있습니다.
풀어서 말씀드리자면 NOSCRIPT 요소는 HEAD 요소의 자식 요소는 사용될 수 없는 엘리먼트 입니다.
따라서 HEAD 요소에 NOSCRIPT 요소의 사용은 원칙적으로 표준에서 어긋난 작성법인거죠.
이런 어긋난 방법이 대중화(?)가 되고 있는것은 잘못된 접근성 평가 도구들 때문입니다.
정보통신 접근성 향상 표준화 포럼에서 제공하는 KADO-WAH라는 접근성 평가 도구라든지 후지쯔의 Web Accessibility Inspector의 접근성 평가 도구에서 접근성 평가를 테스트 해본 결과 이러한 반표준을 권하고 있더군요.
테스트 결과에는 언제나 NOSCRIPT 요소의 사용 여부를 수동으로 검사를 해보라는 말뿐이지, 어디에도 HEAD 요소에서는 사용될수 없으며, BODY요소에서는 꼭 사용해야 한다는 안내 문구는 찾아 볼수 없었습니다.
이것은 접근성 평가 도구 자체가 접근성을 전혀 고려 하지 않았고, 오히려 혼란을 야기 시킬 뿐입니다.
아마도 충분한 준비없이 표준과 접근성의 대세에 떠밀려 어쩔수 없이 무분별한 도입을 해야 할 경우 모든 홈페이지는 이러한 도구에 의해서 출판되기 마련일겁니다.
웹 접근성을 사회전반으로 확산, 적용시키려는 노력은 충분히 좋은 흐름이라고 반길만한 것임이 분명합니다.
허나, 기본적인것부터 지켜지지 않는다면 그 노력은 사상누각처럼 언젠가는 허물어질것이고 다시 많은 비용과 시간을 들여야 할것입니다. 우리가 지금 표준과 접근성을 이야기하는 이유도 그 동안 잘못 알고 행하는 것들 때문임을 명심했으면 좋겠습니다.
|
Tracked from Blog of Hyeonseok | 2009/09/07 23:59 | DEL
플래시 넣는 방법은 정말로 다양합니다. 그중에 제가 오늘 읽은 [웹접근성]Flash의 Object의 접근성(noscript포함)에서는 접근성을 높이면서 플래시를 페이지에 넣는 방법을 고민하고 있습니다. 플... |
2007/08/06 15:02
웹페이지의 상호 호환성(Cross Browsing)을 구축하였다고 반드시 웹표준을 준수 했다고 말할 수 없습니다.
익스플로러, 파이어폭스, 오페라, 사파리 등 여러 브라우저에서 동일한 화면을 보여주는 걸로 웹표준 사이트라고 오해를 하고 있는 분들이 많으시더군요.
웹 표준을 준수하지 않고도 웹페이지의 상호 호환성(Cross Browsing)은 얼마든지 제공 할 수 있습니다.
예를 들어 테이블만으로 레이아웃을 잡고 정확하게 Fixed된 사이즈와 단위를 사용해도 웬만한 브라우저에서 동일한 구성을 보여 줄 수 있습니다.
현재 웹표준 준수는 'W3C에서 권고하는 권고사항을 지키는냐?'입니다.
우리는 목표를 확실하게 설정을 해야 합니다. 웹표준을 준수 하는것이냐?, 웹페이지의 상호 호환성(Cross Browsing)을 구축하는 것이냐?, 아니면 이 두가지를 모두 추구하는 것이냐? 입니다.
웹표준과 접근성을 사회전반으로 확산 시키려면 이러한 개념이 확실하게 정의되어야 합니다.
kwsg.org라는 홈페이지가 있더군요. (저는 이 홈페이지를 누가 운영을 하는 지도 모릅니다. 그리고 비난을 하고자 하는 것도 아니고요.)
위의 문구로 보아 웹표준을 준수한 홈페이지 목록을 제공하는거 같습니다만, 실제 유효성을 체크 해보면 오류가 나지 않는 홈페이지는 몇개 되지 않더군요. 제가 봤을땐 50개의 홈페이지가 있었는데..그중 18개만이 유효성에서 오류가 발생되지 않았습니다. 더 재미있는 것은 공공기관도 몇개 보이던데 그중에 1곳을 제외한 모든 곳이 유효성 체크에서 오류가 났었고, 웹접근성 평자툴을 제작하는 업체의 홈페이지도 있더군요. 이곳도 유효성 체크에서 오류가 났습니다.
제 이야기는 위의 목록을 제공하는 홈페이지나 목록에 올라있는 홈페이지들을 비난하고자 하는것이 아니고요.
웹표준과 접근성에 대해 오해를 하고 계시는 분들이 많습니다. 그래서 kwsg.org가 생겨난 좋은 취지는 좋으나 운영자의 표준에 대한 오해가 그 좋은 취지를 퇴색시키는거 같아 안타까움에 예를 들었습니다.(운영자님 죄송합니다.^^)
월드와이드웹 컨소시엄 홈페이지에서 HTML 유효성 체크와 CSS 유효성 체크를 할 수 있는 서비스가 있습니다. (http://validator.w3.org/, http://jigsaw.w3.org/css-validator/)
현재 웹표준을 준수 했다는 홈페이지들이 도데체 어디서 어떻게 누구에 의해서 어떤기준으로 소문이 나고 여러 블로그에 소개가 되고 있는지...
이야기가 옆 길로 흐르네요...^^;
다시 본론으로 돌아와서
그렇다고 웹표준을 준수 했다고 웹페이지의 상호 호환성(Cross Browsing)이 보장되는 것도 아닙니다.
여기에는 많은 노력이 필요합니다.
브라우저마다 랜더링 방식이 틀리고 html과 css 적용 방식이 조금씩 차이가 나기에 이것들의 성격을 파악해서 많은 조작이 필요합니다.
어쨌든 흔히들 웹표준에 대해서 이야기를 해보면 거의 모든사람이 웹페이지의 상호 호환성(Cross Browsing)을 구축에 대해서 이야기를 할 뿐입니다.
접근성까지 이야기가 확장 되지도 않지요. 표준에 대한 이해도가 떨어지는 상황에서 접근성은 어불성설입니다.
다시한번 말씀 드리지만, 우리는 목표를 확실하게 설정을 해야 합니다. 웹표준을 준수 하는것이냐?, 웹페이지의 상호 호환성(Cross Browsing)을 구축하는 것이냐?, 아니면 이 두가지를 모두 추구하는 것이냐? 입니다.
이것이 또한 접근성의 시작입니다. 우리가 웹 표준과 접근성을 이야기하는것은 결국 '만인은 모든 정보 수집에 평등해야 한다'라는 목표를 향해 한발작 한발작 내딛는거 아닐까요?
익스플로러, 파이어폭스, 오페라, 사파리 등 여러 브라우저에서 동일한 화면을 보여주는 걸로 웹표준 사이트라고 오해를 하고 있는 분들이 많으시더군요.
웹 표준을 준수하지 않고도 웹페이지의 상호 호환성(Cross Browsing)은 얼마든지 제공 할 수 있습니다.
예를 들어 테이블만으로 레이아웃을 잡고 정확하게 Fixed된 사이즈와 단위를 사용해도 웬만한 브라우저에서 동일한 구성을 보여 줄 수 있습니다.
현재 웹표준 준수는 'W3C에서 권고하는 권고사항을 지키는냐?'입니다.
우리는 목표를 확실하게 설정을 해야 합니다. 웹표준을 준수 하는것이냐?, 웹페이지의 상호 호환성(Cross Browsing)을 구축하는 것이냐?, 아니면 이 두가지를 모두 추구하는 것이냐? 입니다.
웹표준과 접근성을 사회전반으로 확산 시키려면 이러한 개념이 확실하게 정의되어야 합니다.
kwsg.org라는 홈페이지가 있더군요. (저는 이 홈페이지를 누가 운영을 하는 지도 모릅니다. 그리고 비난을 하고자 하는 것도 아니고요.)
사이트 추천
누구나 자유롭게 사이트를 추천 할 수 있습니다.
한국어 사이트 또는 한국에서 만들고 웹표준을 수용하여 제작된 사이트를 대상으로 합니다.
추천 후 관리자의 승인을 거쳐서 등록 됩니다.
위의 문구로 보아 웹표준을 준수한 홈페이지 목록을 제공하는거 같습니다만, 실제 유효성을 체크 해보면 오류가 나지 않는 홈페이지는 몇개 되지 않더군요. 제가 봤을땐 50개의 홈페이지가 있었는데..그중 18개만이 유효성에서 오류가 발생되지 않았습니다. 더 재미있는 것은 공공기관도 몇개 보이던데 그중에 1곳을 제외한 모든 곳이 유효성 체크에서 오류가 났었고, 웹접근성 평자툴을 제작하는 업체의 홈페이지도 있더군요. 이곳도 유효성 체크에서 오류가 났습니다.
제 이야기는 위의 목록을 제공하는 홈페이지나 목록에 올라있는 홈페이지들을 비난하고자 하는것이 아니고요.
웹표준과 접근성에 대해 오해를 하고 계시는 분들이 많습니다. 그래서 kwsg.org가 생겨난 좋은 취지는 좋으나 운영자의 표준에 대한 오해가 그 좋은 취지를 퇴색시키는거 같아 안타까움에 예를 들었습니다.(운영자님 죄송합니다.^^)
월드와이드웹 컨소시엄 홈페이지에서 HTML 유효성 체크와 CSS 유효성 체크를 할 수 있는 서비스가 있습니다. (http://validator.w3.org/, http://jigsaw.w3.org/css-validator/)
현재 웹표준을 준수 했다는 홈페이지들이 도데체 어디서 어떻게 누구에 의해서 어떤기준으로 소문이 나고 여러 블로그에 소개가 되고 있는지...
이야기가 옆 길로 흐르네요...^^;
다시 본론으로 돌아와서
그렇다고 웹표준을 준수 했다고 웹페이지의 상호 호환성(Cross Browsing)이 보장되는 것도 아닙니다.
여기에는 많은 노력이 필요합니다.
브라우저마다 랜더링 방식이 틀리고 html과 css 적용 방식이 조금씩 차이가 나기에 이것들의 성격을 파악해서 많은 조작이 필요합니다.
어쨌든 흔히들 웹표준에 대해서 이야기를 해보면 거의 모든사람이 웹페이지의 상호 호환성(Cross Browsing)을 구축에 대해서 이야기를 할 뿐입니다.
접근성까지 이야기가 확장 되지도 않지요. 표준에 대한 이해도가 떨어지는 상황에서 접근성은 어불성설입니다.
다시한번 말씀 드리지만, 우리는 목표를 확실하게 설정을 해야 합니다. 웹표준을 준수 하는것이냐?, 웹페이지의 상호 호환성(Cross Browsing)을 구축하는 것이냐?, 아니면 이 두가지를 모두 추구하는 것이냐? 입니다.
이것이 또한 접근성의 시작입니다. 우리가 웹 표준과 접근성을 이야기하는것은 결국 '만인은 모든 정보 수집에 평등해야 한다'라는 목표를 향해 한발작 한발작 내딛는거 아닐까요?
2007/07/29 00:32
이 글은 http://designe.x-y.net/tt/tag/exeCcommand에서 일부를 그대로 옮겨 왔습니다.
2D-Position 항상 드래그로 위치된 엘레멘트의 이동시킬 수 있다.
AbsolutePosition 엘레멘트의 위치(position)를 절대위치(absolute)로 설정한다.
BackColor 현재 선택의 배경색을 지정하거나 반환한다.
Bold 현재의 선책을 굵은 글자(bold)나 굵지않은 글자로 전환한다.
ClearAuthenticationCache 캐쉬(cache)의 모든 내용을 지운다. execCommand에서만 사용이 가능하다.
Copy 현재의 선택한 내용을 클립보드로 복사한다.
CreateBookmark 현재 선택이나 삽입 포인트의 anchor 혹은 북마크의 상대 이름 앤커로 북파크(bookmark)를 생성한다.
CreateLink 현재 선택에 주소 연결(hyperlink)을 삽입하거나, 주소를 입력하여 삽입할 수 있는 대화창을 열어준다.
Cut 현재의 선택한 내용을 클립보드로 복사하고 선택 내용을 지운다.
Delete 현재 선택을 삭제한다.
FontName 현재 선택의 글꼴을 지정하거나 반환한다.
FontSize 현재 선택의 글꼴 크기를 지정하거나 반환한다.
ForeColor 현재 선택의 글꼴 색상(foreground)을 지정하거나 반환한다.
FormatBlock 현재 블럭의 태그를 설정한다.
Indent 현재 선택 문자를 한 증가분 만큼 뒤로 들여쓰기 한다.
InsertButton 사용자나 메서드에 의하여 선택된 단추(button)의 보이는 내용을 삽입한다. selection 개체 createRange 메서드를 사용하여 선택한 문자를 반환하거나 설정할 수 있다.
InsertFieldset 문자 선택(text selection)의 박스를 삽입한다.
InsertHorizontalRule 문자 선택(text selection)의 수평선(HR)을 합입한다.
InsertIFrame 문자 선택(text selection)의 인라인 프레임(IFRAME)을 삽입한다.
InsertImage 문자 선택(text selection)의 이미지(IMAGE)를 삽입한다.
InsertInputButton 문자 선택(text selection)의 단추(BUTTON)를 삽입한다.
InsertInputCheckbox 문자 선택(text selection)의 체크박스(CHECKBOX)를 삽입한다.
InsertInputFileUpload 문자 선택(text selection)의 파일업로드(FileUpload)를 삽입한다.
InsertInputHidden 문자 선택(text selection)의 감춘단추(HIDDEN)를 삽입한다.
InsertInputImage 문자 선택(text selection)의 이미지(IMAGE) 제어를 덮어씌우기한다.
InsertInputPassword 문자 선택(text selection)의 암호(PASSWORD) 제어를 덮어씌우기한다.
InsertInputRadio 문자 선택(text selection)의 레디오단추(RADIO) 제어를 덮어씌우기한다.
InsertInputReset 문자 선택(text selection)의 재설정(RESET) 제어를 덮어씌우기한다.
InsertInputSubmit 문자 선택(text selection)의 송신(SUBMIT) 제어를 덮어씌우기한다.
InsertInputText 문자 선택(text selection)의 문자열입력(TEXT) 제어를 덮어씌우기한다..
InsertMarquee 문자 선택(text selection)의 빈 마퀴(MARQUEE)를 덮어씌우기한다..
InsertOrderedList 문자 선택(text selection)의 번호있는 목록(OL)과 보통 블럭간의 전환을 한다.
InsertParagraph 문자 선택(text selection)의 줄바꿈(BR)을 덮어씌우기한다.
InsertSelectDropdown 문자 선택(text selection)의 드롭다운 제어를 덮어씌우기한다.
InsertSelectListbox 문자 선택(text selection)의 목록박스 선택 제어를 덮어씌우기한다.
InsertTextArea 문자 선택(text selection)의 여러 줄 텍스트 입력 제어를 덮어씌운다..
InsertUnorderedList 문자 선택(text selection)을 번호있는 목록과 일반 블럭 양식을 서로 교차시킨다.
Italic 문자 선택(text selection)에서 이태릭(italic) 문자와 보통 문자간 전환한다.
JustifyCenter 문자 선택(text selection)이 위치한 불럭에서 중앙에 위치시킨다.
JustifyLeft 문자 선택(text selection)이 위치한 불럭에서 왼똑에 위치시킨다.
JustifyRight 문자 선택(text selection)이 위치한 불럭에서 오른쪽에 위치시킨다.
LiveResize 위치 변경과 크기 변경에 따라 업데이트 뿐 아니라, 과정 중 계속적으로 모양을 유지위하기 업데이트를 한다.
MultipleSelection 예를 들어 편집기의 이미지와 제어를 하나의 엘레멘트처럼, 한개 이상의 엘레멘트를 선택할 수 있게 허용한다. 지명적이거나 암시적으로 속성이 지정된 엘레멘트는 한번에 SHIFT 나 CTRL로 선택될 수 있다.
Outdent 문자 선택(text selection)의 현위치에서 들어쓰기 한 증가분 만큼 왼쪽으로 내어쓰기 한다.
OverWrite 문자 입력 방식과 덮어쒸우기 방식 사이를 전환한다.
Paste 문자 선택(text selection)을 클립보드 내용으로 덮어씌우기 한다.
Print 사용자가 편재의 문서를 인쇄할 수 있도록 인쇄 대화상자를 열어 준다.
Refresh 현재의 문서를 새로고침 한다..
RemoveFormat 현재 선택 문자로 부터 태그들을 제거한다.
SaveAs 현재의 문서를 파일로 저장한다.
SelectAll 전체 문서를 선택한다.
UnBookmark 현재의 선택으로부터 북마크의 어떤 내용을 삭제한다.
Underline 현재 선택 문자에서 밑줄 그어진 부분과 밑줄 없는 부분 사이를 전환한다.
Unlink 현재 선택 문자에서 모든 연결을 삭제한다.
Unselect 현재 선택 문자을 취소한다.
2007/07/21 13:00
이슈:
텍스트가 아닌 콘텐츠에는 모두 데체 텍스트가 제공되어야 한다.
체크리스트:
텍스트가 아닌 콘텐츠에 대해서는 대체 텍스트를 제공하고 있는가?
적용예제:
이미지 태그에 대체 텍스트 적용하기
- 텍스트를 이미지로 만들어 사용할 경우
- 이미지에 나타나는 텍스트를 img 요소의 alt 속성의 값으로 사용한다.



