웹사이트에서 돋보기 아이콘을 누르면 검색창이 열리고, X 아이콘을 누르면 창이 닫힙니다. 눈으로 보면 기능을 짐작할 수 있지만 스크린리더에서는 버튼의 이름이 제대로 전달되지 않을 수 있습니다. 화면에는 아이콘이 있는데 보조 기술에는 단순히 '버튼'이라고만 알려지는 상황입니다. 이때 버튼의 크기나 색상을 바꾸는 것만으로는 문제가 해결되지 않습니다. 스크린리더에 전달되는 '접근 가능한 이름(Accessible Name)'을 확인해야 합니다. HTML 코드에서 이름을 제공하는 방법과 Chrome 개발자 도구로 수정 전후를 점검하는 절차를 살펴보겠습니다. 핵심은 모든 아이콘 버튼에 aria-label을 추가하는 것이 아닙니다. 이미 의미 있는 텍스트가 있다면 이를 활용하는 것이 좋고, 다른 요소의 텍스트를 참조..

모바일 웹사이트에서 검색 아이콘을 눌렀는데 옆의 메뉴가 열리거나, 페이지 번호를 누르려다 다른 번호가 선택되는 문제가 있습니다. 버튼이 화면에 잘 보이더라도 실제 손가락으로 누를 수 있는 영역이 너무 작거나 인접한 버튼과 붙어 있으면 잘못 누르기 쉽습니다. 해결할 때는 아이콘을 무조건 크게 만드는 것보다 실제 클릭 영역의 크기, 주변 버튼과의 간격, 적용하려는 접근성 기준을 구분해야 합니다. WCAG 2.2에서는 기본 최소 기준으로 24×24 CSS 픽셀을 제시하고, 더 엄격한 강화 기준에서는 44×44 CSS 픽셀을 사용합니다. 이번 글에서는 두 숫자의 차이를 살펴보고 Chrome 개발자 도구에서 실제 버튼 크기를 확인한 다음, CSS로 클릭 영역을 늘리는 방법과 버튼을 키우기 어려울 때 간격을 조정하..

PC에서는 정상적으로 보이던 웹사이트 배너가 휴대폰에서 양옆이 잘리거나, 카드 썸네일 속 인물이 지나치게 확대되어 보이는 경우가 있습니다. 반대로 이미지는 전부 나타나지만 위아래에 빈 공간이 생기거나, 사진 속 사람이 가로로 늘어나 보이기도 합니다. 이미지 파일이 손상된 것이 아니라 원본 사진과 화면에 표시할 영역의 가로세로 비율이 서로 달라 발생하는 현상일 수 있습니다. 이때 CSS를 무작정 바꾸면 잘림은 해결되더라도 여백이나 왜곡이라는 다른 문제가 생깁니다. 해결의 핵심은 세 가지를 구별하는 것입니다. object-fit은 사진을 표시 영역에 어떻게 맞출지, object-position은 사진의 어느 부분을 중심으로 보여줄지, aspect-ratio는 요소의 가로세로 비율을 어떻게 정할지 결정합니다...

CSS에서 선택자를 더 구체적으로 작성했는데도 버튼 색상이 바뀌지 않거나, 스타일시트 아래쪽에 추가한 규칙이 적용되지 않는 일이 있습니다. 특히 @layer를 도입한 뒤 이런 현상이 생겼다면 CSS 코드의 작성 순서보다 캐스케이드 레이어의 우선순위를 먼저 살펴볼 필요가 있습니다. @layer는 스타일 충돌을 체계적으로 관리하기 위한 CSS 기능입니다. 그러나 일반 CSS 선언과!important 선언에서 레이어 우선순위가 서로 반대로 적용되기 때문에 기존 CSS의 선택자 규칙만 생각하면 결과를 잘못 판단하기 쉽습니다. 핵심은 세 가지입니다. 일반 선언은 나중에 생성된 레이어가 우선합니다. 레이어 밖에 있는 일반 선언은 레이어 내부의 일반 선언보다 우선합니다. 하지만!important가 붙으면 레이어 순서..

웹사이트에 웹폰트를 설정했는데 글자가 여전히 기본 글꼴로 보인다면 CSS 파일부터 수정하기 쉽습니다. 하지만 글꼴 파일을 찾지 못한 경우와 파일은 정상적으로 다운로드했지만 실제 텍스트에 적용되지 않은 경우는 해결 방법이 다릅니다. 크롬 개발자 도구에서 실제로 사용된 글꼴과 네트워크 요청을 구분하면 불필요하게 CSS를 수정하거나 CORS 설정을 변경하지 않고도 문제의 범위를 좁힐 수 있습니다. 특히 404 오류, CORS 차단, 글꼴 이름 불일치, 로컬 설치 글꼴의 영향은 서로 다른 증거로 판단해야 합니다. CSS에 적힌 글꼴과 화면에 사용된 글꼴은 다를 수 있습니다 font-family에 원하는 글꼴 이름이 표시된다고 해서 브라우저가 반드시 그 글꼴 파일로 문자를 그렸다는 뜻은 아닙니다. 해당 파일을 불..

