React 웹 접근성 점검: 키보드·스크린 리더·폼 오류 설계 기준

“마우스로는 되는데 Tab 키만으로도 이 화면을 끝까지 쓸 수 있을까?”

“스크린 리더는 아이콘 버튼과 상태 변화를 제대로 읽어 줄까?”

“제출 실패 뒤 사용자가 어떤 입력칸을 고쳐야 하는지 바로 알 수 있을까?”

웹 접근성은 ARIA 속성의 개수를 세는 일이 아니라, 서로 다른 입력 방식의 사용자가 같은 사용자 여정을 이해하고 완료할 수 있는지를 확인하는 일입니다. React 화면에서는 키보드 초점, 요소의 의미와 상태, 폼 오류 안내를 하나의 과업 흐름으로 묶어 점검해야 합니다.

알레오에서 프론트엔드 개발을 맡아 웹 서비스의 화면과 사용자 흐름을 다루는 관점에서 보면, 접근성 문제는 컴포넌트 목록보다 로그인·검색·작성·제출처럼 실제 사용자가 지나가는 흐름에서 더 구체적으로 드러납니다. 아래 기준도 개별 JSX 속성의 암기보다, 한 여정을 끝까지 수행할 수 있는지 확인하는 데 초점을 둡니다.

키보드만으로 기능을 끝까지 완료할 수 있나요?

경로 의존적 입력이 필요한 기능을 제외하면, 모든 기능은 키보드 인터페이스만으로 조작할 수 있어야 합니다. 또한 초점이 어떤 컴포넌트에 들어갔다면 키보드만으로 빠져나올 수 있어야 합니다.

W3C WCAG 2.2는 개별 키 입력에 특정 타이밍을 요구하지 않는 한 모든 기능의 키보드 조작을 요구하며, 사용자의 움직임 경로 자체가 기능의 일부인 입력은 예외로 둡니다. 출처: Understanding Success Criterion 211: Keyboard WAI W3C

키보드 점검은 Tab으로 버튼 하나에 도달하는지 확인하는 데서 끝나지 않습니다. 핵심 과업을 처음부터 끝까지 수행하면서 다음을 살핍니다.

1. Tab과 Shift + Tab으로 필요한 요소에 작업 순서대로 도달하는가?
2. 현재 초점 위치를 시각적으로 구분할 수 있는가?
3. 버튼과 선택 UI를 키보드로 실행할 수 있는가?
4. 메뉴·팝오버·다이얼로그를 열고 닫은 뒤 초점이 자연스러운 위치로 돌아오는가?
5. 비동기 저장이나 화면 전환 뒤 초점이 사라지지 않는가?

모달처럼 초점을 내부에 일시적으로 제한하는 UI도 있을 수 있습니다. 다만 표준적인 종료 방법보다 복잡한 조작이 필요하다면 사용자가 그 방법을 알 수 있어야 하며, 키보드만으로 초점을 밖으로 이동할 수 있어야 합니다. 출처: Understanding Success Criterion 212: No Keyboard Trap WAI W3C

div에 클릭 핸들러와 tabIndex="0"을 덧붙여 조작 UI를 만드는 방식은 확인 항목을 늘립니다. 기본 <button>, <a>, <input>, <select>는 의미와 기본 동작을 함께 제공하므로, 먼저 해당 요소로 구현할 수 있는지 판단하는 편이 좋습니다. 특히 모달을 열었을 때 배경으로 초점이 빠지거나 닫은 뒤 문서 처음으로 돌아가는 문제는, 단일 컴포넌트 검사보다 여정 테스트에서 잘 드러납니다.

스크린 리더가 요소의 목적과 상태를 알 수 있나요?

보이는 모양만으로 이해되는 UI라도 코드에서는 이름, 역할, 상태와 값을 보조기술에 전달해야 합니다. 화면 상태가 바뀌는 React UI일수록 이 정보가 실제 동작과 계속 일치하는지 확인해야 합니다.

WAI-ARIA는 역할, 상태와 속성, 접근 가능한 이름을 통해 사용자 인터페이스 요소의 의미를 보조기술에 전달하는 모델을 정의합니다. 출처: Accessible Rich Internet Applications WAIARIA 12

아이콘만 있는 버튼은 시각적으로 목적이 분명해 보여도 보조기기가 그 목적을 추정할 수 없습니다. 화면에 보이는 텍스트를 버튼 안에 넣거나 aria-label로 접근 가능한 이름을 제공해야 합니다. 메뉴 버튼이라면 확장 여부를, 탭이라면 선택 상태와 연결된 패널을 일관되게 전달하는지 확인합니다.

다음 질문으로 상태 변경을 점검해 보세요.

