Header Anchor 추가

Author: narusas

ko-KR/src/guide/best-practices/accessibility.md

@@ -2,7 +2,7 @@
 import CodepenSnippet from './accessibility-demos/CodepenSnippet.vue'
 </script>
 
-# 접근성
+# 접근성 {#accessibility}
 
 웹 접근성(a11y라고도 함)은 장애가 있는 사람, 네트워크 속도가 느린 사람, 오래되거나 손상된 하드웨어 또는 단순히 낙후된 환경에 있는 사람 등 누구나 사용할 수 있는 웹사이트를 만드는 것 입니다.
 예를 들어, 비디오에 자막을 추가하면 청각 장애인, 난청 및 시끄러운 환경에서 소리를 들을 수 없는 사용자 모두에게 도움이 됩니다.
@@ -17,7 +17,7 @@ import CodepenSnippet from './accessibility-demos/CodepenSnippet.vue'
 이 가이드에 첨부된 크롬 개발자도구 스크린샷은 한글화가 적용되어 있습니다. 크롬 개발자도구 한글화에 대한 자세한 방법은 [여기](https://developer.chrome.com/ko/blog/new-in-devtools-94/#localized)를 참고하십시오.
 :::
 
-## 건너뛰기 링크
+## 건너뛰기 링크 {#skip-link}
 
 사용자가 여러 웹 페이지에서 반복되는 콘텐츠를 건너뛸 수 있도록 각 페이지 상단에 기본 콘텐츠 영역으로 직접 연결되는 링크를 추가해야 합니다.
 
@@ -92,12 +92,12 @@ watch(
 
 [주요 콘텐츠로 건너뛰기 링크에 대한 설명서 읽기](https://www.w3.org/WAI/WCAG21/Techniques/general/G1.html)
 
-## 콘텐츠 구조
+## 콘텐츠 구조 {#content-structure}
 
 접근성의 가장 중요한 부분 중 하나는 디자인이 접근성 구현을 지원할 수 있는지 확인하는 것입니다.
 디자인은 색상 대비, 글꼴 선택, 텍스트 크기 및 언어뿐만 아니라 앱에서 콘텐츠가 구성되는 방식도 고려해야 합니다.
 
-### 제목
+### 제목 {#headings}
 
 사용자는 제목을 통해 앱을 탐색할 수 있습니다.
 앱의 모든 섹션에 제목이 있으면, 사용자가 각 섹션의 내용을 더 쉽게 예측할 수 있습니다.
@@ -127,7 +127,7 @@ watch(
 </main>
 ```
 
-### 랜드마크
+### 랜드마크 {#landmarks}
 
 [랜드마크](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/landmark_role)는 앱 내의 섹션에 대한 프로그래밍 방식 접근을 제공합니다.
 보조 기술에 의존하는 사용자는 앱의 각 섹션으로 이동하여 콘텐츠를 건너뛸 수 있습니다.
@@ -151,7 +151,7 @@ watch(
 
 [랜드마크에 대해 자세히 알아보기](https://www.w3.org/TR/wai-aria-1.2/#landmark_roles)
 
-## 의미있는 양식 (Semantic form)
+## 의미있는 양식 (Semantic form) {#semantic-forms}
 
 양식(form)을 만들 때 `<form>`, `<label>`, `<input>`, `<textarea>`, `<button>` 엘리먼트를 사용할 수 있습니다.
 
@@ -178,7 +178,7 @@ watch(
 form 엘리먼트에 `autocomplete='on'`을 포함하면 form의 모든 input에 적용됩니다.
 각 input에 대해 다른 [자동 완성 속성 값](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete)을 설정할 수도 있습니다.
 
-### 레이블
+### 레이블 {#labels}
 
 모든 양식의 용도를 설명하는 레이블을 제공합니다.
 `for`와 `id` 속성을 사용하여 연결하여:
@@ -210,7 +210,7 @@ form 엘리먼트에 `autocomplete='on'`을 포함하면 form의 모든 input에
 일치하는 ID로 레이블을 명시적으로 설정하는 것이 보조 기술에서 더 잘 지원됩니다.
 :::
 
-#### `aria-label`
+#### `aria-label` {#aria-label}
 
 [`aria-label`](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-label_attribute)을 사용하여 input에 접근 가능한 이름을 지정할 수도 있습니다.
 
@@ -232,7 +232,7 @@ form 엘리먼트에 `autocomplete='on'`을 포함하면 form의 모든 input에
 
 ![aria-label에서 입력 가능한 이름을 표시하는 Chrome 개발자 도구](./images/AccessibleARIAlabelDevTools.png)
 
-#### `aria-labelledby`
+#### `aria-labelledby` {#aria-labelledby}
 
 [`aria-labelledby`](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-labelledby_attribute)를 사용하는 것은 화면에 레이블 텍스트가 표시되는 경우를 제외하고는 `aria-label`과 유사하다.
 이는 다른 엘리먼트들과 `id`로 쌍을 이루며, 여러 개의 `id`를 연결할 수 있다:
@@ -264,7 +264,7 @@ form 엘리먼트에 `autocomplete='on'`을 포함하면 form의 모든 input에
 
 ![aria-labelledby에서 입력 가능한 이름을 표시하는 Chrome 개발자 도구](./images/AccessibleARIAlabelledbyDevTools.png)
 
-#### `aria-describedby`
+#### `aria-describedby` {#aria-describedby}
 
 [aria-describedby](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-describedby_attribute)는 사용자에게 필요할 수 있는 설명에 대한 추가 정보를 제공한다는 점을 제외하고는 `aria-labelledby`와 같은 방식으로 사용됩니다.
 이것은 input의 특징을 설명하는 데 사용할 수 있습니다:
@@ -300,7 +300,7 @@ form 엘리먼트에 `autocomplete='on'`을 포함하면 form의 모든 input에
 
 ![input에서 접근 가능한 aria-labelledby의 이름과 aria-descriptedby의 설명을 보여주고 있는 크롬 개발자 도구](./images/AccessibleARIAdescribedby.png)
 
-### 플레이스홀더 (Placeholder)
+### 플레이스홀더 (Placeholder) {#placeholder}
 
 플레이스홀더는 많은 사용자를 혼란스럽게 할 수 있으므로 사용하지 마십시오.
 
@@ -334,7 +334,7 @@ form 엘리먼트에 `autocomplete='on'`을 포함하면 form의 모든 input에
 
 사용자가 양식을 작성하는 데 필요한 모든 정보를 input 외부에 제공하는 것이 가장 좋습니다.
 
-### 지침
+### 지침 {#instructions}
 
 입력 필드에 대한 지침을 추가할 때 input에 올바르게 연결해야 합니다.
 추가 지침을 제공하고 [`aria-labelledby`](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-labelledby_attribute) 내부에 여러 ID를 바인딩할 수 있습니다.
@@ -368,7 +368,7 @@ form 엘리먼트에 `autocomplete='on'`을 포함하면 form의 모든 input에
 <CodepenSnippet title="Form Instructions" slug="JjpxwwP" :height="460"/>
 <!-- <common-codepen-snippet title="Form Instructions" slug="WNREEqv" :height="265" tab="js,result" theme="light" :preview="false" :editable="false" /> -->
 
-### 콘텐츠 숨기기
+### 콘텐츠 숨기기 {#hiding-content}
 
 일반적으로 input에 접근 가능한 이름이 있더라도 레이블을 시각적으로 숨기는 것은 권장되지 않습니다.
 그러나 input의 역할을 주변 콘텐츠로 이해할 수 있다면 레이블을 시각적으로 숨길 수 있습니다.
@@ -404,7 +404,7 @@ CSS를 사용하여 시각적으로 엘리먼트를 숨길 수 있지만, 보조
 <CodepenSnippet title="Form Search" slug="LYQqMqE" :height="210"/>
 <!-- <common-codepen-snippet title="Form Search" slug="QWdMqWy" :height="265" tab="js,result" theme="light" :preview="false" :editable="false" /> -->
 
-#### `aria-hidden="true"`
+#### `aria-hidden="true"` {#aria-hidden-true}
 
 `aria-hidden="true"`를 추가하면 보조 기술에서 엘리먼트가 숨겨지지만, 다른 사용자는 시각적으로 사용할 수 있습니다.
 초점을 맞출 수 있는 엘리먼트, 오직 꾸미기 위한 용도, 복제 또는 화면에 나오지 않는 콘텐츠에 사용하지 마십시오.
@@ -414,7 +414,7 @@ CSS를 사용하여 시각적으로 엘리먼트를 숨길 수 있지만, 보조
 <p aria-hidden="true">이것은 스크린 리더에서 숨겨져 있습니다.</p>
 ```
 
-### 버튼
+### 버튼 {#buttons}
 
 폼 내에서 버튼을 사용할 때 폼이 제출되지 않도록 타입을 설정해야 합니다.
 input을 사용하여 버튼을 만들 수도 있습니다:
@@ -434,7 +434,7 @@ input을 사용하여 버튼을 만들 수도 있습니다:
 <CodepenSnippet title="Form Buttons" slug="PoQVXLj" :height="565"/>
 <!-- <common-codepen-snippet title="Form Buttons" slug="JjEyrYZ" :height="467" tab="js,result" theme="light" :preview="false" :editable="false" /> -->
 
-### 기능적 이미지
+### 기능적 이미지 {#functional-images}
 
 이 기술을 사용하여 기능적 이미지를 만들 수 있습니다.
 
@@ -471,7 +471,7 @@ input을 사용하여 버튼을 만들 수도 있습니다:
 <CodepenSnippet title="Functional Images" slug="XWZOoQQ" :height="360"/>
 <!-- <common-codepen-snippet title="Functional Images" slug="jOyLGqM" :height="265" tab="js,result" theme="light" :preview="false" :editable="false" /> -->
 
-## 표준
+## 표준 {#standards}
 
 W3C(World Wide Web Consortium) WAI(Web Accessibility Initiative)는 다양한 컴포넌트에 대한 웹 접근성 표준을 개발합니다:
 
@@ -482,12 +482,12 @@ W3C(World Wide Web Consortium) WAI(Web Accessibility Initiative)는 다양한 
 - [웹 콘텐츠 접근성 지침 (WCAG: Web Content Accessibility Guidelines)](https://www.w3.org/WAI/standards-guidelines/wcag/)
   - 웹 콘텐츠 - 개발자, 저작 도구 및 접근성 평가 도구에서 사용
 
-### 웹 콘텐츠 접근성 지침 (WCAG: Web Content Accessibility Guidelines)
+### 웹 콘텐츠 접근성 지침 (WCAG: Web Content Accessibility Guidelines) {#web-content-accessibility-guidelines-wcag}
 
 [WCAG 2.1](https://www.w3.org/TR/WCAG21/)은 [WCAG 2.0](https://www.w3.org/TR/WCAG20/)을 확장하고 웹의 변경 사항을 처리하여 새로운 기술을 구현할 수 있습니다.
 W3C는 웹 접근성 정책을 개발하거나 업데이트할 때 최신 버전의 WCAG를 사용하도록 권장합니다.
 
-#### WCAG 2.1의 4가지 주요 기본 원칙(약칭: POUR):
+#### WCAG 2.1의 4가지 주요 기본 원칙(약칭: POUR): {#wcag-2-1-four-main-guiding-principles-abbreviated-as-pour}
 
 - [Perceivable(인지가능)](https://www.w3.org/TR/WCAG21/#perceivable)
   - 사용자는 제공되는 정보를 인지할 수 있어야 합니다.
@@ -498,23 +498,23 @@ W3C는 웹 접근성 정책을 개발하거나 업데이트할 때 최신 버전
 - [Robust](https://www.w3.org/TR/WCAG21/#robust)
   - 기술이 발전함에 따라 사용자가 콘텐츠에 액세스할 수 있어야 합니다.
 
-#### Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA: 웹 접근성 계획 - 접근 가능한 풍부한 인터넷 앱)
+#### Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA: 웹 접근성 계획 - 접근 가능한 풍부한 인터넷 앱) {#web-accessibility-initiative-–-accessible-rich-internet-applications-wai-aria}
 
 W3C의 WAI-ARIA는 동적 콘텐츠 및 고급 사용자 인터페이스 제어를 구축하는 방법에 대한 지침을 제공합니다.
 
 - [Accessible Rich Internet Applications (WAI-ARIA) 1.2](https://www.w3.org/TR/wai-aria-1.2/)
 - [WAI-ARIA Authoring Practices 1.2](https://www.w3.org/TR/wai-aria-practices-1.2/)
 
-## 리소스
+## 리소스 {#resources}
 
-### 문서
+### 문서 {#documentation}
 
 - [WCAG 2.0](https://www.w3.org/TR/WCAG20/)
 - [WCAG 2.1](https://www.w3.org/TR/WCAG21/)
 - [Accessible Rich Internet Applications (WAI-ARIA) 1.2](https://www.w3.org/TR/wai-aria-1.2/)
 - [WAI-ARIA Authoring Practices 1.2](https://www.w3.org/TR/wai-aria-practices-1.2/)
 
-### 보조 기술
+### 보조 기술 {#assistive-technologies}
 
 - 스크린 리더
   - [NVDA](https://www.nvaccess.org/download/)
@@ -526,7 +526,7 @@ W3C의 WAI-ARIA는 동적 콘텐츠 및 고급 사용자 인터페이스 제어
   - [ZoomText](https://www.zoomtext.com/)
   - [Magnifier](https://support.microsoft.com/en-us/help/11542/windows-use-magnifier-to-make-things-easier-to-see)
 
-### 테스트
+### 테스트 {#testing}
 
 - 자동화된 도구
   - [Lighthouse](https://chrome.google.com/webstore/detail/lighthouse/blipmdconlkpinefehnmjammfjpmpbjk)
@@ -540,7 +540,7 @@ W3C의 WAI-ARIA는 동적 콘텐츠 및 고급 사용자 인터페이스 제어
   - [Focus Indicator](https://chrome.google.com/webstore/detail/focus-indicator/heeoeadndnhebmfebjccbhmccmaoedlf?hl=en-US…)
   - [NerdeFocus](https://chrome.google.com/webstore/detail/nerdefocus/lpfiljldhgjecfepfljnbjnbjfhennpd?hl=en-US…)
 
-### 사용자
+### 사용자 {#users}
 
 세계보건기구(WHO)는 세계 인구의 15%가 어떤 형태의 장애를 갖고 있으며,
 그 중 2-4%가 심각한 장애를 갖고 있다고 추정합니다.

ko-KR/src/guide/best-practices/performance.md

@@ -2,9 +2,9 @@
 outline: deep
 ---
 
-# 성능 (Performance)
+# 성능 (Performance) {#performance}
 
-## 개요
+## 개요 {#overview}
 
 Vue는 수동 최적화가 크게 필요하지 않은 가장 일반적인 사용 사례에 적합하도록 설계되었습니다.
 그러나 추가 미세 조정이 필요한 어려운 시나리오가 항상 있습니다.
@@ -31,7 +31,7 @@ Vue는 수동 최적화가 크게 필요하지 않은 가장 일반적인 사용
 
 - Jason Miller의 블로그 [Application Holotypes](https://jasonformat.com/application-holotypes/)(앱 유형)에서 웹 앱의 유형과 이상적인 구현 및 제공에 대해 논의합니다.
 
-## 프로파일링 옵션 (profiling options)
+## 프로파일링 옵션 (profiling options) {#profiling-options}
 
 성능을 개선하려면 먼저 측정 방법을 알아야 합니다.
 이와 관련하여 도움이 될 수 있는 훌륭한 도구가 많이 있습니다.
@@ -47,13 +47,13 @@ Vue는 수동 최적화가 크게 필요하지 않은 가장 일반적인 사용
   - [`app.config.performance`](/api/application.html#app-config-performance)는 크롬 개발자도구의 성능 타임라인에서 Vue 관련 성능 마커를 활성화합니다.
 - [Vue 개발자도구 확장](/guide/scaling-up/tooling.html#브라우저-개발자-도구)은 성능 프로파일링 기능도 제공합니다.
 
-## 페이지 로드 최적화
+## 페이지 로드 최적화 {#page-load-optimizations}
 
 페이지 로드 성능을 최적화하는 것은 프레임워크에 구애받지 않는 경우가 많습니다.
 포괄적인 정리 내용은 [web.dev 가이드](https://web.dev/fast/)를 확인하세요.
 여기서는 주로 Vue에 특화된 기술에 초점을 맞출 것입니다.
 
-### 번들 크기 및 트리 쉐이킹 (tree-shaking)
+### 번들 크기 및 트리 쉐이킹 (tree-shaking) {#bundle-size-and-tree-shaking}
 
 페이지 로드 성능을 향상시키는 가장 효과적인 방법 중 하나는 더 작은 JavaScript 번들을 제공하는 것입니다.
 Vue를 사용할 때 번들 크기를 줄이는 몇 가지 방법은 다음과 같습니다:
@@ -79,7 +79,7 @@ Vue를 사용할 때 번들 크기를 줄이는 몇 가지 방법은 다음과 
 
 - 주로 빌드 단계 없이 Vue를 사용하고 있다면, [petite-vue](https://github.com/vuejs/petite-vue)(**6kb**)를 사용하는 것이 좋습니다.
 
-### 코드 분할
+### 코드 분할 {#code-splitting}
 
 코드 분할은 빌드 도구가 앱 번들을 여러 개의 작은 청크로 분할하는 것으로, 로드 또는 요청 시 병렬로 로드할 수 있는 곳입니다.
 적절한 코드 분할을 사용하면 페이지 로드 시,
@@ -110,15 +110,15 @@ const Foo = defineAsyncComponent(() => import('./Foo.vue'))
 Vue 라우터를 통해 클라이언트 측 라우팅을 사용하는 경우, 라우트 컴포넌트를 비동기 컴포넌트로 사용하는 것이 좋습니다.
 자세한 내용은 [라우트 지연 로드](https://router.vuejs.org/guide/advanced/lazy-loading.html)를 참조하십시오.
 
-### SSR / SSG
+### SSR / SSG {#ssr-ssg}
 
 순수한 클라이언트 측 렌더링은 콘텐츠 생성 시간이 느립니다.
 이는 SSR(서버 사이드 렌더링) 또는 SSG(정적 사이트 생성)를 사용하여 완화할 수 있습니다.
 자세한 내용은 [SSR 가이드](/guide/scaling-up/ssr.html)를 확인하세요.
 
-## 업데이트 최적화
+## 업데이트 최적화 {#update-optimizations}
 
-### Props 안정성
+### Props 안정성 {#props-stability}
 
 Vue에서 자식 컴포넌트는 수신된 props 중 하나 이상이 변경된 경우에만 업데이트됩니다.
 다음 예제를 봅시다:
@@ -146,22 +146,22 @@ Vue에서 자식 컴포넌트는 수신된 props 중 하나 이상이 변경된
 이제 대부분의 컴포넌트에서 `active` prop은 `activeId`가 변경될 때 동일하게 유지되므로, 더 이상 업데이트할 필요가 없습니다.
 이 개념은 일반적으로 자식 컴포넌트에 전달되는 prop을 가능한 한 안정적으로 유지하는 것입니다.
 
-### `v-once`
+### `v-once` {#v-once}
 
 `v-once`는 런타임 데이터에 의존하지만, 업데이트할 필요가 없는 콘텐츠를 렌더링하는 데 사용할 수 있는 내장 디렉티브입니다.
 이것을 사용하는 컴포넌트 내 전체 하위 트리는 이후 모든 업데이트를 건너뜁니다.
 자세한 내용은 [API 참조](/api/built-in-directives.html#v-once)를 참조하세요.
 
-### `v-memo`
+### `v-memo` {#v-memo}
 
 `v-memo`는 큰 하위 트리 또는 `v-for` 목록의 업데이트를 조건부로 건너뛰는 데 사용할 수 있는 내장 디렉티브입니다.
 자세한 내용은 [API 참조](/api/built-in-directives.html#v-memo)를 참조하세요.
 
-## 일반적인 최적화
+## 일반적인 최적화 {#general-optimizations}
 
 > 다음 팁은 페이지 로드와 업데이트 성능에 모두 영향을 미칩니다.
 
-### 대규모 목록 가상화
+### 대규모 목록 가상화 {#virtualize-large-lists}
 
 모든 프론트엔드 앱에서 가장 일반적인 성능 문제 중 하나는, 큰 목록을 렌더링하는 것입니다.
 프레임워크의 성능이 아무리 뛰어나더라도 수천 개의 아이템이 포함된 목록을 렌더링하는 것은 **브라우저가 처리해야 하는 DOM 노드의 수 때문에 느려질 것**입니다.
@@ -176,7 +176,7 @@ Vue에서 자식 컴포넌트는 수신된 props 중 하나 이상이 변경된
 - [vue-virtual-scroller](https://github.com/Akryum/vue-virtual-scroller)
 - [vue-virtual-scroll-grid](https://github.com/rocwang/vue-virtual-scroll-grid)
 
-### 큰 불변 구조에 대한 반응성 오버헤드 감소
+### 큰 불변 구조에 대한 반응성 오버헤드 감소 {#reduce-reactivity-overhead-for-large-immutable-structures}
 
 Vue의 반응형 시스템은 기본적으로 깊습니다.
 이러면 상태 관리가 직관적이지만,
@@ -210,7 +210,7 @@ shallowArray.value = [
 ]
 ```
 
-### 불필요한 컴포넌트 추상화 방지
+### 불필요한 컴포넌트 추상화 방지 {#avoid-unnecessary-component-abstractions}
 
 때때로 우리는 더 나은 추상화 또는 코드 구성을 위해,
 [렌더리스 컴포넌트](/guide/components/slots.html#렌더리스-컴포넌트) 또는 고차 컴포넌트(예: 다른 컴포넌트를 추가 props로 렌더링하는 컴포넌트)를 만들 수 있습니다.