ShortArrow/interface-design

인터페이스 디자인

화면에 관한 질문은 취향에 대한 질문이 아닙니다. 명암비에는 비율이 있고, 타겟에는 크기가 있으며, 리플로우에는 여전히 작동해야 하는 너비가 있고, 레이아웃에는 사용자가 가장 먼저 하는 작업에 따른 정보 순서가 있습니다. 이러한 것들은 측정과 공개된 표준에 의해 결정되므로, 이를 사용자에게 "어느 쪽을 선호하나요?"라고 넘기는 것은 에이전트가 해야 할 일에 사용자의 주의를 소모시키는 것입니다.

측정 후 남는 것은 진정한 질문이며, 이 스킬은 그 나머지를 작게 만들고 증거를 첨부하는 데 있습니다. own-the-call이 그 질문이 어떻게 제기될지를 규정합니다.

이 스킬이 대체하는 순간들

하려는 행동	대신 할 일
사용자에게 선호하는 색상, 크기, 간격 또는 배치를 묻는다	아래 표준에 따라 측정하고, 어떤 임곗값도 해결하지 못하는 경우에만 질문한다
시각적 선택을 주관적이라고 말한다	그것이 통과하거나 실패하는 기준(명암비, 타겟 크기, 리플로우 너비, 포커스 가시성, 정보 순서)을 지목한다
"괜찮아 보인다"고 말한다	그것을 열고 스크린샷을 찍어, 어떤 뷰포트에서 무엇을 측정했는지 말한다
눈대중으로 컨트롤 크기를 정한다	24×24 CSS px는 WCAG AA 최소 기준이며, 디자인 시스템은 더 엄격한 기준(머티리얼: 48dp)을 설정할 수 있다
팔레트에서 색상을 모양만 보고 고른다	비율을 계산한다: 본문 텍스트 4.5:1, 큰 텍스트 및 비텍스트 3:1
하나의 창 크기에서만 확인된 레이아웃을 배포한다	너비 320 CSS px, 높이 256 CSS px에서 리플로우가 여전히 작동하는지 확인한다
녹색 axe 실행 결과를 접근성 통과로 읽는다	axe는 약 57%를 찾아내며, 나머지는 키보드, 포커스 순서, 의미에 달려 있다
디자인 시스템에 이미 정의된 구성 요소를 디자인한다	그들의 것을 사용하고, 어느 것인지 말한다
다이어그램을 그리는 방법을 묻는다	사용자가 먼저 추적하는 것이 무엇인지 결정한 후, 하나의 렌더링을 보여준다

묻기 전에 표준부터 결정하라

네 가지 기관이 대부분을 답변하며, 이들이 완전히 동의하지는 않습니다 — 차이가 있을 때는, 더 엄격한 숫자를 충족 기준으로 삼아야 합니다. 왜냐하면 그것을 충족하면 둘 다 만족시키기 때문입니다.

WCAG 2.2는 최소 기준이며, 규범적입니다: W3C 권고안이자 ISO/IEC 40500입니다. 목표 레벨은 AA입니다. AAA는 모든 콘텐츠에 도달 가능하지 않으며 W3C도 그렇게 명시합니다.

기준	레벨	임곗값
1.4.3 명암비 (최소)	AA	텍스트 4.5:1; 큰 텍스트(≥18pt 또는 14pt 볼드)는 3:1
1.4.11 비텍스트 명암비	AA	인접 색상 대비 3:1
1.4.4 텍스트 크기 조정	AA	200%에서 사용 가능
1.4.10 리플로우	AA	너비 320px 또는 높이 256px에서 양축 스크롤 없음
1.4.12 텍스트 간격	AA	줄 높이 ≥1.5배, 단락 ≥2배, 글자 간격 ≥0.12배, 단어 간격 ≥0.16배 글꼴 크기
2.4.7 포커스 표시	AA	포커스 표시기가 보이는 모드
2.4.11 포커스 가려짐 방지	AA	포커스된 컨트롤이 완전히 숨겨지지 않음
2.5.8 타겟 크기 (최소)	AA	24×24 CSS px 또는 24px 간격
2.4.13 포커스 모양	AAA	≥2px 둘레, 포커스된 상태와 포커스되지 않은 상태 간 3:1
2.5.5 타겟 크기 (향상)	AAA	44×44 CSS px

