어느 서비스의 ’신청’인지 구별되게

KRDS SP-110 — 신청 목록의 각 컨트롤 요소에 title 속성 또는 aria-describedby 속성을 활용하여 접근 가능한 이름이 변별될 수 있도록 하고 있다.

0. 들어가며 — 신청 대상 탐색 서브섹션의 마지막

이번 784편은 신청 목록의 각 컨트롤 요소에 title 속성 또는 aria-describedby 속성을 활용하여 접근 가능한 이름이 변별될 수 있도록 하라는 규칙입니다. ‘신청 대상 탐색’ 서브섹션(SP-101~110)의 마지막이죠.

목록의 모든 ‘신청하기’ 버튼이 — 똑같이 ’신청하기’로만 읽히면, 스크린 리더 사용자는 어느 서비스의 신청인지 모르죠. SP-110은 각 버튼의 접근가능한 이름을 변별되게 규정합니다. 이번 편을 풀어냅니다.

1. 원문 — 컨트롤 접근가능한 이름 변별

SP-110 (서비스 패턴 > 신청 > 신청 대상 탐색) “신청 목록의 각 컨트롤 요소에 title 속성 또는 aria-describedby 속성을 활용하여 접근 가능한 이름이 변별될 수 있도록 하고 있다.”

각 컨트롤의 접근가능한 이름이 변별되도록 title·aria-describedby로 제공하라는 뜻입니다.

정리: 신청 목록 각 컨트롤의 접근가능한 이름을 변별되게 하라. 이게 SP-110입니다.

2. 왜 이름 변별인가

신청 목록에는, 각 서비스마다 컨트롤(신청하기 버튼·상세보기 링크 등)이 있습니다. 그런데 모든 버튼이 똑같이 ‘신청하기’·’상세보기’로만 되어 있으면, 스크린 리더 사용자는 어느 서비스의 버튼인지 구별 못 하죠. SP-110은 접근가능한 이름을 변별되게 하라고 합니다.

이름이 변별되지 않을 때의 문제:

어느 서비스인지 모름 목록의 모든 ‘신청하기’ 버튼이 같은 이름이면, 스크린 리더가 ’신청하기 버튼, 신청하기 버튼…’으로 똑같이 읽습니다. 시각 사용자는 옆의 서비스 이름으로 어느 버튼인지 알지만, 스크린 리더 사용자는 버튼만 따로 탐색하면(버튼 목록 보기 등) 구별 못 하죠.

잘못 신청 위험 어느 서비스의 버튼인지 모르면, 엉뚱한 서비스를 신청할 위험이 있습니다.

그래서 SP-110은 — 이름 변별을 요구합니다:

title / aria-describedby 활용 각 컨트롤(버튼·링크)에, 서비스를 식별하는 접근가능한 이름을요. 방법:

aria-describedby 버튼을, 그 서비스 이름(제목 요소)과 연결합니다. 스크린 리더가 ’○○ 서비스 신청 하기’처럼 읽죠.

title 속성 또는 title로 부가 설명을요(단 title은 접근성 한계가 있어 보조적으로).

aria-label ’○○ 신청하기’처럼 직접 이름을요.

변별 가능 각 버튼의 이름이, ‘○○ 신청하기’·’△△ 신청하기’처럼 서비스별로 변별되게요. 스크린 리더 사용자가 어느 서비스의 버튼인지 알게요.

반복 텍스트 보완 시각적으론 ’신청하기’만 보여도, 접근가능한 이름은 서비스 이름을 포함하게요. 시각 간결함 + 접근성 변별을 둘 다요.

WCAG 2.4.4(맥락 속 링크 목적). 링크·버튼의 목적이, 그 자체로(또는 맥락으로) 명확해야 한다(WCAG 2.4.4). ’신청하기’만으론 맥락(어느 서비스) 없이 모호하므로, 서비스 이름을 접근가능한 이름에 포함해 변별하죠.

SP-025(접근가능한 이름)의 신청 적용. SP-025(시각 레이블 없어도 접근가능한 이름)·SP-110이 같은 정신입니다. 반복되는 컨트롤(신청하기)을, 각각 변별되는 접근가능한 이름으로요. 신청 목록에 구체 적용한 거죠.

**‘신청 대상 탐색’의 접근성 마무리.** ’신청 대상 탐색’(SP-101~110)은 정렬·메타·상태·기한·간결·명칭·말줄임·바로 신청· 외부 단서·이름 변별까지 탐색의 전반을 다뤘습니다. SP-110은 그 접근성 마무리죠.

