마크업에도 유의가 필요하다고!?
그렇다..내가 HTML의 효용도를 과소평가 했던 것이다..
HTML은 컨텐츠의 구조를 정의하는 마크업 언어다. javaScript처럼 상호작용하는 액션을 정의할 수 있는 ‘프로그래밍 언어’와는 구분된다. 난 프로젝트에서 프론트엔드 작업을 하는 일이 많았는데 그 과정에서 마크업을 ‘잘’ 하려면 어떤 것들을 고려하면 좋을지 자료들을 찾아보았다. 그리고 실무자들과 함께 기획과 UX 디자인에 대한 얘기를 나누었을때 이 자료들이 꽤나 유용했으며 ‘웹’이라는 최종 결과물에 크고 작은 영향을 미칠 수 있다는 사실을 알았다.
예시를 들어보자.
개발자가 웹 기획안을 읽다가 한 버튼에 서로 다른 두 가지 동작이 포함되어 있는걸 확인 -> 버튼의 의도를 명확히 파악하기 힘들고 웹 접근성을 해치지 않을까? -> 기획자에게 말씀을 드림 -> 동작 예측이 가능한 버튼 두개가 생김
-> 무야호! 컨텐츠 의도가 명확해졌다!
그렇다.. 결국 컨텐츠의 구조를 정의하는 고민을 한다는 건 지금 당장 개발 작업이 아니더라도 기획이나 UX를 개선할 수 있는 기회로 이어질 수 있는 것. 모든 실무는 연결되어 있는거 아니겠습니까..
지금부터 어떻게 하면 마크업이라는 언어를 의도대로 작성할 수 있는지, 어떤 장점이 있는지, 실무에서는 어떻게 했는지에 대해 얘기해보려 한다.
마크업 원칙
사실상의 표준(De facto standard)처럼 널리 퍼져있는 마크업 원칙들을 크게 다섯개로 정리해보았다.
1. 웹 표준
W3C가 지정한 표준안에 따라 목적과 방법에 맞게 웹 페이지를 제작해야 한다.
2. 웹 접근성
accessibility는 내가 최근 관심을 갖기 시작한 이슈이다.
여성 개발자 컨퍼런스에서 연사자 ‘정효진’님이 주요하게 다룬 의제이며 IEEE에서 발표한 코드 윤리강령에서도 공공의 이익을 위해 개발자가 기여해야 할 문제라며 반복 강조한다.
인터넷을 통해 볼 수 있는 정보들은 나날이 늘어나는데 노인이나 시각 장애인 등 신체가 불편한 사람은 의지와 상관없이 불편함을 겪어야 한다. 일부만 접근가능한 웹 사이트가 소수의 사람들의 접근을 배제하는 것을 넘어서 그게 당연하다는 차별적 관습을 조장한다면? 개발물에 직접적인 영향을 미치는 기회가 있는 작업자로서 내가 할 수 있는게 뭐가 있을까?를 고민해보기로 했다. 그리고 접근성은 그 실천의 첫발이다.
다시 돌아와서, 그렇다면 마크업을 통해 웹 접근성을 어떻게 높일 수 있을까?
아래 목록은 mozilla-HTML: A good basis for accessibility를 참고했다.
- 목적에 부합하는 컨텐츠를 만들기 위해 마크업시 의도에 맞는 요소 사용하기
- IR(Image replacement) 기법: 이미지를 볼 수 없는 사용자에게 적절한 대체 텍스트 제공하기 (alt속성)
- 비디오 컨텐츠를 키보드로 제어할 수 있도록 핸들러 추가하기
- CSS를 해결하기 위해 Headings를 남용하지 않기 (H1-H6)
- CSS 요소를 화면에서 숨길때 Screen reader가 인식하도록 처리
3. 시맨틱 마크업
개발자는 브라우저가 의미를 알 수 있는 태그를 작성해야 한다. semantic tag 종류에는 main
, section
, article
, aside
등이 있다. 모든 박스를 div, span으로 처리하던 때가 있었으나.. 크게 뉘우친 부분인 것 같다. 시맨틱 마크업을 준수하면 아래와 같은 세가지 장점을 얻을 수 있다.
- SEO: 검색엔진이 시맨틱 태그를 주요히 인식하여 검색 결과에 영향을 미친다.
- 접근성: 페이지를 시각으로 확인할 수 없는 사람들을 위해 reader가 페이지 내용을 읽어 음성을 전달하는데 이때 듣는 사람이 컨텐츠 구조를 이해하는데 도움이 된다.
- 코드 가독성: 마크업을 작성한 후로 긴 시간이 지나고 다시 코드를 보았을때 문서 구조를 파악하기 좋다.
참고로 난 https://blueshw.github.io/2020/05/09/know-html-semantic-elements/ 이분의 블로그 글을 참고해 시맨틱 태그를 이해하고 구분할 수 있었다.
4. 크로스 브라우징
브라우저 마다 마크업을 해석하는 방식이 다르다. 또한 initial CSS value가 다르게 적용되어 있기 때문에 동일한 페이지여도 브라우저가 다르면 출력 결과가 다른 상황이 벌어진다. 입력과 사용이 브라우저에 의존해 문제가 생기지 않도록 작업자는 ‘크로스 브라우징’을 처리할 수 있다. 모든 브라우저에서 동일한 화면을 볼 수 있도록 말이다.
- reset.css 만들기: 기본 css를 초기화 시키고 프로젝트에 맞게 제작
- vendor prefix 설정: CSS에서 각 브라우저에서 판독 가능케 하는 프로퍼티
위와 같은 장점들을 알게 된 이후로는 될 수 있으면 지키기 위해 노력한다. 한 사람이라도 중요성을 알고 있으면 팀 전체에 영향을 줄 수 있는 일이니 스스로 자각하고 실천으로 옮기며 좋은 관행을 만들어 갈 수 있을 것 같다. mdn에서 얘기하는 ‘완벽하지 않더라도 이러한 노력들이 중요한 이유’를 언급하고 글을 마친다.
The goal isn’t “all or nothing”. Every improvement you can make will help the cause of Accessibility.