디자인 시스템은 WCAG가 열어둔 부분(간격 척도, 타입 척도, 구성 요소 구조, 색상 역할)을 결정합니다. 그 구성 요소를 사용하는 것은 지름길이 아니라 결정 그 자체입니다 — 그리고 이미 완료된 접근성 작업을 수반합니다. 머티리얼 디자인 3은 48×48 dp 터치 타겟을 설정하며, WCAG의 24px보다 엄격하고, 고정된 16진수 색상이 아닌 역할(primary, on-primary, surface)로 색상을 선택하도록 요구하므로, 테마 변경과 다크 모드가 두 번째 결정 없이 따라옵니다. 일본의 공공 서비스를 대상으로 하는 경우, 디지털청 디자인 시스템(design.digital.go.jp, 생활 표준으로서의 β版)은 구성 요소, 지침 및 토큰을 제공하며, 토큰과 샘플 구성 요소는 MIT 라이선스로 GitHub에 있습니다.

axe-core는 측정 가능한 것을 측정하며, 자체 한계를 명시합니다: 평균 약 57%의 WCAG 이슈. 따라서 녹색 실행은 질문의 57%에 대한 증거일 뿐이며, 이 숫자 없이 "axe 통과"라고 말하는 것은 과장입니다 — measured-claims는 이 수치에도 다른 것과 동일하게 적용됩니다.

npx @axe-core/cli http://localhost:5173 --tags wcag2a,wcag2aa,wcag22aa
npx lighthouse http://localhost:5173 --only-categories=accessibility --quiet

Lighthouse의 접근성 점수는 동일한 엔진이 숫자를 입은 것입니다. 그 감사는 axe-core 규칙입니다 — 각각은 Deque의 규칙 페이지로 연결됩니다 — 따라서 57%를 상속받으며, 점수는 오독될 수 있는 두 가지 방식을 추가합니다. 이는 가중 평균이며, 가중치는 axe의 사용자 영향 평가에 따라 3에서 10 사이이고, 수동 및 모범 사례 감사는 점수에서 완전히 제외되므로, 산술적으로 사람이 확인해야 할 부분에 도달할 수 없습니다. 각 감사는 또한 이진적입니다: 레이블이 없는 버튼 하나는 "Buttons have an accessible name"을 바로 실패시키며, 부분 점수는 없습니다. 따라서 100은 "가중 자동화 하위 집합이 통과했음"을 의미하며, 완벽한 점수에 대한 정직한 보고는 그렇게 말해야 하지, "접근성 통과"라고 말해서는 안 됩니다. 수정할 항목의 순위 목록에는 Lighthouse를 사용하고, 발견 사항이 순위보다 더 중요할 때는 axe의 JSON을 사용하십시오. Lighthouse의 성능 카테고리는 web-perf의 영역이며, 이 스킬의 영역이 아닙니다.

둘 다 볼 수 없는 것: 포커스 순서가 읽기 순서를 따르는지, 레이블이 레이블이 지정하는 것을 올바르게 명명하는지, 아이콘의 의미가 색상 없이도 유지되는지, 레이아웃의 정보 순서가 작업과 일치하는지. 이러한 것은 사람이 읽으며, 그 사람은 에이전트일 수 있습니다.

보고 나서, 무엇을 보았는지 말하라

관찰이 없는 인터페이스 주장은 다른 매체에서의 measured-claims의 소문일 뿐입니다. 호스트에는 브라우저가 있으므로 관찰이 가능합니다:

mcp__claude-in-chrome__navigate      → 페이지
mcp__claude-in-chrome__read_page     → 구조, 제목, 레이블
mcp__claude-in-chrome__computer      → 명시된 뷰포트에서의 스크린샷
mcp__claude-in-chrome__resize_window → 320px, 리플로우 테스트용

뷰포트를 발견 사항과 함께 보고하십시오. "올바르게 보인다"는 너비와 측정값을 언급하지 않습니다. "320px에서 두 번째 열이 첫 번째 열 아래로 감싸지고 아무것도 가로로 스크롤되지 않는다"는 누군가가 확인할 수 있는 판독값입니다. 키보드 순서는 Tab으로 탐색하고 관찰된 순서대로 보고됩니다. 왜냐하면 그것이 axe가 다루지 않는 절반이기 때문입니다.

정보 순서는 파생되는 것이지 선택되는 것이 아니다

무언가가 어디에 가는지는 사용자가 그것으로 무엇을 하는지에 따르며, 이는 reader-map의 질문이 화면에 적용된 것입니다: 누가 도착했는지, 무엇을 하러 왔는지, 그들이 가장 먼저 필요한 것이 무엇인지. 설정 시 한 번 사용되는 컨트롤과 매분 사용되는 컨트롤은 같은 자리를 놓고 경쟁하지 않습니다.

따라서 "이게 어디로 가야 하나"는 세 가지 위치를 나열하는 것이 아니라 작업을 명명함으로써 답변됩니다. 두 작업이 진정으로 경쟁하고 어느 쪽도 지배적이지 않을 때, 그것이 질문할 가치가 있는 나머지입니다 — 그리고 경쟁하는 작업의 이름과 함께 질문되며, 모서리 선택으로 제시되지 않습니다.

다이어그램에도 동일하게 적용됩니다. 독자가 먼저 추적하는 것이 흐름의 방향을 결정합니다. 모양은 추적을 따르며, 세 가지를 설명하는 대신 하나의 렌더링이 표시됩니다.

진정으로 사용자의 몫인 것

측정에서 살아남는 세 가지가 있습니다:

• 인터페이스가 제공하는 대상 또는 시장 (아직 고정되지 않은 경우) — 이는 어떤 표준이 전혀 적용되는지를 결정합니다 (regulated-claims 참조, 규제 시장의 경우).
• 브랜드 제약 조건 — 필수 색상, 서체 또는 마크. 제약 조건은 고객의 것입니다. 4.5:1을 충족하는지 여부는 여전히 측정되며, 실패한 브랜드 색상은 비율과 가장 가까운 통과 변형과 함께 보고됩니다.
• 양쪽이 이미 측정된 절충안 (증거가 결정하지 못하는 경우): 밀도 대비 스캔 가능성, 한 화면 대비 두 화면. 두 측정값이 모두 첨부된 상태로 질문되며, 이는 own-the-call이 허용하는 질문입니다.

그 외의 모든 것 — 명암비, 간격, 타겟 크기, 포커스, 리플로우, 구성 요소 선택, 다이어그램 모양, 작업을 따르는 배치 — 은 결정되고 보고됩니다.

체크리스트

• 명암비 계산, 눈대중이 아님: 텍스트 4.5:1, 큰 텍스트 및 비텍스트 3:1
• 인터랙티브 타겟 ≥24×24 CSS px, 또는 디자인 시스템의 더 엄격한 수치
• 너비 320px, 높이 256px에서 양축 스크롤 없음 확인
• 모든 인터랙티브 요소에 포커스가 표시되고 가려지지 않음
• 탭 순서 탐색 및 관찰된 대로 보고
• 디자인 시스템이 정의한 구성 요소를 가져와서 명명함
• axe 또는 Lighthouse 실행 및 57% 한계 명시(암시하지 않음)
• Lighthouse 접근성 점수는 "가중 자동화 하위 집합"으로 보고, 절대 "접근성 통과"로 보고하지 않음
• 모든 모양 주장은 관찰된 뷰포트를 포함함
• 사용자에게 남겨진 질문은 위의 세 가지 유형이며, 증거가 첨부됨

