React 및 Flutter UI 리뷰를 위한 접근성 프롬프트

사람들이 UI를 접근 가능하게 만들려다 놓치는 것들

대부분의 접근성 문제는 "대규모 재설계" 문제가 아닙니다. 사용자가 UI를 실제로 사용할 수 있는지를 결정하는 작은 디테일들입니다.

흔히 먼저 깨지는 부분은 매우 일관적입니다. 페이지는 시각적으로 괜찮아 보이고 빠른 시각 검사도 통과하지만, 키보드나 스크린 리더로는 사용하기 어려울 수 있습니다.

UI가 흔히 실패하는 첫 번째 장소는 다음과 같습니다:

• 키보드 접근성: 주요 컨트롤에 도달할 수 없거나 모달 안에 갇힘
• 포커스 순서 및 포커스 상태: 포커스가 튀거나 현재 위치를 볼 수 없음
• 레이블과 이름: 입력과 버튼에 불명확하거나 누락된 접근 가능한 이름
• 안내(Announcements): 동적 업데이트가 발생하지만 스크린 리더에 알리지 않음
• 대비와 가독성: 텍스트, 아이콘, 오류 상태가 잘 보이지 않음

문제는 회귀가 얼마나 쉽게 발생하는가 입니다. 버튼을 아이콘으로 바꾸거나 카드에 제스처 핸들러를 감싸거나 커스텀 드롭다운을 추가하는 작은 변경만으로 키보드 지원이 사라지거나 포커스 순서가 깨지거나 레이블이 빠져도 아무도 눈치채지 못할 수 있습니다.

흔한 시나리오: React 폼에 입력 내부에 새로운 "지우기" 아이콘이 추가됩니다. 유용해 보이지만 아이콘이 포커스가 불가능하고 이름이 없으며 클릭 이벤트를 가로챕니다. 이로 인해 키보드 사용자는 활성화할 수 없고 스크린 리더 사용자는 이름 없는 컨트롤을 듣게 됩니다.

이 글은 두 가지를 제공합니다: UI 코드(React 및 Flutter)에 바로 붙여 쓸 수 있는 복사 가능한 프롬프트와 몇 분 내에 실행할 수 있는 반복 가능한 리뷰 흐름입니다. 목표는 첫날 완벽함이 아니라 실제 사용자를 막는 문제를 잡는 것입니다.

제품 화면을 만들지만 접근성 전문가는 아닌 분들을 위해 작성했습니다. Koder.ai 같은 바이브 코딩 도구를 사용하는 팀에도 잘 맞습니다. UI 변경이 빠르게 일어나므로 빠르고 일관된 점검이 필요하기 때문입니다. 실용적인 출발점을 원한다면, 이 React 및 Flutter UI 리뷰용 접근성 프롬프트는 배포할 때마다 재사용하도록 설계되었습니다.

대부분의 문제를 빠르게 잡아내는 5가지 체크

화면을 검토할 시간이 15분뿐이라면, 이 체크들이 대부분의 문제를 찾아냅니다. React와 Flutter 모두에 적용되며, 이 접근성 프롬프트와 잘 맞습니다.

1) 키보드만으로 사용할 수 있나요?

마우스를 사용하지 않고 페이지를 이동해보세요. Tab과 Shift+Tab으로 이동하고 Enter와 Space로 활성화하며, 메뉴, 탭, 리스트처럼 보이는 위젯에는 방향키를 사용하세요.

빠른 확인 지표: 모달 안에 갇히거나 "닫기" 같은 주요 컨트롤에 도달할 수 없으면 문제가 있습니다.

2) 포커스 순서는 합리적이고 포커스가 시각적으로 보이나요?

탭할 때 포커스는 시각적 레이아웃(위에서 아래, 왼쪽에서 오른쪽)을 따라야 하며 숨김 영역으로 튀지 않아야 합니다. 포커스는 또한 명확해야 합니다. 디자인에서 미묘한 아웃라인을 사용한다면, 밝은 배경과 어두운 배경 모두에서 여전히 보이는지 확인하세요.

3) 컨트롤에 명확한 이름이 있나요?

