아이콘(Icon) 자가진단 — ViewCheck 5분 점검

"우리 사이트, 아이콘은 다 잘 쓰고 있겠죠?" 회의실에서 이 질문이 나오면 보통 잠깐 침묵이 흐릅니다. 디자이너는 "표준 아이콘 가져다 썼어요"라고 답하고, 개발자는 "라벨도 다 붙였을 거예요"라고 합니다. '거예요'. 이 말이 문제입니다. 누구도 확신을 못 합니다. 왜냐하면 아이콘은 화면 곳곳에 수십 개씩 박혀 있는데, 그걸 하나하나 열어 보고 "이 버튼에 이름이 있나, 저 장식 아이콘은 숨겨졌나"를 확인한 사람이 아무도 없거든요.

이 글은 바로 그 "거예요"를 "확인했어요"로 바꾸는 글입니다. 아이콘이 무엇이고 왜 중요한지를 길게 설명하기보다는, 지금 당장 우리 사이트의 아이콘을 어떻게 점검하고, 무엇이 나오면 위험 신호인지, 그리고 그 결과를 어떻게 읽고 어디부터 고쳐야 하는지에 집중하려 합니다. 손으로 5분 만에 할 수 있는 셀프 점검부터, ViewCheck로 전 페이지를 한 번에 훑는 자동 점검까지. 다 읽고 나면 "우리 사이트 아이콘이 추측 게임을 만들고 있는지" 오늘 안에 답을 낼 수 있을 겁니다.

먼저 솔직하게 말씀드리면, 아이콘은 "점검하기 가장 귀찮은" 요소입니다. 작고, 많고, 보기엔 멀쩡하니까요. 마우스로 눌러 보면 다 잘 작동하는 것처럼 보입니다. 그래서 대부분의 팀이 아이콘을 점검 대상에서 슬그머니 빼 버립니다. "버튼 동작 테스트했으니 됐지" 하고요. 그런데 그 마우스 테스트가 놓치는 사용자가 있습니다. 키보드만 쓰는 사람, 스크린리더로 듣는 사람, 색을 구분하기 어려운 사람, 손가락이 떨리는 고령 사용자. 이들에게 점검 안 된 아이콘은 그냥 "없는 기능"이 됩니다. 점검은 이 보이지 않는 사용자들을 위한 안전장치입니다.

아이콘 점검, 도대체 무엇을 보는 건가

본격적인 점검에 들어가기 전에, "아이콘을 점검한다"는 게 구체적으로 무엇을 보는 일인지부터 정리하겠습니다. 막연히 "잘 쓰고 있나"가 아니라, 점검에는 확인해야 할 항목이 정해져 있습니다.

아이콘 점검은 크게 세 갈래입니다. 첫째, 의미 전달입니다. 이 아이콘이 기능을 나타내는데 이름(접근 가능한 이름)이 붙어 있는가, 아니면 장식인데 스크린리더에 쓸데없이 읽히고 있는가. 둘째, 지각 가능성입니다. 충분히 크고 또렷한가, 색에만 의존하지 않는가, 키보드 초점이 보이는가, 누를 영역이 넉넉한가. 셋째, 일관성입니다. 같은 의미에 같은 모양을 쓰는가, KRDS 표준을 우선했는가, 페이지마다 제각각이지 않은가.

이 세 갈래를 머릿속에 넣어 두면 점검이 막막하지 않습니다. 어떤 아이콘을 보든 "이건 의미인가 장식인가(전달), 잘 보이고 잘 눌리는가(지각), 다른 데랑 같은가(일관)" 세 질문만 던지면 되거든요. 이 글의 모든 점검 항목은 결국 이 세 질문에서 갈라져 나옵니다.

여기서 한 가지 강조하고 싶은 건, 점검의 핵심은 "눈에 보이는 것"이 아니라 "코드가 말해 주는 것"을 본다는 점입니다. 아이콘은 화면에 그림으로 떠 있지만, 스크린리더 사용자에게는 그 그림이 아니라 코드가 담은 의미가 전부입니다. 그래서 점검은 늘 두 겹입니다. "보이는가"와 "읽히는가". 이 둘이 어긋나는 지점이 바로 위반이 숨는 자리입니다.

KRDS는 아이콘에 어떤 기준을 두는가 — 점검의 근거

점검을 하려면 "무엇을 기준으로" 통과/미통과를 가를지가 있어야 합니다. 그 기준이 바로 KRDS(대한민국 정부 디자인 시스템)입니다. KRDS는 공식 컴포넌트 킷(GitHub KRDS-uiux/krds-uiux)을 통해 시스템 아이콘을 SVG 형식으로 제공하고, 검색·메뉴·닫기·화살표·체크 같은 공공 서비스 반복 기능을 위한 표준 아이콘 세트를 갖춰 두고 있습니다. KRDS 스타일 가이드 페이지에서 아이콘 항목을 직접 확인할 수 있고, 디자이너용 원본은 공식 Figma(@krds)에서 제공됩니다.

KRDS가 아이콘을 "알아서 예쁘게 쓰세요"로 두지 않고 별도 시스템으로 정리한 이유는, 모든 공공 사이트가 "검색"을 제각각 다른 돋보기로 그리면 사용자가 사이트마다 "이게 검색이 맞나"를 다시 판단해야 하기 때문입니다. 같은 의미는 같은 모양으로 — 이 약속 하나가 수백 개 정부 사이트를 오가는 국민의 인지 부담을 줄입니다. 그래서 점검의 첫 기준은 "표준을 썼는가"입니다.

KRDS 가이드라인(디지털 정부서비스 UI/UX 가이드라인 2025.08판)과 한국형 웹 접근성 지침(KWCAG)을 종합하면, 아이콘 점검에서 확인해야 할 기준은 다음과 같이 정리됩니다.

의미 있는 아이콘 vs 장식 아이콘의 구분: 기능을 전달하는 아이콘은 이름이 있어야 하고, 옆에 텍스트가 이미 있는 장식 아이콘은 스크린리더가 무시하도록(aria-hidden="true") 해야 합니다.
아이콘 전용 버튼의 이름: 텍스트 없이 아이콘만 있는 버튼(햄버거 메뉴, 돋보기 검색 등)에는 aria-label이나 화면에 안 보이는 텍스트로 "메뉴 열기", "검색" 같은 이름을 반드시 부여해야 합니다.
충분한 크기와 터치 영역: 아이콘이 버튼 역할을 하면 누를 수 있는 영역이 충분해야 합니다. KWCAG와 국제 표준 모두 터치 대상 최소 크기를 권장하며, 보통 한 변 44px 이상을 기준으로 봅니다.
색에만 의존하지 않기 + 충분한 대비: 상태를 색으로만 전하지 말고 모양·텍스트가 함께 받쳐야 하며, 아이콘과 배경의 명도 대비가 충분해야 합니다.
일관성: 같은 동작에는 같은 아이콘을, 가능하면 KRDS 표준 아이콘을 써서 다른 정부 사이트와도 맞춥니다.
누를 수 있는 아이콘의 초점 표시: 키보드로 초점이 왔을 때 또렷이 보여야 합니다.