연결 방법

own-the-call은 이 스킬에서 살아남은 질문의 형태를 결정합니다. 화면에 관한 대부분의 질문은 이 스킬에 도달해서는 안 됩니다. reader-map은 이 스킬이 배치에 적용하는 작업 순서를 제공합니다. measured-claims는 여기의 모든 비율과 백분율(57% 포함)을 규율합니다. document-structure와 cognitive-rhythm은 페이지의 산문을 담당합니다. 이 스킬은 그 주변의 프레임을 담당합니다. any-screenshot은 브라우저 외부에서 화면이 캡처되는 방법입니다. 로딩 및 상호 작용 속도, Core Web Vitals 및 Lighthouse의 성능 점수는 cloudflare 플러그인의 web-perf에 속합니다. 이 스킬은 Lighthouse의 접근성 카테고리만 가져옵니다.

출처

• W3C, "Web Content Accessibility Guidelines (WCAG) 2.2", W3C 권고안, 2024년 12월 12일 (www.w3.org/TR/WCAG22/): 4가지 원칙, A/AA/AAA 레벨, 및 4.1.1 구문 분석의 제거.
• W3C, "How to Meet WCAG 2.2 (Quick Reference)" (www.w3.org/WAI/WCAG22/quickref/): 위 표의 모든 임곗값, 레벨 AAA에서 2.4.13 및 2.5.5를 포함하여 읽음.
• Deque Labs, axe-core README (github.com/dequelabs/axe-core): MPL-2.0; A, AA 및 AAA 수준에서 WCAG 2.0, 2.1 및 2.2에 매핑된 규칙; "평균적으로 WCAG 문제의 57%를 자동으로 찾을 수 있습니다".
• Chrome for Developers, "Accessibility scoring in Lighthouse" (developer.chrome.com/docs/lighthouse/accessibility/scoring): 점수는 가중 평균이며, 가중치는 3에서 10, "axe 사용자 영향 평가 기반", 모든 감사는 Deque University axe-core 4.11 규칙 페이지에 연결됨. 각 감사는 이진적이며, 수동 및 영향이 적은 감사는 점수에서 제외됨. 페이지 자체는 완벽한 점수가 페이지가 접근 가능하다는 것을 의미한다고 말하지 않습니다 — 반대도 마찬가지이므로, 위의 경고는 이 스킬의 것입니다.
• 디지털청 디자인 시스템 (design.digital.go.jp): v2.18.2, 생활 표준의 의미에서 β版으로 표시됨. 사이트는 WCAG 레벨 또는 JIS X 8341-3 목표를 명시하지 않음. digital-go-jp/design-tokens, design-system-example-components-react 및 -html on GitHub는 MIT 라이선스.
• 머티리얼 디자인 3의 48×48 dp 터치 타겟 및 색상 역할 지침은 m3.material.io를 인용한 2차 출처에서 가져왔으며, 해당 사이트 자체에서 가져온 것이 아닙니다. 해당 사이트의 페이지는 스크립트로 렌더링되어 여기서 읽을 수 없었습니다. 48 dp 수치는 디자인 권장 사항이며, 플랫폼에서 강제하는 최소값이 아닙니다.

이 출처들이 동의하지 않으며, 더 엄격한 수치를 충족해야 한다는 주장은 이 카탈로그 소유자의 해석이며, 출처들의 공식 입장이 아닙니다.

이 스킬이 작성되는 동안 위의 명령어는 실행되지 않았습니다: 둘 다 처음 사용 시 패키지를 가져오며, 여기의 샌드박스는 새로 다운로드된 코드를 실행하지 않습니다. 플래그는 각 도구의 문서에서 가져온 것이지 실행에서 가져온 것이 아니므로, 프로젝트에서 처음 사용하는 것이 호출의 첫 번째 테스트이기도 합니다.