스프레드시트 감사가 우리를 힘들게 해서 접근성 도구를 만들었습니다

I’m happy to translate the article for you, but I’ll need the text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line at the top exactly as you provided and preserve all formatting, markdown, and technical terms.

The Problem

WCAG 감사를 위해 아홉 번째 스프레드시트를 열었을 때, “Fail” 로 표시된 로그인 여정의 14단계와 검토자의 사본에서는 “Not Tested” 로 표시된 같은 단계가 보이는 특정한 절망감이 있습니다.

어느 쪽이 맞을까요? 아무도 모릅니다. 원래 기록을 남긴 테스터는 현재 휴가 중이고, 스크린샷은 슬랙 어딘가에, 아마도 배포 논쟁에 묻힌 스레드에 있을 겁니다.

그것이 바로 2년 전 미국의 의료 접근성 감사를 진행하던 우리 팀이 겪은 상황이었습니다. 클라이언트는 엄격했고, 규정도 엄격했으며, 모든 것이 엄격했습니다—하지만 우리의 도구는 구글 시트, 수동 날짜, 그리고 희망으로 간신히 유지되고 있었습니다.

우리는 아홉 개의 스프레드시트를 열어 두었습니다:

• 하나는 테스터를 추적했습니다.
• 하나는 심각도를 추적했습니다.
• 하나는 메모를 추적했습니다.
• 하나는 다른 스프레드시트의 백업인 듯했지만, 데이터가 달랐습니다.

스크린샷은 슬랙 채널에, 때로는 DM에, 때로는 다른 버전의 WCAG 기준을 참조하는 Jira 티켓에 첨부되어 있었습니다.

그때 우리는 상충되는 보고서를 발견했습니다. 같은 사용자 흐름, 같은 단계, 두 명의 다른 테스터, 두 개의 다른 결과. 한 명은 Fail 이라고 적고 대체 텍스트가 없다는 메모를 남겼고, 다른 한 명은 Not Tested 라고 적었습니다. 두 보고서 모두 같은 주에 클라이언트에게 제출되었습니다.

그 순간 우리는 프로세스를 계속 임시방편으로 고치는 대신, 무언가를 구축하기 시작했습니다.

The Tool Is Called Auditi

It lives at . We built it at because nothing else matched how we actually test accessibility: by user journeys, broken into steps, with everything traceable back to a specific tester, date, platform, and WCAG criterion.

Core Idea

1. Model journeys the way a user experiences them – login flow, checkout flow, onboarding, etc.
2. Each journey has steps.
3. Each step gets an audit result: Pass, Fail, or Not Applicable.
4. Every result stores: tester name, severity, notes, evidence files, and a timestamp.

That sounds obvious. It isn’t. In spreadsheet world you’re tracking all of that across columns, tabs, and files. Someone renames a column. Someone adds rows in the middle. Someone filters by severity and forgets to un‑filter before sending the report. I’ve watched an experienced QA engineer spend forty minutes rebuilding a pivot table that broke because Excel decided to reinterpret dates.

Auditi gives you filters by journey, tester, status, severity, platform, WCAG level, device, and date. If you’ve ever tried to find “that one iOS Safari fail from last Tuesday” in a spreadsheet, you understand why this matters.

실제로 만든 것

• 과제 대화창과 검토 대기열을 도입해 작업이 Slack 메시지 체인 없이도 배분됩니다.
• 접근성 감사의 기본 단위인 단계별 Pass/Fail/N‑A 토글.
• 마감일 및 초대 알림, 스프레드시트를 매일 확인하도록 사람에게 의존하는 방식은 효과가 없기 때문입니다.

분석

• 시간에 따른 통과율.
• WCAG 준수 매트릭스.
• 테스터, 플랫폼, 심각도별 세부 분류.

이 부분이 바로 관리자가 실제로 관심을 갖는 영역이며, 전담 인력이 차트를 업데이트하지 않으면 스프레드시트로 유지하기 거의 불가능한 부분입니다.

보고서