스크린 리더는 모든 상호작용 요소에 유용한 이름을 발표해야 합니다. "Button"만으로는 부족합니다. 아이콘은 접근 가능한 레이블이 필요하고, 폼 필드는 플레이스홀더가 사라져도 연결된 레이블이 필요합니다.

4) 대비와 텍스트 크기는 괜찮나요?

작은 텍스트, 비활성 텍스트, 컬러 버튼의 텍스트를 확인하세요. 또한 줌을 테스트하세요: 글자 크기를 키워도 레이아웃이 겹치거나 주요 콘텐츠가 잘리는지 확인합니다.

5) 변경 사항이 명확하게 안내되나요?

무언가가 변경될 때(오류, 로딩, 성공), 사용자가 추측하지 않도록 해야 합니다. 필드 옆의 인라인 오류 텍스트를 사용하고 폼 오류를 알리며 로딩 상태를 분명히 만드세요.

Koder.ai에서 화면을 만든다면 "이 페이지의 키보드 전용 흐름, 포커스 순서, 스크린 리더 레이블을 검증해줘"라고 요청한 다음 위 단계로 결과를 검토하세요.

UI를 변경하기 전에 리뷰 범위 설정하기

접근성 작업은 검토 대상과 "충분히 좋은" 기준을 변경하기 전에 정하면 더 빨리 진행됩니다. 범위를 좁히면 이 React 및 Flutter UI 리뷰용 접근성 프롬프트가 더 유용해집니다. 모델이 실제 화면과 상호작용에 집중할 수 있기 때문입니다.

중요한 여정을 선택하세요

제품 전체가 아니라 2~4개의 핵심 사용자 여정으로 시작하세요. 좋은 선택은 사용자가 완료해야 가치를 얻는 흐름과 실패 시 사용자가 잠길 수 있는 흐름입니다.

대부분의 앱에서는 로그인, 주요 "생성 또는 구매" 흐름(결제, 예약, 제출), 그리고 설정이나 프로필 같은 계정 영역 하나가 적당합니다.

그다음 각 여정의 정확한 화면들을 적어두세요(5~8 화면이라도 좋습니다). 에러 메시지, 빈 상태, 로딩 상태, 확인 대화상자 같은 "중간" 상태도 포함하세요. 포커스와 스크린 리더 출력을 망가뜨리는 곳이 바로 여기입니다.

구체적 예: Koder.ai에서 작은 CRM 화면을 만든다면 범위를 "로그인 -> 연락처 열기 -> 연락처 추가 -> 저장 -> 성공 메시지 보기"로 정하세요. 이 단일 흐름은 폼, 검증, 대화상자, 안내를 모두 건드립니다.

"통과" 기준을 정하세요

실용적으로 접근하세요. WCAG AA 스타일 기대치를 목표로 삼되, 빠르게 적용할 수 있는 평범한 체크로 옮기세요: 키보드가 끝까지 동작하는지, 포커스가 눈에 보이고 논리적인지, 이름과 레이블이 의미 있는지, 대비가 읽기 쉬운지 등.

간단한 합격/불합격 기록 형식을 사용해 논쟁에 시간을 낭비하지 마세요. 각 화면에 대해 다음을 기록하세요:

• 체크: (키보드, 포커스 순서, 레이블, 대비, 안내)\n- 결과: 통과 또는 실패\n- 증거: 한 문장으로 발생한 일 설명\n- 수정 추측: 변경이 필요한 항목(컴포넌트, prop, 스타일)
• 재검토: 수정 후 시도할 항목

이 방식은 React와 Flutter 모두에서 일관된 리뷰를 유지하고, 문제를 다른 사람에게 넘길 때 재설명이 필요 없게 만듭니다.

React 컴포넌트용 복사 가능한 프롬프트(키보드, 레이블, 역할)

접근성 리뷰를 요청할 때 가장 빠른 성과는 구체적으로 묻는 데서 옵니다: 어떤 컴포넌트인지, 어떤 사용자 동작인지, 무엇이 "좋은" 것인지. 이 React 및 Flutter UI 리뷰용 접근성 프롬프트는 컴포넌트 코드와 UI가 무엇을 하려는지에 대한 짧은 설명을 붙여서 사용할 때 가장 잘 작동합니다.

