http://www.arko.or.kr 대한 의견 부탁드립니다.
위 사이트는 문화예술의 진흥을 위한 사업과 활동을 지원하기 위해
설립된 한국문화예술위원회 홈페이지로
8~9월중 홈페이지 개편을 계획중에 있습니다.
위 홈페이지에 대한 비판도 좋고
앞으로 이런 홈페이지가 만들어지면 좋겠다는 의견도 좋습니다.
좋은 의견을 남겨주시면 적극 반영하도록 하겠습니다.
예술위원회 홈페이지 개편문의
-
- 해커
- Posts: 1146
- Joined: 2004 01 15 20:06 36
딱 2분 동안 소스와 첫번째 페이지를 들여다 본 결과입니다.
* 시각 장애우용 별도 페이지 제거하기 !!!
* 표준 XHTML과 CSS를 써서 내용, 구조, 표현 방식 분리 : 작년 말/금년 초 KIPA에서 나온 책과 거기에서 언급한 참고 문헌 및 KADO의 한국형 웹 접근성 지침과 그 참고 문헌을 보세요.
* 표준 DOM 사용하기
* (불필요한) 팝업 안 쓰기. (첫 페이지에 가자마자 뜨도록 만들어 놓은 팝업이 불필요한 팝업의 대표적인 보기입니다. 팝업의 유혹에서 벗어나 보세요)
* 모든 페이지를 EUC-KR 대신 UTF-8로 만들기 (특히, 예술 관련 사이트인 점을 감안하고 영어와 일본어판도 있음을 감안하면 더욱. 현재 한국어 페이지는 EUC-KR이고 일본어 페이지는 Shift_JIS임)
* 모든 페이지에 언어 정보를 lang이나 xml:lang으로 표시하기 (HTML tag의 속성으로). 현재는 별 쓸데도 없는 meta tag에만 lang을 붙여 놓았음
* font-family 이름을 'Dotum 돋음'처럼 한글과 로마자로 같이 표기한 것은 잘 한 일이나, generic font family 이름이 빠져 있는데, 넣어야 합니다. 돋음과 굴림, 고딕에 대해서는 sans-serif를, 바탕, 명조 등에 대해서는 'serif'를 맨 끝에 써 주어야 함.
* 영어 페이지에도 font-family에 돋음이나 굴림을 쓰고 있음. 돋음, 굴림, 바탕 등에 들어 있는 로마자 부분은 매우 모양이 좋지 않으므로, 한국어 페이지에서는 쓴다고 해도 영어 페이지에서는 절대 써서는 안 됨.
* flash 사용 자제. 사용하더라도 flash 접근성 지침을 준수할 것
- 메뉴 등 navigation을 위해서 flash 사용하지 않기.
- flash에 들어 있는 글씨 크기가 대체로 너무 작음
* 마찬가지 이유로 메뉴나 링크 등 사이트 탐색을 위한 곳에 image icon (특히, 작은 글씨나 작은 사이즈의) 쓰는 일 자제하기. 꼭 써야 한다면 꼭 alt text 넣기 (웹 접근성 지침 참고)
* HWP 파일만 올리지 말고, PDF로 변환하거나 HTML로 변환한 파일도 같이 올리기. plain text로 내용 전달에 아무 문제가 없는 경우에는 plain text로 올리기
* 파일을 내보낼 때에 Content-Type 제대로 적기 (무조건 application/octet-stream이나 text/plain이 아닌 파일 종류에 맞는 MIME type 적어 내보내기)
* 시각 장애우용 별도 페이지 제거하기 !!!
* 표준 XHTML과 CSS를 써서 내용, 구조, 표현 방식 분리 : 작년 말/금년 초 KIPA에서 나온 책과 거기에서 언급한 참고 문헌 및 KADO의 한국형 웹 접근성 지침과 그 참고 문헌을 보세요.
* 표준 DOM 사용하기
* (불필요한) 팝업 안 쓰기. (첫 페이지에 가자마자 뜨도록 만들어 놓은 팝업이 불필요한 팝업의 대표적인 보기입니다. 팝업의 유혹에서 벗어나 보세요)
* 모든 페이지를 EUC-KR 대신 UTF-8로 만들기 (특히, 예술 관련 사이트인 점을 감안하고 영어와 일본어판도 있음을 감안하면 더욱. 현재 한국어 페이지는 EUC-KR이고 일본어 페이지는 Shift_JIS임)
* 모든 페이지에 언어 정보를 lang이나 xml:lang으로 표시하기 (HTML tag의 속성으로). 현재는 별 쓸데도 없는 meta tag에만 lang을 붙여 놓았음
* font-family 이름을 'Dotum 돋음'처럼 한글과 로마자로 같이 표기한 것은 잘 한 일이나, generic font family 이름이 빠져 있는데, 넣어야 합니다. 돋음과 굴림, 고딕에 대해서는 sans-serif를, 바탕, 명조 등에 대해서는 'serif'를 맨 끝에 써 주어야 함.
* 영어 페이지에도 font-family에 돋음이나 굴림을 쓰고 있음. 돋음, 굴림, 바탕 등에 들어 있는 로마자 부분은 매우 모양이 좋지 않으므로, 한국어 페이지에서는 쓴다고 해도 영어 페이지에서는 절대 써서는 안 됨.
* flash 사용 자제. 사용하더라도 flash 접근성 지침을 준수할 것
- 메뉴 등 navigation을 위해서 flash 사용하지 않기.
- flash에 들어 있는 글씨 크기가 대체로 너무 작음
* 마찬가지 이유로 메뉴나 링크 등 사이트 탐색을 위한 곳에 image icon (특히, 작은 글씨나 작은 사이즈의) 쓰는 일 자제하기. 꼭 써야 한다면 꼭 alt text 넣기 (웹 접근성 지침 참고)
* HWP 파일만 올리지 말고, PDF로 변환하거나 HTML로 변환한 파일도 같이 올리기. plain text로 내용 전달에 아무 문제가 없는 경우에는 plain text로 올리기
* 파일을 내보낼 때에 Content-Type 제대로 적기 (무조건 application/octet-stream이나 text/plain이 아닌 파일 종류에 맞는 MIME type 적어 내보내기)
-
- Posts: 11
- Joined: 2005 11 29 21:48 46
- Contact:
글자는 글자로 해주세요.
소위 웹디자이너라는 분들이 하는 짓 중에 모든 글자를 죄다 포토샵에서 쓰고 잘라다 붙이라고 하는데, 아주 난잡합니다. 여기도 보면 각종 메뉴와 링크에 다 글자를 써놓은 그림을 붙였는데, 그냥 글자로 바꾸는 편이 좋다고 생각합니다.
별다르게 독특한 글꼴을 쓴 것도 아니니까 어차피 보이는 건 같습니다. 정 필요하면 웹폰트를 쓰는 것도 한 방법입니다. 국내에서 웹폰트라고 하면 대부분 익스플로러만 생각하는데 EOT라는 형식만 그러하고, 포맷이 공개되어 다른 데서도 쓸 수 있는 것도 있습니다.
별다르게 독특한 글꼴을 쓴 것도 아니니까 어차피 보이는 건 같습니다. 정 필요하면 웹폰트를 쓰는 것도 한 방법입니다. 국내에서 웹폰트라고 하면 대부분 익스플로러만 생각하는데 EOT라는 형식만 그러하고, 포맷이 공개되어 다른 데서도 쓸 수 있는 것도 있습니다.
-
- 해커
- Posts: 1146
- Joined: 2004 01 15 20:06 36
Re: 글자는 글자로 해주세요.
그림 대신 글자를 쓰는 게 좋다는 데에는 이론의 여지가 없습니다.
웹 폰트를 지원하는 현재 널리 쓰이는 브라우저가 MS IE 말고 있습니까? Netscape 4.x 시절에 지원하던 pfr(?)인지 하는 포맷은 소스 공개 후로 관련 코드의 저작권을 가진 회사와 협의가 잘 안 되었는지 더 이상 지원하지 않습니다. 웹 폰트 지원은 gecko 계열 브라우저의 버그 가운데 아주 오래된 것이지만, 별 해결의 기미가 보이지 않는군요. (기술적 문제도 없지 않지만, 별로 관심이 없어서) 최근에 CSS의 '발명자'라고 할 오페라의 CTO인 'Hakon Wium Lie '가 웹 폰트에 대해 다음과 같이 썼습니다.
http://news.com.com/2010-1032_3-6085417.html
굳이 특정 글꼴을 써야 한다면 웹 폰트를 쓰는 게 (비록 MS IE에서만 그 글꼴이 쓰이더라도) image로 만드는 것보다는 더 나은 방법이라는데 동의합니다. 단, 브라우저의 지원 상황에 대해서는 제가 아는 것과 좀 다른 얘기를 쓰셨군요.kz wrote:정 필요하면 웹폰트를 쓰는 것도 한 방법입니다. 국내에서 웹폰트라고 하면 대부분 익스플로러만 생각하는데 EOT라는 형식만 그러하고, 포맷이 공개되어 다른 데서도 쓸 수 있는 것도 있습니다.
웹 폰트를 지원하는 현재 널리 쓰이는 브라우저가 MS IE 말고 있습니까? Netscape 4.x 시절에 지원하던 pfr(?)인지 하는 포맷은 소스 공개 후로 관련 코드의 저작권을 가진 회사와 협의가 잘 안 되었는지 더 이상 지원하지 않습니다. 웹 폰트 지원은 gecko 계열 브라우저의 버그 가운데 아주 오래된 것이지만, 별 해결의 기미가 보이지 않는군요. (기술적 문제도 없지 않지만, 별로 관심이 없어서) 최근에 CSS의 '발명자'라고 할 오페라의 CTO인 'Hakon Wium Lie '가 웹 폰트에 대해 다음과 같이 썼습니다.
http://news.com.com/2010-1032_3-6085417.html
-
- 서포터즈
- Posts: 83
- Joined: 2006 05 04 02:44 45
- Location: 대전
- Contact:
첨언하여..
1. 문서형은 XHTML 1.0 transitional.dtd 를 권장하며 strict.dtd 사용도 좋으나 숙련자가 필요합니다. strict.dtd 를 사용하는 순간부터는 frame 요소와 target 속성을 사용할 수 없다는 점을 인지하여야 합니다.
2. 태그의 본래 목적대로 사용하고 XHTML 문법을 준수합니다.
레이아웃용 [table] 은 사용하지 않으며 화면을 분할 하려면 [div] 태그를 사용합니다. 메뉴 또는 목록은 [ol][ul][dl] 등의 목록태그를 사용합니다. 시각적인 요소를 장식하기 위하여 아무 의미없는 마크업을 사용하지 않습니다. HTML 페이지에는 문서의 구조를 결정하는 마크업만 작성하고 디자인 표현은 CSS 파일로 완전히 분리 합니다.
Validation 검사를 통과하고 CSS로 디자인 표현을 분리했다고 하여 웹 표준 문서가 되거나 접근성 높은 문서가 되는 것은 아닙니다. Validation 검사는 단지 문법만 검사하기 때문에 시멘틱한 마크업과 접근성 높은 코딩이 되었는지의 여부는 검사하지 않습니다.
3. 각 페이지의 [title] 부분은 각각의 페이지의 제목을 입력합니다.
예)[title]한국문화예술위원회]사업소개]교육프로그램[title]
이것은 검색엔진에게 매우 중요한 키워드로 인식되어 피 검색시 상위에 랭크될 수 있는 기법이며 또한 시각장애인들이 각각의 페이지를 만나면서 가장 처음 듣게되는 문서의 제목 입니다.
4. 제목요소는 [h1]~[h6] 태그로 마크업 합니다.
예1)[h1][img src="logo.gif" alt="한국문화예술위원회"][/h1]
예2)[h2]사업소개[/h2]
예3)[h3]교육프로그램[/h3]
이것 또한 [title] 태그와 마찬가지 이유로 중요합니다. [title] 태그와 [h] 제목태그만 잘 사용하면 구글과 같은 검색엔진에서 상위로 랭크되는 것은 크게 어렵지 않습니다. 물론 시각장애인에게도 도움이 되고 웹 브라우저가 아닌 다른 장치에서 문서의 구조를 쉽게 파악할 수 있는 장점도 있습니다. 최소한 [h] 태그는 있어야 형식을 갖춘 진정한 문서라고 봅니다.
5. 다양한 브라우저간 호환성을 유지합니다.
IE, FF, Opera, Safari 에서 브라우저 호환성이 유지되도록 검토합니다. 각각 브라우저의 이전버전에 대한 호환성 검토가 어려우면 최신버전에 대한 호환이라도 유지합니다.
6. WCAG 1.0 및 KWCAG 1.0 지침을 준수 합니다.
국제 및 국내 웹 접근성 지침을 준수 하면 장애인 뿐만 아니라 일반인들의 사용성이 높아지며 다양한 장치에서 접속하는 소수의 일반인들에게도 도움이 됩니다.
7. 웹 표준 및 접근성 검증
KADO-WAH 또는 W3C 에서 제공하는 Validation Service(HTML, CSS) 를 이용하면 웹 표준 문법의 준수여부는 검증할 수 있습니다. 실무자가 드림위버와 같은 도구를 사용한다면 툴에서 제공하는 Validation 검사기능을 이용할 수도 있는데 이것이 최종 검증 수단이 될 수는 없지만 작업중 수시로 오류문법을 체크할 수 있습니다. 웹 접근성 검증은 WCAG 1.0 및 KWCAG 1.0 항목을 기준으로 얼마나 지켜졌는지 KADO-WAH 도구와 함께 병행하여 사람이 직접 체크해 보는것이 정확 합니다. 예를 들어 [img src="login.gif" alt=""] 이런식으로 alt 속성을 비워놓고 사용하면 문법적인 오류는 드러나지 않지만 접근성은 말짱 꽝이 되기 때문입니다.
2. 태그의 본래 목적대로 사용하고 XHTML 문법을 준수합니다.
레이아웃용 [table] 은 사용하지 않으며 화면을 분할 하려면 [div] 태그를 사용합니다. 메뉴 또는 목록은 [ol][ul][dl] 등의 목록태그를 사용합니다. 시각적인 요소를 장식하기 위하여 아무 의미없는 마크업을 사용하지 않습니다. HTML 페이지에는 문서의 구조를 결정하는 마크업만 작성하고 디자인 표현은 CSS 파일로 완전히 분리 합니다.
Validation 검사를 통과하고 CSS로 디자인 표현을 분리했다고 하여 웹 표준 문서가 되거나 접근성 높은 문서가 되는 것은 아닙니다. Validation 검사는 단지 문법만 검사하기 때문에 시멘틱한 마크업과 접근성 높은 코딩이 되었는지의 여부는 검사하지 않습니다.
3. 각 페이지의 [title] 부분은 각각의 페이지의 제목을 입력합니다.
예)[title]한국문화예술위원회]사업소개]교육프로그램[title]
이것은 검색엔진에게 매우 중요한 키워드로 인식되어 피 검색시 상위에 랭크될 수 있는 기법이며 또한 시각장애인들이 각각의 페이지를 만나면서 가장 처음 듣게되는 문서의 제목 입니다.
4. 제목요소는 [h1]~[h6] 태그로 마크업 합니다.
예1)[h1][img src="logo.gif" alt="한국문화예술위원회"][/h1]
예2)[h2]사업소개[/h2]
예3)[h3]교육프로그램[/h3]
이것 또한 [title] 태그와 마찬가지 이유로 중요합니다. [title] 태그와 [h] 제목태그만 잘 사용하면 구글과 같은 검색엔진에서 상위로 랭크되는 것은 크게 어렵지 않습니다. 물론 시각장애인에게도 도움이 되고 웹 브라우저가 아닌 다른 장치에서 문서의 구조를 쉽게 파악할 수 있는 장점도 있습니다. 최소한 [h] 태그는 있어야 형식을 갖춘 진정한 문서라고 봅니다.
5. 다양한 브라우저간 호환성을 유지합니다.
IE, FF, Opera, Safari 에서 브라우저 호환성이 유지되도록 검토합니다. 각각 브라우저의 이전버전에 대한 호환성 검토가 어려우면 최신버전에 대한 호환이라도 유지합니다.
6. WCAG 1.0 및 KWCAG 1.0 지침을 준수 합니다.
국제 및 국내 웹 접근성 지침을 준수 하면 장애인 뿐만 아니라 일반인들의 사용성이 높아지며 다양한 장치에서 접속하는 소수의 일반인들에게도 도움이 됩니다.
7. 웹 표준 및 접근성 검증
KADO-WAH 또는 W3C 에서 제공하는 Validation Service(HTML, CSS) 를 이용하면 웹 표준 문법의 준수여부는 검증할 수 있습니다. 실무자가 드림위버와 같은 도구를 사용한다면 툴에서 제공하는 Validation 검사기능을 이용할 수도 있는데 이것이 최종 검증 수단이 될 수는 없지만 작업중 수시로 오류문법을 체크할 수 있습니다. 웹 접근성 검증은 WCAG 1.0 및 KWCAG 1.0 항목을 기준으로 얼마나 지켜졌는지 KADO-WAH 도구와 함께 병행하여 사람이 직접 체크해 보는것이 정확 합니다. 예를 들어 [img src="login.gif" alt=""] 이런식으로 alt 속성을 비워놓고 사용하면 문법적인 오류는 드러나지 않지만 접근성은 말짱 꽝이 되기 때문입니다.
Who is online
Users browsing this forum: Ahrefs [Bot] and 5 guests