부트캠프 코스 중에서 기술면접 대비 세션이 있었다. 이제까지 한 달 동안 배운 html, css, javascript, dom 관련 주제 중에서 면접에 나올 만한 예상 질문 리스트를 추려서 주고, 그 중에 일부를 선택해서 모의 면접을 보는 식으로 진행되는 세션이었다.
💡 기술 면접 Tip :
결론은 간명하게, 설명과 사례는 구체적으로
css의 box model, 자바스크립트의 스코프, 클로저, 원시자료형과 참조자료형의 차이 등은 충분히 예상 가능한 질문이었지만 <li> 요소는 왜 <ul> 요소의 자식 요소여야만 할까? 라는 질문은 이제껏 너무 당연하게 마크업을 해오면서 한 번도 생각해 보지 못한 질문이었다.
일단 html 파일을 하나 생성해서 브라우저에 띄워보기로 했다.
<body>
<div>
<li>item1</li>
<li>item2</li>
<li>item3</li>
<li>item4</li>
</div>
</body>
<ul> 요소로 감싸지 않고 <div>로 감싸도 화면에는 똑같이 보인다. 심지어 부모 요소인 <div>를 제거하고, 바로 <body> 아래에 <li> 요소들을 나열해도 똑같은 화면이 보인다. 따라서 <li> 요소가 항상 <ul> 또는 <ol> 요소의 자식 요소여야만 하는 것은 아니다.
하지만 여기서 이렇게 끝낼 수는 없지. 본격적으로 웹 서칭을 시작했다.
HTML의 웹 표준을 정의한 WHATWG의 HTML Living Standard에 따르면 <ul>, <ol> 뿐만 아니라 <menu> 태그의 자식 요소로도 <li> 요소가 올 수 있다. 이렇게 <li> 요소를 <ul>, <ol> 등의 부모 요소로 감싸주는 것은 보다 semantic한 마크업을 위해서다. semantic한, 다시 말해서 보다 의미론적인 의미(?)를 담고 있는 태그를 사용해 웹페이지를 만드는 것은 동료 개발자에게 해당 코드의 의미를 즉각적으로 전달할 수 있다는 장점도 있지만, 이에 더해 웹 표준을 지키려는 노력의 일환이다.
웹 표준을 준수하는 것은 곧바로 웹 접근성을 향상시키는 것으로 이어진다. 가령 <ul>이나 <ol> 요소를 쓰지 않고 바로 <li> 요소를 써서 아이템을 나열해도 화면의 컨텐츠를 '보는' 사용자는 아무런 차이도 느끼지 못한다. 하지만 스크린리더 기능을 사용해 컨텐츠를 '듣는' 사용자의 사용자 경험은 다르다. <ul>이나 <ol> 요소를 부모 요소로 쓸 경우, 스크린리더는 사용자에게 해당 요소가 목록이라는 것과 목록에 있는 아이템의 개수를 알려준다. 목록의 전체 아이템 개수와 목록 중에서 현재 어느 아이템을 읽고 있는지를 사용자에게 알려주기 때문에 스크린리더 기능을 사용하는 사용자가 어떤 내용을 듣고 있고, 앞으로 어떤 내용이 나올지 예상하면서 들을 수 있다.
개발자 구인 공고의 job description을 보면 웹 표준과 웹 접근성을 준수하는 마크업에 대해 종종 언급이 되는 걸 본 적이 있다. semantic한 웹 페이지에 대해서 한 번 더 생각해 볼 수 있는 계기가 된 질문이었다. 오늘의 일기 끝🥸
'배워서 남 주자' 카테고리의 다른 글
| console.log(), console.dir() 그리고 console.table() (0) | 2022.11.30 |
|---|---|
| 화살표 함수를 쓸 때 주의할 점 (1) | 2022.11.24 |
| children vs. childNodes (0) | 2022.11.10 |
| 배열 reduce 메소드 - array.reduce() (0) | 2022.11.08 |
| 변수, 선언, 할당, 메모리 그게 다 뭔데? (부제: 원시자료형과 참조자료형의 차이) (1) | 2022.11.07 |