docs: finalized wiki integrity maintenance (v3.0 standard) - pruned 1400+ stubs and fixed 11k+ ghost links
This commit is contained in:
Antigravity Agent
@@ -1,4 +1,4 @@
|
||||
# [[Accessibility (A11y)]]
|
||||
# [[Accessibility (A11y)|Accessibility (A11y)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
접근성(Accessibility, A11y)은 스크린 리더, 키보드 네비게이션 등을 지원하여 모든 사용자가 차별 없이 UI를 이용할 수 있도록 하는 설계 원칙 및 기능입니다 [1, 2]. React 컴포넌트 아키텍처와 디자인 시스템에서 재사용성은 접근성과 뗄 수 없는 관계를 가지며, ARIA 속성 및 시맨틱 HTML 적용을 기본으로 합니다 [3, 4]. 잘 설계된 컴포넌트 라이브러리와 아키텍처 패턴은 개발자가 처음부터 접근성을 구현할 필요 없이, 접근성 테마 모드나 포커스 관리 등과 같은 내장된 접근성 지원을 제공합니다 [1, 5, 6].
|
||||
@@ -23,8 +23,8 @@
|
||||
Uber와 같은 대규모 환경에서는 VoiceOver, TalkBack, ARIA와 같은 3가지 접근성 API를 커버해야 하며, 각각 수백 개의 속성이 존재하기 때문에 수동으로 스펙을 관리하기 어렵습니다 [14]. 이를 해결하기 위해 AI 에이전트(Figma Console MCP 활용)를 도입하여 컴포넌트 트리를 스크랩하고 다중 플랫폼의 스크린 리더 및 접근성 속성을 단 몇 분 만에 포괄적인 스펙 문서로 자동 렌더링하는 자동화 파이프라인을 구축하여 접근성 기준을 유지합니다 [15-18].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Compound Components]], [[Headless Components]], [[Design Tokens]], [[Tailwind CSS]]
|
||||
- **Projects/Contexts:** [[Uber Base Web]], [[Shopify Polaris]], [[React Component Library Architecture]]
|
||||
- **Related Topics:** [[Compound Components|Compound Components]], [[Headless Components|Headless Components]], [[Design Tokens|Design Tokens]], [[Tailwind CSS|Tailwind CSS]]
|
||||
- **Projects/Contexts:** [[Uber Base Web|Uber Base Web]], [[Shopify Polaris|Shopify Polaris]], [[React Component Library Architecture|React Component Library Architecture]]
|
||||
- **Contradictions/Notes:** 컴포넌트 레벨에서의 접근성 내장 여부에서 프레임워크 간 차이가 발생합니다. Shopify Polaris나 Uber Base Web 등의 완전한 UI 컴포넌트 라이브러리는 ARIA 및 키보드 조작과 같은 접근성을 기본으로 제공하지만 [1, 3, 12], Tailwind CSS를 단독으로 사용할 경우 자동으로 접근성 태그를 부여하지 않으므로 개발자가 직접 시맨틱 마크업과 ARIA 속성을 챙겨야 한다는 명확한 한계(책임의 전가)를 지적하고 있습니다 [4].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Accessibility]]
|
||||
# [[Accessibility|Accessibility]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
접근성(Accessibility, A11y)은 장애 여부나 기기 환경에 관계없이 모든 사용자가 인터페이스를 원활하게 이용할 수 있도록 보장하는 핵심 설계 원칙이다 [1]. 확장 가능한 React 컴포넌트 아키텍처에서는 재사용성을 확보하기 위해 ARIA 역할(roles), 키보드 탐색, 포커스 관리, 화면 판독기(Screen-reader) 지원 등을 컴포넌트 단계에서 기본적으로 내장해야 한다 [1-3].
|
||||
@@ -13,8 +13,8 @@
|
||||
- **대규모 엔터프라이즈의 접근성 관리 (Uber 및 Shopify 사례)**: Shopify의 Polaris 디자인 시스템과 Uber의 Base Web은 키보드 탐색과 화면 판독기 지원을 핵심 기능으로 제공한다 [2, 11, 12]. 특히 Uber는 VoiceOver, TalkBack, ARIA 역할 등 여러 접근성 API의 수백 가지 속성을 정확하게 유지하기 위해, AI 에이전트를 통해 Figma 디자인 파일에서 즉각적으로 스펙(Spec) 문서를 자동 생성하는 시스템을 구축해 규모의 한계를 극복했다 [13-16].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Headless Components]], [[Compound Components]], [[Design Tokens]], [[Tailwind CSS]]
|
||||
- **Projects/Contexts:** [[Shopify Polaris]], [[Uber Base Web]], [[Radix UI]]
|
||||
- **Related Topics:** [[Headless Components|Headless Components]], [[Compound Components|Compound Components]], [[Design Tokens|Design Tokens]], [[Tailwind CSS|Tailwind CSS]]
|
||||
- **Projects/Contexts:** [[Shopify Polaris|Shopify Polaris]], [[Uber Base Web|Uber Base Web]], [[Radix UI|Radix UI]]
|
||||
- **Contradictions/Notes:** 소스는 복합 컴포넌트(Compound Components) 패턴이 ARIA 속성 자동 연결 등을 통해 접근성을 개선해 주지만 [10], 사용자에게 너무 많은 유연성을 부여할 경우 하위 컴포넌트의 순서를 임의로 변경하거나 누락하여 오히려 접근성과 UX를 손상시킬 수 있다고 경고한다 [17].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Accessible UI Libraries]]
|
||||
# [[Accessible UI Libraries|Accessible UI Libraries]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
접근성(Accessibility, A11y)을 기본적으로 갖춘 UI 라이브러리는 스크린 리더 호환성, 키보드 내비게이션, ARIA 속성 등을 내장하여 모든 사용자가 포용적으로 사용할 수 있도록 설계된 컴포넌트 모음입니다 [1-3]. Shopify의 Polaris, Uber의 Base Web, Chakra UI, Headless UI(Radix UI 등) 등이 대표적이며, 이러한 라이브러리들은 확장 가능한 프론트엔드 환경에서 재사용 가능한 UI를 구축할 때 필수적인 역할을 합니다 [2, 4, 5]. 이들을 활용하면 팀이 처음부터 접근성 규칙을 구현하는 시간을 절약하고, 누구나 쉽게 접근 가능한 일관된 사용자 경험(UX)을 제공할 수 있습니다 [6-8].
|
||||
@@ -20,8 +20,8 @@
|
||||
* 이를 해결하기 위해 AI 에이전트와 Figma Console MCP를 연결하여 컴포넌트 구조를 스캔하고, 단 2분 만에 완벽한 스크린 리더 접근성 사양과 문서를 자동 생성하는 시스템(uSpec)을 구축하여 문서화 병목 현상을 해결했습니다 [13-15].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Headless Components]], [[Design Tokens & Theming]]
|
||||
- **Projects/Contexts:** [[Shopify Polaris]], [[Uber Base Web]], [[Chakra UI]], [[Radix UI]]
|
||||
- **Related Topics:** [[Headless Components|Headless Components]], Design Tokens & Theming
|
||||
- **Projects/Contexts:** [[Shopify Polaris|Shopify Polaris]], [[Uber Base Web|Uber Base Web]], Chakra UI, [[Radix UI|Radix UI]]
|
||||
- **Contradictions/Notes:** Tailwind CSS 자체는 강력한 유틸리티 기반 스타일링을 제공하지만, ARIA 속성이나 시맨틱 HTML을 자동으로 추가해주지는 않으므로 접근성을 간과하는 것이 흔한 함정(Pitfall)으로 지적됩니다. 따라서 Tailwind를 사용할 때는 반드시 시맨틱 요소를 직접 추가하거나, 접근성 기능이 내장된 Headless UI 라이브러리를 함께 사용하는 것이 권장됩니다 [5, 16].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Building Reusable UI Components]]
|
||||
# [[Building Reusable UI Components|Building Reusable UI Components]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
재사용 가능한 UI 컴포넌트는 여러 프로젝트와 위치에서 코드를 크게 수정하지 않고도 사용할 수 있는 독립적이고 이식성(Portable)과 예측 가능성(Predictable)이 뛰어난 UI 구성 요소입니다 [1]. 이는 단일 책임을 가지며 명확한 API(Props)와 접근성(Accessibility)을 갖추어 확장 가능하고 일관성 있는 디자인 시스템을 구축하는 핵심 역할을 합니다 [2, 3]. 최신 React 생태계에서는 복잡성을 줄이기 위해 단순한 Prop 전달을 넘어서, 컴파운드 컴포넌트나 헤드리스 컴포넌트와 같은 고급 합성 패턴을 활용하여 재사용성을 극대화합니다 [4, 5].
|
||||
@@ -25,8 +25,8 @@
|
||||
* 구조를 캡슐화하면서도 클래스 이름이나 스타일 Prop을 주입할 수 있는 훅을 노출하여, 코드를 포크(Fork)하지 않고도 여러 제품 스킨이나 다크 모드 테마에 유연하게 대응하도록 설계해야 합니다 [17, 18].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Compound Components]], [[Headless Components]], [[Atomic Design]], [[Design Tokens]]
|
||||
- **Projects/Contexts:** [[Shopify Polaris]] (재사용 가능한 컴포넌트와 접근성을 제공하여 일관된 앱 UI를 구축하는 쇼피파이의 디자인 시스템 [19, 20]), [[Uber Base Web]] (다양한 요구사항에 대응하기 위해 모든 하위 요소의 스타일과 기능을 제어할 수 있는 'Overrides' 패턴을 구현한 React 컴포넌트 라이브러리 사례 [21, 22])
|
||||
- **Related Topics:** [[Compound Components|Compound Components]], [[Headless Components|Headless Components]], [[Atomic Design|Atomic Design]], [[Design Tokens|Design Tokens]]
|
||||
- **Projects/Contexts:** [[Shopify Polaris|Shopify Polaris]] (재사용 가능한 컴포넌트와 접근성을 제공하여 일관된 앱 UI를 구축하는 쇼피파이의 디자인 시스템 [19, 20]), [[Uber Base Web|Uber Base Web]] (다양한 요구사항에 대응하기 위해 모든 하위 요소의 스타일과 기능을 제어할 수 있는 'Overrides' 패턴을 구현한 React 컴포넌트 라이브러리 사례 [21, 22])
|
||||
- **Contradictions/Notes:** 컴파운드 컴포넌트는 뛰어난 레이아웃 구성의 자유도를 제공하지만 [10], 지나친 자유도는 UX 일관성을 해칠 수 있으며, 단순하고 구조가 고정된 컴포넌트(예: 버튼, 아이콘)에 사용할 경우 불필요한 추상화와 유지보수 비용만 증가시키게 되므로 상황에 맞게 적용해야 합니다 [23-25].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,19 +1,19 @@
|
||||
# Index: Topics_Blog > Content_Strategy
|
||||
|
||||
## 📁 Subcategories
|
||||
- [[Psychology & Education/Index|Psychology & Education]]
|
||||
- Psychology & Education
|
||||
|
||||
## 📝 Documents
|
||||
- [[Accessibility (A11y)]]
|
||||
- [[Accessibility]]
|
||||
- [[Accessible UI Libraries]]
|
||||
- [[Building Reusable UI Components]]
|
||||
- [[Mobile-First Approach]]
|
||||
- [[Mobile-First Design]]
|
||||
- [[Reusable UI Component Libraries]]
|
||||
- [[Web Content Accessibility Guidelines (WCAG)]]
|
||||
- [[모바일 우선 설계(Mobile-First Design)]]
|
||||
- [[모바일 우선주의 (Mobile-First) 디자인]]
|
||||
- [[모바일 퍼스트 인덱싱(Mobile-First Indexing)]]
|
||||
- [[모바일 퍼스트(Mobile-First)]]
|
||||
- [[웹 접근성(Web Accessibility)]]
|
||||
- [[Accessibility (A11y)|Accessibility (A11y)]]
|
||||
- [[Accessibility|Accessibility]]
|
||||
- [[Accessible UI Libraries|Accessible UI Libraries]]
|
||||
- [[Building Reusable UI Components|Building Reusable UI Components]]
|
||||
- [[Mobile-First Approach|Mobile-First Approach]]
|
||||
- [[Mobile-First Design|Mobile-First Design]]
|
||||
- [[Reusable UI Component Libraries|Reusable UI Component Libraries]]
|
||||
- [[Web Content Accessibility Guidelines (WCAG)|Web Content Accessibility Guidelines (WCAG)]]
|
||||
- [[모바일 우선 설계(Mobile-First Design)|모바일 우선 설계(Mobile-First Design)]]
|
||||
- [[모바일 우선주의 (Mobile-First) 디자인|모바일 우선주의 (Mobile-First) 디자인]]
|
||||
- [[모바일 퍼스트 인덱싱(Mobile-First Indexing)|모바일 퍼스트 인덱싱(Mobile-First Indexing)]]
|
||||
- [[모바일 퍼스트(Mobile-First)|모바일 퍼스트(Mobile-First)]]
|
||||
- [[웹 접근성(Web Accessibility)|웹 접근성(Web Accessibility)]]
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Mobile-First Approach]]
|
||||
# [[Mobile-First Approach|Mobile-First Approach]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
모바일 퍼스트(Mobile-First Approach)는 웹사이트를 계획, 구조화, 디자인할 때 가장 작은 모바일 화면 크기를 우선적인 기준으로 삼는 콘텐츠 및 디자인 전략입니다 [1-3]. 데스크톱 화면을 먼저 디자인한 뒤 축소하는 방식과 달리, 모바일 환경에서 가장 핵심적인 콘텐츠와 기능을 먼저 배치한 후 화면이 커짐에 따라 CSS 미디어 쿼리 등을 사용해 점진적으로 레이아웃과 기능을 확장해 나가는 특징을 가집니다 [3-5]. 이는 우선순위를 명확히 하고 깔끔하며 빠른 웹사이트를 구축하는 데 도움을 줍니다 [4, 6].
|
||||
@@ -18,8 +18,8 @@
|
||||
* 모바일 퍼스트를 잘 구현한 실제 사례로는, 기사의 중요도에 따라 모바일에서 단일 스택으로 깔끔하게 조정되도록 설계한 출판 매체 가디언(The Guardian) 지가 있습니다 [11].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Responsive Web Design]], [[Media Queries]], [[Core Web Vitals]]
|
||||
- **Projects/Contexts:** [[The Guardian]], [[CSS Architecture]]
|
||||
- **Related Topics:** [[Responsive Web Design|Responsive Web Design]], [[미디어 쿼리 (Media Queries)|Media Queries]], [[Core Web Vitals|Core Web Vitals]]
|
||||
- **Projects/Contexts:** The Guardian, [[CSS Architecture|CSS Architecture]]
|
||||
- **Contradictions/Notes:** 자료에서는 모바일 퍼스트 디자인과 반응형 웹 디자인을 분명하게 구분하고 있습니다. 모바일 퍼스트는 사용자 여정과 우선순위를 다루는 '전략'이며, 반응형 디자인은 이를 유연하게 조정하는 '기술적 구현'입니다 [1, 2].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Mobile-First Design]]
|
||||
# [[Mobile-First Design|Mobile-First Design]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
모바일 퍼스트 디자인(Mobile-First Design)은 가장 작은 뷰포트인 모바일 화면을 기준으로 디자인과 코드를 먼저 작성한 후, 화면 크기가 커짐에 따라 점진적으로 레이아웃을 확장해 나가는 웹 디자인 방식입니다 [1, 2]. 이 접근법은 필수 콘텐츠의 우선순위를 정하도록 강제하여 더 깔끔하고 빠른 기본 스타일을 생성하게 하며, 최신 검색 엔진의 모바일 우선 인덱싱(Mobile-First Indexing) 기준을 충족시켜 SEO(검색 엔진 최적화)에도 중요한 영향을 미칩니다 [2-4].
|
||||
@@ -18,8 +18,8 @@
|
||||
* 우수한 모범 사례인 '가디언(The Guardian)' 웹사이트의 경우, 작은 폰 화면에서는 단일 에디토리얼 스택으로 표시되다가 데스크톱에서는 4~5개 열로 부드럽게 확장되는 완벽한 모바일 퍼스트 레이아웃을 보여줍니다 [10, 11].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Responsive Web Design]], [[Media Queries]], [[Core Web Vitals]]
|
||||
- **Projects/Contexts:** [[CSS 실전 설계]], [[반응형 디자인]], [[The Guardian Website]]
|
||||
- **Related Topics:** [[Responsive Web Design|Responsive Web Design]], [[미디어 쿼리 (Media Queries)|Media Queries]], [[Core Web Vitals|Core Web Vitals]]
|
||||
- **Projects/Contexts:** CSS 실전 설계, [[반응형 디자인|반응형 디자인]], The Guardian Website
|
||||
- **Contradictions/Notes:** 소스에서는 데스크톱 레이아웃을 먼저 만들고 이를 모바일 크기로 줄이는 방식(Graceful Degradation)은 코드가 복잡해지고 요소가 비좁아져 유지보수가 어렵기 때문에, 모바일 버전을 시작점으로 삼아 큰 화면으로 확장하는 방식(Progressive Enhancement)을 취하는 것이 올바른 CSS 설계 구조라고 강조합니다 [5, 7].
|
||||
|
||||
---
|
||||
|
||||
+5
-5
@@ -1,13 +1,13 @@
|
||||
---
|
||||
id: P-REINFORCE-AI-044
|
||||
category: "[[10_Wiki/💡 Topics/Psychology & Education]]"
|
||||
category: "10_Wiki/💡 Topics/Psychology & Education"
|
||||
confidence_score: 0.97
|
||||
tags: [aba, behavior analysis, education, intervention]
|
||||
last_reinforced: 2026-06-XX
|
||||
github_commit: "[P-Reinforce] Processed FBA.md"
|
||||
---
|
||||
|
||||
# [[Functional Behavior Analysis (FBA)]] (기능적 행동 분석)
|
||||
# [[Functional Behavior Analysis (FBA)|Functional Behavior Analysis (FBA)]] (기능적 행동 분석)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 관찰되는 문제 행동의 '결과'가 아닌, 그 행동이 발생하게 만든 기능(Function)을 과학적으로 파악하여 교육적 개입의 목표를 설정하는 행동주의 심리 평가 방법론이다.
|
||||
@@ -25,7 +25,7 @@ github_commit: "[P-Reinforce] Processed FBA.md"
|
||||
- **정책 변화:** 최근에는 인지 이론(Cognitive Theory)의 관점을 통합하여, 행동 변화 과정에서 사용자의 자기 인식 및 메타인지 개입을 포함하는 다차원적 FBA 모델 개발이 중요해지고 있다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Parent: [[Applied Behavior Analysis (ABA)]]
|
||||
- Related: [[Behavioral Economics]] , [[Cognitive Psychology]] , [[Functional-Behavior-Analysis]]
|
||||
- Raw Source: [[00_Raw/FBA.md]]
|
||||
- Parent: Applied Behavior Analysis (ABA)
|
||||
- Related: [[Behavioral Economics|Behavioral Economics]] , [[Cognitive Psychology|Cognitive Psychology]] , Functional-Behavior-Analysis
|
||||
- Raw Source: 00_Raw/FBA.md
|
||||
---
|
||||
@@ -1,4 +1,4 @@
|
||||
# Index: Topics_Blog > Content_Strategy > Psychology & Education
|
||||
|
||||
## 📝 Documents
|
||||
- [[Functional Behavior Analysis (FBA)]]
|
||||
- [[Functional Behavior Analysis (FBA)|Functional Behavior Analysis (FBA)]]
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Reusable UI Component Libraries]]
|
||||
# [[Reusable UI Component Libraries|Reusable UI Component Libraries]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
재사용 가능한 UI 컴포넌트(Reusable UI Component) 라이브러리는 현대 React 애플리케이션의 뼈대 역할을 하는 '레고 블록'과 같은 요소로, 이식성(Portable)과 예측 가능성(Predictable), 그리고 목적성(Purposeful)을 갖추도록 설계됩니다 [1, 2]. 잘 설계된 컴포넌트 시스템은 일관된 사용자 경험을 제공하고 개발 시간을 단축하며, 단일 책임 원칙과 디자인 토큰 기반의 유연한 스타일링을 통해 확장 가능하고 유지보수가 용이한 프론트엔드 아키텍처를 구축하는 데 핵심적인 역할을 합니다 [1, 3-6].
|
||||
@@ -31,8 +31,8 @@
|
||||
* FSD(Feature-Sliced Design) 아키텍처 방법론을 함께 도입하여 기능(Feature)이나 공유 원시 컴포넌트(Shared) 사이에 딥 임포트(deep imports)를 금지하고 명확한 Public API 인터페이스 규칙을 강제해야 모듈의 응집도를 유지할 수 있습니다 [33, 34].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Compound Components]], [[Atomic Design]], [[Design Tokens]], [[Tailwind CSS]], [[Styled Components]], [[React Server Components (RSC)]], [[Feature-Sliced Design (FSD)]]
|
||||
- **Projects/Contexts:** [[Shopify Polaris]], [[Uber Base Web]], [[Radix UI]]
|
||||
- **Related Topics:** [[Compound Components|Compound Components]], [[Atomic Design|Atomic Design]], [[Design Tokens|Design Tokens]], [[Tailwind CSS|Tailwind CSS]], [[Styled Components|Styled Components]], [[React Server Components (RSC)|React Server Components (RSC)]], [[Feature-Sliced Design (FSD)|Feature-Sliced Design (FSD)]]
|
||||
- **Projects/Contexts:** [[Shopify Polaris|Shopify Polaris]], [[Uber Base Web|Uber Base Web]], [[Radix UI|Radix UI]]
|
||||
- **Contradictions/Notes:**
|
||||
- 복합 컴포넌트(Compound Components) 패턴은 조립의 자유도를 극대화하지만 로직이 여러 컨텍스트 및 Render Props에 분산되어 디버깅이 어려울 수 있습니다. 따라서 레이아웃이 고정되어 있거나 버튼, 배지처럼 단순한 요소에 도입하는 것은 과도한 추상화(Over-engineering)가 되므로 피해야 합니다 [35-37].
|
||||
- Tailwind CSS(유틸리티 퍼스트)와 Styled-Components(CSS-in-JS)는 스타일링 패러다임 측면에서 충돌합니다. Tailwind는 빌드 시점에 정적 CSS를 생성해 React Server Components(RSC) 환경 및 성능 최적화에 뛰어나지만 JSX 마크업이 지저분해질 수 있습니다 [38-40]. 반면 Styled-Components는 훌륭한 캡슐화와 동적 Prop 스타일링을 제공하지만 런타임 시 자바스크립트 실행으로 인한 오버헤드가 발생하며, RSC 환경을 온전히 지원하기 위해 별도의 스타일 레지스트리 패턴 설정이 강제됩니다 [40-43].
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Web Content Accessibility Guidelines (WCAG)]]
|
||||
# [[Web Content Accessibility Guidelines (WCAG)|Web Content Accessibility Guidelines (WCAG)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
웹 콘텐츠 접근성 지침(WCAG)은 모든 사용자가 디지털 콘텐츠와 인터페이스에 장벽 없이 접근할 수 있도록 보장하는 포괄적인 접근성 표준입니다 [1, 2]. 실무 CSS 및 UI/UX 설계에서 WCAG는 애니메이션의 움직임 제한, 텍스트 크기 확대의 보장, 색상 대비 준수 등을 규정하여 포용적이고 안전한 사용자 경험(UX)을 구축하는 핵심 기준이 됩니다 [2-4].
|
||||
@@ -12,8 +12,8 @@
|
||||
디자인 시스템을 구축하고 디자인 토큰을 테스트할 때, 특히 색상 토큰(Color Tokens)은 명도 대비 비율(contrast ratio)이 WCAG 규정을 준수하는지 반드시 검증(Accessibility testing)을 거쳐야 합니다 [3, 8].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[반응형 디자인]], [[애니메이션 (transition / keyframes)]], [[유체 타이포그래피 (Fluid Typography)]], [[디자인 시스템 개념]]
|
||||
- **Projects/Contexts:** [[디자인 토큰(Design Tokens) 구축 및 테스트]], [[프론트엔드 실무 접근성 최적화]]
|
||||
- **Related Topics:** [[반응형 디자인|반응형 디자인]], [[애니메이션 (transition - keyframes)|애니메이션 (transition / keyframes)]], 유체 타이포그래피 (Fluid Typography), [[디자인 시스템 개념|디자인 시스템 개념]]
|
||||
- **Projects/Contexts:** 디자인 토큰(Design Tokens) 구축 및 테스트, 프론트엔드 실무 접근성 최적화
|
||||
- **Contradictions/Notes:** 소스 내에서 상충되는 정보는 없습니다. 다만, 반응형 유체 타이포그래피를 구현할 때 단순히 뷰포트 크기에만 의존하면 텍스트 확대 기능이 작동하지 않아 WCAG 1.4.4 지침을 위반하는 위험성이 발생하므로 설계 시 각별한 주의가 필요하다는 점이 강조됩니다 [2, 9].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[모바일 우선 설계(Mobile-First Design)]]
|
||||
# [[모바일 우선 설계(Mobile-First Design)|모바일 우선 설계(Mobile-First Design)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
모바일 우선 설계(Mobile-First Design)는 가장 작은 화면 크기인 모바일 기기를 기준으로 웹사이트를 먼저 기획하고 구조화하며 디자인하는 접근 방식이다 [1]. 데스크톱 레이아웃을 단순히 축소하는 대신 모바일에서 완벽하게 작동하는 간결한 버전을 시작점으로 삼고, 화면이 커짐에 따라 기능과 디자인을 점진적으로 확장해 나간다 [2, 3]. 이 전략은 핵심 콘텐츠의 우선순위를 정하고 성능을 향상시키며, 반응형 디자인과 결합하여 모든 환경에서 일관된 사용자 경험을 제공하는 데 필수적인 역할을 한다 [1, 4, 5].
|
||||
@@ -14,8 +14,8 @@
|
||||
모바일 우선 접근법은 작은 화면에 맞춰 설계하기 때문에 자연스럽게 가벼운 에셋, 적은 스크립트, 단순화된 시각 요소를 사용하게 되어 웹사이트의 초기 로딩 성능이 향상된다 [4, 7]. 또한 구글(Google)은 기본적으로 모바일 버전을 기준으로 웹사이트를 평가하는 모바일 우선 인덱싱(Mobile-First Indexing) 정책을 사용하므로, 모바일 우선 설계는 검색 가시성과 SEO 순위를 보호하고 높이는 데 직접적인 영향을 미친다 [4, 9, 10].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[반응형 웹 디자인(Responsive Web Design)]], [[미디어 쿼리(Media Queries)]], [[Core Web Vitals]]
|
||||
- **Projects/Contexts:** [[실무에서 CSS 관리하는 방법]], [[반응형 디자인]]
|
||||
- **Related Topics:** [[반응형 웹 디자인 (Responsive Web Design)|반응형 웹 디자인(Responsive Web Design)]], [[미디어 쿼리(Media Queries)|미디어 쿼리(Media Queries)]], [[Core Web Vitals|Core Web Vitals]]
|
||||
- **Projects/Contexts:** [[실무에서 CSS 관리하는 방법|실무에서 CSS 관리하는 방법]], [[반응형 디자인|반응형 디자인]]
|
||||
- **Contradictions/Notes:** 모바일 우선 설계와 반응형 웹 디자인은 함께 작동하지만 해결하는 문제는 서로 다르다. 모바일 우선 설계가 '무엇이 가장 중요한가'를 결정하는 디자인 및 콘텐츠 전략이라면, 반응형 디자인은 인터페이스가 모든 기기에 유연하게 적응하도록 만드는 시스템적 기술(CSS 구현 등)이라는 점에서 구별된다 [1, 5, 11].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[모바일 우선주의 (Mobile-First) 디자인]]
|
||||
# [[모바일 우선주의 (Mobile-First) 디자인|모바일 우선주의 (Mobile-First) 디자인]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
모바일 우선주의(Mobile-First) 디자인은 가장 작은 화면 크기(뷰포트)를 기준으로 먼저 디자인과 코드를 작성한 뒤, 점진적으로 더 큰 화면을 위해 확장(progressive enhancement)해 나가는 접근 방식입니다 [1, 2]. 이 방식은 한정된 공간으로 인해 콘텐츠의 우선순위를 엄격하게 정하도록 강제하며, 결과적으로 더 깔끔하고 빠른 웹사이트의 기본 스타일을 만들어냅니다 [1, 3, 4]. CSS 기술적 측면에서는 모바일을 타겟으로 기본 스타일을 먼저 정의하고, 화면이 커짐에 따라 `min-width` 미디어 쿼리(media queries)를 사용하여 레이아웃의 복잡성을 더해가는 것을 의미합니다 [1, 5, 6].
|
||||
@@ -17,8 +17,8 @@
|
||||
* 영국의 언론사 The Guardian은 모바일 우선 디자인을 가장 잘 구현한 사례 중 하나로 꼽힙니다 [10]. 복잡한 기사와 광고, 멀티미디어 속에서도 작은 스마트폰 화면부터 큰 데스크톱 화면까지 헤드라인과 이미지가 자연스럽게 크기를 조정하고 콘텐츠가 구조화된 형태를 유지합니다 [10].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[반응형 웹 디자인 (Responsive Web Design)]], [[미디어 쿼리 (Media Queries)]], [[모바일 우선 색인 (Mobile-First Indexing)]]
|
||||
- **Projects/Contexts:** [[반응형 디자인]], [[실무에서 CSS 관리하는 방법]]
|
||||
- **Related Topics:** [[반응형 웹 디자인 (Responsive Web Design)|반응형 웹 디자인 (Responsive Web Design)]], [[미디어 쿼리 (Media Queries)|미디어 쿼리 (Media Queries)]], 모바일 우선 색인 (Mobile-First Indexing)
|
||||
- **Projects/Contexts:** [[반응형 디자인|반응형 디자인]], [[실무에서 CSS 관리하는 방법|실무에서 CSS 관리하는 방법]]
|
||||
- **Contradictions/Notes:** 소스 전반에 걸쳐 내용 충돌은 없으며, 반응형 디자인을 효과적으로 구현하기 위해서는 모바일 환경을 '사후 대책'이 아닌 디자인과 개발의 '기반(Foundation)'으로 삼아야 한다는 점이 일관되게 강조되고 있습니다 [6].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[모바일 퍼스트 인덱싱(Mobile-First Indexing)]]
|
||||
# [[모바일 퍼스트 인덱싱(Mobile-First Indexing)|모바일 퍼스트 인덱싱(Mobile-First Indexing)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
모바일 퍼스트 인덱싱(Mobile-First Indexing)은 구글과 같은 검색 엔진이 웹사이트를 평가하고 검색 순위를 매길 때 데스크톱 버전이 아닌 모바일 버전의 사이트를 우선적인 기준으로 삼는 정책입니다 [1, 2]. 이는 모바일 화면에서 레이아웃이 깨지거나 로딩 속도가 느릴 경우 사용자 경험뿐만 아니라 유기적 검색 성능(SEO)에 직접적인 악영향을 미친다는 것을 의미합니다 [1, 2]. 따라서 현대 반응형 웹 개발에서는 가장 작은 화면을 기준으로 먼저 설계하는 모바일 퍼스트(Mobile-First) 디자인 접근이 필수적으로 요구됩니다 [3].
|
||||
@@ -10,8 +10,8 @@
|
||||
* **설계 성능 및 구조적 이점:** 모바일 우선으로 설계하면 제한된 공간으로 인해 불필요한 요소를 최소화하고 가장 중요한 콘텐츠의 우선순위를 정하게 됩니다 [5, 6]. 이는 더 가벼운 에셋, 적은 스크립트 사용을 유도하여 성능을 자연스럽게 향상시키며, 구조적으로도 관리하기 쉬운 깔끔한 CSS 작성을 돕습니다 [5, 7]. 또한 코어 웹 바이탈(Core Web Vitals)과 같은 구글의 주요 성능 지표 개선과도 직접적으로 연결됩니다 [4, 5].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[반응형 웹 디자인(Responsive Web Design)]], [[모바일 퍼스트 디자인(Mobile-First Design)]], [[코어 웹 바이탈(Core Web Vitals)]], [[미디어 쿼리(Media Queries)]]
|
||||
- **Projects/Contexts:** [[검색 엔진 최적화(SEO)]], [[프론트엔드 반응형 레이아웃 설계]]
|
||||
- **Related Topics:** [[반응형 웹 디자인 (Responsive Web Design)|반응형 웹 디자인(Responsive Web Design)]], 모바일 퍼스트 디자인(Mobile-First Design), 코어 웹 바이탈(Core Web Vitals), [[미디어 쿼리(Media Queries)|미디어 쿼리(Media Queries)]]
|
||||
- **Projects/Contexts:** [[검색 엔진 최적화 (SEO)|검색 엔진 최적화(SEO)]], 프론트엔드 반응형 레이아웃 설계
|
||||
- **Contradictions/Notes:** 제공된 소스들은 모두 구글의 모바일 퍼스트 인덱싱 정책으로 인해 모바일 반응형 설계가 프론트엔드 개발에서 선택이 아닌 필수임을 일관되게 강조하고 있으며, 상충되는 내용은 없습니다.
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[모바일 퍼스트(Mobile-First)]]
|
||||
# [[모바일 퍼스트(Mobile-First)|모바일 퍼스트(Mobile-First)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
모바일 퍼스트(Mobile-First)는 웹사이트를 기획, 구조화, 설계할 때 가장 작은 화면 크기(모바일)를 기준으로 시작하여, 점진적으로 더 큰 기기에 맞춰 확장해 나가는 디자인 및 콘텐츠 전략입니다 [1, 2]. 이 접근법은 제한된 공간 안에서 필수적인 콘텐츠와 기능을 최우선으로 배치하여 간결하고 빠른 레이아웃을 생성하는 데 목적이 있습니다 [2, 3]. 기술적으로 CSS를 작성할 때는 모바일용 기본 스타일을 먼저 정의한 후, `min-width` 미디어 쿼리를 사용하여 뷰포트가 커질 때 점진적으로 복잡성을 더해가는 방식으로 구현됩니다 [1, 4, 5].
|
||||
@@ -10,8 +10,8 @@
|
||||
* **사용자 경험(UX) 및 우선순위 설정:** 가장 작은 화면을 위한 설계는 불필요한 요소를 제거하고 가장 중요한 것에만 집중하도록 강제합니다 [3, 12]. 이를 통해 사용자의 인지 부하를 줄일 수 있으며, 내비게이션이나 주요 행동(CTA) 버튼은 추가적인 스크롤 없이도 찾기 쉽고 조작할 수 있는 크기로 배치되어 원활한 사용자 여정을 돕습니다 [2, 5].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[반응형 디자인(Responsive Design)]], [[미디어 쿼리(Media Queries)]], [[모바일 퍼스트 인덱싱(Mobile-first indexing)]]
|
||||
- **Projects/Contexts:** [[CSS 구조 설계 방식]], [[검색 엔진 최적화(SEO) 및 Core Web Vitals 성과 관리]]
|
||||
- **Related Topics:** [[반응형 디자인(Responsive Design)|반응형 디자인(Responsive Design)]], [[미디어 쿼리(Media Queries)|미디어 쿼리(Media Queries)]], [[모바일 퍼스트 인덱싱(Mobile-First Indexing)|모바일 퍼스트 인덱싱(Mobile-first indexing)]]
|
||||
- **Projects/Contexts:** [[CSS 구조 설계 방식|CSS 구조 설계 방식]], 검색 엔진 최적화(SEO) 및 Core Web Vitals 성과 관리
|
||||
- **Contradictions/Notes:** 실무에서는 모바일 퍼스트 디자인과 반응형 디자인이 종종 같은 의미로 혼용되지만, 소스에서는 모바일 퍼스트가 '우선순위를 결정하는 전략'인 반면 반응형 디자인은 '유동적으로 반응하게 하는 기술적 시스템'이라는 점을 들어 이 둘을 명확하게 구분하고 있습니다 [2, 7].
|
||||
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[웹 접근성(Web Accessibility)]]
|
||||
# [[웹 접근성(Web Accessibility)|웹 접근성(Web Accessibility)]]
|
||||
|
||||
## 📌 Brief 시 Summary
|
||||
웹 접근성은 장애나 연령에 상관없이 모든 사용자가 다양한 입력 방식과 기기 환경에서 웹사이트의 정보를 장벽 없이 이용할 수 있도록 설계하는 것을 의미합니다 [1-4]. 반응형 웹 디자인의 필수 요소이며, WCAG(웹 콘텐츠 접근성 지침)와 같은 표준을 준수하여 텍스트 크기 조정, 키보드 탐색, 안전한 애니메이션 제공 등 포용적인 디지털 경험을 구축하는 것이 핵심입니다 [1, 3, 5, 6].
|
||||
@@ -14,8 +14,8 @@
|
||||
* **디자인 시스템에서의 접근성 관리:** 디자인 시스템의 컬러 토큰을 설정할 때 WCAG 명암비(Contrast Ratio) 준수 여부를 반드시 테스트해야 하며, 접근성 고려를 잊는 것은 토큰 설계의 주요 함정 중 하나입니다 [15-17].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[반응형 웹 디자인(Responsive Web Design)]], [[유동적 타이포그래피(Fluid Typography)]], [[애니메이션 성능 최적화 및 모션 제어]], [[디자인 시스템(Design Systems)]]
|
||||
- **Projects/Contexts:** [[WCAG 1.4.4 텍스트 200% 확대 대응]], [[prefers-reduced-motion 미디어 쿼리 구현]], [[키보드 탐색 및 포커스 상태 설계]]
|
||||
- **Related Topics:** [[반응형 웹 디자인 (Responsive Web Design)|반응형 웹 디자인(Responsive Web Design)]], [[유동적 타이포그래피(Fluid Typography)|유동적 타이포그래피(Fluid Typography)]], 애니메이션 성능 최적화 및 모션 제어, [[디자인 시스템(Design Systems)|디자인 시스템(Design Systems)]]
|
||||
- **Projects/Contexts:** WCAG 1.4.4 텍스트 200% 확대 대응, prefers-reduced-motion 미디어 쿼리 구현, 키보드 탐색 및 포커스 상태 설계
|
||||
- **Contradictions/Notes:** 화면 크기에만 반응하게 만들기 위해 뷰포트 단위(`vw`, `vh`)를 단독으로 폰트 크기에 적용하면, 브라우저가 창 크기에 따라 글씨를 조정할 수는 있어도 사용자가 브라우저 자체의 "확대(Zoom)" 기능을 사용할 때는 글씨 크기가 변하지 않아 오히려 접근성을 심각하게 해치는 결과를 초래합니다 [6, 11]. 따라서 `calc()`나 `clamp()`를 통해 기본 픽셀 혹은 `em/rem` 값과 혼합하여 줌(zoom) 기능에 반응하도록 설계해야 합니다 [18, 19].
|
||||
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user