Updates from editorial work in October

README.md

@@ -225,7 +225,7 @@ Your content here
 :::
 ```
 
-### Applies when
+#### Applies when
 
 The following block will be preceded by "Applies when".
 This is _only_ valid within requirements.
@@ -238,7 +238,7 @@ a condition is true.
 
 The label. "Applies when", will be appended before the first paragraph of the block. If the first content item is anything other than a paragraph (e.g. if the block only contains a list), it will appear in a separate paragraph before the content.
 
-### Except when
+#### Except when
 
 The following block will be preceded by "Except when".
 This is _only_ valid within requirements.
@@ -251,6 +251,22 @@ a condition is true.
 
 This follows the same behavior as `:::applies-when` regarding single paragraphs vs. other cases.
 
+#### Assertions replacements
+
+The following leaf directives are to be used before required and recommended documentation to be included for assertions:
+
+```
+::assertion-required
+- List item
+- ...
+
+::assertion-recommended
+- List item
+- ...
+```
+
+Note that these are leaf directives, not container directives, so there is no end marker.
+
 #### Glossary Term References
 
 The text inside `:term[...]` will be transformed into a link referencing a term in the glossary,

custom-words.txt

@@ -20,3 +20,4 @@ mouseup
 numeronym
 numeronyms
 strobing
+TOTP

guidelines/groups/animation-and-movement/avoid-physical-harm/avoid-flashing.md

@@ -1,6 +1,21 @@
 ---
-status: developing
+title: Avoid flashing
 type: foundational
+status: developing
 ---
 
-:term[Content] does not include non-essential :term[flashing] or strobing beyond flashing thresholds.
+:term[Content] does not include non-essential :term[flashing].
+
+:::ednote
+Method(s)
+* Consider if flashing is essential, and if it is not, refrain from including it.
+:::
+
+:::tests
+<b>Procedure</b>
+1. Identify any content that includes flashing.
+2. Verify that, for each instance of flashing, the flashing is essential.
+
+<b>Expected Results</b>
+* #2 is true
+:::

guidelines/groups/consistency-across-views/consistency.md

@@ -1,8 +1,8 @@
 ---
 children:
-  - consistent-navigation
-  - multiple-ways
-  - persistent-navigation
+  - consistent-relative-order
+  - consistent-navigation-relative-order
+  - consistent-navigation-terminology
 ---
 
 Users have consistent and alternative :term[methods] for navigation.

guidelines/groups/consistency-across-views/consistency/consistent-navigation-relative-order.md

@@ -0,0 +1,22 @@
+---
+title: Consistent navigation relative order
+type: supplemental
+status: developing
+---
+
+The relative order of navigation items is consistent within blocks of navigation that are repeated on multiple pages/views of the product or process
+
+:::ednote
+This relates to consistency and terminology within blocks of navigation. The consistent ordering of blocks of navigation within a page/view is covered by 'Consistent relative order'.
+:::
+
+:::tests
+<i>Consistent main navigation relative order</i>
+
+<b>Procedure</b>
+1. Identify repeated blocks of navigation across multiple pages/views of the product or process.
+2. Verify that the navigation items within each block of navigation have the same relative order across all pages/views of the product or process.
+
+<b>Expected Results</b>
+* #2 is true
+:::

guidelines/groups/consistency-across-views/consistency/consistent-navigation-terminology.md

@@ -0,0 +1,26 @@
+---
+title: Consistent navigation terminology
+type: foundational
+status: developing
+---
+
+The labelling of navigation items within blocks of navigation that are repeated on multiple pages/views of the product or process is consistent.
+
+:::except-when
+* Labels for navigation items that are marked as 'current' within the product or process.
+:::
+
+:::ednote
+This relates to consistency and terminology within blocks of navigation. The consistent ordering of blocks of navigation within a page/view is covered by 'Consistent relative order'.
+:::
+
+:::tests
+<i>Consistent main navigation labels</i>
+
+<b>Procedure</b>
+1. Identify repeated blocks of navigation across multiple pages/views of the product or process.
+2. Verify that the navigation items within each block of navigation have the same names across all pages/views of the product or process. 
+
+<b>Expected Results</b>
+* #2 is true
+:::

guidelines/groups/consistency-across-views/consistency/consistent-relative-order.md

@@ -0,0 +1,22 @@
+---
+title: Consistent relative order
+type: foundational
+status: developing
+---
+
+The relative order of :term[structural components] remains consistent throughout each specific :term[variation of product or process].
+
+:::note
+Relative order means that content can be added or removed, but repeated items are in the same order relative to each other.
+:::
+
+:::tests
+<i>Consistent relative order for website</i>
+
+<b>Procedure</b>
+1. For each variation of the product in scope, identify common structural components across multiple pages/views.
+2. For each variation of the product in scope, verify that components are presented in the same order within each page/view.
+
+<b>Expected Results</b>
+* #2 is true
+:::

guidelines/groups/error-handling/correct-errors.md

@@ -1,15 +1,14 @@
 ---
 children:
   - error-notification
-  - error-cause-identified
-  - descriptive-errors
-  - error-cause-in-notification
-  - error-suggestion
   - error-visibility
-  - error-persists
-  - error-cause-association
-  - error-linked
+  - input-errors
+  - error-suggestion
   - error-location
+  - error-persists
+  - error-prevention
 ---
 
 Users know about and can correct errors.
+
+

guidelines/groups/error-handling/correct-errors/error-location.md

@@ -3,4 +3,14 @@ status: developing
 type: supplemental
 ---
 
-Error messages are visually collocated with the error source.
+Error messages are visually collocated with the error source or the focus is moved to the error message and a mechanism is available to move to the input that is in error. 
+
+:::tests
+<b>Procedure</b>
+1. Zoom in 400%
+2. Trigger errors
+3. Make sure the error is visible next to the trigger or that the focus moves to the error. 
+
+<b>Expected Results</b>
+* #3 is true
+:::

guidelines/groups/error-handling/correct-errors/error-notification.md

@@ -3,4 +3,18 @@ status: developing
 type: foundational
 ---
 
-When an error is detected, users are notified visually and programmatically that an error has occurred.
+Errors that can be automatically detected are identified and the problem is clearly described to the user.
+
+:::note
+Examples of errors include invalid form input, server errors or application errors.
+:::
+
+:::tests
+<b>Procedure</b>
+1.Identify parts of the conformance scope where errors can occur.
+2. Trigger errors.
+3. For each error, verify that the nature of the problem is identified and described
+
+<b>Expted results</b>
+* #3 is true for each error.
+:::

guidelines/groups/error-handling/correct-errors/error-persists.md

@@ -3,4 +3,21 @@ status: developing
 type: foundational
 ---
 
-Error messages persist until the user dismisses them or the error is resolved.
+Error messages persist at least until the error is resolved or the user dismisses them.
+
+:::ednote
+Methods & best practices 
+* Method: Keep track of the state of the error and make visibility of the error message depending on this state.
+* Method: In a form, revalidate all fields when the form is submitted and remove all error messages that are no longer relevant.
+* Method: Add a "Dismiss" button to the error that makes the error message disappear.
+* Best Practice: [1-2 sentence description or a link to an example] 
+:::
+
+:::tests
+<b>Procedure</b>
+1. Identify the error messages. 
+2. Verify that the error messages persist until the user fixes the error or dismisses the message. 
+
+<b>Expected Results</b>
+* #2 is true
+:::

guidelines/groups/error-handling/correct-errors/error-prevention.md

@@ -0,0 +1,13 @@
+---
+status: developing
+type: foundational
+---
+
+Data entry allows users to do at least one of the following before submission:
+
+* Review, confirm, and correct all information; or
+* Review and correct input errors found during validation.
+
+:::except-when
+data submission is auto-saved and/or reversible.
+:::

guidelines/groups/error-handling/correct-errors/error-suggestion.md

@@ -3,4 +3,17 @@ status: developing
 type: foundational
 ---
 
-Error messages include suggestions for corrections that can be automatically determined, unless it would jeopardize the security or purpose of the :term[content].
+Error messages include suggestions for corrections.
+
+:::except-when
+it would jeopardize the security or purpose of the :term[content].
+:::
+
+:::tests
+<b>Procedure</b>
+1. Review all error messages.
+2. Verify that the error messages include suggestions for how to fix the error.
+
+<b>Expected Results</b>
+* #2 is true
+:::

guidelines/groups/error-handling/correct-errors/error-visibility.md

@@ -3,12 +3,17 @@ status: developing
 type: foundational
 ---
 
-Error messages are visually identifiable including at least two of the following:
+Error messages are visually identifiable using at least two of the following:
 
-* A symbol.
+* An internally consistent symbol.
 * Color that differentiates the error message from surrounding :term[content].
-* Text that clearly indicates this is an error.
+* Text that clearly indicates the error.
 
-:::note
-Symbols and colors signifying errors vary depending on cultural context and should be modified accordingly.
+:::tests
+<b>Procedure</b>
+1. Identify all validation errors.
+2. Verify that they meet at least two of the listed requirements.
+
+<b>Expected results</b>
+* #2 is true
 :::

guidelines/groups/error-handling/correct-errors/input-errors.md

@@ -0,0 +1,23 @@
+---
+status: developing
+type: foundational
+---
+
+When input validation fails, the errors are visually and programmatically associated with the element that caused the error or that can resolve it.
+
+:::note
+Examples of failing validation:
+
+- When input is required and the field is left empty.
+- When the user input does not meet the requested format.
+:::
+
+:::tests
+<b>Procedure</b>
+1. Identify validation errors.
+2. Verify that validation errors are indicated visually.
+3. Verify that validation errors are indicated programmatically.
+
+<b>Expected Results</b>
+* #2 and #3 are true.
+:::

guidelines/groups/image-and-media-alternatives/captions/adaptable-captions.md

@@ -3,4 +3,4 @@ type: foundational
 status: developing
 ---
 
-The appearance of :term[captions], including associated visual indicators, is adaptable including font size, font weight, font style, font color, background color, background transparency, and placement;
+The appearance of :term[captions], including associated visual indicators, is adaptable including font size, font weight, font style, font color, background color, background transparency, and placement.