티스토리 툴바

출처 : http://jhyun.wordpress.com/2010/11/10/2010%EB%85%84-%EC%9B%B9-%EC%A0%91%EA%B7%BC%EC%84%B1%EC%97%90-%EB%8C%80%ED%95%9C-%EC%98%A4%ED%95%B4myth-456-berea-%EA%B8%80-%EC%9A%94%EC%95%BD/


웹 표준, 접근성에 대한 좋은 글이 올라오는 456 Berea Street에 2010년 접근성 오해(Accessibility myths in 2010)라는 좋은 글이 올라왔습니다.

웹 접근성에 대한 관심이 높아짐에 따라 이에 대한 오해도 더 증폭되는 것 같습니다. 제가 이전에 WEBAIM(Web Accessibility in Mind)에서 발표한 미국 장애인 법과 웹(웹 접근성 관심사와 오해) – WEBAIM 발표자료 일부 번역도 참고하시면 도움이 되실 것이라 생각됩니다.

저자가 2005년 5월에 발표한 웹 접근성 오해(Accessibility myths and misconceptions)에 나타난 5가지 주요한 오해입니다.

    1. 웹 접근성은 시각장애인만을 위한 것이에요(Accessibility is just for blind people)

웹 접근성은 시각장애인만을 위한 것은 아닙니다. 다만 신체적인 제약으로 인해 가장 어려움이 있는 계층의 하나가 시각장애인이기 때문에 이러한 오해가 생기는 것 같습니다.

웹 접근성은 시각장애인뿐만 아니라 청각장애인, 지체장애인 등 다양한 장애인이 함께 이용할 수 있도록 최소한의 기준을 만련한 것이라 이해하시면 좋을 것 같습니다. 이를 위해서는 W3C 웹 접근성 이니셔티브에서 발표한 “장애인이 웹을 사용하는 방법”이 한국어로 번역이 되어 있으니 이를 참고하시면 좋을 것 같습니다.

It’s about respecting different peoples’ different needs and personal preferences. Not everybody uses the web in the same way, with the same equipment.

다양한 사람, 다양한 요구와 다양한 방법이 있다는 것을 이해하는 것이 중요할 것으로 생각됩니다. 보다 많은 사람을 고민하면 할 수록 더 멋진 사이트를 만들 수 있을 것 같습니다.

    2. 웹 접근성을 준수하면 멋 없고 지루한 웹 사이트가 되요(Accessible websites are ugly and boring)

웹 접근성에서 이미지나 동영상 또는 신기술을 활용한 인터페이스 등을 제공하지 말라는 것은 아닙니다. 새로운 기술을 활용하여 보다 좋은 경험을 사용자에게 제공하는 것은 언제나 추천되어야 할 것입니다.

이러한 이미지나 동영상 등을 제공할 경우 대체할 수 있는 수단, 즉 이미지에 대한 대체 텍스트, 동영상에 대한 자막 등을 고민해 달라는 것이 접근성입니다. 다양한 방법으로 다양한 사용자가 콘텐츠를 동등하게 인식하고, 운용할 수 있도록 제공하는 최소한의 기준이라고 이해해 주시면 좋을 것으로 생각됩니다.

Accessibility does not mean removing all colour and graphics. What it does mean is thinking about how colour is used and providing alternative content for images and other graphical objects that are informational or functional.
Ugly or not – no matter what a website looks like, in most cases the content is what’s most important.

저자가 말했듯이 접근성을 하기 위해 색상이나 그래픽적 요소를 모두 제거하라는 것이 아닙니다. 또한 멋진 말인데 보이는 것보다도 무엇을 제공하는 지, 즉 우리의 콘텐츠가 무엇인지를 고민해 볼 필요가 있다는 지적은 정말 가슴에 와 닿습니다.

또 오해하시는 분이 있으실 것 같아 적지만 보이는 것(표현)을 잘 만드는 것은 반드시 필요한 작업입니다. 하지만 보이는 것에 대한 관심 처럼 우리가 무엇을 제공하는지에도 더 많은 고민이 필요한 시점이라 생각합니다.

    3. 웹 접근성을 준수할려면 비용이 많이 들고 어려워요(Accessibility is expensive and difficult)

웹 접근성이 준수되지 않은 큰 사이트를 수정하고 고치기 위해서는 비용이 들고 어려운 일이 많을 것이라 생각됩니다. 하지만 중요한 것은 새로운 개편 작업시, 새로운 사이트를 만들 경우에 기획 단계부터 접근성을 고민하고 만들면 큰 비용이 들지는 않으실 것입니다.

더욱 중요한 것은 접근성을 준수하게 되면 장기적으로는 운영비용을 절감할 수 있다는 것입니다. W3C 웹 접근성 이니셔티브에서 발표한 “기관을 위한 웹 접근성 비즈니스 사례 개발 시 재정적 요인”의 한국어 번역본을 참고하시기 바랍니다.

Retrofitting full accessibility into a large and completely inaccessible website can in some cases be difficult, expensive, and take a long time, that much is true. But if you know how accessibility works and do things the right way from the beginning, the costs involved are very much negligible. Plus you greatly reduce the risk of having to rebuild the site after a couple of years, either because of changes in browser technology or because legislation requires it.

Building an accessible website will save you money in the long run.

    4. 텍스트 전용 페이지를 제공하면 충분해요(Offering a text-only version is good enough)

텍스트 전용 페이지, 시각장애인 전용 페이지, oo 전용 페이지만으로 접근성을 해결하기는 어렵다는 것입니다. 텍스트 전용 페이지를 제공하게 되면 기존 웹 사이트(main websites)에서 제공하는 정보와 기능을 모두 제공 받지 못하는 경우도 발생하며, 기존 웹 사이트와 텍스트 전용 페이지로 인해 검색엔진 등 기계가 접근할 때 콘텐츠 중복에 따른 문제가 발생할 우려가 있으며, 비장애인과 장애인을 구분하는 우를 범하는 것이 되는 등의 문제가 발생한다는 것입니다.

중요한 것은 하나의 웹(One web)으로 문제를 해결해야 한다는 것입니다.

Text-only versions are not a good idea, for several reasons:
* They often lack information and functionality that the main website has.
* They cause problems with search engines since content is duplicated – which version should people coming to the site from search engines get?
* Text-only versions segregate their intended audience – people with disabilities.
* It can be difficult to find the link to the text-only version.
* There is no guarantee that the text-only version is accessible.

    5. 장애인 고객 맞춤 및 음성 서비스 등을 제공하면 웹 접근성을 준수한 것이에요(Customisation and read-aloud functionality make a site accessible)

장애인이 보다 편리하게 보기 위해 웹 페이지에 확대기능 제공, 웹 페이지를 방문하게 되면 음성으로 서비스를 제공한다든지 등 다양한 기능을 부가할 수 있을 것입니다. 이는 장애인을 위해 좋은 것입니다. 하지만 이러한 기능과 서비스가 있다고 접근성을 준수한다는 것은 아닙니다.

