분석 횟수는 의료서비스 사이트에 집중됐다
주간 대상 52곳의 공식 사이트를 9월 23일 확인해 운영 사업을 분류했다. 의료서비스 사이트는 22곳·362회로, 전체 도메인의 42.3%, 분석 횟수의 74.8%를 차지했다. 사이트 수보다 반복 분석이 의료서비스 쪽에 더 집중된 기록이다. 특히 주 5회 이상 분석된 의료서비스 도메인 8곳에서 345회가 나왔고, 나머지 14곳은 합쳐 17회였다. 의료서비스 분석 362회 중 345회가 이 8곳에 집중됐다.
| 공식 사이트의 운영 유형 | 도메인 | 분석 완료 |
|---|---|---|
| 의료서비스 | 22곳 | 362회 |
| IT·디지털서비스 | 5곳 | 38회 |
| 상품 판매·대여 중개 | 4곳 | 11회 |
| 기타 확인된 서비스 | 5곳 | 17회 |
| 미분류 | 16곳 | 56회 |
| 합계 | 52곳 | 484회 |
이는 분석 대상 사이트의 운영 유형이다. 분석한 사람의 직업이나 고객사의 업종을 조사한 결과는 아니다. 한 운영자가 여러 도메인을 가질 수 있어 22곳을 22개 의료기관으로 세지도 않는다. 사업 설명을 확인할 수 없거나 접속이 안 되는 곳, 실제 분석 페이지의 사업을 대표하지 못하는 복합 플랫폼 등 16곳은 미분류로 남겼다. 작은 분류는 묶어 공개했다.
한 분석기의 이용 기록으로 의료업계 전체의 SEO 수요나 시장점유율을 판단할 수는 없다. 전주를 같은 기준으로 분류한 자료도 없어, 이 분석기 안의 업종별 증감 역시 알 수 없다. 지금 보이는 것은 이 분석기에서 어느 유형의 사이트를 많이 점검했는가다. 다음 관측에서도 도메인 수와 반복 횟수를 함께 비교해야, 새로운 사이트가 늘었는지 같은 사이트를 더 자주 살폈는지 나눌 수 있다.
업종 집계 52곳과 진단 표본 35곳을 교차 분석하지는 않았다. 따라서 앞서 본 입력칸·이미지 후보를 의료 사이트의 문제로 연결할 근거도 없다. 현재 공식 사이트의 사업 설명으로 분류했으므로 관측 당시 사업 내용이 같았는지까지 보증하지 않는다.
한 주 이용은 484회, 진단 표본은 35곳
이번 주 전체 이용량은 52개 도메인에서 484회였다. 전주의 58곳·453회보다 도메인은 6곳 줄고 실행은 31회 늘었다. 양쪽 주에 등장한 공통 12곳의 분석은 249회에서 272회로 증가했다. 이 이용량에는 각 주의 모든 클라이언트와 기록 형식을 포함했다. 같은 버전의 진단 결과가 좋아지거나 나빠졌다는 비교와는 구분한다.
진단 항목은 이 52곳을 한꺼번에 비교하지 않았다. 주중에 기록 형식이 바뀌었기 때문이다. 이전 형식인 v2의 완결 기록 306회에서 도메인마다 마지막 한 건을 골라 35곳을 살폈다. 모두 확장 프로그램 2.3.2 기록이다. 그 뒤 새 버전으로 다시 분석됐을 수 있으므로, 아래 표는 이번 주 말의 최종 사이트 상태를 뜻하지 않는다.
| 확인할 항목 | 마지막 v2 기록에 항목이 나온 도메인 |
|---|---|
| 입력칸 레이블 누락 후보 | 15곳 |
| 이미지 alt 속성 누락 후보 | 13곳 |
| 두 항목 모두 | 9곳 |
| 둘 중 하나 이상 | 19곳 |
19곳은 15곳과 13곳을 단순히 더한 수가 아니다. 같은 도메인에서 두 항목이 함께 나올 수 있어 겹친 9곳을 한 번 뺐다. 자동 판정이 남긴 점검 후보이며, 실제 페이지와 보조기술로 확인해 확정한 접근성 오류 수는 아니다.
화면에 보이는 설명이 코드에도 연결돼 있는가
입력칸 레이블 항목이 기록된 15곳에서는, 선택된 분석 시점에 검사기가 인정하는 설명 연결을 찾지 못한 입력 요소가 있었다. 이 버전은 일반 입력칸·여러 줄 입력칸·선택 상자에서 연결된 label, aria-label·aria-labelledby 속성, title 등의 경로를 확인한다. aria-labelledby의 참조가 실제 유효한지는 검사하지 않는다. hidden 타입 입력이나 제출 버튼 등은 별도 제외한다. 다만 CSS로 가려진 요소는 제외하지 않으므로, 실제로 보이고 사용하는 요소인지 함께 확인해야 한다.
운영자가 확인할 대상은 그 입력칸의 목적이다. 예를 들어 검색칸 옆에 ‘검색’ 버튼이 보이는 것과 입력칸 자체에 읽을 이름이 연결된 것은 다른 문제다. W3C는 가능한 경우 label과 입력 요소를 연결하고, for와 id를 일치시키도록 설명한다. 눈으로 문맥을 알 수 있는 배치에서도 보조기술이 읽을 이름은 확인해야 한다. 이 예시는 15곳에서 실제로 본 화면을 재현한 것이 아니라, 기록을 받은 뒤 확인할 방법이다. W3C 입력 요소 레이블 안내
이미지 쪽 13곳의 기록은 alt 속성 자체가 없는 후보를 뜻한다. 의도적으로 빈 alt를 둔 이미지와 같은 집계가 아니다. 검사기는 role 속성이나 파일 경로의 icon·sprite·logo 패턴 등으로 장식이라 추정한 대상을 제외하지만, 실제 문맥에서 장식인지 정보를 전달하는 이미지인지는 다시 봐야 한다.
W3C의 판단 기준도 이미지 역할에 따라 달라진다. 정보를 전달하는 사진에는 그 의미를, 링크나 버튼으로 쓰인 이미지에는 이동할 곳이나 실행할 동작을 전달해야 한다. 주변 글과 완전히 겹치거나 순수한 장식이라면 빈 alt가 적절할 수 있다. 모든 이미지에 파일명이나 같은 문구를 채워 넣는 방식으로 처리할 일은 아니다. W3C 이미지 대체텍스트 판단 기준
이 두 항목은 입력할 내용과 이미지가 전하는 의미를 확인하는 출발점이다. 이번 집계는 고객이 입력을 포기했는지, 화면을 잘못 이해했는지까지 측정하지 않았다. 그런 결과를 추정하는 대신, 기록된 요소를 실제 화면과 접근성 트리에서 확인할 수 있다.
로딩 권고는 더 많았지만, 수정 방식은 서로 다르다
아래는 전체 진단 항목의 빈도 순위가 아니다. 이미지·스크립트 로딩 관련 세 항목을 골라 코드 조건과 확인 방법을 짚었다. CSP 관련 기록도 33곳으로 많았지만, 메타 태그 미검출과 응답 헤더 검사가 같은 항목으로 남아 실제 헤더 부재로 단정할 수 없었다. 선택한 세 항목을 보면, 이미지 지연 로딩 후보는 30곳, 이미지 형식 후보는 28곳, head 안의 동기 스크립트 후보는 26곳에 기록됐다.
| 많이 기록된 항목 | 도메인 | 실제 코드가 찾는 신호 | 후속 확인 |
|---|---|---|---|
| 이미지 지연 로딩 후보 | 30곳 | DOM 순서상 세 번째 이후 이미지에 lazy 미지정 | 실제 첫 화면 밖 이미지인지 |
| 이미지 형식 후보 | 28곳 | JPEG/PNG 주소이며 대체 포맷 신호가 없는 이미지 | 실제 응답 형식·용량·화질 |
| 동기 스크립트 후보 | 26곳 | head의 script src에 async/defer가 없고 module도 아님 | 로딩 타이밍과 실행 순서 의존성 |
특히 지연 로딩 항목은 이름만 보고 일괄 수정하기 어렵다. 이 버전의 ‘누락’ 검사는 이미지의 실제 화면 위치를 재지 않고 DOM 순서를 이용한다. 세 번째 이미지라도 첫 화면에 보일 수 있다. web.dev도 첫 화면에 보이는 이미지는 지연 로딩하지 않도록 구분한다. 30곳에 기록됐다는 사실이 30곳의 모든 이미지에 lazy를 붙이라는 뜻은 아니다. 브라우저 이미지 지연 로딩 안내
이미지 형식 후보도 실제 전송 용량을 재서 낸 결과가 아니다. 주소가 JPEG처럼 보이더라도 서버가 다른 형식을 보낼 수 있으므로 응답부터 확인해야 한다. 동기 스크립트 항목 역시 DOM의 속성을 검사한다. 26곳의 실제 지연 시간이나 검색 성과를 측정한 것은 아니다. 실행 순서에 의존하는 코드인지 확인한 뒤 로딩 방식을 검토할 수 있다. MDN script 속성과 실행 방식
이번 기록에서 이미지 로딩 권고는 널리 나왔고, 입력칸·이미지의 설명 누락 후보는 35곳 중 19곳에서 기록됐다. 빈도가 높은 항목부터 기계적으로 지우기보다는, 입력 요소의 이름과 이미지의 역할을 확인하고 성능 권고는 실제 로딩 측정과 연결하는 순서가 합리적이다. 이는 이 관측을 바탕으로 제안하는 점검 순서이며, 모든 사이트의 수정 우선순위를 확정한 결과는 아니다.
관측은 한국 시간 2026년 9월 14일 00:00 이상~9월 21일 00:00 미만이며, 알려진 내부·테스트 도메인을 제외했다. 사용 횟수는 v2와 v3를 모두 포함하지만 진단 표는 위에서 정한 v2 표본만 쓴다. 기록되지 않은 항목을 정상으로 간주하지 않으며, 주중 도입된 v3의 주간 발생률은 공개 조건 미충족으로 사용하지 않았다. 출처는 SOYOYU의 줍줍 익명 집계이며 VLYVLY와 운영 주체가 같다.