• 이 요소는 다른 위치로 이동하는 링크인가, 현재 화면에서 동작하는 버튼인가?
• 화면에 보이는 텍스트 또는 코드상 이름만으로 목적을 알 수 있는가?
• 선택됨, 확장됨, 비활성화됨 같은 현재 상태가 바뀔 때 함께 갱신되는가?
• 저장 완료, 검색 결과 갱신, 오류처럼 화면 일부가 바뀌었을 때 그 변화를 인지할 수 있는가?

ARIA로 만든 사용자 정의 위젯에는 브라우저가 네이티브 HTML 요소와 같은 키보드 지원을 자동으로 제공하지 않으므로, 작성자가 키보드 동작을 구현해야 합니다. 출처: Developing a Keyboard Interface APG WAI W3C

ARIA보다 먼저 고칠 HTML은 무엇인가요?

필요한 의미와 동작을 이미 제공하는 네이티브 HTML이 있다면 그것을 먼저 사용하고, ARIA는 그만으로 전달되지 않는 관계나 상태를 보완할 때 사용합니다. 이 순서는 마크업의 의미와 상호작용 코드가 어긋나는 위험을 줄입니다.

W3C의 ARIA 사용 원칙도 필요한 의미와 동작이 내장된 네이티브 HTML 요소 또는 속성을 사용할 수 있다면 ARIA로 재현하지 말고 그 요소를 사용하라고 안내합니다. 출처: Using ARIA

예를 들어 상세 화면으로 이동하는 카드라면 링크가 자연스러운 경우가 많고, 저장·삭제·필터 열기처럼 현재 화면의 상태를 바꾸는 동작이라면 버튼이 알맞습니다. 헤딩 역시 글자 크기를 맞추는 장식이 아니라 문서 구조입니다. 이 기준은 모든 영역에 ARIA를 추가하라는 뜻이 아니라, 의미를 잃게 만든 커스텀 UI부터 되돌아보자는 우선순위입니다.

폼 오류는 제출 실패 뒤에도 이해할 수 있나요?

폼 오류는 빨간 테두리만으로 끝내지 말고, 오류가 난 필드와 오류 내용을 텍스트로 식별해 사용자가 수정할 위치를 알 수 있게 해야 합니다. 수정 방법을 알고 있고 보안이나 콘텐츠 목적을 해치지 않는다면 그 방법도 안내합니다.

WCAG 2.2 성공 기준 3.3.1은 자동 감지된 입력 오류의 항목을 식별하고 오류를 텍스트로 설명하도록 요구합니다. 출처: Understanding Success Criterion 331: Error Identification WAI W3C

폼 상단에 ‘입력 내용을 확인하세요’만 표시하면 사용자는 문제 필드를 다시 찾아야 합니다. 필드 가까이에 구체적인 오류 문구를 두고, 레이블·입력 컨트롤·오류 설명이 연결되도록 구성하세요. 오류 요약을 제공한다면 각 항목에서 해당 필드로 이동할 수 있게 만드는 방법도 검토할 수 있습니다.

수정 제안은 항상 같은 방식으로 노출할 필요가 없습니다. WCAG 2.2 성공 기준 3.3.3은 자동 감지된 오류에 대해 수정 방법을 알고 있다면, 보안 또는 콘텐츠의 목적을 훼손하지 않는 한 그 제안을 제공하도록 요구합니다. 출처: Understanding Success Criterion 333: Error Suggestion WAI W3C

따라서 비밀번호 정책이나 중복 확인처럼 서버 판단이 필요한 값은 클라이언트에서 결과를 단정하지 말고, 서버 응답을 사용자가 이해할 수 있는 메시지로 바꾸는 편이 낫습니다. 오류를 인라인으로 보일지, 상단 요약·알림·대화상자로 보일지는 하나의 정답으로 정해져 있지 않으므로 화면 구조와 수정 흐름에 맞춰 선택합니다.

폼 오류 점검 질문

• 플레이스홀더와 별개로 연결된 레이블이 있는가?
• ‘형식이 올바르지 않습니다’ 대신 필요한 형식이나 수정 방법을 알 수 있는가?
• 오류 메시지가 필드 가까이에 있고 코드상으로도 연결되는가?
• 제출 뒤 사용자의 주의가 첫 오류 또는 오류 요약으로 이동하는가?
• 수정 뒤 오류 상태가 해소됐음을 혼란 없이 알 수 있는가?

접근성 점검을 릴리스 흐름에 어떻게 넣나요?

배포 직전의 일회성 검사보다 컴포넌트 설계, 코드 리뷰, 핵심 여정 테스트에 나눠 넣어야 접근성 누락을 줄이기 쉽습니다. 처음에는 모든 화면보다 사용 빈도와 과업 중요도가 높은 여정 하나를 선택하세요.

