chore: update origin to V17.3.4

Author: ricardochl

adev-es/src/app/sub-navigation-data.ts

@@ -17,16 +17,16 @@ Use attribute binding template syntax to control the values of accessibility-rel
 When binding to ARIA attributes in Angular, you must use the `attr.` prefix. The ARIA specification depends specifically on HTML attributes rather than properties of DOM elements.
 
 <docs-code language="html">
-&lt;!-- Use attr. when binding to an ARIA attribute --&gt;
-&lt;button [attr.aria-label]="myActionLabel"&gt;&hellip;&lt;/button&gt;
+<!-- Use attr. when binding to an ARIA attribute -->
+<button [attr.aria-label]="myActionLabel">…</button>
 </docs-code>
 
 Note: This syntax is only necessary for attribute *bindings*.
 Static ARIA attributes require no extra syntax.
 
 <docs-code language="html">
-&lt;!-- Static ARIA attributes require no extra syntax --&gt;
-&lt;button aria-label="Save document"&gt;&hellip;&lt;/button&gt;
+<!-- Static ARIA attributes require no extra syntax -->
+<button aria-label="Save document">…</button>
 </docs-code>
 
 HELPFUL: By convention, HTML attributes use lowercase names \(`tabindex`\), while properties use camelCase names \(`tabIndex`\).
@@ -77,14 +77,14 @@ The following example shows how to make a progress bar accessible by using host
 * In the template, the `aria-label` attribute ensures that the control is accessible to screen readers.
 
 <docs-code-multifile
-  path="accessibility/src/app/app.component.ts"
+  path="adev/src/content/examples/accessibility/src/app/app.component.ts"
   preview>
   <docs-code
-    path="accessibility/src/app/progress-bar.component.ts"
+    path="adev/src/content/examples/accessibility/src/app/progress-bar.component.ts"
     linenums
     highlight="[12, 20]"/>
   <docs-code
-    path="accessibility/src/app/app.component.html"
+    path="adev/src/content/examples/accessibility/src/app/app.component.html"
     linenums
     highlight="[8, 9]"/>
 </docs-code-multifile>
@@ -103,8 +103,8 @@ The following example shows how to find and focus the main content header in the
 
 <docs-code language="typescript">
 
-router.events.pipe(filter(e =&gt; e instanceof NavigationEnd)).subscribe(() =&gt; {
-  const mainHeader = document.querySelector('&num;main-content-header')
+router.events.pipe(filter(e => e instanceof NavigationEnd)).subscribe(() => {
+  const mainHeader = document.querySelector('#main-content-header')
   if (mainHeader) {
     mainHeader.focus();
   }

adev-es/src/content/best-practices/a11y.md

@@ -59,7 +59,7 @@ If Angular handles an event within a component with OnPush strategy, the framewo
 
 As an example, if Angular handles an event within `MainComponent`, the framework will run change detection in the entire component tree. Angular will ignore the subtree with root `LoginComponent` because it has `OnPush` and the event happened outside of its scope.
 
-<img alt="Change detection propagation from OnPush component" src="assets/content/images/best-practices/runtime-performance/on-push-trigger.svg">
+<img alt="Change detection propagation from OnPush component" src="assets/images/best-practices/runtime-performance/on-push-trigger.svg">
 
 ```mermaid
 graph TD;

adev-es/src/content/best-practices/runtime-performance/skipping-subtrees.md

@@ -10,7 +10,7 @@ A single slow computation within a template or a lifecycle hook can slow down th
 
 You can identify heavy computations with Angular DevTools’ profiler. In the performance timeline, click a bar to preview a particular change detection cycle. This displays a bar chart, which shows how long the framework spent in change detection for each component. When you click a component, you can preview how long Angular spent  evaluating its template and lifecycle hooks.
 
-<img alt="Angular DevTools profiler preview showing slow computation" src="assets/content/images/best-practices/runtime-performance/slow-computations.png">
+<img alt="Angular DevTools profiler preview showing slow computation" src="assets/images/best-practices/runtime-performance/slow-computations.png">
 
 For example, in the preceding screenshot, the second recorded change detection cycle is selected. Angular spent over 573 ms on this cycle, with the most time spent in the `EmployeeListComponent`. In the details panel, you can see that Angular spent over 297 ms evaluating the template of the `EmployeeListComponent`.
 

adev-es/src/content/best-practices/runtime-performance/slow-computations.md

@@ -13,13 +13,13 @@ This section covers how to identify such conditions, and how to run code outside
 
 You can detect unnecessary change detection calls using Angular DevTools. Often they appear as consecutive bars in the profiler’s timeline with source `setTimeout`, `setInterval`, `requestAnimationFrame`, or an event handler. When you have limited calls within your application of these APIs, the change detection invocation is usually caused by a third-party library.
 
-<img alt="Angular DevTools profiler preview showing Zone pollution" src="assets/content/images/best-practices/runtime-performance/zone-pollution.png">
+<img alt="Angular DevTools profiler preview showing Zone pollution" src="assets/images/best-practices/runtime-performance/zone-pollution.png">
 
 In the image above, there is a series of change detection calls triggered by event handlers associated with an element. That’s a common challenge when using third-party, non-native Angular components, which do not alter the default behavior of `NgZone`.
 
 ## Run tasks outside `NgZone`
 
-In such cases, you can instruct Angular to avoid calling change detection for tasks scheduled by a given piece of code using [NgZone](/guide/zone).
+In such cases, you can instruct Angular to avoid calling change detection for tasks scheduled by a given piece of code using [NgZone](/api/core/NgZone).
 
 <docs-code header="Run outside of the Zone" language='ts' linenums>
 import { Component, NgZone, OnInit } from '@angular/core';