• Excel, PDF, CSV(대부분의 고객이 기대하는 포맷)로 내보내기.
• 개요, 상세, 매트릭스 보고서 생성.
• AI 기반 스마트 보고서는 실행 요약, WCAG 레벨별 점수, 우선순위별 주요 이슈 표시, 해결 방안 제안을 제공합니다.
  • 솔직한 말: AI 요약은 구조화된 데이터를 압축해 주기 때문에 유용하며, 판단을 내리는 것이 아니라 테스트 담당자가 통과/실패를 결정합니다. AI는 단지 여러분이 한 시간 정도 걸려 작성할 요약을 대신 써줄 뿐입니다.

React 앱을 WCAG‑준수하도록 만들려고 시도했다면

문제의 나머지 절반: 해결하기

우리는 BetterQA 생태계에서 열다섯 개의 제품을 운영합니다: Vite/React SPA, Next.js 앱, Laravel 앱, WordPress 사이트 등. 올해 초, 자체 스캐너 도구를 사용해 모든 제품을 접근성 검토하기로 했습니다. 이 도구는 Playwright를 통해 axe‑core를 실행합니다.

결과는 겸손하게 만들었습니다

• 13개 사이트 중 8개가 접근성 점수가 60 이하였습니다.
• 가장 큰 문제점은? 색 대비—특히 흰 배경 위에 적용된 Tailwind의 purple‑400.

모든 Vite/React SPA에서 링크, 배지, 라벨, 보조 텍스트 등에 text-purple-400을 사용했습니다. 색상은 보기 좋지만 흰색 배경 대비 대비 비율이 약 3.3:1에 불과합니다. WCAG AA는 일반 텍스트에 4.5:1을 요구합니다. 우리는 페이지당 수십 개의 대비 검사를 실패했으며, 8개 사이트 모두에서 이런 문제가 있었지만 페이지가 보기 좋았기 때문에 아무도 눈치채지 못했습니다.