채팅 기반 빌더(예: Koder.ai)를 사용 중이라면 화면이나 컴포넌트를 생성한 직후에 프롬프트를 추가해 문제가 앱 전체에 퍼지기 전에 수정하세요.

Review this React component for keyboard navigation issues. 
- Can every interactive element be reached with Tab and activated with Enter/Space?
- List the exact problems you see in the code.
- Propose fixes with small code edits.

Check focus order and focus visibility.
- Describe the expected focus order for a keyboard-only user.
- Point out where focus could get lost (modals, menus, drawers).
- Tell me exactly where to add :focus-visible styles (which elements, which CSS).

Find missing accessible names.
- Identify inputs, buttons, and icons without clear labels.
- Suggest label + htmlFor, aria-label, aria-labelledby, or visible text.
- If there is helper/error text, connect it with aria-describedby.

Identify interactive elements that are not buttons/links.
- Find div/span with onClick, custom dropdowns, and clickable cards.
- Suggest correct semantics (button/a) or add role, tabIndex, and keyboard handlers.

List screen reader announcements that will be confusing.
- Predict what a screen reader will announce for key controls.
- Rewrite UI text to be shorter and clearer.
- Suggest aria-live usage for status changes (loading, errors, saved).

프롬프트를 보내기 전에 다음 세부사항을 포함하면 일반적인 조언이 아니라 실용적인 수정을 받을 수 있습니다:

• 컴포넌트가 무엇인지(예: "로그인 폼", "요금제 토글", "설정 모달").
• 사용자가 따라야 할 키보드 경로(시작점과 끝점).
• 사용된 UI 라이브러리(MUI, Chakra, Radix, 커스텀 컴포넌트).
• 테스트할 상태(로딩, 오류, 비활성, 결과 없음).
• 하나의 구체적 사용자 목표(예: "요금제 변경 후 확인").

Flutter 위젯용 복사 가능한 프롬프트(Semantics, 포커스, 제스처)

일관된 결과를 원한다면 위젯 스니펫(또는 전체 화면)을 붙여 넣고 특정 체크를 요청하세요. 이 React 및 Flutter UI 리뷰용 접근성 프롬프트는 위젯 트리, 화면에 도달하는 방법, 커스텀 제스처를 포함할 때 가장 잘 작동합니다.

리뷰에 붙여 넣을 수 있는 프롬프트

Review this Flutter widget tree for keyboard navigation and focus traversal.
Call out focus traps, missing focus order, and places where Tab/Shift+Tab will feel confusing.
Suggest exact widget changes (Focus, FocusTraversalGroup, Shortcuts, Actions).

Check this screen for missing Semantics labels, hints, and tap targets.
Point to the exact widgets that need Semantics(label/hint), tooltip, or exclusion.
Also flag controls under 48x48 logical pixels and suggest fixes.

Find custom gestures that break accessibility (GestureDetector/Listener).
Replace them with accessible widgets or add keyboard + semantics support.
If a gesture is required, describe how a keyboard user triggers the same action.

Audit error messages and validation on this form.
What should be announced to a screen reader, and when?
Suggest how to expose errors via Semantics and focus movement after submit.

Propose a consistent focus highlight style across screens.
It should be obvious on dark/light themes and work with keyboard navigation.
Show a small code example using FocusTheme/ThemeData.

어시스턴트가 제안해야 할 빠른 수정

답변은 몇 가지 구체적인 패턴을 언급해야 합니다:

• 메인 콘텐츠를 FocusTraversalGroup으로 감싸고 필요할 때만 FocusTraversalOrder를 설정하세요.
• 복합 컨트롤에는 Semantics(또는 MergeSemantics)를 사용하고 중복 레이블을 피하세요.
• 가능하면 원시 GestureDetector 대신 InkWell, IconButton, ListTile, SwitchListTile을 사용하세요.
• 비텍스트 입력에는 Shortcuts + Actions를 추가하세요(예: Enter로 활성화, Escape로 닫기).

커스텀 카드를 버튼처럼 동작하게 하는 최소 예시:

Semantics(
  button: true,
  label: 'Add payment method',
  hint: 'Opens the add card screen',
  child: Focus(
    child: InkWell(
      onTap: onPressed,
      child: Card(child: child),
    ),
  ),
)