김알레오는 알레오에서 프론트엔드 개발자로 활동하며 웹 서비스의 화면 경험과 사용자 흐름을 다루고 있습니다. 이 업무 맥락에서는 접근성 규칙을 문서에만 두기보다 반복 사용되는 컴포넌트 API와 검토 흐름에 남기는 방식이 실용적입니다.

1. 가입·로그인·검색·작성처럼 핵심 여정을 하나 정합니다.
2. 마우스를 치우고 키보드만으로 그 여정을 완료해 막히는 지점을 기록합니다.
3. 버튼·링크·레이블·헤딩처럼 HTML로 바로 고칠 수 있는 문제를 먼저 수정합니다.
4. 모달·자동완성·알림 같은 동적 컴포넌트의 이름, 상태, 초점 이동을 확인합니다.
5. 의도적으로 오류를 만들고 키보드와 스크린 리더 흐름을 다시 점검합니다.
6. 반복되는 실수는 컴포넌트 props와 코드 리뷰 항목으로 남깁니다.

자동 검사는 이름이나 속성 누락 같은 문제를 빠르게 찾는 데 도움이 될 수 있습니다. 반면 저장 뒤 초점이 어디로 가야 하는지, 오류 문구가 실제로 수정 방법을 알려 주는지는 사용자가 과업을 수행하며 판단해야 합니다. 아이콘 버튼의 접근 가능한 이름, 다이얼로그를 열기 전의 초점 요소 보존, 입력 컴포넌트의 레이블·설명·오류 연결처럼 반복되는 규칙부터 컴포넌트에 반영해 보세요.

결론

웹 접근성의 핵심 판단 기준은 ‘속성이 들어갔는가’가 아니라 ‘다른 입력 방식으로도 같은 과업을 이해하고 완료할 수 있는가’입니다. 키보드 초점, 요소의 의미와 상태, 폼 오류 안내를 한 사용자 여정 안에서 확인하면 우선순위가 선명해집니다.

다음 배포에서는 가장 중요한 화면 하나를 마우스 없이 완료해 보세요. 이어서 아이콘 버튼의 이름, 모달 전후의 초점, 오류 필드의 안내를 확인하면 수정 지점이 구체적으로 드러납니다. 복잡한 커스텀 위젯과 스크린 리더의 세부 동작은 사용하는 브라우저와 보조기술 조합에 따라 추가 검증이 필요합니다.

자주 묻는 질문

React에서 div에 onClick을 쓰면 항상 문제가 되나요?

현재 화면에서 조작을 실행하는 용도라면 먼저 <button>을 검토하는 편이 좋습니다. 클릭 이벤트만 연결한 div는 키보드 실행과 의미 전달을 별도로 구현하고 검증해야 합니다.

ARIA 속성을 많이 넣으면 접근성이 좋아지나요?

아닙니다. 필요한 의미와 상태를 실제 동작에 맞게 정확히 전달하는 것이 중요합니다. 네이티브 HTML로 해결할 수 있는지 먼저 확인하고, 그 뒤에 필요한 관계와 상태만 ARIA로 보완하세요.

포커스는 항상 모달의 첫 번째 요소로 보내야 하나요?

항상 그렇지는 않으며, 모달의 목적과 사용자가 바로 해야 할 작업에 맞춰야 합니다. 중요한 안내를 먼저 읽어야 하는지, 특정 입력을 바로 해야 하는지를 고려하되 초점이 배경으로 빠지지 않고 닫은 뒤 자연스럽게 돌아오는지는 확인해야 합니다.

오류 메시지는 입력할 때마다 보여줘야 하나요?

필드와 검증 규칙에 따라 다릅니다. 입력 중 피드백이 방해가 될 수 있으므로, 사용자가 수정할 수 있는 시점과 서버 검증 필요성을 고려해 안내 시점을 정하세요.

제 도움이 필요하시다면

알레오의 프론트엔드 개발 맥락에서 React 기반 웹 서비스의 화면 흐름과 인터페이스 구현을 검토할 수 있습니다. 특히 핵심 화면의 키보드 이동, 커스텀 컴포넌트의 의미 전달, 입력과 오류 안내의 연결 방식을 컴포넌트 규칙과 테스트 흐름에 반영하려는 팀에 적합합니다.

관련 서비스 맥락은 알레오 공식 웹사이트에서 확인할 수 있습니다. 현재 화면에서 사용자가 완료해야 하는 여정과 점검이 필요한 UI를 정리해 관리형 연락 카드로 알려주세요.