Restructure Porfolio site

_baselines/document-baselines/01KeyboardDocs.md

@@ -3,102 +3,28 @@ title: "1. Keyboard Accessible (Docs)"
 order-number: 2
 toc-group: baseline-docs
 banner-title: "Baseline for Documents"
+source: Doc
 ---
 
 ## 1. Keyboard Accessible
-### Accessibility Requirements
 
-- [WCAG SC 2.1.1 Keyboard ](https://www.w3.org/WAI/WCAG22/Understanding/keyboard)-- All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
-- [WCAG SC 2.1.2 No Keyboard Trap](https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap) -- If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.
-- [Conformance Requirement 5: Non-Interference](https://www.w3.org/WAI/WCAG22/Understanding/conformance#conf-req5) The following success criteria apply to all content on the page, including content that is not otherwise relied upon to meet conformance, because failure to meet them could interfere with any use of the page:
-    -   1.4.2 - Audio Control
-    -   2.1.2 - No Keyboard Trap
-    -   2.3.1 - Three Flashes or Below Threshold, and
-    -   2.2.2 - Pause, Stop, Hide.
+<!-- ### Accessibility Requirements -->
+{% include baseline-segments/acc-reqs/01-keyboard-acc-reqs.md %}
 
-### Test Method Rationale
+<!-- ### Test Method Rationale -->
+{% include baseline-segments/test-method-rationales/01-keyboard-tmr.html %}
 
-This requirement relies on use of a keyboard to validate access and control of all functionalities of the content first by checking use of standard keyboard commands (Tab, Space Bar, Enter, Escape, etc.). If a document uses non-standard keyboard commands, the document must clearly document the commands and make users aware that the commands exist.
+<!-- ### Limitations, Assumptions, or Exceptions -->
+{% include baseline-segments/lim-assmpt-except/01-keyboard-lae.md %}
 
-Keyboard access and control includes the ability to navigate to **AND** away from interactive content using only a keyboard.
+<!-- ### 1.A Test Procedure for Keyboard Access -->
+{% include baseline-segments/tests/1A-keyboardaccess.html %}
 
-### Limitations, Assumptions, or Exceptions
+<!-- ### 1.B Test Procedure for No Keyboard Trap -->
+{% include baseline-segments/tests/1B-nokeyboardtrap.html %}
 
--   This test was written to be performed on a standard physical keyboard for a Windows PC. While keyboard emulators (such as on-screen keyboards, alternate keyboards, speech input, etc.) may be utilized, testing instructions may differ. Mouse Keys (a Windows and Mac OS feature that enables control of the mouse pointer by keyboard) is not a keyboard emulator.
+<!-- ### Advisory: Tips for streamlined test processes -->
+{% include baseline-segments/advisory/01-keyboard-adv.html %}
 
--   Notes from SC 2.1.1:
-
-    -   Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input, but the underlying function (text input) does not.
-    -   Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.
-
--   Note from SC 2.1.2:
-
-    -   Note 1: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole document, all content in a document (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.
-
-### 1.A Test Procedure for Keyboard Access
-
-**Baseline Test ID:** 1.A-KeyboardAccess
-
-#### Identify Content
-
-<p id="d1aIC">All functionality of the content that is available by mouse control must be keyboard accessible. Determine the functionality of visible and hidden interactive document components (links, form fields, drop down menus, show/hide content, tree views, pop ups, etc.) available using a mouse (hover and/or click).</p>
-
-#### Test Instructions
-
-<ol id="d1aTI">
-    <li id="d1aTI-1">Check that all functionality can be accessed and executed using only the keyboard. [SC 2.1.1]
-        <ol>
-            <li id="d1aTI-1a">Use the keyboard to perform functions available by mouse (including drop-down menus, form fields, revealing/hiding content, tooltips, **AND** all interactive interface components).</li>
-            <li id="d1aTI-1b">If an interactive component is not available by keyboard, check if another keyboard control with the same functionality is provided. (All functionalities must meet this requirement.)</li>
-        </ol>
-    </li>
-    <li id="d1aTI-2">Check that individual keystrokes do not require specific timings for activation. [SC 2.1.1]
-        <ol>
-            <li id="d1aTI-2a">If operation requires specific timings of individual keystrokes, check if another control is provided on the page with the same functionality which does not require specific timings for operation. (All functionality must be available without requiring specific timings for individual keystrokes to operate.)</li>
-        </ol>
-    </li>
-</ol>
-
-#### Test Results
-
-<p id="d1aTR">If any of the above checks fail, then Baseline Test 1.A-KeyboardAccess fails.</p>
-
-### 1.B Test Procedure for No Keyboard Trap
-
-**Baseline Test ID:** 1.B-NoKeyboardTrap
-
-#### Identify Content
-
-<p id="d1bIC">Components that receive keyboard focus.</p>
-
-#### Test Instructions
-
-<ol id="d1bTI">
-    <li id="d1bTI-1">Check that focus can be moved away from the component. There must be NO "TRAP" that disrupts keyboard navigation. [SC 2.1.2, Conformance Requirement 5]
-        <ol>
-            <li id="d1bTI-1a">If a keyboard trap is found, inspect any help (contextual help, or application help) and documentation for notification of available alternate keyboard commands (e.g., non-standard keyboard controls, access keys, hotkeys).</li>
-            <li id="d1bTI-1b">If nonstandard keyboard commands are required to navigate away from a component or set of components, check that the commands work.</li>
-        </ol>
-    </li>
-</ol>
-
-
-
-#### Test Results
-
-<p id="d1bTR">If the above check fails, then Baseline Test 1.B-NoKeyboardTrap fails.</p>
-
-### Advisory: Tips for Streamlined Test Processes
--   Keyboard focusable components include links, form fields, drop-down menus, show/hide content, tree views, embedded objects, and pop ups. Focusable components may also be "hidden", positioned off-screen, and/or have no visible indication of focus.
--   Keyboard commands include standard and any nonstandard keyboard commands.
--   This test may be combined with tests for keyboard focus.
--   Tips and techniques for finding hidden content may be useful for testers.
--   Based on the document format being tested, it may be useful for testers to reference the applications' guide for keyboard commands.
--   Content that is found non-conformant with SC 2.1.1 may be marked for further review for a Section 508 exception if "the underlying function requires input that depends on the path of the user's movement and not just the endpoints".
-
-### WCAG 2.2 Techniques
-
-The following sufficient techniques and/or common failures were considered when developing this test procedure for this baseline requirement:
--   [G21: Ensuring users are not trapped in content](https://www.w3.org/WAI/WCAG22/Techniques/general/G21)
--   [G202: Ensuring keyboard control for all functionality](https://www.w3.org/WAI/WCAG22/Techniques/general/G202)
--   [F10: Failure of Success Criterion 2.1.2 and Conformance Requirement 5 due to combining multiple content formats](https://www.w3.org/WAI/WCAG22/Techniques/failures/F10) in a way that traps users inside one format type
+<!-- ### WCAG 2.2 Techniques -->
+{% include baseline-segments/wcag-techs/01-keyboard-wcag.md %}

_baselines/document-baselines/02FocusDocs.md

@@ -3,137 +3,32 @@ title: "2. Focus (Docs)"
 order-number: 3
 toc-group: baseline-docs
 banner-title: "Baseline for Documents"
+source: Doc
 ---
 
 ## 2. Focus
 
-### Accessibility Requirements
+<!-- ### Accessibility Requirements -->
+{% include baseline-segments/acc-reqs/02-focus-acc-reqs.md %}
 
--   [WCAG SC 2.4.3 Focus Order](https://www.w3.org/WAI/WCAG22/Understanding/focus-order) -- If a document can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.
--   [WCAG SC 2.4.7 Focus Visible](https://www.w3.org/WAI/WCAG22/Understanding/focus-visible) -- Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
--   [WCAG SC 3.2.1 On Focus](https://www.w3.org/WAI/WCAG22/Understanding/on-focus) -- When any user interface component receives focus, it does not initiate a change of context.
+<!-- ### Test Method Rationale -->
+{% include baseline-segments/test-method-rationales/02-focus-tmr.html %}
 
-### Test Method Rationale
+<!-- ### Limitations, Assumptions, or Exceptions -->
+{% include baseline-segments/lim-assmpt-except/02-focus-lae.md %}
 
-Manually navigating or controlling document components by keyboard-only will enable a tester to identify when there is no visual differentiation between a focused item and the rest of the document or content. Using the keyboard to navigate facilitates inspection of focus order.
+<!-- ### 2.A Test Procedure for Focus Visible -->
+{% include baseline-segments/tests/2A-focusvisible.html %}
 
-### Limitations, Assumptions, or Exceptions
+<!-- ### 2.B Test Procedure for Focus Order -->
+{% include baseline-segments/tests/2B-focusorder.html %}
 
--   Some interface components (e.g., screen text for form filling instructions), which are not normally considered interactive, may be in the tab order. Such interface components should receive a visible indication of focus when the user navigates to them using a keyboard.
--   Loss of visible focus should not occur while manually shifting focus through the page (using the TAB or arrow keys). However, when a function that moves the focus is executed (such as an internal page link or hidden content is revealed), it may be necessary to manually shift focus once with the keyboard before focus becomes visible again. This is not considered a failure.
--   Focus may be moved to a control either via the keyboard (e.g., tabbing to a control) or the mouse (e.g., clicking on a text field). Moving the mouse over a control does not move the focus unless scripting implements this behavior.
--   While it may be a common best practice, Focus Order is not required to move left to right, top to bottom.
--   Focus order includes forward and backward navigation.
--   Without exception, focus must shift to modal dialog boxes and remain within the dialog box until the box is closed by the user.
--   For some types of controls, clicking a control may also activate the control (e.g., button), which may, in turn, initiate a change in context. Controls that are clearly labeled and intended to initiate a change in context do not fail under this test.
--   This test evaluates 3.2.1 On Focus using only the keyboard to avoid unintentional activation of controls with a mouse.
--   [Changes of context](https://www.w3.org/TR/WCAG22/#dfn-change-of-context) are major changes in content that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously. Changes in context include changes of:
-    1.  User agent
-    2.  Viewport
-    3.  Focus
-    4.  Content that changes the meaning of the page
-    -   **Note:** A change of content is not always a change of context. Changes in content, such as an expanding outline, dynamic menu, or a tab control do not necessarily change the context, unless they also change one of the above (e.g., focus).
-    -   **Examples:** Opening a new window, moving focus to a different component, going to a new document or window (including anything that would look to a user as if they had moved to a new document) or significantly re-arranging the content of a page/screen are examples of changes of context.
+<!-- ### 2.C Test Procedure for On Focus -->
+{% include baseline-segments/tests/2C-onfocus.html %}
 
-### 2.A Test Procedure for Focus Visible
+<!-- ### Advisory: Tips for streamlined test processes -->
+{% include baseline-segments/advisory/02-focus-adv.html %}
 
-**Baseline Test ID:** 2.A-FocusVisible
+<!-- ### WCAG 2.2 Techniques -->
+{% include baseline-segments/wcag-techs/02-focus-wcag.html %}
 
-#### Identify Content
-
-<p id="d2aIC">Keyboard accessible interface components (e.g., links, form fields, drop-down menus, show/hide content, tree views, and pop ups).</p>
-
-#### Test Instructions
-
-<ol id="d2aTI">
-    <li id="d2aTI-1">Use the keyboard to navigate through each interface component.</li>
-    <li id="d2aTI-2">Check that a visible indication of focus is provided when focus is on the interface component. The focus indicator must not be limited; when the keyboard focus is shown it must remain. [SC 2.4.7]</li>
-</ol>
-
-#### Test Results
-
-<p id="d2aTR">If any of the above checks fail, then Baseline Test 2.A-FocusVisible fails.</p>
-
-### 2.B Test Procedure for Focus Order
-
-**Baseline Test ID:** 2.B-FocusOrder
-
-#### Identify Content
-
-<p id="d2bIC">Keyboard accessible document components (links, form fields, drop-down menus, show/hide content, tree views, and pop ups, etc.) that have a meaningful sequence of navigation.</p>
-
-#### Test Instructions
-
-<ol id="d2bTI">
-    <li id="d2bTI-1">Use the keyboard to navigate through document components.
-        <ol>
-            <li id="d2bTI-1a">Use the keyboard to activate trigger controls that reveal hidden content (menus, dialogs, expandable tree list, etc.).
-                <ol>
-                    <li id="d2bTI-1ai">Check that the revealed focusable content is included in the focus order. [SC 2.4.3]</li>
-                    <li id="d2bTI-1aii">Advance the focus through the revealed content.</li>
-                </ol>
-            </li>
-            <li id="d2bTI-1b">Use the keyboard to close/hide the revealed content.
-                <ol>
-                    <li id="d2bTI-1bi">Check that focus is returned to the trigger control. It is acceptable to Shift+ TAB once or use an arrow key to move the focus backward to the trigger control. [SC 2.4.3]</li>
-                </ol>
-            </li>
-        </ol>
-    </li>
-    <li id="d2bTI-2">Check that the focus order preserves the meaning and usability of the page. [SC 2.4.3]</li>
-</ol>
-
-
-
-#### Test Results
-
-<p id="d2bTR">If any of the above checks fail, then Baseline Test 2.B-FocusOrder fails.</p>
-
-### 2.C Test Procedure for On Focus
-
-**Baseline Test ID:** 2.C-OnFocus
-
-#### Identify Content
-
-<p id="d2cIC">Keyboard accessible document components (links, form fields, drop-down menus, show/hide content, tree views, and pop ups, etc.).</p>
-
-#### Test Instructions
-
-<ol id="d2cTI">
-    <li id="d2cTI-1">Use the keyboard to move focus to and navigate through each interactive document component (including form drop-down lists and form fields).</li>
-    <li id="d2cTI-2">Check that when a document component receives focus, it does not initiate an unexpected change of context. [SC 3.2.1]
-        <ul>
-            <li>Forms submitted automatically when a component receives focus</li>
-            <li>New document window or browser launched when a component receives focus</li>
-            <li>Focus is moved to another component</li>
-        </ul>
-    </li>
-</ol>
-
-#### Test Results
-
-<p id="d2cTR">If any of the above checks fail, then Baseline Test 2.C-OnFocus fails.</p>
-
-### Advisory: Tips for Streamlined Test Processes
-
--   The clarity of visible focus is subjective, and the minimum level is the application's (or OS platform's) default display setting for indicating focus. Applications may also represent visual focus differently in specific situations.
--   This test may be performed simultaneously with [Baseline 1: Keyboard Access]({{site.baseurl}}/document-baselines/01KeyboardDocs).
--   No focus modifications should be enabled in the test environment during testing. Some testing tools will add a visible outline around elements that receive focus. While testing tools may help testers to track focus, any markup provided by a testing tool should not be used as an indicator of visible focus for meeting this requirement.
--   Given the variability in how applications may present visual focus in specific situations, test reports should include details about testing environment, including application and version.
--   Tab order that initially appears illogical may still meet this requirement due to an application-specific business logic.
--   It may be useful to combine these tests with tests for keyboard navigation and visible focus.
--   It may be useful to provide instructions about what "modal dialog boxes" are and how they should behave.
-
-### WCAG 2.2 Techniques
-
-The following sufficient techniques and/or common failures were considered when developing this test procedure for this baseline requirement:
-
--   [F55: Failure of Success Criteria 2.1.1, 2.4.7, and 3.2.1 due to using script to remove focus when focus is received](https://www.w3.org/WAI/WCAG22/Techniques/failures/F55)
--   [F85: Failure of Success Criterion 2.4.3 due to using dialogs or menus that are not adjacent to their trigger control](https://www.w3.org/WAI/WCAG22/Techniques/failures/F85) in the sequential navigation order
--   [G59: Placing the interactive elements in an order that follows sequences and relationships within the content](https://www.w3.org/WAI/WCAG22/Techniques/general/G59)
--   [G107: Using "activate" rather than "focus" as a trigger for changes of context](https://www.w3.org/WAI/WCAG22/Techniques/general/G107)
--   [G149: Using user interface components that are highlighted by the user agent when they receive focus.](https://www.w3.org/WAI/WCAG22/Techniques/general/G149)
--   [G165: Using the default focus indicator for the platform so that high visibility default focus indicators will carry over](https://www.w3.org/WAI/WCAG22/Techniques/general/G165)
--   [G195: Using an author-supplied, highly visible focus indicator](https://www.w3.org/WAI/WCAG22/Techniques/general/G195)
--   [SCR26: Inserting dynamic content into the Document Object Model immediately following its trigger element](https://www.w3.org/WAI/WCAG22/Techniques/client-side-script/SCR26)
--   [PDF3: Ensuring correct tab and reading order in PDF documents](https://www.w3.org/WAI/WCAG22/Techniques/pdf/PDF3)