이 기준 목록이 바로 점검표의 뼈대입니다. 아래에서 하나씩 "어떻게 확인하는지"로 풀어 보겠습니다. 기준만 아는 것과, 그 기준대로 내 사이트를 채점할 줄 아는 것은 전혀 다른 일이니까요.

왜 아이콘 점검을 따로 해야 하나 — 방치되는 원리

"버튼 테스트하면 아이콘도 같이 보는 거 아닌가?" 싶으실 텐데, 아이콘은 유독 점검에서 빠지는 구조적 이유가 있습니다. 이걸 알아야 왜 별도 점검이 필요한지 납득이 됩니다.

첫째, 작습니다. 화면에서 차지하는 면적이 작으니 검수 우선순위에서 밀립니다. 메인 비주얼은 모두가 들여다보지만, 우측 상단의 16px짜리 아이콘이 스크린리더에 어떻게 읽히는지는 아무도 확인하지 않습니다. 둘째, 너무 흔합니다. 한 화면에 수십 개씩 들어가다 보니 하나하나 점검하는 게 번거롭게 느껴지고 "다음에 보자"가 쌓입니다. 셋째, 만든 사람에게는 너무 명백합니다. 디자이너가 직접 고른 아이콘이라 그에게는 의미가 자명하지만, 처음 보는 사용자나 음성으로 듣는 사용자에게는 전혀 그렇지 않습니다.

여기에 한 가지가 더 겹칩니다. 마우스 테스트는 아이콘 문제를 거의 못 잡습니다. 마우스로 누르면 다 작동하니까요. 라벨이 없어도 마우스 사용자는 모양으로 짐작해서 누릅니다. 그래서 "테스트했는데 멀쩡하던데요"라는 말이 나오는 겁니다. 정작 문제가 생기는 건 키보드·스크린리더·색각·터치 영역인데, 이건 마우스 테스트로는 절대 드러나지 않습니다. 점검 방법 자체가 사용자를 가리고 있는 셈입니다.

그래서 아이콘 점검은 "마우스를 치우는 것"에서 시작합니다. 의식적으로 마우스를 손에서 놓고, 키보드로만, 또는 스크린리더로, 또는 흑백 화면으로 봐야 비로소 숨어 있던 문제가 보입니다. 이게 셀프 점검의 핵심 원리입니다 — 평소 쓰던 방식을 일부러 버리고, 가장 도움이 필요한 사용자의 조건으로 화면을 다시 보는 것.

보이는 것과 읽히는 것이 갈리는 자리

조금 더 깊이 들어가면, 아이콘 위반의 근본 원인은 거의 다 "보이는 것 ≠ 읽히는 것"입니다. 화면엔 분명히 돋보기가 떠 있는데 코드엔 이름이 없어서 스크린리더는 "버튼"으로만 읽습니다. 또는 "검색" 글자 옆 돋보기가 코드상 숨겨지지 않아서 "이미지 검색"처럼 중복으로 읽힙니다. 보이는 그림과 코드가 담은 의미가 어긋나는 거죠.

점검이 어려운 이유가 여기 있습니다. 이 어긋남은 눈으로는 절대 안 보입니다. 화면만 보면 완벽해 보이거든요. 코드를 열거나, 스크린리더로 들어 보거나, 자동 도구로 코드를 분석해야만 드러납니다. 그래서 "눈으로 보고 괜찮으니 통과"는 아이콘 점검에서 가장 위험한 판단입니다. 통과 여부는 눈이 아니라 코드와 보조기술로 판정해야 합니다.

5분 셀프 점검 — 지금 바로 해보기

거창한 도구 없이도, 지금 우리 사이트에서 아이콘을 직접 점검할 수 있습니다. 마우스를 잠깐 치우고 순서대로 해보세요. 다섯 가지만 해봐도 대부분의 아이콘 문제가 드러납니다.

1단계 — Tab 키만으로 훑기. 마우스를 치우고 Tab 키만 눌러서 화면 위쪽부터 초점을 옮겨 보세요. 우측 상단 아이콘들(검색·메뉴·설정·닫기 등)에 초점이 가나요? 가서 또렷이 보이나요? 초점이 아예 안 가면 그 아이콘 버튼은 키보드 사용자에게 존재하지 않는 겁니다. 초점은 가는데 어디 있는지 안 보이면(포커스 링이 지워졌으면) 키보드 사용자는 길을 잃습니다.

2단계 — 이미지를 끄거나 스크린리더로 듣기. 브라우저 개발자도구로 아이콘 SVG를 잠시 숨기거나, 운영체제의 스크린리더(Windows 내레이터, macOS VoiceOver)를 켜고 아이콘 버튼에 초점을 줘 보세요. 무슨 버튼인지 들리나요? "검색, 버튼"이라고 읽어 주면 통과. 그냥 "버튼"이라고만 하면 이름이 없는 겁니다. 그 버튼은 시각장애인에게 사라진 기능입니다.

3단계 — 화면을 흑백으로 보기. 운영체제의 색 필터(흑백/회색조)를 켜고 상태 아이콘들을 보세요. 빨간 점/초록 점으로 "오류/정상"을 구분하던 아이콘이 흑백에서 구별되나요? 안 되면 색 의존 문제입니다. 색각 이상 사용자에게 그 정보는 전달되지 않고 있습니다.

4단계 — 모바일에서 빠르게 눌러 보기. 실제 스마트폰으로 아이콘 버튼들을 평소 속도로 눌러 보세요. 옆 버튼이 눌리거나 자꾸 빗나가면 터치 영역이 부족한 겁니다. 특히 16px 그림에만 클릭이 걸려 있으면 손가락이 살짝만 빗나가도 안 눌립니다. 손 떨림이 있는 분이나 고령 사용자에겐 더 큰 장벽입니다.

5단계 — 같은 동작을 여러 페이지에서 비교. "닫기"나 "검색" 같은 같은 동작을 메인·검색·신청·로그인 페이지에서 각각 찾아 모양을 비교하세요. 어떤 곳은 X, 어떤 곳은 화살표, 어떤 곳은 텍스트로 제각각이면 일관성 문제입니다. 사용자는 페이지를 옮길 때마다 새로 학습해야 합니다.