단계별: 간단한 키보드 및 포커스 리뷰 흐름

빠른 키보드 및 포커스 리뷰는 스크린 리더와 스위치 장치에도 영향을 주는 문제를 찾아냅니다. 실제 페이지 흐름에서(단일 버튼이 아니라) 수행하고, 동일한 경로를 나중에 다시 확인할 수 있도록 메모를 남기세요.

5단계 흐름

사용자가 취할 "행복한 경로" 하나를 선택하세요(예: 로그인, 설정 열기, 저장).

1. 전체 흐름을 키보드만으로 수행하세요. 마우스를 치워두고 Tab과 Shift+Tab, Enter와 Space를 사용하며 메뉴나 라디오 그룹, 탭 같은 곳에는 방향키를 사용합니다. 클릭이나 스와이프가 필요하면 표시하세요.
2. 포커스가 항상 명확한지 확인하세요. 포커스가 이동할 때마다 어디에 포커스가 있는지 즉시 보여야 합니다. 얇은 아웃라인이 어두운 배경에서 사라지거나 CSS로 포커스 링이 제거된 경우, Flutter 위젯이 "활성"처럼 보이지만 포커스를 표시하지 않는 경우를 주의하세요.
3. 순서가 보이는 것과 일치하는지 확인하세요. 포커스는 시각적 레이아웃과 읽기 순서를 따라야 합니다. 흔한 위험 신호: 푸터로 튀거나 사이드바에 갇히거나 포커스 불가로 필드를 건너뛰는 경우.
4. 오버레이를 스트레스 테스트하세요. 메뉴, 대화상자, 드로어를 열어보세요. 포커스는 오버레이로 이동하고, 열린 동안 내부에 머물며, 닫을 때 합리적인 위치로 돌아와야 합니다. 적절하면 Escape로 오버레이가 닫혀야 합니다.
5. 각 변경 후 재검토하세요. 한 가지 문제를 고친 뒤 동일 경로를 다시 실행하세요. 어떤 것이 개선되었고 무엇이 악화되었는지(특히 포커스 순서 변화와 새로운 "막다른 길")를 기록하세요.

진행 중 기록할 항목

간단하게 유지하세요: 페이지 이름, 누른 키, 발생한 일, 기대한 바. 이 작은 로그는 React 리팩터나 Flutter 위젯 교체가 조용히 키보드 접근을 깨뜨리지 않았는지 확인하기 쉽게 만듭니다.

스크린 리더 친화적 이름, 레이블, 안내

스크린 리더는 UI를 "보지" 않습니다. 이름, 역할, 짧은 메시지에 의존해 무엇이 바뀌었는지 설명합니다. 이름이 없거나 모호하면 앱은 추측으로 변합니다.

폼 필드부터 시작하세요. 모든 입력은 필드가 채워져도 유지되는 실제 레이블이 필요합니다. 플레이스홀더는 힌트이며 레이블이 아닙니다. 입력하면 사라지기 쉽습니다.

아이콘만 있는 동작도 흔한 실수입니다. 휴지통 아이콘, 연필, 점 3개 메뉴는 결과를 설명하는 의미 있는 이름이 필요합니다. "프로젝트 삭제"는 "버튼"이나 "휴지통"보다 낫습니다.

머리말과 섹션 레이블도 중요합니다. 이는 페이지 개요가 되기 때문입니다. 화면 구조를 반영하는 머리말을 사용하세요. 스크린 리더 사용자는 "청구(Billing)" 또는 "팀 구성원(Team members)"을 머리말로 건너뛰며 찾기 때문에 섹션 레이블은 내용과 일치해야 합니다.

오류 메시지는 구체적이고 실행 가능해야 합니다. "잘못된 입력"은 부족합니다. 무엇이 잘못되었고 다음에 무엇을 해야 하는지 말하세요. 예: "비밀번호는 최소 12자여야 합니다" 또는 "이메일 주소에 @가 없습니다".

복사 가능한 리뷰 프롬프트(React 및 Flutter)

화면을 검토할 때(또는 Koder.ai 같은 도구에 컴포넌트 수정을 요청할 때) 이 프롬프트들을 사용하세요:

• "이 화면을 통해 모든 텍스트 입력에 가시적 레이블이 있고 접근 가능한 이름이 일치하는지 확인해줘(React: label + htmlFor, aria-labelledby; Flutter: InputDecoration.labelText)."
• "아이콘 전용 버튼을 찾아 각 버튼에 동작을 설명하는 접근 가능한 이름을 달아줘(React: aria-label; Flutter: Tooltip 또는 Semantics(label: ...))."
• "머리말을 확인해줘: React에서는 적절한 머리말 레벨을 사용하고, Flutter에서는 섹션 제목을 분명히 해서 구조가 올바르게 읽히도록 해줘."
• "검증 오류를 다시 작성해서 무엇이 잘못되었고 어떻게 고치는지 말하게 하고, 오류가 나타날 때 발표되도록 해줘."

동적 업데이트 안내

많은 화면이 페이지 리로드 없이 변경됩니다: 프로필 저장, 항목 추가, 결과 로딩 등. 이러한 업데이트가 안내되도록 하세요.

React에서는 aria-live 영역을 선호하세요(저위협적(polite)은 "저장됨", 강한(assertive)은 치명적 오류용). Flutter에서는 Semantics를 사용하고 배너나 SnackBar처럼 상태 메시지를 가시적으로 만들어 읽히게 하세요. 빠른 확인: "저장"을 트리거하고 버튼에서 포커스가 벗어나지 않고 짧은 메시지(예: "변경사항이 저장되었습니다")가 들리는지 확인하세요.

시간을 많이 쓰지 않는 대비 및 시각적 명확성 체크

작은 텍스트, 아이콘, 포커스 링, 상태 색상에 집중하면 대부분의 대비 문제를 몇 분 안에 잡을 수 있습니다. 이는 React 및 Flutter UI 리뷰용 접근성 프롬프트의 실용적 부분입니다. 확인은 쉽고 수정도 쉽습니다.

10분 대비 점검

한 화면을 100% 줌과 200% 줌으로 스캔하세요. 읽기 어려워지는 부분이 있으면 보통 대비, 굵기 또는 간격 문제입니다.

다음 다섯 곳을 먼저 확인하세요:

• 본문 텍스트, 캡션, 도움말 텍스트(특히 연한 회색에 흰 배경)
• 비활성 상태(비활성처럼 보여야 하지만 읽을 수 있어야 함)
• 레이블 없는 아이콘(희미한 아이콘은 많은 사용자에게 사실상 보이지 않음)
• 포커스 표시기(링/아웃라인은 배경과 구별되어야 함)
• 오류 및 성공 메시지(색만 사용하지 말고 텍스트 및 아이콘도 사용)

간단한 규칙: 눈을 찡그려야 한다면 사용자도 그럴 것입니다. 색 쌍이 확실하지 않으면 임시로 텍스트를 완전 검정이나 완전 흰색으로 바꿔보세요. 가독성이 좋아지면 원래 대비가 너무 낮았던 것입니다.

포커스 가시성은 자주 놓칩니다. 포커스 아웃라인은 충분히 굵고 배경과 같은 색이 아니어야 합니다. 리스트에 "선택됨" 상태가 있다면 그 차이는 흑백으로 봐도 구별될 수 있어야 합니다(예: 아이콘 추가, 밑줄, 분명한 테두리).

모바일 명확성: 터치 대상과 테마

모바일에서는 시각적 명확성이 터치에도 관련됩니다. 버튼과 아이콘 전용 동작은 충분한 탭 영역과 간격이 있어야 사용자가 잘못 누르지 않습니다.

빠른 테마 점검: 다크 모드를 전환하고 앱이 지원하면 고대비 설정도 확인하세요. 표면, 구분선, 포커스 링에서 텍스트를 재검토하세요. 흔한 버그는 다크 모드에서 포커스 링이 사라지거나 "비활성" 아이콘이 배경과 거의 같은 색이 되는 경우입니다.

Koder.ai처럼 UI를 빠르게 생성하는 경우 한 단계를 더 추가하세요: 첫 레이아웃 후 "대비 및 포커스 링 점검" 요청을 하세요.

계속 반복되는 실수들