윈도우에서 다크모드를 켰는데 웹사이트는 여전히 흰색이거나, 화면 배경은 어두워졌는데 입력창만 밝게 남아 있는 경우가 있습니다. 반대로 사이트에서 다크모드를 구현하지 않았는데 Chrome에서는 색상이 자동으로 바뀌기도 합니다. 이 문제는 모두 같은 설정으로 해결되지 않습니다. 사용자의 테마 선호를 감지하는 CSS, 웹페이지 요소의 색상을 지정하는 CSS, 브라우저가 직접 그리는 기본 UI의 색상 처리가 서로 다르기 때문입니다. 이번 글에서는 Chrome 개발자 도구로 문제가 발생하는 위치를 확인하고, prefers-color-scheme과 color-scheme을 어떤 상황에서 수정해야 하는지 구분합니다. 실제 사이트를 수정하기 전에 사용할 수 있는 독립적인 HTML 테스트 코드도 제공합니다.화면 증상에 ..

웹사이트에서 팝업이나 모달 창을 만들었는데 상단 메뉴, 고정 헤더, 사이드바 뒤로 숨어버리는 경우가 있습니다. CSS의 z-index를 100에서 9999로, 다시 999999로 높여도 달라지지 않는다면 숫자보다 요소가 속한 겹침 구조를 살펴봐야 합니다. 핵심은 두 가지입니다. 일반 HTML 요소는 부모의 stacking context(쌓임 맥락)에 영향을 받지만, 브라우저의 top layer에 올라간 모달은 일반 문서의 z-index 계층과 다른 규칙으로 표시됩니다. 문제를 해결하려면 현재 팝업이 어느 쪽에 해당하는지부터 구분해야 합니다. z-index가 999999인데도 팝업이 뒤에 표시되는 이유 z-index는 요소가 겹쳐지는 순서를 조절하는 CSS 속성입니다. 그러나 모든 요소의 z-index를 ..

PC에서는 정상인 웹사이트가 스마트폰에서는 하단 버튼이 잘리거나 화면 아래에 불필요한 스크롤이 생길 때가 있습니다. 특히 CSS에서 height: 100vh를 사용하는 로그인 화면, 첫 화면, 전체 화면 메뉴에서 나타나기 쉬운 문제입니다. 하지만 모든 하단 잘림 현상을 100dvh로 바꾸는 것만으로 해결할 수는 없습니다. 브라우저 주소창이 차지하는 공간인지, 콘텐츠가 화면보다 긴 것인지, 입력창을 눌렀을 때 나타나는 가상 키보드 때문인지에 따라 수정할 부분이 다릅니다. 이번 글에서는 세 상황을 구별하고, CSS 수정 예제와 Chrome 개발자 도구의 검증 절차를 함께 살펴봅니다. 마지막에는 직접 파일로 저장해 비교할 수 있는 최소 재현 예제도 제공합니다. 하단이 언제 잘리는지에 따라 수정할 코드가 달라집..

웹사이트의 메뉴나 사이드바에 position: sticky를 적용했는데, 페이지를 내려도 화면에 고정되지 않는 경우가 있습니다. CSS에 sticky를 선언했는데도 요소가 그대로 사라지거나, 잠깐 고정되다가 예상보다 일찍 움직이기도 합니다. 이때 top 값만 계속 조정하면 해결되지 않을 수 있습니다. sticky는 브라우저 화면에 무조건 붙는 기능이 아니라, 상위 요소의 스크롤 설정과 자신이 속한 영역의 경계에 따라 움직이기 때문입니다. 문제를 좁히려면 세 가지를 구분해야 합니다. 고정을 시작할 위치가 지정됐는지, 어떤 요소를 기준으로 스크롤하는지, 그리고 고정된 상태로 이동할 공간이 남아 있는지입니다. 페이지에 붙일까, 스크롤 박스 안에 붙일까? 수정할 CSS를 결정하기 전에 고정하려는 위치부터 생각해..

웹페이지를 아래로 스크롤하면 요소가 나타나거나 상단 진행 표시줄이 늘어나도록 CSS 애니메이션을 설정했는데, 아무 반응이 없을 때가 있습니다. 반대로 스크롤하기도 전에 애니메이션이 끝나거나, 특정 브라우저에서만 콘텐츠가 보이지 않는 경우도 있습니다. 이때 animation-timeline 속성 하나만 바꾸는 것으로는 해결되지 않을 수 있습니다. 애니메이션의 진행 기준, CSS 선언 순서, 실제 스크롤 영역, 브라우저 지원 여부가 서로 연결되어 있기 때문입니다. 이번 글에서는 CSS의 scroll()과 view()가 각각 어떤 움직임을 추적하는지 구분하고, 오류가 발생하는 조건을 재현용 코드와 함께 살펴봅니다. 브라우저가 기능을 지원하지 않을 때에도 중요한 콘텐츠가 정상적으로 표시되도록 대체 스타일을 구성..