이 다섯 가지는 누구나 5분이면 할 수 있습니다. 그런데 한 가지 한계가 있습니다 — 페이지가 많아지면 사람이 다 못 봅니다. 메인 한 페이지는 5분이지만, 100페이지짜리 공공 사이트를 이렇게 손으로 점검하면 며칠이 걸립니다. 그래서 셀프 점검으로 "감을 잡고", 자동 점검으로 "전수 조사"를 하는 2단 구성이 현실적입니다.

셀프 점검에서 자주 나오는 위험 신호

위 5단계를 돌리다 보면 거의 매번 걸리는 신호들이 있습니다. 미리 알아 두면 "아 이게 그거구나" 하고 바로 잡아낼 수 있습니다.

신호 ①: 우측 상단 아이콘에 Tab이 안 간다 → 진짜 버튼이 아니라 <div>에 클릭만 붙인 가짜 버튼. 키보드 사용자에게 차단.
신호 ②: 스크린리더가 "버튼"이라고만 말한다 → 이름(aria-label) 누락. 가장 흔하고 치명적.
신호 ③: 스크린리더가 "이미지 검색 검색"처럼 두 번 읽는다 → 장식 아이콘이 안 숨겨짐(aria-hidden 누락).
신호 ④: 흑백에서 상태 구분이 안 된다 → 색 의존. 모양·텍스트 보강 필요.
신호 ⑤: 모바일에서 자꾸 빗나간다 → 터치 영역 부족. 버튼 패딩 확대 필요.
신호 ⑥: 페이지마다 닫기 모양이 다르다 → 일관성 붕괴. 전사 통일 필요.

이 여섯 신호 중 하나라도 나오면, 그건 "우연"이 아니라 "패턴"일 가능성이 높습니다. 한 페이지에서 라벨이 빠졌으면 다른 페이지에서도 빠졌을 확률이 높거든요. 그래서 하나 발견했을 때가 바로 전체 점검을 시작할 타이밍입니다.

공공 사이트가 자주 틀리는 지점 — 점검에서 걸러야 할 것들

이제 현장에서 반복되는 아이콘 실수들을, "점검할 때 무엇을 보면 잡히는지"와 함께 정리하겠습니다. 모두 익명화한 일반적 사례입니다. 특정 기관을 지목하지 않습니다.

실수 1) 이름 없는 아이콘 버튼

햄버거 메뉴, 돋보기 검색, X 닫기 — 라벨 없이 아이콘만 덩그러니.

나쁜 예: <button><svg>...</svg></button> 끝. 스크린리더는 "버튼"으로만 읽음. 무슨 버튼인지 알 수 없음.
올바른 예: <button aria-label="메뉴 열기"><svg aria-hidden="true">...</svg></button>. 버튼엔 이름을, 안의 장식 svg는 숨김.
점검 방법: 스크린리더로 그 버튼에 초점을 줬을 때 동작 이름이 들리는지 확인. 들리면 통과.

실수 2) 장식 아이콘이 스크린리더에 읽힘

"검색" 글자 옆 돋보기가 aria-hidden 없이 그대로 노출.

나쁜 예: "이미지 검색"처럼 중복 낭독. 텍스트와 아이콘이 같은 의미인데 두 번 읽힘.
올바른 예: 텍스트 라벨이 있으면 아이콘은 aria-hidden="true"로 숨겨 한 번만 읽히게.
점검 방법: 텍스트가 있는 버튼/링크에서 스크린리더가 같은 의미를 두 번 읽는지 확인.

실수 3) 의미를 색으로만 전달

상태 아이콘을 빨강/초록으로만 구분.

나쁜 예: 빨간 점과 초록 점만으로 "오류/정상" 구분. 색각 이상 사용자는 둘을 구별 못 함.
올바른 예: 색 + 모양(경고 삼각형 / 체크) + 텍스트를 함께. 어느 하나에만 의존하지 않음.
점검 방법: 흑백 필터를 켜고 상태가 구분되는지 확인.

실수 4) 너무 작거나 흐린 아이콘

장식성에 치중해 아이콘을 작고 연하게.

나쁜 예: 12px 연회색 아이콘. 저시력·고령 사용자에겐 거의 안 보이고, 터치 영역도 부족.
올바른 예: 충분한 크기와 대비, 터치 영역(약 44px 이상) 확보.
점검 방법: 모바일에서 빠르게 눌러 빗나가는지, 화면을 멀리서 봤을 때 보이는지 확인.

실수 5) 의미 불명의 커스텀 아이콘 남발

표준에 없는 독창적 아이콘을 라벨 없이 사용.

나쁜 예: 디자이너만 아는 추상 픽토그램. 사용자는 "이게 뭐지?" 추측 게임.
올바른 예: KRDS 표준을 우선 사용하고, 부득이 새 아이콘이면 반드시 텍스트 라벨 병기.
점검 방법: 처음 보는 사람에게 "이 아이콘이 무슨 기능 같아?"라고 물어보기. 답이 갈리면 위험.

실수 6) 같은 의미, 다른 아이콘

같은 "닫기"를 페이지마다 다른 모양으로.

나쁜 예: 한 곳은 X, 한 곳은 ←, 한 곳은 "닫기" 텍스트. 일관성 붕괴.
올바른 예: 동작별 아이콘을 통일하고, 디자인 시스템 차원에서 한 번 정해 전사에 적용.
점검 방법: 같은 동작을 여러 페이지에서 찾아 모양을 나란히 비교.

실수 7) 포커스 표시 없는 아이콘 버튼

아이콘 버튼이 작다는 이유로 포커스 링을 생략.

나쁜 예: 키보드로 툴바를 훑어도 지금 어느 아이콘에 있는지 안 보임.
올바른 예: 아이콘 버튼에도 또렷한 포커스 표시. 텍스트 버튼과 동일 기준.
점검 방법: Tab으로 이동하며 현재 위치가 시각적으로 표시되는지 확인.

실수 8) 클릭 영역이 아이콘 그림에만 한정

16px 그림 픽셀에만 클릭이 걸려 있어, 살짝만 빗나가도 안 눌림.

나쁜 예: 작은 아이콘 외곽을 정확히 눌러야만 작동. 손 떨림·모바일에서 고역.
올바른 예: 아이콘을 감싸는 버튼 영역 자체를 충분히(약 44px) 넓혀 여유 있게.
점검 방법: 개발자도구로 버튼 요소의 실제 크기를 측정하거나, 모바일에서 가장자리를 눌러 보기.