대부분의 접근성 버그는 사소한 UI 조정처럼 느껴지기 때문에 반복됩니다. React 및 Flutter UI 리뷰용 접근성 프롬프트를 실행할 때 먼저 다음 패턴을 확인하세요.

플레이스홀더 텍스트는 레이블이 아닙니다. 플레이스홀더는 사용자가 입력하면 사라지고 많은 스크린 리더는 이를 필드 이름으로 취급하지 않습니다. 입력이 비어 있을 때, 채워졌을 때, 오류가 있을 때 모두 이해할 수 있도록 실제 가시적 레이블(또는 명시적 접근 가능한 이름)을 사용하세요.

포커스 스타일이 "보기 싫다"는 이유로 제거되는 경우가 있습니다. 이는 키보드 사용자를 길 잃게 만듭니다. 기본 아웃라인을 변경한다면 동등하게 명확한 대체(강한 링, 배경 변화, 충분한 대비)를 제공하세요.

또 다른 반복 범죄자는 가짜 버튼입니다. React에서는 onClick이 달린 div를 쓰고, Flutter에서는 GestureDetector만 감싼 Container를 쓰기 쉽습니다. 적절한 시맨틱이 없으면 키보드 지원과 스크린 리더가 손상됩니다. 네이티브 컨트롤(button, a, TextButton, ElevatedButton)은 포커스, 역할, 비활성 상태, 활성화 동작을 기본 제공합니다.

대화상자와 폼 포커스 버그는 미묘하지만 고통스럽습니다. 모달을 닫거나 폼을 저장한 뒤 포커스가 페이지 상단으로 가거나 사라지는 경우가 많습니다. 이는 포커스를 대화상자를 연 트리거로 복원하지 않거나 저장 액션이 화면을 재렌더링해 포커스를 떨어뜨릴 때 발생합니다. 사용자는 어디에 있었는지 다시 찾아야 합니다.

ARIA(또는 Flutter Semantics)를 과도하게 사용하면 오히려 문제가 될 수 있습니다. 모든 곳에 역할과 레이블을 추가하면 네이티브 요소가 이미 제공하는 것과 충돌해 중복 발표나 잘못된 이름을 초래할 수 있습니다.

리뷰 시 요청할 수 있는 빠른 "반복 문제" 체크:

• 모든 입력에 플레이스홀더가 아닌 영구 레이블이 있는지 확인
• 모든 상호작용 요소가 올바른 역할을 가진 실제 컨트롤인지 확인
• 포커스가 항상 보이고 대체 없이 제거되지 않는지 확인
• 대화상자, 토스트, 저장 후 트리거로 포커스가 복원되는지 확인
• ARIA/Semantics는 네이티브 컨트롤이 제공하지 않는 것만 추가하는지 확인

채팅에서 UI를 생성한다면(예: Koder.ai), 이러한 항목을 수락 기준으로 포함해 초기 초안이 흔한 함정을 피하게 하세요.

예시 워크스루: 한 화면, 끝까지

간단한 설정 화면을 상상해보세요: 프로필 폼(이름, 이메일), 토글 두 개(이메일 알림, 다크 모드), "변경사항 저장" 버튼, 저장 후 나타나는 토스트.

먼저 키보드부터 확인하세요. 예상 포커스 순서는 시각적 순서와 일치해야 합니다(위에서 아래, 왼쪽에서 오른쪽). 탭 시 토스트 영역, 푸터, 숨겨진 메뉴로 절대 튀면 안 됩니다.

대부분의 접근성 프롬프트에 유효한 빠른 패스:

• 탭을 위에서 눌러: 포커스가 Name -> Email -> Email notifications 토글 -> Dark mode 토글 -> Save changes 순으로 간다.
• Shift+Tab으로 뒤로 가면 깔끔하게 반대로 돌아가는지 확인.
• 토글에서는 Space로 전환되어야 한다. 방향키가 포커스를 가두지 않아야 한다.
• Save changes에서 Enter로 제출하고 제출 후 포커스가 사라지지 않아야 한다.
• 토스트가 나타날 때 포커스는 원래 있던 곳에 남아 있어야 한다(Undo 같은 동작이 없으면).

