이 글은 Manuel Matuzovic의 Writing CSS with Accessibility in Mind를 번역한 글입니다.
웹 접근성에 대한 소개와 css로 접근성을 향상하는 방법에 대한 팁을 제공합니다.
글보다 영상을 선호하시는 분들은 CSS Conf Budapest에서 강연한 제 유튜브 영상을 참고하시면 됩니다.
일 년 전 웹 접근성에 집중하기 시작했습니다. 제게 가장 효과적인 학습방법은 남들에게 알려주는 것입니다. 이러한 이유로 제가 밋업이나 컨퍼런스에서 강연을 하게 되었고, 이번 주제로 글을 쓰게 되었습니다. 저는 Smashing Magazine에서 'Progressive Enhancement'에 관한 글을 , medium에서는 접근성에 대한 글을 썼습니다.
이번 글은 접근성 팁관련 3번째 글이고, 특별한 글의 순서가 있는 것은 아닙니다. 관심 있다면 접근성을 고려한 html작성하기와 접근성을 고려한 자바스크립트 작성하기도 한번 읽어보세요.
저는 css가 상대적으로 나온 지 얼마 안 되었을 때인 17살에 처음 웹사이트를 만들었습니다. 그때 이후에 많은 것들이 바뀌었고, CSS는 현재 웹을 스타일링할 수 있는 엄청난 툴들을 제공하고 있습니다. Verdana에서 웹폰트로, 고정 너비에서 반응형 웹디자인으로, 테이블 기반 레이아웃에서 그리드로 옮겨갔고, 더 이상 테두리, 폰트나 그림자를 위해 이미지를 사용할 필요가 없습니다. 개인적으로 만들 수 있는 속성(custom properties), 기능 쿼리(feature queries), calc()나 다양한 새로운 단위(unit)를 사용할 수 있습니다. 물론 이것들은 최근 몇 년간의 개발 연대기에서는 매우 적은 부분입니다.
CSS로 문제를 해결할 수 있는 무한한 방법들과 많은 속성들이 우리의 삶을 편하게 해 주지만 우리의 사용자에게는 더 안 좋은 경험을 제공할 수 있는 가능성이 있습니다. css 3줄로 웹사이트에 접근하지 못하도록 할 수 있습니다. ( .css{a11y:in mind;})
이번 글에서는 더 접근성이 높은 css를 위한 다양한 테크닉, 고려사항, 접근법들을 소개합니다. 기본적인 개념과 잘 알려진 속성들부터 시작하여 마지막에는 새로운 것들에 대한 것들을 얘기해보고자 합니다.
생각보다 양이 많기 때문에 원하시는 부분으로 바로 넘어가실 수 있도록 인덱스를 만들었으니 참고해주세요.
- 인식하기 쉽고 읽기 쉬운 텍스트
- 가상요소의 content 사용 시 주의하기
- 화면 스크린만이 접근 수단이 아닙니다
- 불완전한 지원을 하는 속성들에 대한 대안책
- 콘텐츠를 숨기는 다양한 방법
- 낮은 명도 대비를 믿지 마세요
- 색상이 정보전달의 유일한 수단이어서는 안 됩니다
- 순서 고려하기
- 중요한 것에 포커싱하기 : focus
- 그리드와 flat 한 문서 구조
인식하기 쉽고 읽기 쉬운 텍스트
이미지, 아이콘, 비디오는 오늘날 웹디자인의 필수요소이긴 하지만 텍스트가 여전히 대부분의 웹사이트의 주요 콘텐츠를 담당하고 있습니다. 디바이스에 상관없이 텍스트는 항상 읽을 수 있어야 하기 때문에 폰트 속성들을 스타일링하고, 테스트하고 조정하는 데에 시간을 쏟는 것이 중요합니다.
점점 커지는 폰트 사이즈
본문 텍스트의 폰트 사이즈 기준이 12px 일 때가 있었습니다. 하지만 고해상도의 디바이스가 등장하기 시작했고, 15-18px의 폰트 사이즈가 평균 사이즈가 되었습니다. 최근 몇 년 사이에는 20px 이상으로 올랐습니다. 텍스트는 스마트폰에서 읽기에 충분한 사이즈로 커져야 하고, 거리감이 있는 tv와 같은 큰 화면에서도 읽을 수 있도록 사이즈를 키울 수 있어야 합니다.
서체마다 특징이 많이 다르기 때문에 표준의 최소 사이즈를 지정하는 것은 어렵지만 18-20px 정도면 작은 화면에서도 잘 보일 수 있는 폰트 사이즈일 것입니다. 물론, 폰트 사이즈 관련된 많은 얘기들이 있습니다만 이 글에서 전부를 설명하는 것은 무리가 있으니 Christian Miller의 Your Body Text Is Too Small라는 글을 읽어보시길 추천합니다.
줄 간격 설정하기
브라우저의 기본 줄 간격은 대략 1.2입니다. Web Content Accessibility Guidelines에 따르면 문단 사이의 줄 간격을 1.5로 제시하고 있습니다.
문단 내 조정된 줄 간격이 적용된 텍스트는 읽기 쉬울 뿐 아니라 비주얼적으로도 더 매력적으로 보일 것입니다.
왼쪽 / 오른쪽 정렬
몇몇 분들은 더 보기 좋게 보인다는 이유로 왼쪽이나 오른쪽 정렬보다 양쪽 정렬을 선호하지만, 이는 잘못된 방법입니다. text-align: justify는 줄마다 같은 길이를 만들기 위해 단어 사이 간격을 조정하는데, 이렇게 해서 만들어진 균등하지 않은 간격이 가독성을 떨어트릴 수 있고, 집중력을 떨어트리는 요소가 될 수 있습니다. 필요할 경우, 단어 단위로 쪼개는 것(breaking up words)이 해결책이 될 수 있습니다. 하지만 CSS Hyphenation은 잘 지원되지 않고 예상한 대로 실행되지 않을 수 있습니다.
문단의 너비 정의하기
몇몇 자료에 따르면, 이상적인 문단의 너비가 대략 65글자 정도이기 때문에 디자이너들은 한 줄에 45 - 85글자 정도로 구성하려고 노력합니다.
텍스트 박스의 너비를 정의할 때 'ch'라는 단위를 사용하면 도움이 됩니다. 1ch가 숫자 0의 너비와 동일하기 때문입니다. 이 단위는 font-family나 font-size의 영향을 받기도 합니다.
p {
/* Maximum width of 65characters */
max-width: 65ch;
}
만약 당신이 반응형 타이포그래피를 사용하고자 한다면 꼭 매우 큰 화면에서도 테스트를 해보시길 권합니다. 폰트 사이즈에 제한이 없다면 텍스트는 특정 viewport 사이즈에서 읽기 어렵게 될지도 모릅니다. 만약 당신이 사이즈의 마지노선을 어떻게 설정하는지 모르거나 반응형 타이포그래피에 익숙하지 않다면 Mike Riethmullers의 Precise control over responsive typography를 읽어보시길 권합니다.
가상요소의 content 사용 시 주의하기
우리는 가상 요소인 ::before과 ::after를 사용하여 요소의 맨 앞이나 뒤에 CSS를 추가할 수 있습니다. 이 방법은 우리가 만드는 컴포넌트에 다양하고 쉬운 방법으로 디자인적 요소를 추가할 수 있게 합니다. content라는 속성을 사용하여 내용을 추가할 수도 있습니다. 하지만 내용과 디자인적인 부분을 분리하기 위해 다음과 같이 해서는 안 됩니다.
h2 {
content: "이렇게 하지 마세요!";
}
내용적인 부분인 컨텐츠는 HTML 문서나 데이터베이스에 있거나 API로 가져오는 방법을 써야지 CSS에 있어서는 안 됩니다. 우리가 content 속성을 사용하는 경우는 폰트 아이콘이나 특수문자와 같은 비문자 콘텐츠를 추가할 때 사용합니다. 만약 그렇게 한다면(css content속성으로 텍스트를 넣는다면), 몇몇의 스크린 리더는 css에서 생성된 콘텐츠를 인식하고 읽어준다는 것을 기억해야 합니다. 생성한 콘텐츠가 단순히 디자인(시각적)을 위한 것이라면 aria-hidden 같은 것을 사용하여 보조기술로부터 숨겨야 합니다.
<span class="icon icon-key" aria-hidden="true"></span>
화면 스크린만이 접근 수단이 아닙니다
우리가 디지털 시대에 살고 있다 하더라도 인간은 여전히 인쇄물에서 벗어날 수 없습니다. 당신의 웹페이지가 인쇄되거나 PDF로 저장될 때에도 사용 가능하고, 접근 가능하도록 해야 한다는 것을 명심하세요. 당신은 @media를 사용하여 인쇄되었을 때 보이지 않는 게 나은 것들을 숨기거나 바르게 보일 수 있도록 스타일을 수정하거나 보이지 않게 하세요. (예를 들어, 내비게이션이나 광고)
@media print {
.header {
position: static;
}
nav {
display: none;
}
}
인쇄된 웹페이지의 문제 중 하나는 링크가 어떤 주소를 가리키는지 모른다는 것입니다. 다행히도 CSS에는 속성의 값을 스크린(or 인쇄물)에 표시되도록 하는 방법을 제공하고 있습니다.
@media print {
a[href^="http"]:not([href*="mywebsite.com"])::after {
content: " (" attr(href) ")";
}
}
위 코드를 추가해주면, 모든 링크의 href 값들을 보여줄 것입니다. 다만, http로 시작하고, mywebsite.com은 없는 값만 보여준다는 뜻입니다.
파이어폭스, 특히 크롬 같은 경우 인쇄 관련 스타일시트를 테스팅하고 디버깅할 수 있는 툴을 제공합니다. 좀 더 깊게 파보고 싶다면 제가 정리한 인쇄 관련 스타일 관련 팁과 트릭을 참고하세요.
불완전한 지원을 하는 속성 값에 대한 대안책
가끔 사용하고 싶은 속성이 몇몇 브라우저에서 지원하지 않아서 사용하지 못한 경험이 다들 있을 것입니다. 우리는 이러한 상황을 대안책들을 사용하여 피해 갈 수 있습니다. 가끔 우리는 기능 쿼리조차 필요 없고, 다른 기능 탐색(feature detection)이 그렇게 하도록 둘 필요가 없습니다.
당신이 vmax라는 단위를 사용하고 싶다고 가정해봅시다. vmax는 IE와 Edge 구버전에서 지원하지 않습니다.
div {
width: 50vmax; /* Doesn't work in IE and older versions of Edge */
}
대안으로는 width속성 값을 vmax보다 더 지원범위가 넓은 속성을 사용하세요. 더 지원범위가 넓은 것을 선언 후, 사용하고자 하는 속성으로 써주세요.
div {
width: 50vw;
width: 50vmax;
}
vmax를 해석하지 못하는 브라우저는 width: 50vw를 해석할 것이고, width: 50vmax는 뛰어넘을 것입니다. 반면에 vmax를 해석할 수 있는 브라우저라면 width: 50vw를 먼저 해석한 후에 width: 50vmax를 해석할 것입니다. vmax를 선언한 부분이 vw 뒤에 있기 때문에 vmax가 사용자에게 노출될 것입니다.
콘텐츠를 숨기는 여러 가지 방법
html의 헤딩 태그는 문서의 아웃라인을 잡는데 매우 유용합니다. <h1> - <h6>를 사용함으로써 브라우저와 다른 소프트웨어들에게 당신의 문서가 어떤 구조인지 , 어떻게 연결되어있는지 등을 알려줄 수 있습니다. 정확한 문서의 아웃라인은 매우 중요한데, SEO에도 좋고 스크린리더를 사용하는 사용자가 당신의 사이트를 살피는 데에도 도움이 됩니다. 헤딩 태그가 있어도 자연스러운데 디자인을 위해서 헤딩 태그를 사용하지 않는 경우가 있을 수 있습니다. 예로는 디자인 자체에서 문서의 구조를 전달하는 경우가 있습니다. 이러한 경우에는 마크업에서 헤딩 태그를 지우는 것이 아니라 시각적으로 숨기면 됩니다. 반드시 css의 유무에 상관없이 문서의 구조가 명확해야 합니다.
form에서 label을 감추는 것을 하나의 예로 들 수 있습니다. ( UX perspective의 you should't hide labels(라벨을 숨기지 마라) 라는 글이 있긴 하지만요)
모두로부터 콘텐츠 숨기기
hidden 속성을 사용하거나 visibility:hidden이나 display:none을 사용하여 콘텐츠를 완전히 숨길 수 있습니다. 사용자, 스크린리더나 검색엔진이 콘텐츠를 보거나 인식할 수 없습니다.
시각적으로 콘텐츠 숨기기
시각적으로만 콘텐츠를 숨기는 것은 그리 어렵지 않습니다. 다만 숨기더라도 스크린리더에서 접근이 가능하다는 것을 인식하고 있어야 하고, 브라우저 쿼크 모드에 대한 대처와 포커싱 되었을 때의 상태에 대한 고려가 필요합니다. 물론 몇몇 사람들이 이미 이렇게 사용하고 있고, 여러 설루션들이 있습니다.
관련하여 조사를 좀 하였는데, 다양한 방법들이 많이 있었습니다. 전문가들에게 그들의 의견을 물어보았고, 어떻게 하는지 알아보기 위해 추천받은 방법들을 분석해보았습니다.
.visually-hidden {
/* Remove the item from normal flow */
position: absolute;
/* Workaround for falsely pronounced, smushed text */
white-space: nowrap;
/* Set it to the smallest possible size (some screen readers ignore elements with zero height and width) */
width: 1px;
height: 1px;
/* Hide overflowing content after resizing */
overflow: hidden;
/* Reset any property that may change the elements size */
border: 0;
padding: 0;
/* Clipping defines what part of an element should be displayed. */
/* Deprecated clip property for older browsers */
clip: rect(0 0 0 0);
/* clip-path for newer browsers. inset(50%) defines an inset rectangle that makes the content disappear. */
clip-path: inset(50%);
/* It seems like at the moment nobody is quite sure why margin: -1px is there. On top of that it seems to cause issues (see: https://github.com/h5bp/html5-boilerplate/issues/1985). */
margin: -1px;
}
이 클래스와 css를 저장해두시고, 시각적으로만 숨기고 보조기술과 검색엔진에서는 접근 가능하도록 하고 싶을 때 사용해보세요.
스킵 링크
앞부분에서 설명한 클래스는 스킵 링크에도 사용할 수 있습니다. 스킵 링크는 처음에는 시각적으로 숨김 처리되어있지만 포커싱 상태일 경우 보이게 됩니다. 스킵 링크는 스크린리더나 키보드를 쓰는 사용자가 서론 콘텐츠 부분을 뛰어넘어 바로 주요 콘텐츠로 넘어갈 수 있도록 하기 위해 페이지의 가장 처음 부분에 나와야 합니다. 사용자가 페이지의 특정 부분으로 이동할 수 있도록 하는 링크입니다.
Code pen을 통해 테스트해보세요. tab을 누르면 스킵 링크가 보입니다.
의미론적으로 맞게 콘텐츠 숨기기
콘텐츠를 시각적으로 보이게 하는 것이 적절한 경우도 있지만, 아이콘을 사용하는 경우는 스크린 리더로부터 감춰야 합니다. 숨기고 싶은 요소에 area-hidden속성을 추가하고, 값에 true를 추가해주세요.
<button>
<span class="icon icon-hamburger" aria-hidden="true"></span>
<span class="text">Menu</span>
</button>
이외
다른 방법들도 있습니다. text-indent에 음수 값을 주거나 font-size나 height의 값을 0으로 주는 것입니다. 몇몇은 잘 적용되지만 주의해야 할 사항이 있습니다. webaim.org의 Techniques for hiding text를 참고해주세요.
낮은 대비를 믿지 마세요
가독성을 위해 배경과 텍스트 사이의 충분한 대비 효과를 제공해야 합니다. 저시력자뿐만 아니라 시각장애가 없는 사람들에게도 고대비는 도움이 됩니다. 햇빛이 없는 곳에서 당신의 스마트폰을 사용하는 경우를 생각해보면 쉽습니다.
색상대비가 무엇이고 왜 중요한가
WHO(World Health Organization)에 따르면 인구의 4%는 시각장애를 갖고 있습니다. 남성의 7 - 12%, 여성의 1%가 색맹입니다. 이러한 시각 손상의 대부분이 대비를 인지하는 능력을 감소시키고, 몇몇의 경우는 색상을 구별하는 능력을 감소시킵니다.
색상환의 다른 부분에 위치할 경우 두 색상은 대비됩니다. 일반적으로 두 색상의 차이가 커질수록 대비는 커집니다. 웹디자이너나 개발자인 우리에게 이것은 단순한 대비 문제가 아니라 텍스트에 잘 적용되는지에 대한 것입니다. 텍스트와 배경 사이의 대비는 일반적 저시력의 사람들도 읽을 수 있을 만큼의 명도 대비가 되어야 합니다. 이 기준을 충족했는지 가늠하고 측정할 필요가 없습니다. Web Accessibility Initiative(WAI)에서 비율을 이미 정해두었습니다.
대비 최소치 기준
대비 비율은 특정 사이즈와 너비의 텍스트와 특정 배경의 대비가 얼마나 높은 지를 말해줍니다. 비율 범위는 1 : 1에서 21 : 1 사이입니다. 비교되는 두 색상이 같은 경우 1:1이 되고, 흑/백으로 비교가 되면 21:1입니다.
Web Content Accessibility Guidelines(WCAG) 2.0에 따르면 텍스트와 배경 사이에 최소 4.5:1의 대비 비율을 유지해야 합니다. bold가 아니라면 24px 이하의 텍스트에, bold가 적용되었다면 19px 이하 텍스트에 적용됩니다. 큰 텍스트의 경우 3:1이면 충분합니다. level AA 기준을 충족하기 위한 최소 수치입니다. level AAA를 통과하기 위해서는 최소 수치가 일반 텍스트일 경우 7:1 , bold 텍스트일 경우 4.5:1입니다. 꼭 일치해야 할 필요는 없지만 아이콘을 사용하고 있다면 텍스트에 대해 제시한 대비 기준을 충족시켜야 합니다.
제 친구 Daniel에게 명도 대비가 중요가 때문에 우리가 현재 하고 있는 프로젝트에 제대로 적용해야 한다고 말했습니다. 손을 보고 난 후, Daniel은 생각했던 것보다 어려웠다고 얘기했습니다. 시각적으로 괜찮게 보이는 조합이 많지 않다는 게 문제가 아니라 최근 들어 디자이너들이 낮은 대비 조합을 사용한다는 것이 문제입니다. Apple이나 Google 같은 큰 회사들 뿐 아니라 작은 곳들도 이러한 지양해야 할 디자인 트렌드를 따르고 있습니다.
나이가 드는 것이 내 시력에 영향을 주긴 했지만,
디자인 트렌드에도 영향을 받았음에 분명하다.
대비 비율을 계산하는 공식이 있지만 걱정하지마세요. 직접 계산기를 두드리지 않아도 됩니다. 도구를 이용해 보세요.
대비 비율 계산하기
크롬 카나리아에서 개발자 도구로 대비 비율을 바로 확인하게 할 수 있습니다. Remy Sharp의 사용법 관련 블로그 글을 참고해주세요.
색상 대비와 접근성을 확인할 수 있는 많은 도구들이 있습니다. 아래 목록은 많은 도구들 중 제가 선호하는 도구입니다.
온라인
- Lea Verou의 contrast ratio
빠르고 쉬운 브라우저 명도 대비 체커
- Jonathan Snook의 Colour Contrast Check
추가 옵션을 사용 가능한 브라우저 명도 대비 체커
명도대비 외의 것들도 체크할 수 있는 브라우저 툴
- Kevin Gutowski의 Accessible Color Spaces
자동으로 명도 대비 체크되는 색상 피커
브라우저 확장 프로그램과 개발자 도구
Chrome 60은 Lighthouse에서 제공하는 새로운 audits 패널을 공개했습니다. 사이트의 접근성 점수와 관련 이슈들을 보여줌
- tota11y
명도 대비, 문서 아웃라인을 확인해주는 확장 프로그램
- aXe
사이트의 접근성 측면의 결함을 자동으로 찾아주는 확장 프로그램
이외
- Color Contrast Analyser for Sketch
WCAG와 비교하여 평가하고, 두 레이어 사이의 색상 대비를 계산하는 Sketch 플러그인
- 이 외 툴들
고대비 경험
높은 색상대비를 사용하는 것은 매우 좋으나 저시력 사용자들은 여전히 웹사이트에 사용된 색상을 바꾸길 원할 것입니다. 다양한 사용자들의 욕구가 많고, 그에 따라 색상을 바꿀 수 있는 다양한 방법들이 있습니다. 이 사실은 특정한 불확실성을 동반하고, 우리 사이트가 언제나 완전하게 접근 가능하다는 것을 확신하는 것을 어렵게 합니다. 그래서 우리는 level AA /AAA 기준을 만족하는 것만 믿어서는 안 되고, 전체적으로 사이트를 테스트해보고 고대비 대안을 제시할 수 있도록 해야 합니다.
윈도우에서 고대비 모드
윈도우에서 설정에 보면 고대비 옵션이 있습니다. 사용자는 자신만의 색상을 지정할 수 있고, 이미 설정된 테마를 고를 수 있습니다.
간단한 로그인 폼을 만들고, ( https://dribbble.com/shots/1687064-Simple-Login-Form을 참고함) 각기 다른 고대비 테마를 적용하여 테스트해보았습니다.
Anika Henke는 사용자가 웹사이트에서 어떻게 색상을 바꾸는지에 대해 글을 썼습니다. 그녀는 form을 테스트하면서 input이 보이지 않게 되고, button이 인식하기 어려운 상태가 되는 것을 발견했습니다. 위의 스크린샷에서 해당 문제를 확인할 수 있습니다. placeholder의 텍스트가 없었다면 사용자는 두 개의 input이 있는지 인식하지 못했을 것입니다. 빠르게 수정할 수 있는 방법은 input과 button에 기본 border를 주는 것입니다.(크로스브라우징 테스트는 하지 못했습니다.)
고대비 모드에서 활성화될 수 있도록 하는 미디어 쿼리를 사용하여 특정 스타일을 지정할 수 있습니다.
/* High contrast mode active */
@media (-ms-high-contrast:active) {
}
/* High contrast mode with specific black on white theme */
@media (-ms-high-contrast:black-on-white) {
}
/* High contrast mode with specific white on black theme */
@media (-ms-high-contrast:white-on-black) {
}
Patrick H. Lauke는 미디어 쿼리에 대해 그의 생각들을 Window High Contrast Mode:the limited utility of -ms-high-contrast에서 공유하고 있습니다. Greg Whitworth는 "주목적은 명도 대비에 민감성을 갖고 있는 유저에게 더 나은 경험을 제공하는 데에 도움이 되는 것입니다."라고 말하고 있습니다. 특정 색상이 어떤 것인지 대해 신경 쓸 필요가 없습니다. 좀 더 확장하여, 당신의 사이트가 어떻게 보이는지 신경 쓸 필요가 없습니다. 하지만 고대비에서 어떻게 동작하는지는 고려해야 합니다.
고대비 크롬 확장 프로그램
Google Chrome의 고대비확장 프로그램이 있습니다. 좀 더 쉽게 텍스트를 읽을 수 있도록 디자인된 여러 가지 고대비 색상 필터를 제공하고 있습니다.
고대비 대안
당신의 디자인에 충분한 명도 대비가 이뤄지지 않은 부분이 있다면, Alternate Version조항을 이용해 WCAG 기준을 만족시켜 보세요. 이에 따르면 당신은 사용자에게 고대비 페이지로 이동할 수 있는 링크나 모든 부분을 확인할 수 있도록 페이지를 바꿀 수 있는 제어요소를 반드시 제공해야 합니다.
이 대안에 대한 몇 가지 기준입니다.
- 링크나 제어요소는 눈에 띄는 부분에 있어야 합니다.
- 링크나 제어요소는 명도 대비 기준을 만족해야 합니다.
- 새로운 페이지는 기존 페이지와 같은 정보와 같은 기능을 제공해야 합니다.
- 새로운 페이지는 요구되는 기준을 모두 만족시켜야 합니다.
NoCoffee로 테스트하기
기준을 충족하는 것과 실제 사람에게 테스트하는 것은 또 다른 얘기입니다. 모든 사람이 전문적인 테스트 수단을 갖고 있지는 않습니다. 감사하게도, NoCoffee는 빠르고 쉽게 저시력, 색상 결함, 시각적 부분을 감추는 것을 테스트해볼 수 있는 기능을 제공합니다. 심각한 시력 문제를 갖고 있는 사용자가 겪고 있는 문제와 상황을 이해하는데 도움을 줍니다.
색상이 정보전달의 유일한 수단이어서는 안 됩니다.
이미 언급했지만, 매우 높은 비율의 사람들이 색맹을 갖고 있습니다. 다른 유형도 있습니다. 녹색약은 가장 많고, 빨간색과 초록색 구분을 어려워합니다. 색맹이 있는 사람들이 사이트를 이용하기 어려울 수 있기 때문에 우리는 색상만으로 정보 제공하는 것을 지양해야 합니다.
앞에서 예로 들었던 form을 다시 예로 들어보겠습니다. 성공/에러 상태를 알리도록 input에 border를 추가하였습니다. 색상만으로는 사용자에게 피드백을 줄 수 없다는 것을 아래 스크린샷을 보면 알 수 있습니다. border의 색상이 제대로 보이지 않습니다.
간단한 아이콘을 추가하는 것이 접근성과 사용자 경험을 향상하는데 도움이 될 수 있습니다.
다른 예는 링크입니다. 색상만으로 일반 텍스트와의 차이를 두어서는 안 됩니다. 좋은 방법은 밑줄을 유지하는 것입니다.
순서에 유의하기
요소들이 나열되어 있을 때 순서를 바꾸는 데에는 여러 방법이 있습니다. 예를 들어, flex-direction, flex-auto-flow로 순서를 조정하고 그리드로 위치를 분리시키는 방법도 있습니다. 이러한 속성들이 매우 도움이 되지만, DOM 순서와 실질적으로 보이는 콘텐츠의 순서상의 불일치를 야기할 수 있습니다.
아래 이미지 갤러리 예시에서 이미지들은 여러 그리드 속성을 사용하여 위치를 잡았습니다.
Grid gallery with jumbled items
...
codepen.io
언뜻 보기에는 별 문제없어 보이지만 키보드로 이미지 사이를 이동하려고 하면 예상하는 순서대로 움직이지 않는 것을 볼 수 있습니다. tab키를 눌렀을 때, 다음에 어떤 이미지가 표시될지 알 수 있는 방법이 없습니다. 이제 포커싱 스타일을 놓치는 것과 당신이 만든 최악의 시나리오를 합쳐봅시다.
예상할 수 없거나 잘못된 순서는 키보드 사용자만의 걱정거리가 아닙니다. 스크린 리더는 DOM 순서에 따라 콘텐츠를 읽습니다. 스크린 리더는 CSS로 조작한 순서에 영향을 받지 않지만 사용자들은 영향을 받습니다. 당신이 스크린 리더 사용자는 시각적으로 보이는 콘텐츠에 신경 쓰지 않는다고 생각할지도 모르겠습니다. 하지만 스크린 리더 사용자가 언제나 시각장애가 있는 것은 아니기 때문에 모든 경우가 그런 것은 아닙니다. 저시력자나 장애 상황을 경험하고자 하는 몇몇의 사람들이 화면에서 보이는 것을 보완하기 위해 스크린 리더를 사용합니다.
이러한 순서 문제는 flex나 grid item 에만 적용되지 않고, 모든 위치 관련 속성에 적용된다. 스타일이 적용되지 않고도 콘텐츠 순서가 알맞게 나열되는 것이 중요하고, 그 후에 디자인에서의 순서와 일치시키도록 해야 합니다. 그렇지 않다면 당신의 디자인을 재검토해봐야 한다. 당신이 무엇을 하든지 CSS로는 순서를 알맞게 배치할 수 없기 때문에 마크업에서 보이지 않게 요소 순서를 재조정하면 안 된다.
Rod Dodson의 Rob Dodson’s Does reordering content affect accessibility? 를 보세요. Adrian Roselli의 Source Order Matters를 보면 더 자세히 알 수 있습니다.
중요한 것에 포커싱 하기 : focus
이미 키보드 네비게이션 기본과 포커싱할 수 있는 요소에 대해 Writing Javascript with Accessibility in Mind에서 얘기했습니다. 만약 이 주제에 대해 처음 접하시는 분이라면 이 글 읽는 것을 잠시 멈추고, 위의 글을 먼저 빠르게 읽어보세요.
당신이 만든 사이트가 키보드로 이동이 가능하도록 하는 것은 매우 중요합니다. 많은 사용자들은 웹을 서핑할 때 키보드를 많이 사용합니다. 그들 중에는 운동장애가 있는 사람도 있고, 시각 장애, 손이 없는 사람이나 어떠한 이유로 트랙패드나 마우스를 사용할 수 없는 사람이 있습니다.
포커싱할 수 있는 요소를 css로 스타일링할 수 있는 방법이 몇 가지 있습니다.
포커싱 된 요소 선택하기
:focus라는 가상 클래스를 사용하여 포커싱할 수 있는 요소들의 포커싱 상태에서 해당 요소를 선택할 수 있고, 스타일을 적용할 수 있습니다.
a:focus {
background-color: #000000;
color: #FFFFFF;
}
기본 포커스 스타일은 모든 브라우저에서 통일되어 있지 않습니다. 외관상 별로이고, 몇몇의 경우에는 당신의 디자인과 잘 어울리지 않기도 합니다. 사용자 경험을 향상하고, 당신의 디자인과 잘 맞는 각자의 포커스 스타일링을 하는 것을 권장합니다.
당신이 어떻게 하던지 대안이 되는 스타일을 적용하지 않는다면, 기본 outline(점선, 파란색/주황색 테두리)은 지우지 마세요. 키보드를 주요 수단으로 사용하는 사용자들은 포커스가 어디 있는지 확인할 수 없다면 당신의 사이트를 사용할 수 없을 것입니다.
이건 단순한 팁이 아니고, level AA 기준입니다.
키보드 사용자와 마우스 사용자를 구분하기
이미 언급한 것과 같이, 디자이너를 괴롭히는 것 중 하나는 브라우저마다 다른 포커스 스타일입니다. 디자이너를 괴롭히는 또 다른 요소는 포커스 스타일이 마우스를 사용할 때에도 보인다는 것입니다. 가끔은 적용한 스타일이 보이지 않아도 되는 경우가 있습니다. 마우스 사용자에게는 이러한 스타일이 보이는 것이 주의를 뺏는 요소가 될 수도 있고, 별로 기분이 좋지 않게 하는 요인이 되기도 합니다.
키보드 사용자가 더 이상 해당 요소에 접근할 수 없게 되기 때문에 outline을 지우는 것은 선택사항이 아닙니다. 우리가 해야 하는 것은 키보드 사용자와 마우스 사용자를 구분하는 것입니다. CSS level 4 selectors 명세에 나오는 :focus-ring이라는 가상 클래스를 사용하면 가능합니다. :focus-ring 가상 클래스는 :focus 가상 클래스와 같이 사용되고, UA에서 포커스는 "focus ring"을 통해서 요소에 적용될 수 있다고 실험을 통해 정의하였습니다. (출처 : CSS Selectors Level 4 Draft)
/* Remove the default outline */
:focus {
outline: none;
}
/* Add an outline only when it should be visible */
:focus-ring {
outline: 2px solid blue;
}
안타깝게도 브라우저들에서 :focus-ring의 표준 사용을 지원하고 있지 않지만(firefox는 -moz-focus-ring을 지원함), . focus-ring 클래스를 추가함으로써 가벼운 poly-fill을 사용할 수 있습니다.
/* If JavaScript is active and works, select all focusable elements that do not have the.
focus-ring class and remove the outline */
.js-focus-ring :focus:not(. focus-ring) {
outline-width: 0;
}
더 자세한 내용은 Rob Dodson의 a11ycasts episode, Focus Ring! 을 참고하세요.
자식이 포커싱된 경우 요소 스타일링 하기
:focus-within은 대부분의 주요 브라우저에서 지원하고 있는 상대적으로 최신에 속하는 가상 클래스입니다. 이 가상 클래스로 현재 포커싱 된 자식 요소를 갖고 있는 요소를 선택할 수 있습니다.
form:focus-within {
box-shadow: 0 0 4px 6px rgba(80,88,156,0.2);
}
CodePen을 통해서 확인해보세요.
더 자세한 포커스의 기본을 알고 싶다면 유튜브에서 What is Focus?를 볼 수 있습니다.
그리드와 플랫한 문서 구조
새로운 사이트를 만들 때 보통 html을 작성하는 것에서부터 시작합니다. 논리적 순서에 맞게 올바른 마크업을 선택하고 요소를 집어넣습니다. html 문서가 논리적으로 맞고, 순서와 구조가 잘 구성되었다면 CSS를 추가합니다. CSS 그리드 레이아웃 이전에 레이아웃을 만드는 것은 매우 까다롭습니다. 특히 DOM 순서와 디자인 순서가 일치하지 않을 경우가 그렇습니다. 몇몇의 상황에 float, position 심지어 flexbox가 유연하게 작용하지 않고, DOM 순서를 바꾸고 싶은 유혹을 받게 됩니다. 그리드를 통해서 영역과 위치 이동을 할 수 있게 된 덕분에 우리는 유연성 있게 요소들을 위치시킬 수 있습니다. 이것은 매우 좋지만, 그리드 또한 문서 구조와 일치해야 한다는 새로운 유혹을 받게 됩니다.
h2와 ul을 이용해 아래 디자인을 만들었다고 가정해봅시다. (당신은 h2와 ul이 가장 적절하다고 생각하여 사용한 것입니다.)
<div class="wrapper">
<h2>Heading</h2>
<ul>
<li><a href="#">Element 1</a></li>
<li><a href="#">Element 2</a></li>
<li><a href="#">Element 3</a></li>
<li><a href="#">Element 4</a></li>
<li><a href="#">Element 5</a></li>
<li><a href="#">Element 6</a></li>
</ul>
</div>
요소들을 열에 배치시키고, h2의 위치를 잡는 것은 아래처럼 꽤 쉽거나 아래처럼 보일 것입니다.
.wrapper {
display: grid;
grid-template-columns: 120px repeat(2, 1fr);
grid-gap: 20px;
}
h2 {
grid-column: 2 / -1;
}
우리가 예상한 것처럼 보이지 않습니다. 문제는 오직 그리드 컨테이너의 바로 아래 자식만 그리드 영역으로 잡힐 수 있는데, 이 경우에서는 <h2>와 <ul>가 바로 아래 자식이고, <li>는 바로 아래 자식이 아니기에(손자임) 그리드 아이템처럼 행동하지 않습니다. 해결책은 구조를 단순화하여 <ul>을 지우고, <li>를 <div>로 바꿔 그리드 컨테이너의 바로 아래 자식으로 만드는 것입니다.
가장 좋은 해결책은 <ul>의 display 속성을 subgird로 바꾸는 것인데 안타깝게도 subgrid는 명세의 level 1에 들어가지 못했고, 반영될 때까지 기다려야 합니다.
<ul>에 display: contents를 사용할 수 있지만 firefox만이 유일하게 지원하고 있습니다. display: contents는 요소의 자식들을 해당 요소는 무시하고, 해당 요소의 부모의 바로 아래 자식인 것처럼 보이게 합니다.
결론적으로 <ul>을 위해 다른 그리드를 정의하면 됩니다. 이상적인 방법은 아니지만 문서의 구조를 단순화하거나 의미론적으로 타협하는 것(위에서 div으로 대체했던 방법)보단 나은 방법입니다. 매우 기초적인 예시이고, 리스트가 전체 그리드에 걸쳐지기 때문에 부모 그리드로부터 몇몇 속성을 물려받을 수 있습니다.
ul {
/* span the whole grid */
grid-column: 1 / -1;
/* create another grid and inherit the values from the parent grid */
display: inherit;
grid-template-columns: inherit;
grid-gap: inherit;
/* overwrite display for browsers that understand display: contents */
display: contents;
}
두 해결책이 작동하는 것은 Codepen에서 확인할 수 있습니다.
결론
여러 가지를 다뤘지만, 이것들이 CSS와 접근성 관련하여 여러분이 알아야 할 전부는 아닙니다. 오히려 시작점이 더 맞다고 생각합니다. DOM을 가져오고, 포커스 순서를 맞추고, 높은 대비를 유지하고, 접근성에 대해 생각하며 디자인한다면, 여러분은 이미 잘하고 있는 것입니다. 앞으로 만들 새로운 페이지나 사이트에서도 조금 더 접근성에 대한 고려를 한다면 더 나은 웹을 만들 수 있을 것입니다.
Designing with constraints in mind is simply designing well.
글을 읽으신 분들이 즐겁고 유익하였길 바랍니다. 질문이나 의견이 있다면 댓글을 남기거나 트위터로 연락해주세요.
이 글을 작성하는 데 도움을 준 제 멘토 Aaron Gustafson에게 감사합니다.
+ 더 많은 접근성 팁
이 글을 4개의 연재 시리즈 중 세 번째 글입니다. 마지막은 작업 중이고, 곧 오픈하도록 하겠습니다.
1. Writing HTML with accessibility in mind
2. Writing JavaScript with accessibility in mind
3. Writing CSS with accessibility in mind
4. 다음 글 : Learn how to design and develop with accessibility in mind
읽어주셔서 감사합니다. 유익하였다면 좋아요와 이 글을 공유하는 것 잊지 마세요.
제가 다음 글을 작업하는 동안, 제가 쓴 다른 글들도 확인해보세요.
Progressively Enhancing CSS Layout: From Floats To Flexbox To Grid
Progressively Enhancing CSS Layout: From Floats To Flexbox To Grid — Smashing Magazine
“When can I start using CSS grid layout?” “Too bad that it’ll take some more years before we can use grid in production.” “Do I need Modernizr in order to make websites with CSS grid layout?” “If I wanted to use grid today, I’d have to build two to three v
www.smashingmagazine.com
The Difference Between Explicit and Implicit Grids
The Difference Between Explicit and Implicit Grids | CSS-Tricks
Grid Layout finally gives us the ability to define grids in CSS and place items into grid cells. This on its own is great, but the fact that we don't have
css-tricks.com
관련 글과 자료
인식하기 쉽고 읽기 쉬운 텍스트
- Your Body Text Is Too Small by Christian Miller
- How the Web Became Unreadable by Kevin Marks
- Why is Vertical Rhythm an Important Typography Practice? by Zell Liew
- Precise control over responsive typography by Mike Riethmuller
가상 요소의 content 사용 시 주의하기
- Accessibility support for CSS generated content by Léonie Watson
화면 스크린만이 접근 수단이 아닙니다
- I totally forgot about print style sheets by Manuel Matuzović
불완전한 지원을 하는 속성에 대한 대안책
- CSS and progressive enhancement by Michael Scharnagl
콘텐츠를 숨기는 다양한 방법
- Techniques for hiding text
- Beware smushed off-screen accessible text by J. Renée Beach
- a11y.js: Hiding DOM elements
- Bulletproof Accessible Icon Fonts by Zach Leatherman
낮은 명도 대비를 믿지 마세요
- How users change colours on websites by Anika Henke
- Color Contrast And Why You Should Rethink It by Cathy O’ Connor
- What is Color Contrast? by Rachel R. Vasquez
- A Beginner’s Guide to Contrasting Colors by Jacci Howard Bear
색상이 정보전달의 유일한 수단이어서는 안 됩니다
- Be Kind to the Color Blind by Chris Champbell
- On Link Underlines by Adrian Roselli
순서 고려하기
- Not All Screen Reader Users Are Blind by Adrian Roselli
- Source Order Matters by Adrian Roselli
중요한 것에 집중하기 : focus
- a11y.js: Default Browser Focus Outline Styles
- Keyboard-Only Focus by Roman Komarov
그리드와 flat 한 문서 구조
- Modern CSS Layout, power and responsibility by Rachel Andrew
'번역' 카테고리의 다른 글
| 가장 좋은 아이콘은 텍스트 라벨입니다 (0) | 2019.06.24 |
|---|---|
| 키보드와 스크린 리더의 네비게이션 차이 (0) | 2019.06.13 |
| 접근성을 고려한 HTML 작성하기 (0) | 2019.05.29 |