실수 9) 외부에서 긁어온 제각각 아이콘

여러 무료 아이콘 사이트에서 그때그때 가져와 선 두께·스타일이 뒤죽박죽.

나쁜 예: 어떤 건 두꺼운 선, 어떤 건 채워진 면, 어떤 건 둥글고 어떤 건 각진. 화면이 어수선.
올바른 예: KRDS 표준처럼 한 세트의 통일된 스타일을 쓰고, 라이선스도 명확히.
점검 방법: 화면 캡처를 떠서 아이콘만 모아 놓고 선 두께·스타일이 한 가족인지 비교.

이 아홉 가지가 점검에서 가장 자주 걸리는 항목입니다. 그리고 눈여겨볼 점은, 점검 방법이 대부분 "마우스가 아닌 다른 방식으로 확인"이라는 것입니다. 스크린리더로 듣기, 흑백으로 보기, Tab으로 이동하기, 크기 측정하기. 평소 쓰던 마우스만으로는 이 아홉 가지를 거의 못 잡습니다.

한 장면 — 같은 버튼, 두 사람의 점검

추상적인 점검 항목보다 한 장면이 빠를 것 같습니다. 어느 공공 서비스의 모바일 화면, 우측 상단에 돋보기 아이콘 하나가 있습니다. 텍스트는 없고 그림만 있습니다.

이 화면을 만든 팀의 김 주무관이 점검을 합니다. 마우스로 돋보기를 누르니 검색창이 잘 열립니다. "정상." 옆 동료도 눌러 봅니다. "잘 되네요." 둘 다 마우스로요. 그래서 이 팀의 점검표에는 "검색 아이콘 — 통과"라고 적힙니다. 0.5초도 안 걸린 점검입니다.

그런데 같은 화면을, 시각장애가 있는 한 선생님이 스크린리더로 들어가 봅니다. 화면을 훑어 내려가다 그 자리에서 "버튼"이라는 말만 듣습니다. 무슨 버튼인지 알 수 없습니다. 돋보기 그림은 코드상 이름이 없어서, 스크린리더가 "검색"이라고 말해 줄 수가 없거든요. 한 선생님은 그 버튼을 그냥 지나칩니다. 검색 기능이 분명히 있는데도, 그에게는 없는 것이나 마찬가지입니다.

같은 돋보기, 같은 점검 대상. 그런데 김 주무관의 점검(마우스)은 "통과"라 하고, 한 선생님의 실제 경험(스크린리더)은 "차단"입니다. 무엇이 둘을 갈랐을까요. 점검 방법입니다. 김 주무관이 마우스를 잠깐 치우고 스크린리더로 한 번만 들어 봤다면, "어 이거 이름이 안 들리네"를 바로 알아챘을 겁니다. 그리고 고치는 비용은 놀랄 만큼 작습니다. 버튼에 aria-label="검색" 한 줄. 그거면 한 선생님의 스크린리더도 "검색, 버튼"이라고 읽어 줍니다.

이 장면의 교훈은 명확합니다. 잘못된 방법으로 한 점검은 통과를 남발하고, 올바른 방법으로 한 점검은 진짜 문제를 드러냅니다. 마우스로만 하는 점검은 "통과"라는 거짓 안심을 줍니다. 점검의 가치는 얼마나 자주 하느냐가 아니라, 사용자의 조건으로 하느냐에 달려 있습니다.

직접 점검·개선하기 — 역할별 가이드

점검은 한 사람의 일이 아닙니다. 발견은 누가 하든, 고치는 건 역할이 나뉩니다. 그래서 점검 결과를 누가 무엇으로 받아야 하는지 정리해 두는 게 좋습니다.

개발자라면 — 점검의 핵심 습관은 단 두 가지입니다. 아이콘이 버튼·링크로 동작하면 그 요소에 이름을 주고(aria-label="검색"), 안의 그림 SVG는 aria-hidden="true"로 숨깁니다. 아이콘이 순수 장식(옆에 텍스트가 이미 있음)이면 역시 aria-hidden="true"로 숨깁니다. "장식 SVG는 무조건 숨기고, 기능 요소에는 이름을 준다" — 이 한 문장만 지켜도 아이콘 접근성의 대부분이 해결됩니다. 점검 후 수정할 때는 KRDS 컴포넌트 킷(npm install krds-uiux 또는 CDN krds.min.css/krds.min.js)의 표준 아이콘으로 교체하면 일관성과 라이선스를 한 번에 정리할 수 있습니다. 추가로 챙길 것: 아이콘 버튼의 클릭 영역을 그림보다 넓게(패딩으로 약 44px), 포커스 표시 유지, 상태 아이콘에 색 외에 텍스트/모양 동반.

디자이너라면 — 점검에서 "비표준 아이콘", "제각각 스타일", "같은 의미 다른 모양"이 나왔다면, KRDS 공식 Figma(@krds) 라이브러리의 표준 아이콘으로 교체를 검토하세요. 새 아이콘을 만들기 전에 "이미 표준에 있는가"를 먼저 확인하는 습관이 점검 부담을 근본적으로 줄입니다. 표준에 있는 걸 새로 그리는 건 일관성을 깨고 점검 항목을 늘리는 일입니다.

기획자라면 — 점검에서 가장 많이 나오는 "이름 없는 아이콘 버튼"은 사실 기획 단계에서 막을 수 있습니다. 화면 정의서에 "아이콘 버튼"이라고만 쓰지 말고, 그 아이콘이 의미하는 동작 이름(예: "메뉴 열기")을 함께 적어 두세요. 그 한 줄이 개발 단계의 라벨 누락을 막고, 나중에 점검에서 걸릴 일을 사전에 없앱니다.

아이콘 라벨 문구, 점검 후 이렇게 채우세요

점검에서 "라벨 누락"이 나와 채워 넣을 때, 그 문구도 신경 써야 합니다. 좋은 라벨은 짧고, 동작 중심이며, 듣고 바로 이해할 수 있어야 합니다.