이제 스크린 리더가 무엇을 발표하는지 확인하세요. 각 컨트롤은 명확한 이름, 역할, 상태가 있어야 합니다. 예: "Name, text field, required" 와 "Email notifications, switch, on". Email 필드에 오류가 있으면 포커스가 필드로 들어갈 때와 오류가 발생할 때 발표되어야 합니다(예: "Email, text field, invalid, Enter a valid email address"). Save 버튼은 "Save changes, button"으로 읽히고 비활성화 상태라면 이유도 함께 전달되어야 합니다.

대비에 대해서는 일반 텍스트, 플레이스홀더 텍스트, 오류 메시지를 확인하세요. 포커스 링도 밝은/어두운 배경 모두에서 쉽게 보여야 합니다. 오류 상태는 빨간색만으로 의존하지 마세요. 아이콘이나 명확한 텍스트를 추가하세요.

발견한 내용을 짧은 수정 리스트로 바꾸세요:

• 레이아웃에 맞게 포커스 순서 수정
• 토글과 아이콘의 누락된 접근 가능한 이름 추가
• 오류를 필드와 함께 발표하도록 수정(배너만 사용하지 않음)
• 포커스 스타일과 낮은 대비의 플레이스홀더/오류 텍스트 개선
• 토스트를 차단하지 않거나 액션이 있을 때만 포커스 가능하게 만들기

Koder.ai에서 구축 중이라면, 이 화면 설명과 발견 사항을 채팅에 붙여 넣고 React 또는 Flutter UI가 기대되는 키보드 및 스크린 리더 동작을 따르도록 업데이트해달라고 요청하세요.

다음 단계: 이 체크리스트를 재사용하고 워크플로에 녹여라

이 React 및 Flutter UI 리뷰용 접근성 프롬프트를 장기적으로 유용하게 만들려면, 일회성 정리 작업이 아니라 반복적 습관으로 만드세요. 목표는 새 화면이나 컴포넌트를 추가할 때마다 같은 소규모 체크를 실행하는 것입니다.

UI 변경의 단일 "완료 정의(Definition of Done)"를 유지하세요. 무언가 배포되기 전에 키보드, 포커스, 이름, 대비를 빠르게 점검하세요. 자주 하면 몇 분이면 됩니다.

거의 모든 UI에서 실행할 수 있는 빠른 체크리스트:

• 키보드: 모든 상호작용 요소에 마우스 없이 접근하고 사용할 수 있나?
• 포커스: 포커스가 보이고 논리적 순서로 이동하나?
• 레이블: 모든 필드와 버튼(아이콘 포함)에 명확한 이름이 있나?
• 안내: 상태 변경(오류, 로딩, 성공)이 발표되나?
• 대비: 텍스트가 읽기 쉽고 비활성 상태도 이해 가능한가?

최고의 프롬프트를 템플릿으로 저장하세요. 한 가지 방법은 각 변경 요청 끝에 붙여 넣는 "React 리뷰 프롬프트"와 "Flutter 리뷰 프롬프트" 한 개씩을 보관하는 것입니다. 그런 다음 새 컴포넌트와 특별한 동작(모달, 스테퍼, 무한 스크롤 리스트)을 설명하는 짧은 한 줄을 추가하세요.

릴리스 전에 같은 체크를 다시 실행하세요. 반복적으로 느껴지더라도 하세요. 접근성 문제는 종종 작은 편집에 의해 유입됩니다: 아이콘 전용 버튼, 커스텀 드롭다운, 토스트 메시지, 대화상자의 포커스 트랩 등.

Koder.ai를 사용한다면, 프롬프트를 채팅에 붙여 넣어 구체적 수정을 요청하고, 변경을 적용하기 전에 영향 검토를 위해 계획 모드를 사용하세요. 접근성 패스 전에 스냅샷을 찍고 수정으로 레이아웃이나 동작이 깨지면 롤백하세요. 이렇게 하면 포커스 순서와 시맨틱을 안전하게 반복할 수 있습니다.

접근성 패스 후에는 이를 릴리스 게이트처럼 취급하세요: 코드 저장소 워크플로를 위해 소스 코드를 내보내거나, 만족스러우면 앱을 배포하고 커스텀 도메인을 연결하세요.