해결책: purple-600 (#9333ea)으로 교체하면 4.6:1의 대비를 제공해—임계값을 겨우 넘지만 통과합니다.

/* Before: 3.3:1 contrast – fails WCAG AA */
.text-purple-400 { color: #a855f7; }

/* After: 4.6:1 contrast – passes WCAG AA */
.text-purple-600 { color: #9333ea; }

우리는 8개 사이트 모두에서 이 변경을 적용했습니다. 일부 사이트는 개별 클래스 24개를 업데이트해야 했습니다. BetterFlow(Laravel/Blade 앱)에서도 Blade 템플릿에 동일한 패턴이 있었습니다.

이 덕분에 접근성 점수가 50대에서 70대‑80대로 상승했지만, 이는 아직도 저수준 문제만 해결한 셈이었습니다.

더 깊은 수정이 우리에게 가르쳐 준 것

색상 대비 검사를 마친 뒤 우리는 더 깊이 파고들었습니다.

• 아이콘 전용 버튼(예: jrny.ro에서)에는 접근 가능한 이름이 없었습니다. 화면 읽기 프로그램은 단순히 “버튼”이라고만 읽어냈습니다.

  • 수정: aria-label 속성을 추가합니다.

• 레이블이 없는 폼 입력(예: menute.ro에서). 시각 사용자는 플레이스홀더 텍스트에 의존하지만, 화면 읽기 프로그램은 유용한 정보를 전혀 듣지 못합니다.

  • 수정: 각 입력에 aria-label을 추가하거나 <label> 요소와 연결합니다.

이러한 더 깊은 문제들은 접근성이 체크리스트 그 이상이며, 의도적이고, 추적 가능하며, 협업적인 작업이라는 점을 다시 일깨워 주었습니다. 바로 Auditi가 지원하는 부분이죠.

most was nis2manager.ro

이 사이트는 기본 색상에 CSS 커스텀 프로퍼티를 사용합니다. 원래 --primary 값은 0.65의 oklch 밝기로 설정되어 있었는데, 이를 0.48로 변경함으로써 한 줄의 CSS만으로 70개가 넘는 대비 위반을 해결했습니다. 한 변수만 바꾸면 70개의 문제가 사라집니다.

/* One variable, seventy fixes */
--primary: oklch(0.48 0.2 270);  /* was 0.65 */

전체 화면 모드 진입
전체 화면 모드 종료

우리가 계속 되새기는 교훈은 이렇습니다: 디자인 시스템이 CSS 커스텀 프로퍼티나 Tailwind 테마 색상을 사용한다면, 먼저 기본 토큰들의 대비를 확인하세요. 개별 요소를 몇 시간씩 찾아볼 수도 있지만, 근원을 수정하면 수십 개의 위반이 한 번에 사라지는 것을 볼 수 있습니다.

Source:

실제 자동화 도구가 잡아내는 것

이 부분은 직접적으로 말하고 싶습니다. 자동 접근성 테스트가 문제를 해결한다는 주장을 너무 많이 보았기 때문입니다. 그렇지 않습니다—거의 해결되지 않습니다.

• axe‑core 같은 자동화 도구는 WCAG 문제의 30‑40 % 정도만 잡아냅니다.
  • 잘하는 부분: 색 대비, 누락된 alt 텍스트, 누락된 폼 레이블, 중복 ID, 깨진 ARIA 속성.
  • 못하는 부분: 컨텍스트가 필요한 모든 것—alt 텍스트가 의미가 있는지, 포커스 순서가 적절한지, 커스텀 위젯이 키보드로 작동하는지, 화면 읽기 프로그램으로 선형적으로 읽을 때 내용이 이해되는지 등.

WCAG에는 레벨 A, AA, AAA를 포함해 대략 80개의 성공 기준이 있습니다. 자동화 도구가 신뢰성 있게 검사할 수 있는 것은 25‑30개 정도에 불과합니다. 나머지는 사용자 흐름, 콘텐츠 의도, 마우스 없이 경험이 어떠한지를 이해하는 사람이 필요합니다.

그래서 Auditi는 자동 스캔 결과가 아니라 인간 중심 감사를 기반으로 여정과 단계로 구성되어 있습니다. 자동화는 회귀를 잡아내는 데는 유용하지만, 실제로 화면 읽기 프로그램을 사용해 사이트를 탐색하는 테스터를 대체할 수는 없습니다.

우리가 틀린 점

솔직히 말하자면 몇 가지가 있습니다:

1. 복잡성 – Auditi 초판은 모든 WCAG 기준을 별개의 감사 포인트로 모델링하여 테스트 담당자가 단계마다 수십 개의 기준을 클릭해야 했으며, 그 중 대부분은 적용되지 않았습니다. 우리는 중요한 항목만 표시하고 나머지는 건너뛸 수 있도록 간소화했습니다.
2. 내보내기 형식 – 초기 내보내기 파일은 깔끔했지만 컴플라이언스 담당자들이 기대하는 형태와 맞지 않았습니다. 우리는 의료 및 정부 고객이 이미 사용하고 있는 문서 형식에 매핑되는 특정 보고서 레이아웃을 추가했습니다.
3. 자체 감사 실패 – 자체 생태계 점검 결과, 접근성 도구를 만들면서도 접근성이 결여된 제품을 배포하고 있었습니다. 꽤 충격적이었죠. 이를 수정했지만, 도구를 만드는 것과 실제로 일관되게 사용하는 것은 별개의 일이라는 점을 다시 한 번 상기시켜 주었습니다.

The Honest Numbers

Our ecosystem scores before and after the sweep:

완벽한 점수는 아니며—아직 멀었습니다. 하지만 8개 사이트에서 25‑30점 상승을 이루었고, 반복 가능한 프로세스입니다.

이것이 여러분의 스택에 중요한 이유

React 또는 Vite SPA를 사용하고 있고 아직 axe‑core를 실행하지 않았다면, 먼저 실행하세요. 대비 문제, 누락된 레이블, 버튼 이름 위반 등을 발견하게 될 것이며, 이는 오후 안에 해결할 수 있습니다.

그 다음부터가 더 어려운 작업입니다:

• 키보드 네비게이션
• 모달 및 동적 콘텐츠에서의 포커스 관리
• 상태 변화에 대한 스크린리더 알림

이때 스프레드시트는 한계에 부딪히고 실제 감사 추적이 필요합니다.

우리는 Auditi를 만들었습니다. 기존 도구들로는 이 작업을 제대로 수행할 수 없었기 때문입니다. 확인하고 싶다면 **auditi.ro**에서 이용할 수 있습니다.

다양한 도메인에서 QA에 접근하는 방법에 대해 더 알고 싶다면 **BetterQA 블로그**를 확인해 보세요.