동작 + 대상으로: 단순 "검색"보다 맥락이 필요하면 "게시물 검색"처럼. 단 너무 길면 거추장스러우니 균형이 중요합니다.
무엇이 일어날지 알려주기: 메뉴 버튼은 "메뉴 열기", 닫기 버튼은 "닫기"처럼 결과를 짐작하게.
토글은 상태도 함께: 펼침/접힘이 바뀌는 버튼은 aria-expanded로 현재 상태를 전달. "메뉴, 접힘 → 메뉴, 펼침"처럼 변화가 읽히게.
군더더기 빼기: "검색 버튼 아이콘"처럼 "버튼/아이콘"을 라벨에 넣지 마세요. 스크린리더가 이미 역할을 읽어 주므로 중복됩니다. "검색"이면 충분합니다.
같은 동작엔 같은 문구: "닫기"를 어떤 곳은 "닫기", 어떤 곳은 "창 닫기", 어떤 곳은 "취소"로 쓰면 일관성이 깨집니다. 표준 문구를 한 번 정해 두세요.

이 라벨 문구는 사실 "보이지 않지만 읽히는 글자"입니다. 음성으로만 서비스를 쓰는 사용자에게는 이 라벨이 곧 화면 전체입니다. 점검에서 라벨을 채울 때, 화면에 보이는 글자만큼 공들여 다듬어야 하는 이유입니다.

헷갈리기 쉬운 아이콘들 — 점검 때 특히 의심할 것

점검을 하다 보면 "이건 다들 아는 아이콘이니까 괜찮겠지" 하고 넘기게 되는 것들이 있습니다. 그런데 의외로 의미가 갈리는 아이콘이 많습니다. 이런 아이콘일수록 텍스트 병기나 명확한 라벨이 됐는지 더 꼼꼼히 봐야 합니다.

종(bell): "알림"으로 흔히 쓰이지만 "소리/음량"으로 오해될 수 있습니다. 알림이면 "알림" 라벨을 분명히.
하트(heart): "좋아요"인지 "찜/즐겨찾기"인지 서비스마다 다릅니다. 별(star)과도 혼용되니 라벨로 못박기.
세 점(⋯ / ⋮): "더보기/추가 메뉴"를 뜻하지만 초보 사용자에겐 모호합니다. 라벨 "더보기" 권장.
공유(share): 운영체제마다 모양이 달라 헷갈립니다.
새로고침/되돌리기: 둥근 화살표가 "새로고침"인지 "실행 취소"인지 갈립니다.
플로피 디스크: "저장"의 관습적 상징이지만 실물을 본 적 없는 세대에겐 의미가 안 닿습니다.
햄버거(≡) vs 케밥(⋮) vs 미트볼(⋯): 모두 "메뉴/더보기" 계열이라 자주 혼동됩니다.

점검의 교훈은 단순합니다. "유명한 아이콘"과 "누구에게나 명확한 아이콘"은 다릅니다. 조금이라도 갈릴 여지가 있으면 텍스트를 함께 두는지 확인하세요. 특히 공공 서비스에서는 디자인 트렌드보다 "처음 온 사람도 헤매지 않는가"가 우선입니다.

그래서 우리 사이트는? — ViewCheck로 자동 점검

손으로 하는 5분 셀프 점검은 "감을 잡는" 데 좋습니다. 그런데 페이지가 수십·수백 개인 공공 사이트라면 사람이 다 볼 수 없습니다. 아이콘 버튼이 몇 개인지, 각각 이름이 붙어 있는지, 장식 아이콘이 잘못 노출되는지를 전 페이지에서 손으로 확인하려면 끝이 없죠. 이 전수 조사를 자동화하는 게 ViewCheck입니다.

ViewCheck(krds.viewcheck.co.kr)는 URL만 넣으면 페이지를 실제로 크롤링해서, 아이콘과 관련된 KRDS 기준을 자동으로 점검합니다. 아이콘은 KRDS 846규칙 중 디자인 시스템(DS) 규칙군 120개와 컴포넌트 접근성 항목에 걸쳐 있고, 분석 결과의 디자인 시스템(Design System) 탭에서 확인할 수 있습니다. 이 탭에서는 디자인 토큰 채택률 리포트도 함께 볼 수 있어, 아이콘을 포함한 시각 자산이 표준 토큰을 얼마나 따르고 있는지가 수치로 드러납니다.

ViewCheck가 아이콘과 관련해 자동으로 보는 것들:

아이콘 전용 버튼의 이름 유무: 라벨 없이 아이콘만 있는 버튼을 찾아냄
장식/의미 아이콘 처리: 텍스트와 중복되는 아이콘이 적절히 숨김 처리됐는지
크기·대비: 아이콘 버튼의 터치 영역과 색 대비가 기준을 충족하는지(반응형·대비 분석과 연계)
디자인 토큰 채택률: 아이콘을 포함한 시각 자산이 KRDS 표준 토큰을 따르는지

화면으로만 보이는 시각적 부분은 KRDScan Vision AI가 스크린샷을 함께 보고 보강 판정하기 때문에, 이미지로 박아 넣은 아이콘처럼 코드만으로는 놓치기 쉬운 경우도 잡아냅니다. 단순 코드 검사 도구와 다른 점이 여기입니다 — 사람이 눈으로 보듯 화면을 함께 보기 때문에, 표준을 우회해 만든 UI도 놓치지 않습니다.

리포트를 어떻게 읽나 — 디자인 시스템 탭

분석이 끝나면 디자인 시스템 탭에서 아이콘 관련 DS 규칙의 통과/미통과 수가 먼저 나옵니다. 그리고 미통과한 항목의 위치(어느 페이지)·이유·개선 방법(howToFix)이 함께 표시됩니다. 예를 들어 "검색 페이지 헤더의 아이콘 버튼 2개가 라벨 미연결"처럼 구체적으로요. 막연한 "아이콘 잘 쓰자"가 아니라 "이 페이지의 이 아이콘 버튼에 이 라벨을 붙이자"는 구체적인 작업 목록이 나오는 셈입니다.

여러 페이지를 한꺼번에 분석하면 페이지별 편차도 한눈에 드러납니다. "메인은 멀쩡한데 신청 페이지의 아이콘 버튼들만 라벨이 빠졌다" 같은 패턴이 보이는 거죠. 이게 손 점검과 결정적으로 다른 부분입니다. 사람은 보통 메인 한두 페이지만 보고 "괜찮네"라고 판단하는데, 정작 문제는 사용 빈도 높은 신청·로그인 페이지에 숨어 있는 경우가 많거든요. 전 페이지 전수 조사라야 이런 숨은 편차를 잡습니다.

리포트를 읽는 순서를 권하자면 이렇습니다. 첫째, 미통과 건수가 가장 많은 페이지를 먼저 봅니다. 둘째, 그중 우선순위(P0~P3)가 높은 것부터 읽습니다. 셋째, 같은 유형의 위반이 여러 페이지에 반복되는지 봅니다 — 반복된다면 그건 컴포넌트 차원의 문제라 한 곳을 고치면 전부 고쳐질 가능성이 높습니다. 이렇게 읽으면 "어디부터 손대야 효율이 가장 좋은지"가 자연스럽게 정해집니다.

