AI 검색 최적화를 위한 SEO·접근성 점검과 답변 검증
AI 검색이 문서를 찾고 답변을 만드는 원리에서 SEO와 웹 접근성의 역할을 설명합니다. 가상의 요금 안내 페이지를 바탕으로 수집 경로와 정보의 정확성을 확인하고, 체크리스트와 LLM 검토를 CMS 운영에 적용하는 방법을 살펴봅니다.
태그
accessibility
5개 글
aria-modal="true"는 아무것도 막지 않았다 — 모달 포커스 이탈 실측과 inert
role="dialog"에 aria-modal="true"까지 붙인 모달에서 Tab을 세 번 누르자 포커스가 오버레이 뒤로 빠져나갔다. axe는 위반 0건. 같은 마크업을 aria-hidden, inert로 바꿔가며 키보드 포커스가 실제로 어디에 떨어지는지 기록했다.
WCAG 2.2 최소 타깃 크기, 초록불 92점 뒤에 숨은 AA 실패
손끝이 빗나가는 22×22 버튼에 Lighthouse는 접근성 92점을 줬다. WCAG 2.2 SC 2.5.8(최소 24×24)을 샌드박스에 심어 재보니 자동 도구는 크기 위반만 잡고 예외 조항은 사람에게 넘겼다. 스페이싱 예외 계산과 CSS 수정을 실측 로그로 정리한다.
접근성 자동 검사가 초록불을 줘도 남아 있는 네 가지 장벽
체크아웃 페이지 하나에 WCAG 장벽 여덟 개를 일부러 심고 axe-core로 돌렸다. 규칙형 위반 넷은 잡혔지만, 사람의 판단이 필요한 넷은 초록불 뒤에 그대로 남았다. 무엇을 자동화가 끝까지 못 보는지, 그 자리를 메우는 수동 리뷰 체크리스트를 실측 로그와 함께 정리했다.
접근성 이름이 틀리면 음성 제어도 AI 에이전트도 버튼을 못 누른다
버튼에 aria-label을 붙였는데 접근성 트리는 화면에 없는 글자를 읽는다. WCAG 2.5.3 Label in Name 위반을 샌드박스에서 재현해 확인하고, Lighthouse 13.3.0의 Agentic Browsing 점수가 0점에서 100점으로 바뀌는 과정을 실측했다.