이 글은 Manuel Matuzovic의 Writing HTML with Accessibility in Mind를 번역한 글입니다.
웹 접근성에 대한 소개입니다. 당신의 마크업 능력을 향상시키고, 사용자가 당신의 사이트를 사용할때 좀 더 나은 방법으로 탐색할 수 있는 방법을 제공하기 위한 팁에 관한 것입니다.
서론을 읽기 원치 않으시는 분은, 바로 팁 부분으로 넘어가세요.
이 글은 Workafrolic이 번역한 러시아어, EmanuelG가 번역한 포르투칼어로도 볼 수 있습니다.
개인적 개발 경험과 관점의 변화
제가 첫번째 사이트를 만들때 가장 우선순위를 둔 것이 콘텐츠를 온라인으로 얻는 것이었습니다. 사용성, 접근성, 실행, UX나 브라우저 호환성에 대해 그닥 신경쓰지 않았습니다. 제가 왜그랬을까요? 레이아웃에 기반한 견고한 테이블을 만들었고, 800x600버전과 1024x768버전으로 만들었습니다. 무엇보다도 사이트가 IE5에 최적화 되어있다고 사용자에게 알렸습니다.
물론 이 얘기는 제가 웹디자이너로서 전문적 커리어를 쌓기 전의 얘기이고, 무엇이 중요한가에 대한 저의 관점은 바뀌었습니다. 몇년 후, 제 사이트를 위한 필요 조건을 찾는 대신에 모든 주요 브라우저에 사이트를 맞추기 시작했습니다. Ethan Marcotte’s game changing article을 시작으로 디바이스 또한 고려하기 시작했습니다. 모든 종류의 브라우저와 디바이스를 위한 사이트를 만들면 제일 좋겠지만, 사이트가 느려지게 되고 사이트가 쓸모없게 될 수 있습니다. 그래서 저는 주요 CSS, speed Index, 폰트 로딩, CDNs 등에 관련된 것들을 배우기 시작했습니다.
접근성(a11y) 시작하기
최근 저의 관점이 또 한번 바뀌었습니다. 하위 브라우저에서 작동하는 빠른 반응형 웹사이트를 만드는 것이 키보드를 통해 탐색할 수 없다면 완전한 것이 아님을 깨달았습니다. 접근성은 사이트를 런칭하기 전에 우리의 할일 목록에서 지워나갈 수 있는 요소가 아닙니다. 접근성은 우리가 웹디자이너, 웹 개발자로서 해야하는 기본이고, 그렇게 접근성에 다가가야 하는 것이 의무입니다.
지난 몇개월을 웹 접근성과 관련해 읽고, 듣고 공부하는 데에 시간을 보냈습니다. 시작한 지 얼마 안되어 머리속에 관련 내용들을 넣는 데에 시간이 좀 걸렸지만, 점점 더 공부할수록 무언가 완전히 새로운 것을 습득하지 않아도 곧 바로 할 수 있다는 것에 스스로 놀랐습니다.
HTML, CSS, Javascript를 공부하며 배우게 된 가장 중요한 것은 접근성이 단지 특정 사람들에게만 적용되는 의학 용어가 아니라는 것입니다. 접근성은 우리 모두가 매일같이 신경써야 하는 것입니다. 우리가 만든 것이 접근할 수 없다면 쓸모 없게 됩니다.
이번 시리즈 글들에서 제가 새롭게 알게 된 지식들을 나누고자 합니다. 제가 알려드리는 팁들을 단순한 체크리스트로 생각하지 마시고, 실천하는 첫 시작점이 되길 바랍니다. 이 팁들을 여러분의 업무가운데 사용하는 것이 접근성의 시작점이 될 것이고, 당신의 사용자에 대해 좀 더 고려하고 배우는 것을 촉진시키는 계기가 되길 바랍니다.
소개는 이쯤 하고, 접근성 팁들으 소개하겠습니다.
문서의 기본 언어를 설정하는 것은 중요합니다.
브라우저에게 문서에서 어떤 언어를 사용할 것인지 알려주는 것은 이점이 많습니다. SEO에도 좋고, 타사 번역도구나 브라우저가 알맞는 언어와 단어를 구분할 수 있도록 합니다. HTML 페이지에서 정확한 언어를 정의하는 것은 보조기술이 알맞는 음성 프로파일이나 문자 집합을 선택하는데에 도움이 됩니다. (1) Adrian Roselli는 그의 웹 사이트에 lang 속성을 사용하는 것의 장점을 더 많이 소개하고 있습니다.
<html lang="en">
…
</html>
유튜브에서 lang 속성 사용을 시연한 것을 확인해보세요.
만약 문서 안에서 언어가 바뀐다면 lang 속성을 특정 태그에 사용하면 됩니다.(2)
<p>
There is a certain <i lang="fr" class="idiomatic">je ne sais quoi</i>in the air.
</p>
알맞는 언어를 선언해야 함을 명심하세요. Steve Faulkner는 알맞은 lang을 사용하지 않았을 경우 어떤 일이 일어나는지 보여주는 비디오를 만들었습니다. 모든 언어 코드는 IANA Language Subtag Registry에 있는 목록에서 확인하세요.
hidden 속성을 사용해 콘텐츠를 숨길 수 있습니다.
시각적으로 숨기거나 screen reader가 읽어주길 원하지 않을 경우, hidden 속성을 사용해 보세요.
hidden 속성의 브라우저 지원범위는 IE10이하를 제외하고는 사용 가능합니다. 아래 코드를 css에 추가하면, 하위 브라우저에서도 지원할 수 있습니다.
[hidden] {
display: none;
}
<img> 태그에 alt 속성을 빈 값으로 두는 것이 더 나을 때도 있습니다.
이미지가 콘텐츠로 사용된다면 이미지 콘텐츠에 대한 충분한 정보와 묘사를 위해 alt 속성을 사용합니다. 이럴 경우에는 스크린 리더가 "~의 사진, 그래프"라고 읽어주기 때문에 이러한 내용을 넣지 않습니다.
이미지가 단순히 디자인을 위한 것이고, 유용한 추가 정보를 제공하지 않는다면 css에서 배경이미지로 관리해보세요. html에 넣고싶거나 그래야 한다면, alt 속성을 지우지는 말고, 빈 값으로 두세요.(3)
<img src="decorative_image.jpg" alt="" />
이미지의 alt 속성은 절대 생략해서는 안됩니다.
이 속성을 전부 생략하는 것(alt자체 생략)은 이미지가 콘텐츠의 중요한 부분인데 텍스트로 표현할 것이 없을 때입니다. 이미지가 콘텐츠의 중요한 부분이 아닐 경우 속성을 빈 값(alt="")으로 두면 비시각적인 브라우저에서 랜더링시 제외시킬 것입니다.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img
The A11y Project의 alt 텍스트 적절하게 사용하기(Quick Tip: Using alt Text Properly)에 alt 속성을 사용하는 데에 적용할 수 있는 더 많은 팁들을 소개하고 있습니다.
버튼이 필요하다면, <button> 태그를 사용하세요.
일반적으로 당신이 선호하는 HTML 기본 요소가 있을 것인데, 그것을 사용하기 위해 여러분 스스로를 속이면 안됩니다. 예를 들어, button이 필요하다면 <div>말고 <button>을 사용하세요.
button은 중요하고 유용한 특징이 많이 있습니다.
- 포커싱 가능
- 클릭 가능( 마우스와 키보드로)
- 스크린 리더가 해당 요소를 버튼으로 인식함
Rob Dodson은 <div> 보다 <button>의 이점을 아주 잘 설명합니다. 더 자세한 내용을 얻고 싶다면 A11ycasts episode- "Just use Button"을 시청하세요.
a 링크태그를 쓸지 button을 쓸지 확실하지 않다면, Marcy Suttons의 웹 어플리케이션에서의 링크 vs. 버튼(Link vs. Buttons in Morden Web Applications)를 읽어보세요.
헤댕태그로 정확하게 마크업을 구조화하는 것은 중요합니다.
<h1> - <h6> 헤딩태그를 사용하여 아웃라인을 잡아줌으로써 사용자에게 더 나은 페이지 구조에 대한 이해와 각 색션사이의 관계를 알려줄 수 있습니다. 무엇보다도 보조기술을 사용하는 사용자가 탐색하는 데에 도움이 됩니다. 스크린리더는 여러 다른 방법으로 콘텐츠의 이동을 합니다. 예를 들어, NVDA 스크린 리더를 사용하는 사용자는 단축키(H 와 Shift + H)를 통해 헤딩태그에서 다른 헤딩태그로 바로 이동할 수 있습니다.
헤딩태그를 쌓을때 단계를 뛰어넘는 것은 피해야 합니다.(4) 또한 아웃라인을 생성하는 데에 <h1> 태그를 여러 번 사용하면 안됩니다. 문서 아웃라인 알고리즘은 없습니다(There Is No Document Outline Algorithm)와 "여러 개의 h1 태그에 대한 진실"에 관한 진실(The Truth about "The Truth About Multiple H1 tag" 이라는 Adrian Roselli의 글을 보면 이유를 알 수 있습니다.
<!-- 단계를 뛰어넘지 마세요: -->
<body>
<h1>My website</h1>
<h4>Heading</h4>
<h2>Subheading</h2>
<h3>Heading</h3>
</body>
<!-- 존재하지 않는 아웃라인 알고리즘을 믿지 마세요: -->
<body>
<h1>My website</h1>
<section>
<h1>Heading</h1>
<section>
<h1>Subheading</h1>
</section>
</section>
<section>
<h1>Heading</h1>
</section>
</body>
<!-- 이렇게 하세요: -->
<body>
<h1>My website</h1>
<h2>Heading</h2>
<h3>Subheading</h3>
<h2>Heading</h2>
</body>
tota11y는 당신의 아웃라인이 괜찮은지 확인할 수 있는 괜찮은 방법을 제공합니다. 다른 방법은 css를 비활성화하고 페이지 내용을 읽을 수 있고, 구조가 말이 되는지를 확인하는 방법입니다.
랜드마크를 사용하면 사용자가 사이트를 탐색하는데에 도움이 됩니다.
HTML5(<article>,<aside>,<nav>,<section>)으로 주제에 맞게 섹션을 나눠 마크업하는 것이 가능하고, 권장합니다. search와 같은 적절한 태그가 없는 섹션이나 하위브라우저을 위해 WAI-ARIA role 속성을 사용하는 것도 할 수 있습니다. 섹션을 나누는 요소들은 <div>요소의 대안이 아닙니다. 섹션을 나누는 요소들을 다른 콘텐츠와 구별되는 관련있는 콘텐츠들의 큰 집합으로 보고 사용하면 됩니다. 섹션을 나누는 요소들을 남용하지 마세요. 의미에 맞는 구분과 목적이 아니라면 CSS/JS를 위해 <div>를 사용하세요.
주요 이점 중 하나는 스크린 리더 사용자들이 섹션과 섹션 사이를 바로 이동하면서 페이지를 탐색할 수 있다는 것입니다. 이러한 탐색할 수 있는 색션을 랜드마크라 부릅니다.(7) 유튜브에서 랜드마크 네비게이션에 대한 설명(demonstration of landmark navigation)을 보세요.
<body>
<header> <!-- landmark -->
<nav> <!-- landmark -->
...
</nav>
</header>
<aside> <!-- landmark -->
</aside>
</body>
Landmarks라는 브라우저 확장프로그램을 통해서 랜드마크와 랜드마크 사이의 이동의 특징을 테스트해볼 수 있습니다. 다음으로 넘어가려면 Alt + Shift + N을 누르고, 이전 랜드마크로 이동하려면 Alt + Shift + P를 누르세요.
섹션에 대해 더 알고 싶다면, 웹 접근성 튜토리얼 페이지(Web Accessibility Tutorials page)에서 섹션 부분을 참고하세요.
모든 소프트웨어가 모든 랜드마크에 그렇게 적용하는 것은 아닙니다.
메인 페이지의 content, header, footer 또한 랜드마크입니다.
주 콘텐츠를 <main>으로 묶음으로써, 사용자가 단축키를 통해 주 콘텐츠로 바로 넘어갈 수 있도록 할 수 있습니다. main 태그는 문서나 어플리케이션의 주 콘텐츠 부분임을 알려주고, 문서당 한 개 이상은 사용되어야 합니다.(5)
이미 말했듯이, 콘텐츠를 랜드마크로 쪼개는 것은 좋은 방법입니다. <header>, <footer>는 <section>이나 <article>에 포함되어 있지 않으면 모든 주요 브라우저에서 랜드마크처럼 행동합니다. 하위 브라우저를 대응해야 한다면, 메인 사이트의 header와 footer를 role 속성을 이용하여 랜드마크로 바꿀 수 있습니다. header에는 role="banner"를, footer에는 role="contentinfo"를 적용하면 됩니다.(6)
<!-- role 속성을 추가적으로 설정하는 것은 하위 브라우저의 경우에만 중요합니다. -->
<body>
<header role="banner">
<h1>My personal blog</h1>
</header>
<main>
<section>
<h2>Blog posts</h2>
....
</section>
</main>
<footer role="contentinfo">
© 2016 Me
</footer>
</body>
fieldsets은 form을 그룹핑하는데 중요하고, 맥락상 알맞습니다.
form에 여러 개의 라디오 버튼과 체크박스를 넣어야 하는 경험을 해본 적이 있을 것입니다. form 요소를 추가하고, 그에 맞게 label을 추가하는 것은 크게 어렵지 않을 것입니다. 하지만 당신이 어떤 요소를 선택하던지 라디오 버튼 그룹이나 체크박스 그룹에 라벨을 추가하고 싶은 경우에는 어떻게 하시나요?
<form>
Shirt size
<input type="radio" id="s" name="shirtsize" />
<label for="s">S</label>
<input type="radio" id="m" name="shirtsize" />
<label for="m">M</label>
<input type="radio" id="l" name="shirtsize" />
<label for="l">L</label>
</form>
Shirt size를 어떻게 마크업하실건가요? <p> 태그가 작동은 하겠지만 라디오 버튼 그룹과 잘 어울리지는 않습니다.
더 나은 방법은 fieldset으로 묶고, T-Shirt size를 <legend>로 작성하는 것입니다. 스크린 리더는 <legend>가 라디오 버튼과 관계있다는 것을 알 것이고, 라디오 버튼이 선택될 때마다 값을 읽을 것입니다.
<form>
<fieldset>
<legend>T-Shirt size</legend>
<input type="radio" id="s" name="shirtsize" />
<label for="s">S</label>
<input type="radio" id="m" name="shirtsize" />
<label for="m">M</label>
<input type="radio" id="l" name="shirtsize" />
<label for="l">L</label>
</fieldset>
</form>
fieldset으로 form 요소들을 감쌀때 <section>처럼 여겨집니다. 경험에 근거하면 그룹을 형성하는 여러 form 요소들과 <legend>에 상응하는 해당 그룹을 나타내는 label이이 있다면 <fieldset>을 사용합니다.
더 나아가기
바로 지금입니다. 저는 여러분이 더 접근가능한 HTML을 작성하는데 이 팁들이 도움이 되길 바랍니다. 여러분이 읽은 거의 모든 것의 기본을 제공해준 책 Inclusive Front-End Design Patterns 의 저자 Heydon Pickering에게 큰 감사를 돌립니다. 접근성과 포괄적 디자인에 대해 더 알고 싶다면 그의 책을 읽기를 강력 추천하는 바입니다.
+ 더 많은 접근성 팁
이 글을 4개의 연재 시리즈 중 세 번째 글입니다. 2,3글은 작업중이며 곧 공개될 예정입니다.
1. Writing HTML with accessibility in mind
2. Writing JavaScript with accessibility in mind
3. Writing CSS with accessibility in mind (한글 번역 : 접근성을 고려한 css 작성하기)
4. 다음 글 : Learn how to design and develop with accessibility in mind
읽어주셔서 감사합니다. 유익하였다면 좋아요와 이 글을 공유하는 것 잊지 마세요.
제가 다음 글을 작업하는 동안, 제가 쓴 다른 글들도 확인해보세요.
Getting started with CSS Font Loading
Getting started with CSS Font Loading
I was in the mood to learn something new and so I decided to take a look at the CSS Font Loading API.
medium.com
I totally forgot about print style sheets
I totally forgot about print style sheets
A small collection of useful CSS techniques and a quick reminder that print style sheets are still a thing.
uxdesign.cc
제 글을 교정해주는 Eva에게 항상 감사합니다.
(1) Pickering, Heydon; Inclusive Design Patterns, p.5
(2) w3.org Wiki — i element
(3) WebAIM — Alternative Text
(4) Web Accessibility Tutorials — Headings
(5) WAI-ARIA — main (role)
(6) Using navigation landmarks
(7) Landmarks must identify content regions
'번역' 카테고리의 다른 글
| 가장 좋은 아이콘은 텍스트 라벨입니다 (0) | 2019.06.24 |
|---|---|
| 키보드와 스크린 리더의 네비게이션 차이 (0) | 2019.06.13 |
| 접근성을 고려한 css 작성하기 (0) | 2019.05.15 |