무료 진단으로 메인 페이지부터 한 번 돌려 보면, 우리 사이트의 아이콘이 추측 게임을 만들고 있는지 5분 만에 확인됩니다. 그리고 그 결과는 다음 개선 작업의 출발점이 됩니다.

점검 결과를 팀에 공유하는 법

점검을 혼자 했다고 끝이 아닙니다. 결과를 팀이 함께 봐야 고쳐집니다. 그런데 "아이콘 라벨이 없어요"라고만 전하면 개발자는 "어느 아이콘요?"라고 되묻습니다. 점검 결과는 다음 세 가지를 함께 담아야 바로 작업으로 이어집니다.

위치: "검색 페이지 헤더 우측" 처럼 어느 페이지, 어느 영역인지.
증상: "스크린리더가 '버튼'으로만 읽음" 처럼 무엇이 잘못됐는지.
기대값: "aria-label='검색' 추가" 처럼 어떻게 고쳐야 하는지.

ViewCheck 리포트는 이 세 가지(위치·이유·howToFix)를 이미 묶어서 내보내기 때문에, 그대로 작업 티켓으로 옮기면 됩니다. 손 점검을 했다면 캡처 화면에 화살표와 메모를 달아 같은 형식으로 정리하세요. "막연한 지적"이 아니라 "구체적 작업 목록"이 돼야 점검이 개선으로 연결됩니다. 점검의 마지막 단계는 발견이 아니라 전달입니다.

점검 주기를 정하는 법

"한 번 고쳤으니 됐다"는 가장 흔한 착각입니다. 사이트는 살아 있어서, 새 페이지가 올라오고 컴포넌트가 수정될 때마다 새 아이콘이 들어옵니다. 그래서 점검은 일회성 행사가 아니라 주기적 루틴이어야 합니다. 권하는 주기는 이렇습니다.

큰 배포 직전·직후: 새로 들어간 아이콘과, 고쳤던 게 다시 깨지는 회귀를 잡기 위해.
분기에 한 번 정기 점검: 그동안 누적된 작은 변경들을 한꺼번에 훑기 위해.
외주 산출물 검수 시점: 외부에서 받은 화면에 비표준·라벨 누락 아이콘이 섞여 들어오기 쉬우므로.

이 주기를 캘린더에 박아 두면, "언젠가 해야지" 하다 미루는 일이 사라집니다. ViewCheck처럼 URL만 넣으면 도는 자동 점검은 이 정기 루틴에 특히 잘 맞습니다. 사람이 매번 수백 개를 손으로 볼 수는 없지만, 자동 점검은 분기마다 같은 기준으로 전 페이지를 똑같이 훑어 주거든요.

셀프 점검과 자동 점검, 어떻게 나눠 쓰나

둘은 경쟁 관계가 아니라 짝입니다. 정리하면 이렇습니다.

셀프 점검(5분): 메인 1~2페이지로 "우리 사이트에 이런 문제가 있나"의 감을 잡을 때. 도구 없이 즉시 가능. 키보드·스크린리더·흑백·모바일로 직접 체험.
자동 점검(ViewCheck): 전 페이지를 빠뜨림 없이 훑고, 위치·이유·우선순위까지 받아 작업 목록을 만들 때. 사람이 못 보는 규모를 커버.

추천 흐름은 "셀프로 한 번 체감 → 자동으로 전수 조사 → 우선순위대로 수정 → 수정 후 다시 자동 점검으로 검증"입니다. 셀프 점검만 하면 규모를 놓치고, 자동 점검만 하면 "왜 이게 문제인지"의 체감이 빠집니다. 둘을 함께 돌릴 때 점검이 완성됩니다.

자주 묻는 질문

점검을 실제로 해보려는 분들이 반복해서 묻는 것들을 모았습니다.

Q. 아이콘 옆에 텍스트가 있으면 점검에서 통과인가요?

텍스트 라벨이 함께 있으면 그 아이콘은 장식으로 봐도 됩니다. 다만 점검에서 통과하려면 그 아이콘이 aria-hidden="true"로 숨겨져 있어야 합니다. 안 숨기면 스크린리더가 "이미지 검색"처럼 중복으로 읽어서 오히려 미통과입니다. "텍스트가 있으니 괜찮다"가 아니라 "장식 아이콘이 숨겨졌는가"까지 봐야 통과 여부가 정해집니다.

Q. 마우스로 다 눌러 봤는데 멀쩡하면 점검 끝난 거 아닌가요?

아닙니다. 이게 가장 흔한 착각입니다. 마우스 테스트는 아이콘 문제의 대부분(라벨 누락, 키보드 미지원, 색 의존, 터치 영역 부족)을 거의 못 잡습니다. 마우스로는 모양으로 짐작해서 누를 수 있으니까요. 점검은 반드시 키보드만, 스크린리더로, 흑백으로, 모바일로 — 마우스가 아닌 조건으로 다시 봐야 합니다.

Q. 햄버거 메뉴(줄 세 개)는 워낙 유명한데도 점검에서 라벨을 봐야 하나요?

네. 시각적으로 익숙해도, 스크린리더 사용자에게는 그 줄 세 개가 "메뉴"라는 정보가 코드로 전달돼야 합니다. aria-label="메뉴 열기" 같은 이름은 유명세와 무관하게 필요합니다. 점검에서 햄버거 버튼은 "유명하니 패스"가 아니라 반드시 라벨 유무를 확인해야 하는 1순위 항목입니다. 메뉴가 열렸는지 닫혔는지 상태(aria-expanded)까지 보면 더 좋습니다.

Q. 이모지를 아이콘 대신 쓴 건 점검에서 어떻게 보나요?

권장하지 않는 구현입니다. 이모지는 기기·폰트마다 모양이 다르게 보이고, 스크린리더가 의도와 다른 이름으로(때로 장황하게) 읽는 경우가 많습니다. 점검에서 이모지 아이콘이 발견되면 KRDS 표준 SVG로 교체를 검토하세요. 기능 아이콘은 표준 SVG가 안전합니다.

Q. 점검에서 "비표준 아이콘"이 나왔는데, 다 바꿔야 하나요?

전부 한 번에 갈아엎을 필요는 없습니다. 먼저 검색·메뉴·닫기 같은 보편 기능 아이콘부터 KRDS 표준으로 맞추세요. 사용자가 가장 많이 마주치는 것들이라 효과가 큽니다. 브랜드 표현이 꼭 필요한 일부는 신중하게 남기되, 어느 쪽이든 의미 있는 아이콘에는 이름이 붙어 있는지 점검해야 합니다.