이 규칙은 신청(SP)의 ’컨트롤 이름 변별’을 담당합니다 — 각 컨트롤의 접근가능한 이름을 변별되게 해(110), 스크린 리더 사용자가 어느 서비스의 버튼인지 알고 정확히 신청하게 하죠. 신청 대상 탐색의 마무리입니다.

정리하면 — 목록의 모든 ‘신청하기’ 버튼이 같은 이름이면 스크린 리더 사용자가 어느 서비스인지 모르므로, title·aria- describedby·aria-label로 각 컨트롤의 접근가능한 이름을 ’○○ 신청하기’처럼 변별되게 해야 합니다.

3. 점검 / 개선

무엇을 점검하나

이름 변별 — 각 신청 버튼의 접근가능한 이름이 서비스별로 변별되는가.

속성 활용 — aria-describedby·title·aria-label로 서비스 이름이 연결되는가.

시각+접근성 — 시각적 간결함(‘신청하기’) + 접근성 변별(‘○○ 신청하기’)을 둘 다 잡는가.

개선 방향

각 컨트롤에 aria-describedby(서비스 제목 연결)·aria-label(‘○○ 신청하기’).

시각은 ‘신청하기’, 접근가능한 이름은 서비스 이름 포함(WCAG 2.4.4).

4. 누가 담당하나 / 우리 사이트에 해당될까?

역할	책임
퍼블리셔/개발	접근가능한 이름 구현
QA/접근성	컨트롤 이름 변별 검증

기관 유형	SP-110 적용
중앙행정기관(대표·운영) / 공공기관 / 지자체	✅ 필수 (웹접근성 의무)

웹접근성 의무 대상이며 신청 목록을 제공하는 사이트가 해당됩니다.

5. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 각 신청 버튼의 접근가능한 이름이 서비스별로 변별되나요?

□ aria-describedby·title·aria-label로 서비스 이름이 연결되나요?

□ 시각적 간결함 + 접근성 변별을 둘 다 잡나요?

❓ FAQ

Q1. 모든 ‘신청하기’ 버튼이 같은 이름이면 왜 문제인가요? 스크린 리더가 ‘신청하기 버튼’으로 똑같이 읽어, 버튼만 따로 탐색하면 어느 서비스의 버튼인지 구별 못 합니다. 엉뚱한 서비스를 신청할 위험이 있죠. Q2. 어떻게 변별하나요? aria-describedby로 버튼을 그 서비스 제목과 연결하거나, aria-label로’○○ 신청하기’처럼 직접 이름을 줍니다. 스크린 리더가 ’○○ 서비스 신청하기’로 읽죠. Q3. 시각적으론 ’신청하기’만 보여도 되나요? 네. 시각은 ’신청하기’로 간결하게, 접근가능한 이름은 서비스 이름을 포함 해 변별되게요. 시각 간결함 + 접근성 변별을 둘 다 잡습니다(WCAG 2.4.4).

6. 마무리

SP-110의 메시지:

어느 서비스의 ’신청’인지 구별되게 — 각 컨트롤의 접근가능한 이름을 변별되게 하라.

모든 ‘신청하기’ 버튼이 같은 이름이면 스크린 리더 사용자가 어느 서비스인지 모릅니다. aria-describedby·aria-label로 변별되게 해 정확히 신청하게 하는 게 핵심이죠. ‘신청 대상 탐색’ 서브섹션이 끝났습니다. 다음 편부터는 ‘서비스 정보 확인’ 서브섹션입니다.

다음 편 예고 ▶ 「785. (SP-111) 본문 콘텐츠의 제목을 신청 서비스명으로 제공하고 있다.」

ViewCheck는 신청 목록 컨트롤의 접근가능한 이름이 변별되는지를 진단합니다.

📚 참고 출처

KRDS 서비스 패턴 — 신청 가이드 — https://www.krds.go.kr/html/site/service/service_04.html

WCAG 2.1 SC 2.4.4 Link Purpose — https://www.w3.org/WAI/WCAG21/Understanding/link-purpose-in-context.html

KRDS #ViewCheck #공공웹사이트 #전자정부 #디지털정부 #웹접근성 #디자인시스템 #UIUX #UI컴포넌트 #웹표준

KRDS,ViewCheck,공공웹사이트,전자정부,디지털정부,웹접근성,디자인시스템,UIUX,UI컴포넌트,웹표준