접근 가능한 문의 양식과 유럽 접근성법

문의 양식은 방문자와 기업 사이의 유일한 문일 때가 많습니다. 그 문을 열려면 마우스, 좋은 시력, 흐릿한 그림 퍼즐을 풀 인내심이 필요하다면 일부 사람은 밖에 남습니다. 2025년 중반부터는 단순한 사용성 문제가 아닙니다. EU의 소비자에게 판매하는 많은 기업에는 법적 문제이기도 합니다.

유럽 접근성법의 적용 대상

유럽 접근성법(지침 (EU) 2019/882)은 2025년 6월 28일부터 적용되었습니다. 전자상거래, 소비자 금융 서비스, 전자책, 전자통신 및 일부 여객 운송 등 소비자에게 제공되는 특정 제품과 서비스에 접근성 요건을 정합니다. 웹사이트에서는 고객이 연락, 질문 또는 불만 제기에 사용하는 양식을 포함하여 온라인 쇼핑몰이나 금융 서비스 전체가 대상입니다. 서비스를 제공하는 영세기업은 면제됩니다. 직원이 열 명 미만이고 연 매출 또는 대차대조표 총액이 EUR 2백만 이하인 기업입니다. 순수하게 다른 기업만을 대상으로 하는 서비스는 일반적으로 적용 범위 밖입니다.

각 회원국은 지침을 국내법으로 전환했습니다. 독일에는 Barrierefreiheitsstärkungsgesetz(BFSG)가 있으며, 폴란드에는 특정 제품 및 서비스의 접근성 요건 충족을 보장하는 2024년 법률이 있습니다. 감독기관과 처벌은 국가마다 다르지만 기술적 기준은 대체로 같습니다. 실무에서는 웹 콘텐츠 접근성 지침(WCAG)을 기반으로 한 유럽 표준 EN 301 549를 사용합니다.

법적 의무가 없어도 도움이 되는 이유

면제 대상이거나 다른 기업만을 고객으로 둘 수도 있습니다. 그래도 접근 가능한 양식을 만들 가치는 있습니다. 중간에 포기하는 사람 한 명 한 명이 받지 못한 문의이기 때문입니다. 화면 낭독기 사용자에게 도움이 되는 개선은 기차 안이나 밝은 햇빛 아래에서 휴대전화로 작성하는 사람, 손목을 다친 사람, 익숙하지 않은 언어로 작성하는 사람에게도 도움이 됩니다. 명확한 레이블과 유용한 오류 메시지는 모든 사용자의 중도 포기를 줄이며 스팸 방지를 약화시키지도 않습니다.

WCAG 2.2 기준을 포함한 실용적인 점검 목록

• 입력 필드와 연결된 눈에 보이는 레이블(1.3.1, 3.3.2): 모든 필드에 for/id로 연결된 표시 레이블을 둡니다. 플레이스홀더만으로는 레이블이 될 수 없습니다. 입력을 시작하면 사라지기 때문입니다.
• 해결 방법을 설명하는 오류 메시지(3.3.1, 3.3.3): 필드 이름, 문제 및 수정 방법을 빨간 테두리뿐 아니라 텍스트로 알려줍니다. “잘못된 입력”보다 “name@example.com 형식의 이메일 주소를 입력하십시오”가 낫습니다.
• 완전한 키보드 조작(2.1.1, 2.1.2): 모든 필드, 확인란, CAPTCHA 및 제출 버튼에 Tab, Space 및 Enter로 접근하고 사용할 수 있어야 하며 키보드가 갇히는 구간이 없어야 합니다.
• 눈에 보이는 포커스(2.4.7): 어떤 필드가 활성화되어 있는지 항상 알 수 있어야 합니다. 대안 없이 브라우저의 포커스 테두리를 없애면 이 기준을 충족하지 못합니다.
• 충분한 명암비(1.4.3): 텍스트, 레이블 및 오류 메시지는 배경과 최소 4.5:1의 명암비를 가져야 합니다. 큰 텍스트는 3:1입니다.
• 대상 크기(2.5.8): 버튼, 확인란 및 링크의 크기는 최소 24 × 24 CSS 픽셀이거나 주변에 충분한 간격이 있어야 합니다.
• CAPTCHA 대안(1.1.1) 및 접근 가능한 인증(3.3.8): 1.1.1은 텍스트 대체와 둘 이상의 감각 형식으로 제공되는 CAPTCHA를 요구합니다. 3.3.8은 엄밀히는 로그인 단계에 적용되지만 그 취지는 이어집니다. 왜곡된 글자를 다시 쓰거나 덧셈을 푸는 퍼즐이 유일한 통과 방법이어서는 안 됩니다. 대안을 제공하거나 퍼즐 자체가 필요 없는 방법을 사용하십시오.
• 보조 기술에서도 숨겨진 허니팟: 함정 필드의 감싸는 요소에 aria-hidden="true"를 적용하고 tabindex="-1"을 지정하여 화면 낭독기 및 키보드 사용자가 도달하지 않도록 합니다.