Q. 아이콘 색을 브랜드 색으로 통일했는데 대비가 약하다고 나옵니다.

브랜드 일관성은 중요하지만, 대비가 부족하면 저시력·고령 사용자가 아이콘을 못 봅니다. 특히 기능 아이콘(누를 수 있는 것)은 배경과의 명도 대비를 충분히 확보해야 통과입니다. 브랜드 색을 쓰더라도 명도를 조정해 대비 기준을 맞추는 게 맞습니다. 점검에서 대비 미달이 나오면 색조는 유지하되 명도만 손보면 됩니다.

Q. 아이콘에 툴팁(마우스 올리면 뜨는 설명)을 달았으면 점검에서 라벨은 통과인가요?

아닙니다. 툴팁은 마우스를 올려야 보이므로 키보드·터치·스크린리더 사용자에게는 닿지 않습니다. 점검에서 툴팁은 접근 가능한 이름(aria-label 등)의 대체가 되지 못합니다. 라벨은 라벨대로 두고, 툴팁은 추가 도움으로만 쓰세요.

Q. 점검 결과가 너무 많이 나오면 어디부터 손대야 하나요?

ViewCheck 리포트의 우선순위(P0~P3)를 따르면 됩니다. 가장 먼저는 이름 없는 아이콘 전용 버튼(특히 메뉴·검색·닫기). 그다음은 색으로만 의미를 전달하는 상태 아이콘. 그 후가 장식 아이콘 중복 낭독·작은 터치 영역·낮은 대비. 마지막이 일관성·표준 교체입니다. "사용자를 가장 많이 막는 것부터" 순서대로 처리하세요.

Q. 이미 운영 중인 사이트에 아이콘이 수백 개입니다. 점검부터 막막한데요.

바로 그래서 자동 점검이 필요합니다. 손으로 수백 개를 다 보는 건 비현실적이지만, ViewCheck로 전 페이지를 한 번에 돌리면 "이름 없는 아이콘 버튼이 어디에 몇 개인지" 목록이 나옵니다. 그 목록을 우선순위대로 핵심 경로(메인·검색·신청·로그인)부터 채워 나가면 됩니다. 막막함의 정체는 보통 "현황을 모른다"는 것인데, 점검이 그 현황을 숫자로 만들어 줍니다.

Q. 한 번 점검하고 고치면 끝인가요?

아니요. 사이트는 계속 바뀝니다. 새 페이지가 추가되고 컴포넌트가 수정되면서 새 아이콘이 들어오죠. 그래서 점검은 한 번의 이벤트가 아니라 주기적인 습관이어야 합니다. 큰 배포 전후로 ViewCheck를 한 번씩 돌려 회귀(고쳤던 게 다시 깨지는 것)를 잡는 흐름을 권합니다. 수정 후 다시 점검해서 "정말 통과로 바뀌었는지" 검증하는 것도 점검의 일부입니다.

Q. 점검을 디자인팀이 해야 하나요, 개발팀이 해야 하나요?

아이콘 점검은 어느 한 팀의 일이 아닙니다. 발견은 누구든 할 수 있지만, 라벨 누락은 개발이, 비표준 아이콘·일관성은 디자인이, "이 버튼이 무슨 동작인지 정의"는 기획이 책임집니다. 그래서 KRDS가 디자인(Figma)·코드(GitHub 킷)·문서(가이드라인)를 한 세트로 제공하는 겁니다. 점검 결과를 세 팀이 같은 기준으로 나눠 받으면 "그건 너희 일" 논쟁이 줄어듭니다. 점검 리포트가 위치·이유·개선 방법을 함께 주면 각자 자기 몫을 바로 가져갈 수 있습니다.

Q. 스크린리더를 써 본 적이 없는데, 점검이 가능할까요?

가능합니다. 거창하게 배울 필요 없습니다. Windows는 내레이터(Ctrl+Win+Enter), macOS는 VoiceOver(Cmd+F5)를 켜고, 아이콘 버튼에 Tab으로 초점을 준 뒤 "무엇이라고 읽는지"만 들어 보면 됩니다. 동작 이름이 들리면 통과, "버튼"만 들리면 미통과. 딱 이 한 가지만 확인해도 가장 흔한 위반(라벨 누락)을 잡습니다. 처음엔 어색하지만 5분만 써 보면 금방 익숙해집니다. 그리고 페이지가 많아 다 듣기 어려우면 ViewCheck가 같은 판정을 자동으로 대신해 줍니다.

Q. 디자인 토큰 채택률은 아이콘 점검과 무슨 상관인가요?

아이콘도 색·크기·간격 같은 시각 속성을 가집니다. 디자인 토큰 채택률은 이 속성들이 KRDS 표준 값을 따르는지를 수치로 보여 줍니다. 채택률이 낮다는 건 아이콘을 포함한 시각 자산이 표준에서 벗어나 제각각이라는 신호일 수 있습니다. 디자인 시스템 탭에서 이 수치를 보면, "개별 아이콘 하나"가 아니라 "사이트 전체의 시각 일관성"이 어느 수준인지 한눈에 잡힙니다.

Q. 점검 통과 기준이 KRDS인데, 우리는 자체 디자인 시스템을 쓰는데요?

자체 디자인 시스템이 있어도 접근성 기준(이름 부여, 색 비의존, 터치 영역, 초점 표시)은 KWCAG와 국제 표준에서 오는 것이라 그대로 적용됩니다. 즉 "표준 아이콘 모양을 쓰느냐"는 자율이어도, "아이콘 버튼에 이름이 있느냐"는 자율이 아닙니다. 점검에서 접근성 항목은 어떤 디자인 시스템을 쓰든 공통으로 통과해야 하는 부분입니다. KRDS는 그 위에 "공공 사이트 간 일관성"을 더 얹은 것이고요.

점검했다면, 무엇부터 고칠까 — 우선순위

점검을 돌리면 보통 아이콘 문제가 한두 개로 끝나지 않습니다. 페이지가 많을수록 "고칠 게 많다"는 압박이 듭니다. 그래서 우선순위가 중요합니다. 심각도 순으로 정리하면 이렇습니다.

