실험 4 · 전후 비교 실습

한국어 실무 UI 컴포넌트 전후(Before / After) 비교

상용 웹 개발 현장에서 가장 빈번하게 발생하는 4대 UI 컴포넌트(카드 제목, 캡션, 버튼, 폼)의 문제 상태와 접근성 개선 코드를 인터랙티브하게 조작하며 실시간 비교합니다.

네 가지 비교에서 확인할 차이

아래 전후 비교 실험에서 유형을 바꾸며 확인할 수 있습니다. 각 사례는 문제를 재현한 조건과 수정 방법을 따로 설명합니다.

  1. 긴 제목: 한 줄 말줄임은 제목 뒤쪽의 신청 조건까지 숨길 수 있습니다. 전체 문장을 표시하고 카드 높이가 달라지는 결과를 확인하세요. 제목 잘림 사례
  2. 회색 캡션: 흰색 배경의 #999999는 2.85:1로 일반 텍스트 AA 기준에 미달합니다. #595959는 7.00:1이며, 실제 배경색에서는 다시 계산해야 합니다. 캡션 색상 사례 · 명도 대비 계산 실험
  3. 확대 버튼: 고정 높이와 숨김 처리는 큰 글자가 들어갈 공간을 막습니다. 최소 높이와 줄바꿈을 적용한 버튼의 변화를 확인하세요. 버튼 확대 사례
  4. 폼 오류: 붉은 테두리만으로는 잘못된 값의 원인을 알 수 없습니다. 제출 후 설명 문구가 나타나고 입력 필드에 연결되는지 확인하세요. 자동 포커스 이동은 구현되어 있지 않습니다. 폼 오류 사례

한국어 실무 UI 컴포넌트 전후(Before / After) 비교 실험

현업 상용 웹에서 가장 빈번하게 발생하는 4대 UI 컴포넌트의 접근성 결함과 수정 코드를 실시간 조작하며 비교합니다.

사례: 오류를 색상으로만 표시하는 폼 vs ARIA 연동 폼

잘못된 이메일을 입력하거나 빈칸으로 제출해 보세요. 문제 예시는 테두리 색만 바뀌고, 개선 예시는 텍스트 설명과 aria-invalid를 제공합니다. 실제 스크린리더 음성 출력은 별도로 검증하지 않았습니다.

⚠️ Before: 색상에만 의존하는 결함 폼WCAG 1.4.1 위반

오류 발생 시 입력 테두리만 붉은색으로 바뀌고 오류 설명이 제공되지 않는 예시

✓ After: 오류 설명과 필드 연결오류 식별 개선 예시
<!-- 오류 설명과 필드를 연결하는 HTML 예시 -->
<label for="user-email">이메일 <span aria-hidden="true">*</span></label>
<input 
  id="user-email" 
  type="email" 
  aria-required="true"
  aria-invalid="true" 
  aria-describedby="email-error-msg" 
  class="input-accessible-error"
/>
<p id="email-error-msg" role="alert" class="error-msg">
  <span aria-hidden="true">⚠️</span> 올바른 이메일 주소(name@domain.com)를 입력해 주세요.
</p>

컴포넌트 단위 웹 접근성(Micro A11y) 엔지니어링 지침

버튼, 입력창, 안내 문구마다 HTML 구조와 CSS를 함께 확인하면 문제 원인과 수정 효과를 이해하기 쉽습니다.

1. 폼 유효성 검증에서의 다중 감각 단서(Multimodal Cues) 제공 원칙

WCAG 2.2의 1.4.1(Use of Color)은 색상만을 정보 전달의 유일한 시각적 수단으로 사용하지 않도록 요구합니다. 폼 오류에는 원인을 설명하는 텍스트를 제공하고 aria-invalid="true"와 aria-describedby로 해당 입력 필드에 연결할 수 있습니다.

2. 텍스트 200% 확대 대응을 위한 상대 단위(Relative Units) 사용

고정 높이(height: 40px;)와 고정 줄 높이(line-height: 40px;)를 사용하면 텍스트를 200%로 확대했을 때 내용이 잘릴 수 있습니다. em 단위 패딩과 최소 높이를 사용해 내용에 맞춰 버튼이 커지도록 할 수 있습니다.

🔗 본 실험과 직접 연계된 사례 연구 2종:

UI 컴포넌트 접근성 자주 묻는 질문 (FAQ)

Q. 스크린리더는 왜 색상 변경(예: 붉은 테두리)을 감지하지 못하나요?

A. 붉은 테두리만 바꾸면 오류 원인에 해당하는 텍스트나 필드 상태가 추가되지 않습니다. 구체적인 오류 문구를 제공하고 aria-invalid와 aria-describedby로 필드에 연결해야 합니다. 실제 음성 출력은 스크린리더와 브라우저 조합에 따라 달라집니다.

Q. 버튼 텍스트가 2줄이 되면 UI 디자인이 망가지지 않나요?

A. 버튼을 무리하게 1줄로 강제(white-space: nowrap)하면 텍스트 확대 시 화면 밖으로 튀어나가거나 버튼 밖으로 글자가 잘려 사용자가 클릭 대상의 기능을 알 수 없습니다. 버튼의 flex-wrap 허용 및 부모 컨테이너의 flex/grid 정렬(align-items: stretch 등)을 통해 2줄이 되더라도 정돈된 균형을 유지할 수 있습니다.

Q. 웹 접근성 결함 컴포넌트가 사이트 전체에 미치는 영향은 무엇인가요?

A. 단 하나의 핵심 컴포넌트(예: 회원가입 폼이나 결제 버튼)에 접근성 결함이 있으면, 보조공학기기 사용자나 고령층 사용자는 웹사이트의 전체 핵심 과업을 완수하지 못하고 이탈하게 됩니다. 마이크로 컴포넌트 단위의 접근성 준수가 전체 디지털 포용의 전제조건입니다.