저자가 밝혔듯이 이러한 서비스 옵션은 좋은 것입니다. 하지만 중요한 것은 웹 사이트의 접근성을 높이는 것이 우선적이며, 이러한 작업들은 부가적인 것이라는 것입니다. 주인과 객이 혼동되지 않아야 할 것 같습니다. 중요한 것은 하나의 웹을 접근성 있게 표준에 맞추어 작업하는 것이 중요하다는 것입니다.

Offering customisation options is not a bad thing to do. On the contrary – it is a very good thing. But it isn’t the first thing to do when a improving a site’s accessibility. It’s better to make sure the site has a solid and sound foundation to build on.

아래의 내용은 Ian Pouncey라는 분이 2010년 1월에 올린 “Web accessibility myths”의 내용입니다.

    6. 웹 표준 문법 준수를 하면 웹 접근성이 해결된다(Validation equals accessibility)

HTML, CSS 등의 문법 준수는 중요합니다. 이러한 문법 준수는 웹 사이트를 보다 사용성 있게하고 접근성을 높이며 견고하게 하는데 도움을 줄 것입니다. 하지만 문법을 준수하였다고 접근성이 모두 보장 되는 것은 아닙니다.

일례로 웹 접근성의 가장 대표적인 지침인 이미지에 대한 대체 텍스트 제공시에도 중요한 것은 무의미한 정보를 제공하는 것이 아니라 이미지와 동등한 정보를 사용자가 인식할 수 있도록 대체 텍스트를 제공하는 것이기 때문입니다.

문법 준수는 단지 대체 텍스트가 있다, 없다만을 평가할 수 있지 제대로 대체 텍스트를 제공하는 지를 평가할 수 없기 때문입니다. 현재까지 상용화된 웹 접근성 평가 도구 통과만으로 접근성 준수 여부를 평가할 수 없는 것도 바로 이 때문입니다.

Good markup is the foundation of a usable, accessible and robust website. (중략) But this is not the same as accessibility, validators do not check that alt attributes are relevant, or that link text is useful.

    7. 스크린리더에서 웹 콘텐츠가 읽히면 웹 접근성이 준수된 것이다(If it works with a screen reader it is accessible)

시각장애인만이 웹 접근성의 대상이 아니다라는 것과 일맥 상통한 것입니다. 전맹 또는 저시력자 등이 사용하는 스크린 리더에서 콘텐츠를 인식할 수 있다, 없다가 접근성의 전부가 아니라는 것입니다. 시각장애인, 스크린리더에만 초점을 맞추면 다른 많은 장애인 등의 사용자를 놓칠 수 있기 때문입니다.

모든 장애인, 사용자 등에 대한 고민이 어려우시다면, 웹 접근성 표준을 준수하는 것이 가장 쉬운 방법일 것입니다.

I think the majority of developers and their clients have got passed the idea that visual impaired people do not use the web, however there is so much focus on screen reader users that it is easy to forget that there are other groups of users that we need to make the web accessible for.

    8. 웹 사이트가 접근성이 있거나 없거나 둘 중의 하나다(Sites are either accessible or inaccessible)

웹 접근성은 다소 주관적일 수 있다라고 저자는 밝히고 있습니다. 이에 접근성이 있다, 없다를 검은색이냐 또는 하얀색이냐 처럼 명백하게 구분할 수 없다는 것이지요. 접근성이 비판을 받는 가장 큰 이유 중 하나일 것입니다. 전문가마다 의견이 다르다는 것이지요. 도데체 어떤 기준이 맞다는 것인지 잘 모르겠다 등의 비판을 하십니다.

본 의견에는 조금은 동의하기 어려운 부문은 있습니다. 최소한의 기준이라고 마련된 표준은 있으니깐 말입니다. W3C 등 표준에서 제기하고 있는 것을 우선적으로 지키는 작업이 필요할 것입니다.

또한 저자가 말한 것처럼 항상 웹 사이트에는 웹 접근성 표준을 준수하였다고 하지만 개선이 필요한 사항이 있다는 것입니다. 사용자에게 더 묻고 더 좋은 서비스를 조금씩 개선하는 작업이 중요하다는 저자의 의견에는 크게 동감합니다.

Accessibility is very subjective .. (중략) The point is that there is almost always room for improvement, and that it is worthwhile making small changes that improve the user experience for only a small number of people – every little bit helps.

    9. 웹 접근성이 100% 준수되지 않으면 공개해서는 안된다(Content that isn’t 100% accessible shouldn’t be published)

접근성이 개선되는 것이 중요한 것이 사실이지만, 100% 모든 지침을 준수하지 않는다고 서비스를 하지 않는 것은 바람직하지 않다는 것입니다. 저도 공감합니다.

다만 웹 접근성 제고를 위해 기관에서 충분한 노력을 하였는지는 고민할 필요가 있을 것 같습니다. 처음부터 모든 것을 할 수는 없을지라도 지침을 정독하고 지침의 배경을 이해하면서 개발하면 지키지 못할 것도 없을 것이라 믿습니다. 중요한 것은 다양한 사용자가 있다는 것을 이해하는 것이 무엇보다 중요할 것이라 생각합니다.

There is a growing trend of criticising any content that isn’t accessible to everyone, and this is counter-productive. The web has thrived and become what it is today because it is easy to publish to, by almost everyone. We might hope for more accessible content on the web but we must not discourage publishers, for example while there is no doubt that captioning of YouTube videos is a great boon to many people I would not like to see the pressure to caption put anyone off uploading a new video. (중략) I believe that open content that is inaccessible to 50% of people is better than content that is never published. Ideally it is published with a license that allows others to take it and convert it to different forms which may be accessible, but this isn’t possible if it only exists in a file on someone’s desktop.

아래 부문은 2010년의 웹 접근성 오해에 추가된 부문입니다.

    10. 자바스크립트 없이도 작동하면 접근성을 준수한 것이다(If it works without JavaScript it’s accessible)

겸손한 자바스크립트(unobtrusive javascript) 구현이 중요하지만, 이것만으로 모든 접근성 문제가 해결되는 것은 아니라는 것입니다. 키보드 접근성 등을 함께 고민해야 한다는 것입니다. 결론적으로 접근성 지침을 고민하여 스크립트를 이용해야 한다는 것입니다.

현재 국내에서는 자바스크립트에 대해 많은 잘못된 오해가 있는 것 같습니다. 접근성을 위해서는 자바스크립트를 쓰지 않아야 한다, 자바스크립트를 끄고 모든 동작이 이루어져야 한다는 등의 오해가 널리 퍼져 있습니다.

접근성에서 말하는 것은 자바스크립트를 보다 견고하게 사용할 필요가 있다는 것입니다. 다양한 사용자 환경 등을 고민해서 스크립트를 이용할 필요가 있다는 것입니다. 적절한 낮춤(Graceful Degradation), 점진적 향상(Progressive Enhancement), 겸손한 구현(Unobtrusive)을 이해한 스크립트 이용이 필요하다는 것입니다.