가장 먼저(치명적): 이름 없는 아이콘 전용 버튼. 특히 메뉴·검색·닫기처럼 핵심 동작 버튼. 스크린리더 사용자에게 기능을 완전히 차단하므로 1순위. 신청·로그인 같은 핵심 경로에 있으면 더더욱 먼저.
그다음(높음): 색으로만 의미를 전달하는 상태 아이콘. 색각 이상·저시력 사용자가 정보를 놓침.
그 후(보통): 장식 아이콘 중복 낭독, 작은 터치 영역, 낮은 대비. 사용은 되지만 특정 사용자에게 불편.
여력이 되면(낮음): 같은 의미인데 제각각인 아이콘 통일, 비표준 아이콘을 KRDS 표준으로 교체. 접근성을 막진 않지만 경험을 한 단계 끌어올리는 항목.

ViewCheck 리포트는 이 우선순위(P0~P3)를 자동으로 매겨 주므로, "일단 눈에 띄는 것부터"가 아니라 "사용자를 가장 많이 막는 것부터" 순서대로 처리할 수 있습니다. 한정된 인력과 일정 안에서 효과 큰 개선에 집중하는 게 핵심입니다.

한 가지 덧붙이면, 같은 유형의 위반이 여러 페이지에 반복될 때는 "근원"을 고치는 게 효율적입니다. 예를 들어 공통 헤더 컴포넌트의 검색 아이콘 버튼에 라벨이 없으면, 그 헤더가 들어간 모든 페이지에서 똑같이 미통과로 잡힙니다. 이때 페이지마다 손대지 말고 공통 컴포넌트 한 곳만 고치면 전부 통과로 바뀝니다. 점검 리포트에서 "같은 위반이 여러 페이지에"라는 신호가 보이면, 개별 페이지가 아니라 공통 컴포넌트를 의심하세요.

더 깊이 확인하려면 — 공식 자료 안내

이 글은 KRDS의 아이콘 기준을 "어떻게 점검하는지" 관점에서 풀어 쓴 것입니다. 정확한 원문 기준과 코드·디자인 자산은 아래 공식 자료에서 직접 확인할 수 있습니다.

KRDS 가이드라인 PDF(디지털 정부서비스 UI/UX 가이드라인, 2025.08판) — 아이콘 사용 원칙의 1차 원천.
KRDS 스타일 가이드(웹) — 아이콘 규격과 예시를 화면으로 확인.
KRDS 컴포넌트 킷(GitHub) — 표준 아이콘 SVG를 그대로 사용(npm install krds-uiux 또는 CDN krds.min.css/krds.min.js).
KRDS 공식 Figma(@krds) — 디자이너용 아이콘 컴포넌트.

공식 자료는 "정답지", ViewCheck는 "내 답안 채점"입니다. 기준을 익히고(가이드라인) → 내 사이트를 점검하고(ViewCheck) → 표준 자산으로 고치는(킷·Figma) 한 바퀴를 돌리면 됩니다. 이 순환을 한 번 경험하면, 다음부터는 점검이 막막한 일이 아니라 "돌리면 답이 나오는" 일상 루틴이 됩니다.

오늘의 체크리스트 — 아이콘 점검, 이것만은

마지막으로, 디자이너·개발자·기획자가 아이콘을 점검할 때 바로 쓸 수 있는 체크리스트로 정리합니다.

☐ 마우스를 치우고 Tab 키만으로 아이콘 버튼에 초점이 가고 또렷이 보이는지 확인했다.
☐ 아이콘 전용 버튼(메뉴·검색·닫기 등)을 스크린리더로 들어 동작 이름이 읽히는지 확인했다.
☐ 텍스트와 함께 있는 장식 아이콘이 aria-hidden="true"로 숨겨져 중복 낭독되지 않는지 확인했다.
☐ 흑백 화면으로 상태 아이콘(오류/정상 등)이 색 없이도 구분되는지 확인했다.
☐ 모바일에서 아이콘 버튼이 빗나가지 않고 잘 눌리는지(터치 영역 약 44px 이상) 확인했다.
☐ 아이콘과 배경의 명도 대비가 충분한지 확인했다.
☐ 같은 동작을 여러 페이지에서 비교해 같은 아이콘을 쓰는지 확인했다.
☐ 보편 기능에 KRDS 표준 아이콘을 우선 썼는지 확인했다.
☐ 의미가 모호할 수 있는 아이콘에 텍스트 라벨이 병기됐는지 확인했다.
☐ 페이지가 많다면 ViewCheck로 전 페이지를 한 번에 점검했다.

이 열 가지 중 앞의 다섯은 도구 없이 5분이면 할 수 있는 셀프 점검이고, 뒤의 다섯은 자동 점검으로 채우면 빠릅니다. 셀프로 감을 잡고 자동으로 전수 조사 — 이 2단 구성이 가장 현실적입니다.

아이콘은 "작아서 사소한" 게 아니라, "작아서 점검에서 빠지기 쉬운" 요소입니다. 그런데 사용자는 바로 그 작은 그림을 보고 어디를 누를지 결정합니다. 점검 안 된 아이콘 하나가 누군가의 길을 막고, 점검해서 라벨 한 줄을 채운 아이콘 하나가 누군가의 길을 엽니다. 그 차이를 만드는 건 거창한 기술이 아니라, "마우스를 한 번 치우고 다른 눈으로 보는" 점검 습관입니다.

오늘 이야기를 한 문장으로 줄이면 이렇습니다. "점검은 마우스를 치우는 데서 시작한다." 키보드로, 스크린리더로, 흑백으로, 모바일로 — 평소와 다른 조건으로 화면을 다시 보면, 멀쩡해 보이던 아이콘들 사이에서 추측 게임을 만드는 것들이 드러납니다. 그리고 페이지가 많아 손으로 다 못 볼 때, ViewCheck가 그 점검을 전 페이지로 확장해 줍니다. 완벽을 한 번에 만들 필요는 없습니다. 가장 많이 막는 아이콘 하나부터 점검하고 고쳐 나가면, 우리 사이트는 분명히 조금씩 더 많은 사람에게 분명해집니다.

우리 사이트의 아이콘은 추측 게임을 만들고 있지 않을까요? krds.viewcheck.co.kr에서 URL만 넣으면, 이름 없는 아이콘 버튼이 어디에 몇 개 있는지 무료로 확인할 수 있습니다. 메인 페이지 하나만 돌려 봐도, 위 체크리스트가 실제로 지켜지고 있는지 5분 만에 보입니다.

#KRDS #공공웹 #디자인시스템 #아이콘Icon #웹접근성 #ViewCheck #정부웹사이트 #UIUX #자가진단 #접근성점검 #픽토그램 #KWCAG #아이콘 #Icon #체크리스트 #점검항목 #전자정부 #디지털정부 #행정안전부 #공공기관