CAPTCHA와 허니팟: 스팸 방지와 접근성이 만나는 곳

엄밀히 말해 기준 3.3.8은 문의 양식이 아니라 로그인과 인증 단계에 관한 것입니다. 그러나 그 취지는 양식에도 잘 적용됩니다. 왜곡된 글자를 입력하거나 덧셈을 풀거나 이미지 격자에서 신호등을 고르는 일은 일부 사람을 완전히 배제합니다. Cloudflare Turnstile, Friendly Captcha, 시간 검사와 결합한 허니팟, Akismet 같은 서버 측 필터링처럼 보통 퍼즐 없이 작동하는 방법은 방문자에게 증명을 요구하지 않고 스팸을 막습니다. 허니팟은 화면 낭독기와 키보드 사용자에게도 실제로 보이지 않아야 친화적입니다.

<div class="hp" aria-hidden="true">
  <label for="hp-website">이 필드는 비워 두십시오</label>
  <input type="text" id="hp-website" name="website"
         tabindex="-1" autocomplete="off">
</div>
<!-- CSS: .hp { position: absolute; left: -10000px; } -->

십오 분 안에 자신의 양식 테스트하기

1. 1마우스를 옆에 두고 키보드만으로 양식 전체를 작성하십시오. 모든 필드와 제출 버튼에 도달할 수 있으며 현재 위치가 항상 보입니까?
2. 2빈 양식을 제출한 뒤 잘못된 이메일 주소로 제출하십시오. 오류가 올바른 필드 옆에 텍스트로 나타나며 무엇을 해야 하는지 명확합니까?
3. 3휴대전화에서 페이지를 열거나 브라우저를 200%로 확대하십시오. 모든 내용을 읽을 수 있고 버튼을 누르기 쉬우며, 쿠키 배너나 채팅 위젯이 제출 버튼을 가리지 않습니까?
4. 4화면 낭독기(VoiceOver, NVDA 또는 TalkBack)를 켜고 들어보십시오. 모든 필드를 레이블과 함께 읽어주고 허니팟은 읽지 않습니까?
5. 5axe-core 같은 자동 점검을 실행하십시오. 누락된 레이블과 명암비 문제를 빠르게 찾지만 모든 것을 찾지는 못합니다. 위의 수동 점검은 여전히 필요합니다.

전체 상태부터 파악하고 싶다면 formexposed가 아무것도 제출하지 않고 공개 양식을 외부에서 확인합니다. 접근성 점검은 각 양식에서 axe-core를 실행하고, 접근 가능한 대안이 없는 CAPTCHA와 화면 낭독기가 읽는 허니팟을 표시합니다. 휴대전화 화면에서도 터치 대상, 제출 버튼을 가리는 겹침 요소, 가로 스크롤을 확인합니다. 무료 점검은 전체 수준을 보여주며 이런 세부 사항은 전체 보고서에 있습니다. 위 목록의 좋은 출발점이지만 실제 사용자를 통한 테스트를 대체하지는 않습니다.