자바스크립트에 관해서는 웹 접근성 연구소의 “접근성 있는 JavaScript 제작기법”과 신현석님의 “접근성을 해치지 않는 자바스크립트 활용”

And since accessibility is not just about screen readers, you also have to consider keyboard accessibility in your scripting.

Unobtrusive JavaScript is great, but it does not guarantee accessibility.

    11. title 속성이 웹 접근성이 좋은 것이다(The title attribute is good for accessibility)

HTML의 많은 요소에 title 속성을 활용하여 부가적인 정보를 제공할 수 있기 때문에 title를 사용하면 접근성이 높아진다고 오해하는 사람이 있는데, 이는 사실이 아니다.

title의 경우 스크린리더를 이용하는 사용자의 경우에도 설정을 변경하지 않으면 title 정보를 무시할 수 있으며, 이미지에 대한 title을 제공할 경우 발생하는 툴 팁도 마우스 사용자의 경우에 2-3초 정도 짧게 보여주며, 키보드 사용자에게는 무용지물이라는 것이다.

적절한 title 제공은 필요하겠으나 title 속성만을 맹신하는 것은 바람직하지 않다는 것이다.

You can use the title attribute to add “advisory information” to almost any HTML element. It sounds like a good idea at first, but there are a couple of rather serious drawbacks.

* title attributes are mostly ignored by screen readers unless the user has changed their configuration
* The content of title attributes is generally displayed as a tooltip in graphical browsers, but only after the mouse cursor has hovered over the element for a second or two. It is not displayed to keyboard users.

저작자 표시 비영리 동일 조건 변경 허락


이전에 한번 한적 있는데 다시 하네요
후원도 있고
관심있는분들 참여하시고 상품도 받아보세요~

ㄱㄱ싱~
http://www.wah.or.kr/campaign/
저작자 표시 비영리 동일 조건 변경 허락

<a href="주소" onclick="스크립트;return false;">
저작자 표시 비영리 동일 조건 변경 허락

웹사이트에서 자체적으로 접근키를 제공하는 것은 웹 브라우저를 포함한 다양한 사용자 도구의 단축키와 항상 충돌할 가능성을 내포하고 있습니다. 하지만 이러한 충돌 가능성을 예측하여 피하도록 하고 핵심 UI에 직접 키보드로 접근할 수 있는 접근키를 제공하는 것은 키보드를 선호하거나 또는 키보드 밖에 사용할 수 없는 사용자에게 도움이 됩니다.

접근키를 지원하는 요소들

  • a
  • area
  • button
  • input
  • label
  • legend
  • textarea

접근키 적용 문법 예

<input type="text" name="search" id="search" title="검색어입력" accesskey="S" />
<input type="text" name="uid" id="uid" title="로그인ID" accesskey="L" />

운영체제 및 웹 브라우저 벤더별 접근키 조합법

아래 표에서 브라우저 버전을 명시하지 않은 이유는 버전별로 접근키에 차이가 존재하지 않기 때문 입니다.

운영체제 웹 브라우저 접근키 조합
Win Internet Explorer Alt + Accesskey
Firefox Alt + Shift + Accesskey
Opera Shift + Esc + Accesskey
Safari Alt + Accesskey
Mac Firefox Ctrl + Accesskey
Safari Ctrl + Accesskey
Opera Shift + Esc + Accesskey

접근키 테스트 셋

아래 버튼에는 표시된 텍스트와 동일한 접근키가 지정되어 있습니다. 여러분의 다양한 운영체제와 브라우저로 접근키 사용 테스트를 시도할 수 있습니다.




웹 브라우징 도구의 단축키와 웹 사이트에서 제공하는 접근키가 충돌하는 경우

웹 사이트에서 제공하는 접근키와 웹 브라우징 도구(스크린리더 포함)의 단축키가 충돌하는 경우 보통 웹 사이트에서 제공하는 접근키가 우선권을 지니게 됩니다. 따라서 겹치도록 설정되어 있다 하더라도 사실상 충돌하지는 않습니다. 하지만 겹치는 설정은 피해야 합니다. 이들이 겹치는 상황에서 사용자가 웹 브라우징 도구의 단축키를 시도하는 경우 의도하지 않았던 상황(웹 사이트 접근키가 실행되는)이 발생하기 때문에 바람직 하지 않습니다.

웹 브라우징 도구의 단축키와 웹 사이트에서 제공하는 접근키가 겹치는 실제 사례

웹 브라우징 도구에서 제공하는 단축키 조합법과 웹 사이트의 접근키 조합법이 다르면 겹치지 않습니다. 대부분의 경우 이 두 가지 경우의 조합법이 서로 다르지만 웹 사이트의 접근키에 'Alt+?' 조합을 사용하는 웹 브라우징 도구의 경우에는 웹 브라우징 도구 자체에 할당된 단축키 조합 'Alt+?' 과 겹칠 수 있습니다. Win + Internet Explorer, Win + Safari 인 경우 웹 사이트 접근키 조합으로 'Alt+?' 형식을 사용하고 있어서 겹칠 수 있는 경우에 해당 됩니다. 아래는 웹 사이트 접근키와 겹칠 수 있는 웹 브라우징 장치의 단축키 목록 이므로 피하도록 합니다. 한편 이 두 설정이 겹치는 경우임에도 불구하고 웹 브라우징 장치의 단축키를 쓰려면 Alt 키와 조합키를 동시에 누르지 않고 순차적으로 따로 누르는 방법으로 브라우징 장치의 단축키를 사용할 수 있게 됩니다. 단, 스크린리더 장치와 기타 장치들은 그렇지 않습니다.

User Agent / Keyboard Shortcut alt+A alt+B alt+D alt+E alt+F alt+G alt+H alt+I alt+N alt+T alt+V alt+W alt+Z alt+\ alt+= alt+*
Web Browser Win + IE 5~6 Favorites     Edit File   Help     Tools View          
Win + IE 7 Favorites   주소표시줄 Edit File   Help     Tools View       접근키 미지원  
Win + Safari   Bookmarks   Edit File   Help History     View Window        
Screen Reader Win + IE + Sense Reader                         읽기모드 화면 재구성   위치기억목록
Etc Win + IE + Naver Toolbar                 툴바 검색창              
Win + IE + Google Toolbar           툴바 검색창                    

Daum, Yahoo 툴바를 함께 조사하였습니다. Daum 툴바는 툴바 검색창 단축키로 Alt+S, Alt+N 을 사용중 입니다. Yahoo 툴바는 툴바 검색창 단축키로 Alt+S 를 사용중 입니다. 그러나 Daum과 Yahoo는 웹 사이트에 이와 겹치는 접근키가 존재하는 경우 웹 사이트가 제공하는 접근키가 우선 적용될 수 있도록 존중하고 있어서 겹치는 사례에 포함시키지 않았습니다.

