반응형 웹을 위한 미디어 쿼리
미디어 쿼리를 사용하면 콘텐츠 자체를 변경하지 않고 장치의 해상도, 뷰포트의 너비, 미디어의 유형 같은 조건에 따라 스타일을 지정할수 있다.
데스크톱과 모바일, 태블릿 등 화면의 크기에 따라 다른 스타일을 지정하거나 인쇄, 음성 장치등의 조건에 따라 다른 스타일을 적용할수 있다.
미디어 쿼리 작성은 크게 CSS 파일 내부에 작성하거나 <link> 나 <style> 에 media 속성으로 작성
각 스타일은 media 속성에 작성된 조건에 해당될때 적용된다. 하지만 css 파일 (stylesheet) 은 조건 여부와는 상관없이 다운로드 되니, 이점을 주의.
미디어 쿼리는 미디어 타입과 미디어 기능을 기준으로 동작. 두 조건이 모두 일치할때 해당 코드가 동작.
미디어 타입 : all, print, screen
미디어 기능 : width, height 등 장치의 환경및 특성. 이 값은 괄호로 묶어서 나타냄. min-, max- 를 이용해 최소, 최대 조건을 명시할 수도 있다. max 면 '이하' min 이면 '이상' 일때 스타일을 적용.
@media (max-width: 425px), (max-height: 425px) {
/* mobile */
font-size: 0.75rem;
padding: 0.125rem 0.5rem;
}
모던 브라우저에서는 >, =, < 등의 비교 연산자를 사용해 min, max 처럼 작성할수 있다. 직관적이지만 지원하지않는 브라우저가 다수 있다.
@media (width =< 425px), (height =< 425px) {
/* mobile */
font-size: 0.75rem;
padding: 0.125rem 0.5rem;
}
미디어 타입과 기능은 ',' and not only 등의 연산자로 이어서 작성
접근성
웹 접근성은 모든 신체적 한계, 환경적 한계를 고려해 개발하는것을 의미.
우리나라의 장애인 차별 금지법에도 웹 접근성과 관련된 내용이 있기 때문에 의무적으로 지켜야하는 사항.
장애가 있거나 노령으로 인한 신체 변화, 여러기기 환경을 사용하는 모든 사람이 웹 사이트와 도구등을 사용할수 있도록 개발하는 것을 의미.
웹 접근성 지침은 W3C 에서 설립한 WAI 에서 전문적으로 연구하며 가이드라인 제공.
웹 컨텐츠에 관한 내용, 사용자들이 사용하는 도구 개발에서 지켜야할점, 브라우저나 확장 프로그램을 만드는 사람들이 주의해야 할점 등을 구분해 가이드 라인 작성.
이번에는 그중 WCAG (Web Content Accessibility) 기반으로 몇가지 가이드라인과 적용 방법을 설명.
WCAG 에서 다루는 Content 는 웹 페이지, 프로그램의 정보를 의미.
텍스트, 이미지, 사운드 같은 정보를 어떻게 작성해야 더 많은 사람이 쉽개 이해하는지 작성한 단일 공유 표준.
속어, 약어 사용을 지양하라
불필요한 전문용어, 속어, 약어를 사용하는것은 지양해야한다.
위와 같은것들을 사용하면 대부분의 사람 모두가 정보를 이해할 가능성이 매우 낮아지며 외국인 또한 사이트를 이해하기 매우 힘들어 진다. 약어를 사용하게 된다면 풀어서 모두가 이해할 수 있도록 작성하고, 속어나 비속어는 사용하지 않는것을 권장.
콘텐츠의 제목과 단락을 명확하게 구분
스크린 리더는 시각 장애인을 위해 컴퓨터의 화면을 읽어주는 프로그램이다.
컨텐츠 내의 제목과 단락을 명확히 구분하는것은 스크린 리더가 내용을 파악할때 도움을 준다.
HTML 을 작성할때 제목요소와 단락을 내용의 의미에 맞게 나누는것이 중요하다. 스크린 리더는 제목 요소를 기준으로 목차를 만들거나 이전, 이후 문단으로 이동하는 기능을 제공할 때가 많다.
또한 문단으로 내용을 적절하게 나누면 스크린 리더가 속도를 조절해 더 명확히 내용을 전달.
+ 시맨틱한 마크업을 해주게 되면 스크린 리더가 정보를 탐색할때 기계에 추가로 정보를 제공해 각 요소의 내용에 맞게 읽는 방식을 조절할 수 있다.
키보드 동작을 제공하자
<div> 같은 태그를 이용해 <button> 이나 <input> 같은 요소와 비슷한 기능을 구현하게 되면, 기본요소들이 제공하는 키보드 동작들을 사용하지 못하게 된다.
엔터키나 탭키를 누를때 해당요소로 이동시키는 동작등의 상호작용들을 누릴수 없다.
<select> 또한 <div>로 구현하면 이벤트를 추가하지 않는 이상 화살표로 아이템을 선택하거나 탭으로 이동하는 여러 동작이 제대로 작동하지 않는다.
또한 스크린리더가 해당요소를 어떤 요소인지 파악하지 못하는 문제가 있다.
그럼에도 불구하고 <div>를 반드시 사용해야 한다면 몇 가지 추가적인 코드 작성으로 사용목적과 유사하게 만들어야 한다.
- role : 해당 요소의 원래 목적을 작성. <div> 를 <button> 으로 사용한다고 하면, role=button 으로 작성하여 스크린 리더등 기계에서 해당 요소를 버튼 으로 인식.
- tab-index : 해당 요소를 탭키로 도달하게 하는 속성. 해당 속성을 통해 탭키로 이동할 다음 키보드 위치를 지정.
- 키보드 이벤트 리스너 추가 : 버튼 동작이 엔터나 스페이스로 동작하게끔 JS로 이벤트를 추가.
<div
tabIndex="0"
role="button"
id="button-id"
className="div-as-button"
>
div로 만든 버튼
</div>
Focus 하는 지점을 명확히
웹사이트는 키보드만으로 모든 기능이 동작해야 한다. 특히 장해가 있는경우 키보드 조작 비중이 높아진다.
키보드 사용자는 일반적으로 탭키를 이용해 링크, 버튼, 텍스트를 입력하는 부분을 찾는다.
항목에 Focus가 된다면 시력이 있는 사용자를 위해 윤곽선이 나타나야 한다.
이런 윤곽선은 기본으로 나타나지만 outline CSS 프로퍼티를 0이나 none 으로 지정할 경우 Focus 가 된 요소인지 화면에서 식별할수 없게 된다.
하지만 윤곽선을 지우는 것은 마우스를 사용할수 없는 사람들에게 현재 포커스 지점을 알려줄수 없어 지양해야 하며,
윤곽선을 지운다면 Focus 할 방법을 따로 지정해야 한다.
멀티미디어 요소에 접근성을 부여하자
스크린 리더는 텍스트에 접근해 해당 요소를 읽지만, 이미지나 동영상, 오디오는 모든 스크린 리더에서 접근할 수 없다.
이미지나 동영상은 시각 장애, 청각 장애가 있으면 접근하기 힘들어진다. 하지만 이러한 요소들이 어떤 의미인지 전달해 주는 속성들이 있다.
<img src="coffee.png">
스크린 리더는 이런 이미지를 "coffee.png, image" 라고 읽는다. 예시처럼 잘 설명한다면 문제가 없지만 파일이름이 해당 이미지랑 관련 없거나 너무 포괄적인 의미라면 어떤 이미지 인지 판단하기 어렵다.
<img src="coffee.png" alt="컵에 담긴 따뜻한 아메리카노" title="아메리카노" />
위의 예제 코드처럼 alt 와 title 속성을 작성하면, 스크린 리더는 "컵에 담긴 따뜻한 아메리카노" 라고 읽는다.
alt 속성을 통해 이미지가 시각적으로 어떤 모습인지 오바르게 전달해야 하며, 개인적인 견해를 작성하는 것을 지양해야 한다.
이 외에 해당 이미지가 문서에서 특별한 의미가 없다면 background 이미지로 작성하거나 alt 속성에 빈 문자열을 지정하는것을 권장.
여기서 작성한 방법 외에 애니메이션이나 깜빡이는 효과, 색상 선택에도 주의를 기울여야 하며,
ARIA (Accessible Rich Internet Applications ) 등 주의해야할 부분이 존재한다.
웹 접근성 가이드 라인을 모두 완벽하게 맞추는 것은 사실상 불가능 하다. 여러 디자인과 서비스의 명세에 따라 제어할 수 없는 요소들 또한 존재하기 때문이다.
하지만 더 많은 사람이 편견없이 사이트를 이용하고, 더 나은 웹 생태계를 위해 프런트엔드 개발자는 이러한 가이드를 항상 고려하고 지키려는 노력을 해야한다.
( 정말 멋진 말이라고 생각한다. 프론트엔드 개발자로써의 의무라고 생각 하고 지킬수 있도록 노력해야겠다. )
각 프레임워크 마다 공식문서 웹 접근성 지침이 있다.
https://reactjs.org/docs/accessibility.html
https://v3.vuejs.org/guide/a11y-basics.html
https://angular.kr/guide/accessibility