웹 브라우징 도구와 겹치지 않는 안전한 접근키

아래 제시된 키들은 2008년 현재 대중적인 웹 브라우징 도구에서 제공하는 단축키와 겹치지 않아서 사용하기에 안전한 것으로 판단되는 권장 접근키 목록 입니다.

Alphabet Key C J K L M O P Q R S U X Y
Numeral Key 1 2 3 4 5 6 7 8 9 0      
Etc Key ` - [ ] ; ' , . /        

현 서비스에 적용중인 접근키 조합

현재 네이버 서비스에는 아래와 같은 접근키가 제공되고 있습니다. 현존하는 대중적인 웹 브라우징 도구의 단축키와 겹치지 않는 설정이며 핵심 UI로 직접 접근하는 것을 돕습니다. 이 밖에 더 많은 접근키를 제공하기 위하여 검토중 입니다. 서비스의 핵심 UI를 선별하고 가능하다면 그 의미에 맞는 두문자어를 선택하여 사용할 것입니다. 되도록 네이버 뿐만 아니라 다른 보편적인 웹사이트에 적용하더라도 유용한 접근키 목록을 만들 수 있도록 노력할 것입니다. 이러한 접근키 목록이 공식적인 표준안 등으로 국내 또는 국제사회에서 명문화 되지는 않겠지만 서로 다른 웹 사이트에서 이것을 일관성 있게 제공한다면 긍정적인 사용자 경험을 만들어 낼 것이기 때문입니다.

서비스 접근 키 접근 키 의미
네이버 검색창 S Search
로그인 L Login


출처 : http://html.nhndesign.com/accessibility_accesskey (nhn 웹표준 블로그)
저작자 표시 비영리 동일 조건 변경 허락

'Web story > 웹표준' 카테고리의 다른 글

웹접근성 지지 캠페인  (0) 2009/10/28
슈도프로토콜 대체  (0) 2009/06/02
키보드 접근키  (0) 2009/05/26
웹 접근성을 고려한 신기술 콘텐츠 제작기법  (0) 2009/05/25
웹 접근성 향상을 위한 국가표준 가이드  (0) 2009/05/25
특수문자 코드표  (0) 2009/05/21

다양한 정보들이 많네요
유용한 정보가 되겠습니다

http://www.iabf.or.kr/Pds/ReportView.asp?board=report&pg=1&bseq=2867&md=&sf=&ss=

저작자 표시 비영리 동일 조건 변경 허락



pdf 파일입니다~
저작자 표시 비영리 동일 조건 변경 허락

특수문자

  • Entity 코드로 표현된 특수문자는 대부분의 브라우저에서 문제없이 출력된다.
  • 꺽쇠기호 < > 등을 Entity로 처리하지 않는 경우 브라우저들은 이것을 HTML 태그의 시작이나 끝으로 인식할 수 있다.
  • 따옴표 " "는 HTML 속성의 값이 시작되거나 끝난 것으로 인식할 수 있다.
  • & 기호는 Entity기호의 시작으로 오인될 수 있다.
  • 가장 흔한 실수 : URL에 포함된 & 기호를 Entity로 변환하지 않는 경우이며 특히 웹에디터에서 입력되는 특수문자 등은 Entity 코드로 치환되어야 한다.

HTML Latin-1 Character Entities Reference

ASCII Entities with Entity Names
Result Description Entity Name Entity Number
" quotation mark &quot; &#34;
' apostrophe  &apos; (does not work in IE) &#39;
& ampersand &amp; &#38;
< less-than &lt; &#60;
> greater-than &gt; &#62;

ISO 8859-1 Symbol Entities
Result Description Entity Name Entity Number
  non-breaking space &nbsp; &#160;
¡ inverted exclamation mark &iexcl; &#161;
¢ cent &cent; &#162;
£ pound &pound; &#163;
¤ currency &curren; &#164;
¥ yen &yen; &#165;
¦ broken vertical bar &brvbar; &#166;
§ section &sect; &#167;
¨ spacing diaeresis &uml; &#168;
© copyright &copy; &#169;
ª feminine ordinal indicator &ordf; &#170;
« angle quotation mark (left) &laquo; &#171;
¬ negation &not; &#172;
­ soft hyphen &shy; &#173;
® registered trademark &reg; &#174;
¯ spacing macron &macr; &#175;
° degree &deg; &#176;
± plus-or-minus  &plusmn; &#177;
² superscript 2 &sup2; &#178;
³ superscript 3 &sup3; &#179;
´ spacing acute &acute; &#180;
µ micro &micro; &#181;
paragraph &para; &#182;
· middle dot &middot; &#183;
¸ spacing cedilla &cedil; &#184;
¹ superscript 1 &sup1; &#185;
º masculine ordinal indicator &ordm; &#186;
» angle quotation mark (right) &raquo; &#187;
¼ fraction 1/4 &frac14; &#188;
½ fraction 1/2 &frac12; &#189;
¾ fraction 3/4 &frac34; &#190;
¿ inverted question mark &iquest; &#191;
× multiplication &times; &#215;
÷ division &divide; &#247;

ISO 8859-1 Character Entities
Result Description Entity Name Entity Number
À capital a, grave accent &Agrave; &#192;
Á capital a, acute accent &Aacute; &#193;
 capital a, circumflex accent &Acirc; &#194;
à capital a, tilde &Atilde; &#195;
Ä capital a, umlaut mark &Auml; &#196;
Å capital a, ring &Aring; &#197;
Æ capital ae &AElig; &#198;
Ç capital c, cedilla &Ccedil; &#199;
È capital e, grave accent &Egrave; &#200;
É capital e, acute accent &Eacute; &#201;
Ê capital e, circumflex accent &Ecirc; &#202;
Ë capital e, umlaut mark &Euml; &#203;
Ì capital i, grave accent &Igrave; &#204;
Í capital i, acute accent &Iacute; &#205;
Î capital i, circumflex accent &Icirc; &#206;
Ï capital i, umlaut mark &Iuml; &#207;
Ð capital eth, Icelandic &ETH; &#208;
Ñ capital n, tilde &Ntilde; &#209;
Ò capital o, grave accent &Ograve; &#210;
Ó capital o, acute accent &Oacute; &#211;
Ô capital o, circumflex accent &Ocirc; &#212;
Õ capital o, tilde &Otilde; &#213;
Ö capital o, umlaut mark &Ouml; &#214;
Ø capital o, slash &Oslash; &#216;
Ù capital u, grave accent &Ugrave; &#217;
Ú capital u, acute accent &Uacute; &#218;
Û capital u, circumflex accent &Ucirc; &#219;
Ü capital u, umlaut mark &Uuml; &#220;
Ý capital y, acute accent &Yacute; &#221;
Þ capital THORN, Icelandic &THORN; &#222;
ß small sharp s, German &szlig; &#223;
à small a, grave accent &agrave; &#224;
á small a, acute accent &aacute; &#225;
â small a, circumflex accent &acirc; &#226;
ã small a, tilde &atilde; &#227;
ä small a, umlaut mark &auml; &#228;
å small a, ring &aring; &#229;
æ small ae &aelig; &#230;
ç small c, cedilla &ccedil; &#231;
è small e, grave accent &egrave; &#232;
é small e, acute accent &eacute; &#233;
ê small e, circumflex accent &ecirc; &#234;
ë small e, umlaut mark &euml; &#235;
ì small i, grave accent &igrave; &#236;
í small i, acute accent &iacute; &#237;
î small i, circumflex accent &icirc; &#238;
ï small i, umlaut mark &iuml; &#239;
ð small eth, Icelandic &eth; &#240;
ñ small n, tilde &ntilde; &#241;
ò small o, grave accent &ograve; &#242;
ó small o, acute accent &oacute; &#243;
ô small o, circumflex accent &ocirc; &#244;
õ small o, tilde &otilde; &#245;
ö small o, umlaut mark &ouml; &#246;
ø small o, slash &oslash; &#248;
ù small u, grave accent &ugrave; &#249;
ú small u, acute accent &uacute; &#250;
û small u, circumflex accent &ucirc; &#251;
ü small u, umlaut mark &uuml; &#252;
ý small y, acute accent &yacute; &#253;
þ small thorn, Icelandic &thorn; &#254;
ÿ small y, umlaut mark &yuml; &#255;

HTML 4.01 Symbol Entities Reference

Math Symbols Supported by HTML
Result Description Entity Name Entity Number
for all &forall; &#8704;
part &part; &#8706;
exists &exists; &#8707;
empty &empty; &#8709;
nabla &nabla; &#8711;
isin &isin; &#8712;
notin &notin; &#8713;
ni &ni; &#8715;
prod &prod; &#8719;
sum &sum; &#8721;
minus &minus; &#8722;
lowast &lowast; &#8727;
square root &radic; &#8730;
proportional to &prop; &#8733;
infinity &infin; &#8734;
angle &ang; &#8736;
and &and; &#8743;
or &or; &#8744;
cap &cap; &#8745;
cup &cup; &#8746;
integral &int; &#8747;
therefore &there4; &#8756;
simular to &sim; &#8764;
approximately equal &cong; &#8773;
almost equal &asymp; &#8776;
not equal &ne; &#8800;
equivalent &equiv; &#8801;
less or equal &le; &#8804;
greater or equal &ge; &#8805;
subset of &sub; &#8834;
superset of &sup; &#8835;
not subset of &nsub; &#8836;
subset or equal &sube; &#8838;
superset or equal &supe; &#8839;
circled plus &oplus; &#8853;
cirled times &otimes; &#8855;
perpendicular &perp; &#8869;
dot operator &sdot; &#8901;

Greek Letters Supported by HTML
Result Description Entity Name Entity Number
Α Alpha &Alpha; &#913;
Β Beta &Beta; &#914;
Γ Gamma &Gamma; &#915;
Δ Delta &Delta; &#916;
Ε Epsilon &Epsilon; &#917;
Ζ Zeta &Zeta; &#918;
Η Eta &Eta; &#919;
Θ Theta &Theta; &#920;
Ι Iota &Iota; &#921;
Κ Kappa &Kappa; &#922;
Λ Lambda &Lambda; &#923;
Μ Mu &Mu; &#924;
Ν Nu &Nu; &#925;
Ξ Xi &Xi; &#926;
Ο Omicron &Omicron; &#927;
Π Pi &Pi; &#928;
Ρ Rho &Rho; &#929;
Σ Sigma &Sigma; &#931;
Τ Tau &Tau; &#932;
Υ Upsilon &Upsilon; &#933;
Φ Phi &Phi; &#934;
Χ Chi &Chi; &#935;
Ψ Psi &Psi; &#936;
Ω Omega &Omega; &#937;
α alpha &alpha; &#945;
β beta &beta; &#946;
γ gamma &gamma; &#947;
δ delta &delta; &#948;
ε epsilon &epsilon; &#949;
ζ zeta &zeta; &#950;
η eta &eta; &#951;
θ theta &theta; &#952;
ι iota &iota; &#953;
κ kappa &kappa; &#954;
λ lambda &lambda; &#955;
μ mu &mu; &#956;
ν nu &nu; &#957;
ξ xi &xi; &#958;
ο omicron &omicron; &#959;
π pi &pi; &#960;
ρ rho &rho; &#961;
ς sigmaf &sigmaf; &#962;
σ sigma &sigma; &#963;
τ tau &tau; &#964;
υ upsilon &upsilon; &#965;
φ phi &phi; &#966;
χ chi &chi; &#967;
ψ psi &psi; &#968;
ω omega &omega; &#969;
ϑ theta symbol &thetasym; &#977;
ϒ upsilon symbol &upsih; &#978;
ϖ pi symbol &piv; &#982;

Some Other Entities Supported by HTML
Result Description Entity Name Entity Number
Œ capital ligature OE &OElig; &#338;
œ small ligature oe &oelig; &#339;
Š capital S with caron &Scaron; &#352;
š small S with caron &scaron; &#353;
Ÿ capital Y with diaeres &Yuml; &#376;
ƒ f with hook &fnof; &#402;
ˆ modifier letter circumflex accent &circ; &#710;
˜ small tilde &tilde; &#732;
en space &ensp; &#8194;
em space &emsp; &#8195;
thin space &thinsp; &#8201;
zero width non-joiner &zwnj; &#8204;
zero width joiner &zwj; &#8205;
left-to-right mark &lrm; &#8206;
right-to-left mark &rlm; &#8207;
en dash &ndash; &#8211;
em dash &mdash; &#8212;
left single quotation mark &lsquo; &#8216;
right single quotation mark &rsquo; &#8217;
single low-9 quotation mark &sbquo; &#8218;
left double quotation mark &ldquo; &#8220;
right double quotation mark &rdquo; &#8221;
double low-9 quotation mark &bdquo; &#8222;
dagger &dagger; &#8224;
double dagger &Dagger; &#8225;
bullet &bull; &#8226;
horizontal ellipsis &hellip; &#8230;
per mille  &permil; &#8240;
minutes &prime; &#8242;
seconds &Prime; &#8243;
single left angle quotation &lsaquo; &#8249;
single right angle quotation &rsaquo; &#8250;
overline &oline; &#8254;
euro &euro; &#8364;
trademark &trade; &#8482;
left arrow &larr; &#8592;
up arrow &uarr; &#8593;
right arrow &rarr; &#8594;
down arrow &darr; &#8595;
left right arrow &harr; &#8596;
carriage return arrow &crarr; &#8629;
left ceiling &lceil; &#8968;
right ceiling &rceil; &#8969;
left floor &lfloor; &#8970;
right floor &rfloor; &#8971;
lozenge &loz; &#9674;
spade &spades; &#9824;
club &clubs; &#9827;
heart &hearts; &#9829;
diamond &diams; &#9830;

더많은 특수문자 코드 보기

출처 : http://waf.seoul.go.kr/source_library/source_05.html (서울특별시 웹개발표준 프레임웍)
저작자 표시 비영리 동일 조건 변경 허락

인터넷 웹 콘텐츠 접근성 지침 체크 항목

개정(안)적용하여 업데이트 함.[2008년 9월08일 월요일]
(구 인터넷 웹 콘텐츠 접근성 지침 1.0 체크 항목 보기)

배경 및 목적

  • 2008년 4월부터 "장애인차별금지 및 권리구제 등에 관한 법률"에 근거하여 장애인을 위한 웹 접근성 준수를 의무화
    ∗동법시행령 제14조 2항 1호에서 웹 사이트 이용 보장을 의무화하였으며, 행위자 등의 성격을 고려하여 '09년~'13년까지 단계적으로 적용
  • 이에 웹 사이트 이용에 대한 장애인의 차별여부를 객관적으로 평가할 수 있는 체계 확립 필요

평가 기준 개선 방향

  • 핵심요소(Core)로 한정 : 사용성(Usability)과 관련되는 평가 항목은 제외하고 접근성에 크게 영향을 미치는 요소로만 한정
    ∗사용에 불편함을 미치는 요소는 가급적 배제하고 미준수시 접근이 불가능한 것만으로 축약, 호환성(Interoperability)과 관련된 요소는 보조기기 사용에 있어 심각한 문제점을 야기하는 것으로 한정
  • 검증가능성(Testability) : 평가가 객관적으로 수행 가능한 것들을 중심으로 다양한 방법으로 해석이 가능한 것은 가급적 배제
    ∗평가자에 따라 준수 여부를 다르게 평가할 수 있는 요소 배제

웹 접근성 준수여부 평가기준 개선
실테조사 품질마크기준 장차법 소송시 평가기준(안)
13개 항목26개 지표 51개 체크리스트 13개 항목 18개 체크리스트

∗ 지침, 항목, 지표, 체크리스트라는 기존의 복잡한 평가기준 체계를 단순화함.

인터넷 웹 콘텐츠 접근성 지침 체크 항목


지침 1. 인식의 용이성 : 웹사이트에서 서비스하고 있는 모든 콘텐츠는 누구나 쉽게 인식할 수 있도록 설계되어야 한다.

항목/체크리스트 평가
항목1.1 텍스트 아닌 콘텐츠(Non-text Contents)의 인식
체크리스트1
이미지의 의미나 목적을 이해할 수 있도록 적절한 대체텍스트를 제공해야 한다.
※ 의미가 있는 이미지의 경우 대체 텍스트를 의미나 기능이 동일하게 제공
※ 의미가 없는 이미지의 경우 대체 텍스트를 blank(alt=" ")로 제공
체크리스트2
배경 이미지가 의미를 갖는 경우, 배경 이미지의 의미를 이해할 수 있도록 대체 콘텐츠를 제공해야 한다.
항목1.2 멀티미디어 매체의 인식
체크리스트3
멀티미디어 콘텐츠(동영상, 오디오 등)를 이해할 수 있도록 자막 또는 원고 등을 제공해야 한다.
∗ 실시간 방송의 경우는 평가에서 예외로 함
항목1.3 콘텐츠의 시각적 명료성
체크리스트4
색상을 배제하여도 원하는 내용을 전달할 수 있도록, 색상 이 외에도 명암이나 패턴으로 콘텐츠 구분이 가능해야 한다.

지침 2. 운용의 용이성 : 웹 콘텐츠에 포함된 모든 요소들의 기능은 누구나 쉽게 사용할 수 있어야 한다.

항목/체크리스트 평가
항목2.1 이미지맵 기법 사용 제한
체크리스트5
서버측 이미지 맵을 제공할 경우, 해당 내용 및 기능을 사용할 수 있는 대체 콘텐츠를 제공해야 한다.
∗ 지리정보시스템(GIS)은 평가에서 예외로 함
항목2.2 프레임의 사용제한
체크리스트6
프레임을 제공할 경우, 프레임의 내용을 이해할 수 있도록 적절한 제목(title 속성)을 제공해야 한다.
항목2.3 깜빡거리는 객체 사용 제한
체크리스트7
깜빡이는 콘텐츠를 제공할 경우, 사전에 경고하고, 콘텐츠를 이용할 수 있도록 깜빡이지 않는 대체 페이지를 제공해야 한다.
∗ 깜박임 기준: 초당 3~49번을 깜박이는 콘텐츠
항목2.4 키보드로만 운용 가능
체크리스트8
키보드만으로 콘텐츠가 제공하는 모든 기능을 이용할 수 있어야 한다.
항목2.5 반복 네비게이션 링크(repetitive navigation link)
체크리스트9
반복되는 링크를 건너뛸 수 있도록 건너뛰기 링크(skip navigation)를 제공해야 한다.
항목2.6 반응 시간의 조절기능
체크리스트10
이용에 시간 제한이 있는 콘텐츠를 제공할 경우, 시간 제어 기능을 제공해야 한다.
∗ 예외 : 경매, 실시간 게임 등과 같이 시간제한이 필수적인 콘텐츠
체크리스트11
새 창(팝업창 포함)을 제공할 경우, 사용자에게 사전에 알려야 한다.

지침 3. 이해의 용이성 : 사용자들이 가능한 한 쉽게 이해할 수 있도록 콘텐츠나 제어 방식을 구성해야 한다.

항목/체크리스트 평가
항목3.1 데이터테이블 구성
체크리스트12
데이터 테이블을 제공할 경우, 테이블의 내용을 이해할 수 있는 정보(제목, 요약정보 등)를 제공해야 한다.
체크리스트13
데이터 테이블을 제공할 경우, 제목 셀과 내용 셀을 구분할 수 있어야 한다.
항목3.2 페이지의 논리적 구성
체크리스트14
해당 페이지를 잘 이해할 수 있도록 페이지 제목(<title>)을 제공해야 한다.
체크리스트15
콘텐츠는 논리적인 순서로 구성되어야 한다.
항목3.3 온라인 서식 구성
체크리스트16
온라인 서식을 제공할 경우, 레이블(<label>)을 제공해야 한다.

지침 4. 기술의 진보성 : 구성한 콘텐츠는 웹 브라우저의 종류, 버전 등에 관계없이 사용될 수 있어야 한다.

항목/체크리스트 평가
항목4.1 신기술의 사용
체크리스트17
애플릿, 플러그인(ActiveX, 플래시) 등 부가 애플리케이션이 제공하는 경우, 해당 애플리케이션이 자체적인 접근성을 준수하거나 또는 사용자가 대체 콘텐츠를 선택하여 이용할 수 있어야 한다.
체크리스트18
링크, 서식, 버튼은 자바스크립트 없이도 작동할 수 있어야 한다.
출처 : 장애인차별금지 및 권리구제 등에 관한 법률 시행을 위한 웹 접근성 준수 가이드라인 개발 계획(안)
- 웹 접근성 준수 가이드라인 개발 계획(안) 다운받기
- 웹 접근성 평가 가이드라인 체크리스트 비교표 다운받기

출처 : http://waf.seoul.go.kr/accessibility/accessibility_01.html (서울특별시 웹개발 표준 프레임웍)
저작자 표시 비영리 동일 조건 변경 허락

웹퍼블리셔란 직업이면서도 스스로 무엇을 하는가에 부딫힐때가 있습니다
그럴때마다 초심으로 돌아가 다시금 하나하나 의미를 되세기는 일을 합니다 오늘도 문득 그런생각이 드네요

 

웹 접근성에 대한 W3C의 정의

W3CWAI 에서는 웹 접근성을 이렇게 소개하고 있습니다.

Web accessibility means that people with disabilities can use the Web.
웹 접근성은 장애를 지닌 사람이 웹을 이용할 수 있는것을 의미한다.

More specifically, Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. Web accessibility also benefits others, including older people with changing abilities due to aging.
특히, 웹 접근성은 장애를 지닌 사람이 인지하고, 이해하고, 항해하고 웹과 상호작용 하는것을 의미한다. 그리고 그들은 웹에 기여 할 수 있다. 또한 웹 접근성은 나이를 먹는동안 능력이 변하는 노인을 포함하여 다른 이들에게도 이득이다.

출처 : WAI > Introduction to Web Accessibility

WCAG 1.0 지침에서는 웹 접근성 지침의 목적을 아래와 같이 설명하고 있습니다.

These guidelines explain how to make Web content accessible to people with disabilities. The guidelines are intended for all Web content developers (page authors and site designers) and for developers of authoring tools. The primary goal of these guidelines is to promote accessibility. However, following them will also make Web content more available to all users, whatever user agent they are using (e.g., desktop browser, voice browser, mobile phone, automobile-based personal computer, etc.) or constraints they may be operating under (e.g., noisy surroundings, under- or over-illuminated rooms, in a hands-free environment, etc.). Following these guidelines will also help people find information on the Web more quickly.
이 지침은 장애를 지닌 사람이 어떻게 웹 콘텐트에 접근할 수 있게 할 것인지를 설명하고 있다. 이 지침은 모든 웹 콘텐트 개발자(페이지 저자와 사이트 디자이너)와 저작 도구 개발자를 위한 것이다. 이 지침의 주된 목표는 접근성을 증진시키는 것이다. 어쨌거나 이 지침을 따르는것은 사용자가 어떤 에이전트를 사용하거나(데스크탑 브라우저, 음성 브라우저, 이동 전화, 자동차용 컴퓨터 등) 또는 조작에 제한을 받더라도(소음, 조명이 지나치게 어둡거나 밝은 곳, 손을 사용할 수 없는 환경 등) 모든 사용자가 웹 콘텐트에 접근이 가능하도록 만들것이다. 또한 이 가이드라인을 따르는 것은 웹에서 좀더 빨리 정보를 찾는 것을 돕는다.

출처 : WCAG 1.0 > Abstract

웹 접근성에 대한 한국정보문화진흥원KADO의 정의

접근성이란 이를 정의하는 학자 및 기관에 따라 다양하게 나타나고 있다. 접근성에 대한 개념의 다양성 으로 인한 인식의 부족보다는 접근성에 대한 개념을 잘 못 이해하고 있는것이 더욱 문제이다. 즉, 접근성을 단지 장애인에게 국한된 문제라고 잘못 이해하고 있는 경우가 대부분이라는 것이다. 비록 접근성 준수가 장애인에게 가장 혜택이 많이 돌아가는 것은 사실이지만, 접근성이란 장애인뿐만 아니라 모든 사람이 정보통신기기나 서비스를 손쉽게 활용할 수 있도록 만드는 것을 말한다. 웹 접근성이란, 어떠한 사용자(장애인, 노인 등), 어떤 기술환경에서도 전문적인 능력 없이도 웹 사이트에서 제공하는 모든 정보에 접근하고 이용할 수 있도록 보장하는 것을 말한다(현준호, 2005). 즉, 장애가 없는 일반인뿐만 아니라 시각장애인, 청각장애인 등 장애인과 노인도 인터넷 정보에 일반인과 동등하게 접근할 수 있도록 보장할 수 있다. 또한 마이크로소프트의 윈도우 기반이 아닌 매킨토시, 리눅스 운영체제 사용자와 인터넷 익스플로러(Internet Explorer)외의 모질라(Mozilla), 파이어 폭스(Firefox), 오페라(Opera), 링스(Lynx) 등의 브라우저 사용자들도 동등하게 인터넷 정보에 접근할 수 있다.

출처 : 우리나라와 외국 웹 접근성 비교 분석 및 대응방안, 현준호 (한국정보문화진흥원 접근기술팀 전임연구원)

보편적 접근성에 대한 정의

보편적 접근성1)이란, 모든 사람이 다양한 조건의 환경2)에서 다양한 장치3)를 이용하여 웹 콘텐트에 접근할 수 있도록 보장하는 것을 의미합니다. 보편적 접근성을 보장하게 되면 장애를 지닌 사람4) 뿐만 아니라 일시적으로 불리한 조건을 갖게 된 정상인5)에 이르기까지 편리하게 웹 콘텐트에 접근할 수 있습니다. 또한, 네트웍 속도가 느리거나 모바일 기기를 사용하는 사람들, 다양한 운영체제와 다양한 웹 브라우저를 이용하는 조건에 관계없이 웹 콘텐트에 접근할 수 있으며 웹의 사용성6)을 증진시켜 주기도 합니다.

1) 보편적 접근성
보편적 웹 접근성의 준말로서 웹 이라는 명사를 생략하였으나 여기서는 그 범위를 웹으로 한정한다. 웹 접근성이 접근 주체를 장애인과 비 장애인으로 구분하고 있는것과는 다르게 보편적 접근성은 유니버설 디자인의 패러다임을 수용하여 장애인과 비 장애인을 구분짓는 것을 경계하는 의미로 보편적 접근성이라는 용어를 사용하였다.
2) 다양한 조건의 환경
신체적 조건과 외부 요인에 의한 환경을 모두 아우르는 것을 의미. 외부 요인에 의한 환경이란, 웹을 탐색하기 위한 적절한 보조수단을 갖추지 못하거나 지원을 받지 못하는 등 외부요인에 의하여 발생할 수 있는 장애를 포함하고 있음.
3) 다양한 장치
하드웨어류와와 소프트웨어류를 모두 총칭함. 일반적인 데스크탑 환경의 웹 브라우징 장치를 포함하여 모바일 기기와 장애인들이 사용하는 보조기기를 모두 아우르는 의미.
4) 장애를 지닌 사람
장애를 지닌 사람이란, 장애인 뿐만 아니라 노화현상에 의하여 자연적으로 신체의 일부 기능이 퇴화된 노인들을 포함하고 있다.
5) 일시적으로 불리한 조건을 갖게 된 정상인
상해를 입거나 다른 일을 동시에 수행하기 때문에 일시적으로 신체의 일부를 사용할 수 없는 환경. 또는 일시적으로 부가 장치의 지원을 받지 못하는 장애환경에 처한 정상인을 의미함.
6) 웹의 사용성
웹 접근성이 웹의 보편성을 지원하기 위한 개념이라면 웹의 사용성은 웹 인터페이스의 효과, 효율, 사용자 만족도를 지원하기 위한 개념이다.
출처 : 직접 작성, NHN 정찬명

저작자 표시 비영리 동일 조건 변경 허락



참여합니다~ 혹시나 아는척좀... ㅎㅎ
저작자 표시 비영리 동일 조건 변경 허락

민간부문의 장애인 웹 접근성 제고 세미나 개최, 2008.11.3(월), 대한상공회의소 국제회의실(지하 2층)

- 속성값은 반드시 "표로 시작해서 "표로 끝냄
- 속성값은 '표 보다는 "표를 사용세요
- URL에 사용되는 '&'는 모두 '&amp;'를 사용
- URL에 한글이 들어있는 경우 유니코드로 표기하세요
- <img> 태그는 반드시 마지막에 "/"을 사용한다.
- <img> 태그는 반드시 alt="설명"을 사용한다. 설명이 없을 경우 ""를 쓰면됨
- <br> 태그 또한 마지막에 /을 사용(사용을 줄인다.)
예) <br />
- <a rel="tag">는 해당포스트의 태그에만 사용한다.(태그리스트 랜덤태그에 사용금지)
- <h3>로 시작되는 태그에는 굵게표시가 기본이다. font-weight:bold;를 중복으로 사용할 필요 없음
- <font="모양">태그를 사용하지 않음
- <... style> 픽셀단위로 조정되는 모든 속성에는 px를 붙여준다. 단 속성값이 0인경우 px를 생략가능
예) padding:15px 0 10px 0;
- class 속성은 중복으로 사용할 수 있다. 단 id속성은 중복으로 사용 못함
예) class="ib text", id="text"
- 리스트 항목에는 ol 또는 ul을 사용하여 작성
- <div id="해더/컨텐츠/푸터"> 구조에 따른 레이아웃 구성
- <b>태그를 <strong>로 사용한다.(레이아웃에는 사용을 줄이고 스타일시트로 대체)
- <s>태그를 <del>로 사용한다.(레이아웃에는 사용을 줄이고 스타일스시로 대체)
- <u>태그를 <ins>로 사용한다.(레이아웃에는 사용을 줄이고 스타일시트로 대체)
- <center>태그를 <div align="center">로 사용한다.(레이아웃에는 사용을 줄이고 스타일시트로 대체)
- 폰트 크기 조정을 위해 <big>텍스트</big>와 <small>텍스트</small>를 사용
- 미디어를 붙이기 위해 <embed> 태그보다는 <object> 태그를 사용

출처 카페 > 하드코딩하는사람들 | 나나
원문 http://cafe.naver.com/hacosa/1699

1) 올바른 DOCTYPE 사용하시기 바랍니다.


 

작업중, 작업완료 후 이 DOCTYPE이 아닌데 하고 바꾸면 맞는 형태가아니기 때문에 화면이 제대로 표현되지 못합니다..

지대로 된 DOCTYPE 선언은 웹표준 문서작성의 기본입니다^^;;

올바른 DOCTYPE 선언하지 않으면 브라우저들은 그들의 표준방식을 취할 것이고 그것은 페이지를 모두 잘못되게 표시한다고 하네요..





2) 유효한 코드를 사용하시기 바래요


 

유효성체크기는 당신의 HTML과 CSS 문법이 올바른지 확인하기 위해서 체크합니다.

그리고 오류와 애매함에 대해 알게 해줍니다.

어떻게 오류를 고쳐야 하는지 알려줍니다. 그러나 보통 실수들은 꽤 명백해서 몇번 하시다 보면 노하우가 생긴답니다..ㅎㅎ


-> 그러나 저도 아직 마감임박상태에 놓여있어서 T.T

유효성 검사 해보고 못고치면 병나요... 그래서 원초부터 안 들어가지고... 고질병이네요..ㅎㅎ




3) 표현용 태그는 CSS로 이동해 주세요..

웹사이트의 궁극적인 목표는 내용으로 부터 표현(색상, 글꼴, 레이아웃, 포지셔닝)을 분리해주세요...
이것은 CSS를 사용함으로써 이루어 집니다.


-> 제가 가끔 예제를 올릴때 <style type="text/css"></style> 해서 올리는건 보기 편함입니다^^


 




참고 : http://webstandardsgroup.org/standards/


 >- 속성값은 반드시 "표로 시작해서 "표로 끝냄
- 속성값은 '표 보다는 "표를 사용세요
- URL에 사용되는 '&'는 모두 '&amp;'를 사용
- URL에 한글이 들어있는 경우 유니코드로 표기하세요
- <img> 태그는 반드시 마지막에 "/"을 사용한다.
- <img> 태그는 반드시 alt="설명"을 사용한다. 설명이 없을 경우 ""를 쓰면됨
- <br> 태그 또한 마지막에 /을 사용(사용을 줄인다.)
예) <br />
- <a rel="tag">는 해당포스트의 태그에만 사용한다.(태그리스트 랜덤태그에 사용금지)
- <h3>로 시작되는 태그에는 굵게표시가 기본이다. font-weight:bold;를 중복으로 사용할 필요 없음
- <font="모양">태그를 사용하지 않음
- <... style> 픽셀단위로 조정되는 모든 속성에는 px를 붙여준다. 단 속성값이 0인경우 px를 생략가능
예) padding:15px 0 10px 0;
- class 속성은 중복으로 사용할 수 있다. 단 id속성은 중복으로 사용 못함
예) class="ib text", id="text"
- 리스트 항목에는 ol 또는 ul을 사용하여 작성
- <div id="해더/컨텐츠/푸터"> 구조에 따른 레이아웃 구성
- <b>태그를 <strong>로 사용한다.(레이아웃에는 사용을 줄이고 스타일시트로 대체)
- <s>태그를 <del>로 사용한다.(레이아웃에는 사용을 줄이고 스타일스시로 대체)
- <u>태그를 <ins>로 사용한다.(레이아웃에는 사용을 줄이고 스타일시트로 대체)
- <center>태그를 <div align="center">로 사용한다.(레이아웃에는 사용을 줄이고 스타일시트로 대체)
- 폰트 크기 조정을 위해 <big>텍스트</big>와 <small>텍스트</small>를 사용
- 미디어를 붙이기 위해 <embed> 태그보다는 <object> 태그를 사용

>

>

>100% 지켜주시나요?^^;;

>

>

>참고 : HTML 4.01 Reference

http://memolog.blog.naver.com/chmylove/322