arc-templated-issues 1.0.0

package/public/web-issue-templates.md

@@ -0,0 +1,912 @@
+# ARC Web Accessibility Issue Templates
+
+> Generated on 2026-04-03
+
+---
+
+# Control lacks a label in the code
+
+## Severity
+1-Critical
+
+## Suggested Priority
+Blocker
+
+-------- copy below ---------
+
+[URL/Path]
+######
+
+[Steps to reproduce]  
+######
+
+[Element] 
+The ##### located ##### 
+
+[What is the issue] 
+The ###### control lacks a label in the code making it difficult for screen reader users to understand its purpose. A meaningful label is not announced. 
+
+[Why it is important] 
+Accessible labels provide critical information about a button’s purpose, enabling users of assistive technologies [such as voice recognition and screen readers] to navigate and interact with the application effectively. Without labels, users may face difficulties understanding what actions buttons will perform, leading to frustration and limited functionality. 
+
+[Code reference] 
+(## Tester note: grab code snippet from experience and delete me ##) 
+{code:html} 
+<button></button> 
+{code} 
+
+[How to fix] 
+Ensure that the control has an accessible label. There are many ways this is defined in the code. The control’s nested text or alternative text of images within controls can be used as the accessible name of the control.  
+
+When on-screen text is not available, authors can use another method to provide an accessible name, such as by using {{aria-labelledby}}, {{aria-label}}, or {{title}} attribute (not recommended in all cases), to provide the accessible name. The {{aria-labelledby}} attribute must contain one or more IDs of elements that label the button. The aria-label attribute is best when there is no on-screen label. Authors should place the string that labels the form field in the aria-label attribute.  
+
+Authors can also identify an accessible name using an associated label element whenever an on-screen label is present. The label element's value is then explicitly associated with the relevant form field using the for and {{ID}} attributes. Use of the label element provides an added benefit as it increases the target area that users can click to focus the form field.  
+
+[Compliant code example] 
+(## Tester note: include real code example or just leave generic examples below and delete me ##) 
+{code:html} 
+<button>My Account</button> 
+{code} 
+
+{code:html} 
+<a href=”/facebook” aria-label=”Facebook”><svg>...</svg></button> 
+{code} 
+
+{code:html} 
+<span id=”example”>Some text</span> 
+<a href=”/facebook” aria-labelledby=”example”><svg>...</svg></button> 
+{code} 
+
+[How to test] 
+Screen reader testing: Use a screen reader to navigate to the control and verify that the correct label is announced. 
+
+Visual inspection: Ensure the button has a clear, descriptive label. Check that either {{aria-label}}, {{aria-labelledby}}, or {{title}} are present in the code, and that the label reflects the button's purpose.  
+
+Use the Chrome DevTools Accessibility Inspector to verify that the Name property has been properly calculated.  Open DevTools > Choose Accessibility Pane > Inspect element > review Computed Properties
+
+[MagentaA11y] 
+https://www.magentaa11y.com/how-to-test/link-button/ 
+https://www.magentaa11y.com/checklist-web/link/ 
+https://www.magentaa11y.com/checklist-web/button/ 
+
+[WCAG] 
+(## Tester note: Choose or add and delete me ##)
+2.4.4: Link Purpose (In Context) (A) 
+2.4.6: Headings and Labels (AA) 
+2.5.3: Label in Name (AA) 
+4.1.2 Name, Role, Value (A)
+
+[Operating system] 
+######
+
+[Browser]
+######
+
+[Assistive technology] 
+Keyboard
+
+---
+
+# Heading levels incorrectly nested
+
+## Severity
+3-Average
+
+## Suggested Priority
+Medium
+
+-------- copy below ---------
+
+[URL/Path]
+######
+
+[Steps to reproduce]  
+######
+
+[Element] 
+(## Tester note: Describe where the heading is in the UI and delete me  ##)
+
+[What is the issue] 
+The following heading level nesting example does not meet the requirements for logically structured heading hierarchy: 
+
+The heading levels on this page are incorrectly nested, meaning that headings do not follow a logical order. For example, a {{<h3>}} may appear before a {{<h2>}}, or a {{<h4>}} may follow a {{<h2>}} without an appropriate {{<h3>}} in between. This disrupts the hierarchical structure of the page and makes it harder for users to understand the page content and navigate effectively.
+
+[Why it is important]
+Proper heading structure is crucial for accessibility as it helps assistive technologies, such as screen readers, understand and convey the relationships between different sections of content. Incorrectly nested headings can confuse users, making it difficult for them to grasp the organization of the page. This issue impacts people who rely on headings for navigation, especially those using screen readers or keyboard navigation, preventing them from efficiently moving through content. WCAG 1.3.1 (Info and Relationships) requires that information, structure, and relationships be conveyed clearly.
+
+[Code reference] 
+(## Tester note: CSS code references can be helpful here – delete me ##)
+{code:css}
+... 
+{code}
+
+[How to fix]  
+
+Ensure that heading levels are used in a logical, hierarchical order. For example:
+
+- An {{<h1>}}  should be the first heading on the page.
+
+- {{<h2>}} headings should follow {{<h1>}}, and {{<h3>}} should follow {{<h2>}}.
+
+- Do not skip heading levels (e.g., {{<h1>}} skipping to {{<h3>}} is incorrect; it should be {{<h1>}} then {{<h2>}} then {{<h3>}}).
+
+- A single heading should not use multiple levels of nested heading elements (e.g., {{<h1>}}T-Mobile {{<h3>}}iPhone Deals{{/h3}}{{/h1}} is incorrect; it should be simplified to use a single heading level {{<h1>}}T-Mobile iPhone Deals {{</h1>}}), and inner text can font sizing and styling be further customized using CSS styles.
+
+Use the correct HTML elements for headings: {{<h1>}}, {{<h2>}}, {{<h3>}}, etc. Avoid using styling (like font size) alone to create the appearance of a heading.
+
+Repeating patterns of headings are allowed so long as they follow a logical sequence (example: {{<h2>}},{{<h3>}},{{<h2>}},{{<h3>}})
+
+[Compliant code example]
+(## Tester note: n/a here if not applicable and is a design change and delete me ##)
+{code:html} 
+
+<h1>My favorite taco recipe</h1>
+
+<!-- Author's entire life story as it relates to tacos -->
+
+<h2>Ingredients</h2>
+
+<!-- List of ingredients -->
+
+<h2>Steps</h2>
+
+<h3>Preparing the protein</h3>
+
+<!-- List of instructions -->
+
+<h3>Preparing the vegetables</h3>
+
+<!-- List of instructions -->
+
+<h3>Assembly and plating</h3>
+
+<!-- List of instructions-->
+
+<h2>Nutrition information</h2>
+
+<!-- List of nutrition info -->
+
+<h2>Related recipes</h2>
+
+<!-- List of related recipes -->
+{code}
+
+[How to test]
+
+Automated:
+- Use an accessibility testing tool such as Axe DevTools or the Level Access extension to detect any heading structure issues. These tools will flag incorrect nesting of heading levels.
+
+- Follow-up with manual verification of the heading hierarchy in the HTML source code. (See Manual checks below.)
+
+Manual:
+
+- Inspect the page's HTML code to check the order of the heading elements (<h1>, <h2>, <h3>, etc.).
+
+- Navigate through the page using a screen reader or keyboard shortcuts (e.g., arrow keys or heading shortcut keys) to verify that headings are in a logical order and the page content is easy to understand.
+
+- Review the document structure using browser developer tools to ensure headings follow the correct hierarchy.
+
+[MagentaA11y] 
+
+https://www.magentaa11y.com/checklist-web/heading/
+
+[Resources]
+
+https://www.w3.org/WAI/tutorials/page-structure/headings
+
+[WCAG] 
+1.3.1 Info and Relationships (Level A)
+
+[Operating system] 
+######
+
+[Browser]
+######
+
+[Assistive technology] 
+######
+
+---
+
+# Images should be marked as decorative
+
+## Severity
+Low
+
+## Suggested Priority
+Low
+
+-------- copy below ---------
+
+[URL/Path]
+######
+
+[Steps to reproduce]  
+######
+
+[Element] 
+(## Tester note: Describe where the thing is in the UI and delete me ##) 
+
+[What is the issue] 
+The (## Tester note: describe image here – delete me ##) image/icon does not provide meaningful information, however, it is not marked as decorative. 
+
+[Why it is important] 
+When images are not properly marked as decorative, screen readers may announce them unnecessarily. This creates noise, cognitive overload, or potentially conveys incorrect information for users who are blind or rely on assistive technologies. Properly marking images as decorative ensures the images are skipped by assistive technologies, which provides a cleaner overall experience for screen reader users.
+
+[Code reference] 
+(## Tester note: CSS code references can be helpful here – delete me ##)
+{code} 
+... 
+{code}
+
+[How to fix]  
+
+Ensure standard {{<img>}} elements have an empty {{alt=””}} attribute or {{alt (null)}}.
+Ensure {{<svg>}}  elements have {{aria-hidden=”true” focusable="false"}} attributes. 
+[Compliant code example] 
+(## Tester note: n/a here if not applicable and is a design change and delete me ##)
+{code:html}
+
+ <img src="image.jpg" alt="">
+
+{code}
+
+{code:html}
+
+<svg aria-hidden="true">...</svg>
+
+{code}
+
+[How to test] 
+
+Automated: Use an automated scanning tool like Axe, Level Access, or Lighthouse to scan for images that are missing {{alt}} attributes. Decorative images still require an empty {{alt}} attribute, so if an image is missing an {{alt}} attribute all together it will be flagged by a scanner. A scanner will not flag images that should be treated as decorative, so manual testing is necessary.
+
+
+Manual: Use a screen reader (e.g., NVDA, JAWS, VoiceOver) to navigate to images on the page with your arrow keys, or try jumping directly to images with the NVDA/JAWS keyboard shortcut key {{G}}, or Voiceover keyboard shortcut keys {{VO key + Command + G}}. Ensure decorative images are being skipped over and not announced by the screen reader.
+
+[MagentaA11y] 
+www.magentaa11y.com/checklist-web/image-decorative/
+
+www.magentaa11y.com/how-to-test/images/
+
+[WCAG] 
+1.1.1 Non-Text Content (A)
+
+[Operating system] 
+######
+
+[Browser]
+######
+
+[Assistive technology] 
+JAWS
+NVDA
+VoiceOver
+
+[Additional Resources]
+
+https://www.w3.org/WAI/tutorials/images/decision-tree/
+
+---
+
+# Interactive element is not keyboard accessible
+
+## Severity
+1-Critical
+
+## Suggested Priority
+Blocker
+
+-------- copy below ---------
+
+[URL/Path]
+######
+
+[Steps to reproduce]  
+######
+
+[Element] 
+The ##### button located #####
+
+[What is the issue] 
+(## Tester note: choose one and delete me ##)
+The ###### is not keyboard accessible. Keyboard users are not able to reach the control in any way or activate it. 
+
+The ###### is not keyboard accessible. Keyboard users are able to reach the control, but nothing happens when those users try to activate the control.  
+
+[Why it is important]
+All functionalities must be operable using only a keyboard or similar input method. Some users rely exclusively on keyboards, screen readers, or alternative input devices, such as switch controls or adaptive keyboards, to navigate and interact with websites. Ensuring that all interactive elements, such as buttons, links, and form controls, can be accessed and activated via keyboard is very important for accessibility. Users with mobility or dexterity-related disabilities as well as screen reader users will benefit from keyboard accessible interfaces.
+
+[Code reference] 
+(## Tester note: show actual code and delete me ##)
+{code:html} 
+... 
+{code} 
+
+[How to fix]  
+- Ensure that all interactive elements are keyboard operable and allow for keyboard focus. Keyboard users should be able to tab to the control and activate it with the keyboard alone.  
+- Use an element that is naturally focusable such as a {{<button>}} or {{<a>}}. 
+- In cases where a negative {{tabindex}} has been used, remove {{tabindex="-1"}} from the element. 
+- Ensure the button does not own {{aria-hidden="true"}} 
+- Ensure anchor tags / links own valid {{href}} attribute values.
+
+[Compliant code example] 
+(## Tester note: show a real code fragment here or use generic examples below and delete me ##)
+{code:html} 
+<button>My Account</button> 
+{code}
+
+{code:html} 
+<a href=”/some-page”>Learn more about MagentaA11y</a> 
+{code}
+
+[How to test]
+Keyboard: Using the keyboard alone, tab to the control. Focus should move to the control. Try activating the control, the control should work with the enter key and spacebar if it is a button and just the enter key if it is a link.
+
+Manual inspection: Using Chrome DevTools, inspect the control and verify that the {{tabindex=”-1”}} and {{aria-hidden=”true”}} attributes are not present.
+
+[MagentaA11y]
+https://www.magentaa11y.com/how-to-test/keyboard-focus/ 
+https://www.magentaa11y.com/checklist-web/button/ 
+https://www.magentaa11y.com/checklist-web/link/ 
+
+[WCAG]
+(## Tester note: Choose or add and delete me ##)
+2.1.1 Keyboard (A) 
+2.4.3 Focus Order (A)
+
+[Operating system] 
+######
+
+[Browser]
+######
+
+[Assistive technology] 
+Keyboard
+
+---
+
+# [WIP] Link text is not descriptive or lacks purpose
+
+## Severity
+3-Average
+
+## Suggested Priority
+Medium
+
+(## Tester note: review guidance prior to logging issue ##)
+
+1) 1.3.1 Information & Relationships does NOT apply to buttons. Buttons can have repetitive names on the same page as long as they are doing the same action. Always inspect the code to learn whether something is coded as a link or button in HTML. `role="button"` on a link counts as a Button.
+
+2) If the link is nested within its related content within the same list item {{<li>}}, {{<p>}}, or table cell {{<td>}} then the link has programmatic determination and satisfies 1.3.1 Information & Relationships.
+
+-------- copy below ---------
+
+[URL/Path]  
+######
+
+[Steps to reproduce]  
+######
+
+[Element] 
+(## Tester note: Describe where the thing is in the UI and delete me ##)
+
+[What is the issue] 
+The ###### link text is not descriptive enough to convey its purpose or destination. For example, links such as "Shop now", "Buy now", "Click here", or "Read more" lack context when read independently.
+
+[Why it is important]  
+Descriptive link text improves navigation for all users, especially for people using assistive technologies such as screen readers. These users often navigate links out of context, so the purpose of each link must be clear without relying on surrounding content.
+
+When multiple links on a screen have the same visible text label but different targets, then providing distinguishing context becomes very important.
+
+Voice Recognition users benefit from having meaningful link purpose in the code so that they can activate controls by voice alone. Imagine saying "click 'Learn more'" and seeing that there are 6 options for voice control to choose from. This is the equivalent of making someone do multiple clicks to perform a single action!!
+
+[Code reference]  
+(## Tester note: CSS code references can be helpful here – delete me ##)
+{code:html}
+...
+{code}
+
+[How to fix]  
+Update the link text to describe the link's purpose or destination. For example, replace "Buy Now" with "Buy our new iPhone 93 Pro" or "Learn more about our services." Ensure that links with identical destinations have consistent text. Avoid overly verbose descriptions. This may be a content change so partner with design or key stakeholders before changing copy.
+
+If the generic link text itself cannot be changed then apply a code-based fix such as proper use of {{aria-describedby}}, {{aria-label}}, {{aria-labelledby}} so that context is included in the link's label in the code.
+
+If the link is pointing to files like PDF or opening pages in new windows, it is best practice to include this information within the link's accessible name in some way.
+
+[Compliant code example]  
+(## Tester note: tester can leave these generic examples in place or author a tailored solution based on the Code Reference (preferred) ##)
+
+**aria-label:** {{aria-label}} attribute value includes the visible text and it is front-loaded followed by a comma and then the additional context which should match nearby text and be super meaningful.
+{code:html}
+<h2>iPhone 24 Pro</h2>
+<a href="#" aria-label="Buy now, iPhone 24 Pro">Buy Now</a>
+{code}
+
+**aria-describedby:** Nearby text content is programmatically associated.
+{code:html}
+<h2 id="unique-id-0">Some cool heading</h2>
+<a href="#" aria-describedby="unique-id-0">Buy Now</a>
+{code}
+
+**aria-labelledby:** The control itself is referenced as well as other nearby content via {{aria-labelledby}}.
+{code:html}
+<h2 id="unique-id-0">Some cool heading</h2>
+<a href="#" aria-labelledby="unique-id-1 unique-id-0" id="unique-id-1">Buy Now</a>
+{code}
+
+**Link to file:**
+{code:html}
+<a href="#">Download the awesome manual (PDF)</a>
+{code}
+
+**Opens in a new window:**
+{code:html}
+<a href="#" aria-label="Learn more, iPhone 24 Pro, opens in a new window">Learn More</a>
+{code}
+
+[How to test]  
+Automated: Use tools such as Axe DevTools or the Level Access extension to identify links with generic text.
+
+Manual:
+- Review all links and ensure the text clearly conveys their purpose out of context.
+- Using Chrome DevTools Accessibility Inspector, inspect the link in the HTML. The Name property value in Computed Properties (in conjunction with any Description property text) should be meaningful.
+- Use a screen reader to navigate the page by links (e.g., NVDA's "Links List"). Confirm the text is descriptive and unambiguous.
+
+[MagentaA11y]  
+https://www.magentaa11y.com/checklist-web/link/
+
+[Resources]
+######
+
+[WCAG]  
+2.4.4 Link Purpose (In Context) (A)
+2.5.3 Label in Name (A)
+
+[Operating system]  
+######
+
+[Build Version]
+######
+
+[Browser]
+######
+
+[Assistive technology]  
+JAWS
+NVDA
+VoiceOver
+TalkBack
+
+---
+
+# [WIP] Non-text content does not meet required 3:1 contrast
+
+## Severity
+2-Severe
+
+## Suggested Priority
+High
+
+-------- copy below ---------
+
+[URL/Path]
+######
+
+[Steps to reproduce]  
+######
+
+[Element] 
+(## Tester note: Describe where the thing is in the UI and delete me ##)
+
+The ##### located at #####
+
+[What is the issue] 
+The ###### lacks 3:1 contrast which is required for non-text content that is important, informative, and contains context (aka not decorative).
+
+[Color reference] 
+(## Tester note: fill out hex codes for XXXXXX which is the foreground or non-text content color and YYYYYY which is the background or adjacent color ##)
+
+Non-text content color XXXXXX fails 3:1 contrast against YYYYYY background.
+https://webaim.org/resources/contrastchecker/?fcolor=000000&bcolor=FFFFFF
+
+[Why it is important]  
+Non-text content such as icons, images of text, graphics, etc. that contain important information must have contrast in order for the most possible users to be able to see them. High contrast helps users with vision disabilities such as low vision users, as well as color vision deficiencies such as red-green color blindness, blue-yellow color blindness, and complete color blindness. 3:1 contrast is actually about calculating the hue contrast such that even if you cannot make out color at all, the lightness/darkness of the colors will be sufficient for a user to tell them apart.
+
+[How to fix]  
+Refer to the WebAIM Contrast checker — https://webaim.org/resources/contrastchecker/?fcolor=000000&bcolor=FFFFFF — to find a color that will have 3:1 contrast.
+
+Consider TDDS color schemes as well: https://www.figma.com/design/HIvbo95KykcH9kuhwcVgky/1.-Foundations?node-id=1-480151&p=f&m=dev
+
+Note: Fix will likely require consultation with a designer to find a branded and TDDS compliant color.
+
+[Compliant code example]
+n/a — this is typically a design change
+
+[How to test]  
+Automated:
+- Run an automated scan tool such as LevelAccess, Axe, or Lighthouse. Note, however, that these tools regularly miss these types of contrast issues. Manual evaluation is recommended.
+- Input hex codes into WebAIM Contrast checker — https://webaim.org/resources/contrastchecker/?fcolor=000000&bcolor=FFFFFF — to verify contrast is less than 3:1.
+
+Manual:
+- Open DevTools in your browser window (F12)
+- Right-click and select "Inspect" on the different color combinations that you see as you move from the top of the page on down
+- Find the hexadecimal color values in the "Styles" tab of your DevTools window
+- Enter the hex values into a contrast checking tool (like WebAIM Contrast Checker or Deque's Color Contrast Analyzer) to verify if the contrast is less than 3:1.
+
+[MagentaA11y] 
+https://www.magentaa11y.com/how-to-test/color-contrast/
+
+[Resources]
+Figma contrast checker: https://www.figma.com/community/plugin/732603254453395948/stark-contrast-accessibility-checker
+
+[WCAG]  
+1.4.11 Non-text Contrast (AA)
+
+[Operating system]  
+######
+
+[Build Version]
+######
+
+[Browser]
+######
+
+[Assistive technology]
+######
+
+---
+
+# [WIP] Screen reader focus is not retained while navigating between modal views
+
+## Severity
+2-Severe
+
+## Suggested Priority
+High
+
+-------- copy below ---------
+
+[URL/Path]  
+######
+
+[Steps to reproduce]  
+######
+
+[Element] 
+(## Tester note: Describe where the thing is in the UI and delete me ##)
+
+[What is the issue] 
+When screen reader users activate the **"[placeholder name]"** button inside a modal, which updates the content within the modal, screen reader focus is not retained within the modal. Instead, focus often lands outside the modal container — typically on the `<body>` — causing screen reader users to unintentionally navigate the page behind the modal when using arrow keys.
+
+(## Tester note: delete this section if not applicable ##) The same issue occurs when the "back" chevron icon button is used to return to the previous modal view. Focus is not retained within the modal.
+
+[Why it is important]  
+Screen reader users rely on logical, programmatically managed focus to stay oriented within dynamic components like modals. If focus is not explicitly managed during view or content changes inside a modal, or when changing to a new modal, users may unknowingly leave the modal context, leading to confusion and difficulty completing tasks. This breaks expected modal behavior.
+
+[Code reference]
+(## Tester note: grab code snippet from experience and delete me ##)
+{code:html}
+...
+{code}
+
+[How to fix]  
+Ensure that when a user clicks the **"[placeholder name]"** button to change the view within the modal or launch another modal, programmatic focus is set to the top-level heading of the newly shown view (e.g., using `.focus()` on the `<h2>`). If there is no heading present on the view, focus can be set to whatever the first interactive element in the modal is, ideally a back or close button. Apply the same approach when changing the modal view with the "back" chevron icon button. This ensures screen reader users remain in the intended modal context.
+
+[Compliant code example]
+(## Tester note: Choose to add or delete this section if not working in Phoenix/AEM environment ##)
+
+While this isn't the only solution, this is a sample fix that has been implemented to resolve the issue for a Phoenix/AEM multi-view modal:
+{code:html}
+/**
+ * Set focus on the heading when the content changes while navigating between promo list to promo details and vice versa.
+ *
+ * @param visibilityScopeIdTarget - The ID of the visibility scope target to set focus on.
+ */
+manageFocus(visibilityScopeIdTarget?: string): void {
+  let focusTarget: HTMLElement;
+
+  if (visibilityScopeIdTarget) {
+    focusTarget = document.querySelector(`[data-xpr-visibility-scope="${visibilityScopeIdTarget}"]`) as HTMLElement;
+  } else {
+    focusTarget = this.component;
+  }
+  const headings: HTMLHeadingElement[] = Array.from(focusTarget?.querySelectorAll(':is(h1,h2,h3,h4,h5,h6)') || []);
+  // Find the first visible heading
+  const el = headings.find((heading) => {
+    return heading.offsetParent !== null && heading.offsetHeight > 0 && heading.offsetWidth > 0;
+  }) as HTMLElement | null;
+
+  if (el) {
+    el.setAttribute('tabindex', '-1');
+    el.focus();
+  } else {
+    (this.component?.closest('.phx-modal') as HTMLElement)?.focus();
+  }
+},
+
+  setTimeout(() => {
+    this.manageFocus();
+  }, 100);
+{code}
+
+[How to test]
+Automated: Automated tools like Chrome's Lighthouse scanner will not detect this issue. Focus management during modal transitions should be tested manually with a screen reader.
+
+Manual:
+- Open the modal and activate the **"[placeholder name]"** button to change the view.
+- With NVDA or JAWS in browse mode, press the arrow keys after the view changes.
+- Confirm that arrow key navigation starts at the new modal content and does not land outside the modal or on the main page.
+- Activate the back button and repeat the test.
+
+[MagentaA11y]
+######
+
+[Resources]
+######
+
+[WCAG]  
+2.4.3 Focus Order (A)
+
+[Operating system]  
+Windows
+
+[Build Version]
+######
+
+[Browser]
+Chrome
+Firefox
+Edge
+
+[Assistive technology]  
+JAWS
+NVDA
+
+---
+
+# [WIP] Semantic meaning of a heading is not conveyed to a screen reader user
+
+## Severity
+3-Average
+
+## Suggested Priority
+Medium
+
+-------- copy below ---------
+
+[URL/Path]  
+######
+
+[Steps to reproduce]  
+######
+
+[Element] 
+(## Tester note: Describe where the thing is in the UI and delete me ##)
+
+[What is the issue] 
+A screen reader user does not know that a heading exists on the page because it is not coded with semantic HTML such as h1|h2|h3|h4|h5|h6. The heading is visually conveyed, but a screen reader user misses out on the same meaning, information, and hierarchy of relationships.
+
+The semantic meaning of a heading is not conveyed to a screen reader user through HTML. This can happen when headings are marked up improperly (e.g., using non-semantic elements like `<div>` or `<span>` instead of proper tags like `<h1>` through `<h6>`).
+
+[Why it is important]
+Headings give a page a clear and logical structure, helping users of screen readers navigate and understand the content hierarchy. If the semantic HTML meaning is not conveyed correctly, users may struggle to comprehend the page structure.
+
+Screen reader users also often make use of keyboard shortcuts to skip around only the headings on a page to learn more about the content overview quickly and efficiently. When HTML headings are missing, it reduces their ability to interact with the site.
+
+[Code reference]  
+(## Tester note: CSS code references can be helpful here – delete me ##)
+{code:css}
+...
+{code}
+
+[How to fix]  
+Ensure all headings use the appropriate HTML heading tags (`<h1>`, `<h2>`, `<h3>`, etc.) for structuring the content.
+
+Do not use non-semantic elements like `<div>` or `<span>` for headings.
+
+The heading hierarchy should be logical, with the `<h1>` being the most important and subsequent headings `<h2>`, `<h3>`, etc., used in a meaningful and logical order.
+
+[Compliant code example]  
+(## Tester note: n/a here if not applicable and is a design change and delete me ##)
+{code:html}
+...
+{code}
+
+[How to test] 
+Automated:
+Use an accessibility testing tool (e.g., Level Access) to check for missing or incorrect heading elements. Verify that headings are being used properly in the HTML.
+
+Manual:
+1. Navigate through the page using a screen reader (e.g., VoiceOver for MacOS or NVDA for Windows).
+   - For VoiceOver, use VO keys + Command + H to skip around by heading
+   - For NVDA, use "H" key to skip around by heading
+2. Ensure that all headings are conveyed as distinct, sequentially organized elements, and the content hierarchy makes sense.
+3. Inspect the HTML structure to verify that proper HTML tags are used instead of non-semantic elements.
+
+[MagentaA11y] 
+https://www.magentaa11y.com/checklist-web/heading/
+
+[Resources]
+######
+
+[WCAG]  
+1.3.1 Info and Relationships (A)
+
+[Operating system]  
+######
+
+[Build Version]
+######
+
+[Browser]
+######
+
+[Assistive technology]  
+JAWS
+NVDA
+VoiceOver
+TalkBack
+
+---
+
+# [WIP] Semantic meaning of a list is not conveyed to a screen reader user
+
+## Severity
+3-Average
+
+## Suggested Priority
+Medium
+
+-------- copy below ---------
+
+[URL/Path]  
+######
+
+[Steps to reproduce]  
+######
+
+[Element] 
+(## Tester note: Describe where the thing is in the UI and delete me ##)
+
+[What is the issue] 
+A screen reader user does not know that a list exists on the page because it is not coded with semantic HTML such as `<ul>` or `<ol>`. The list is visually conveyed, but a screen reader user misses out on the same meaning, information, and hierarchy of relationships.
+
+The semantic meaning of a list is not conveyed to a screen reader user through HTML. This can happen when lists are marked up improperly (e.g., using non-semantic elements like `<div>` or `<span>` instead of proper tags like `<ul>` or `<ol>`).
+
+[Why it is important] 
+Lists (`<ul>` or `<ol>`) provide a clear and logical structure to content, helping users of screen readers navigate and understand the content hierarchy. A screen reader will announce where the list structure begins and ends and normally will announce the number of elements in the list as well (e.g., "1 of 10").
+
+If the semantic meaning is not conveyed correctly, users may struggle to comprehend the page content or find relevant content efficiently, reducing their ability to interact with the site.
+
+[Code reference]  
+(## Tester note: CSS code references can be helpful here – delete me ##)
+{code:css}
+...
+{code}
+
+[How to fix]  
+Ensure all lists use the appropriate HTML list tags (`<ul>`, `<ol>`, and `<li>` for both) for structuring content.
+
+Note: VoiceOver does not announce `<ul>` or `<ol>` when CSS styling removes their numbering or bullets.
+
+[Compliant code example]  
+(## Tester note: n/a here if not applicable and is a design change and delete me ##)
+{code:html}
+...
+{code}
+
+[How to test] 
+Automated:
+Use an accessibility testing tool (e.g., Level Access) to check for missing or incorrect list elements. Verify that lists are being used properly in the HTML.
+
+Manual:
+1. Navigate through the page using a screen reader (e.g., VoiceOver for MacOS or NVDA for Windows).
+2. Ensure that all lists are conveyed as distinct, sequentially organized elements, and the content hierarchy makes sense.
+3. Inspect the HTML structure to verify that proper HTML tags are used instead of non-semantic elements.
+
+[MagentaA11y]
+https://www.magentaa11y.com/checklist-web/list/
+
+[Resources]
+######
+
+[WCAG]  
+1.3.1 Info and Relationships (A)
+
+[Operating system]  
+######
+
+[Build Version]
+######
+
+[Browser]
+######
+
+[Assistive technology]  
+JAWS
+NVDA
+VoiceOver
+TalkBack
+
+---
+
+# [WIP] Text does not meet minimum contrast requirements
+
+## Severity
+3-Average
+
+## Suggested Priority
+Medium
+
+-------- copy below ---------
+
+[URL/Path]
+######
+
+[Steps to reproduce]  
+######
+
+[Element] 
+(## Tester note: Describe where the text is in the UI and delete me ##)
+
+[What is the issue] 
+The following text elements do not meet minimum contrast requirements: 
+
+Text Element:   
+Foreground: #xxxxxx  
+Background: #xxxxxx  
+Current Contrast Ratio: x.x:1
+
+[Why it is important]  
+Good contrast is essential for everyone, particularly for people with low vision, color blindness, or those viewing your website on a mobile device in bright or sunny conditions. If the text doesn't meet WCAG color contrast ratio minimums, it can be difficult for users to read, impacting their overall experience. This applies to any visible element, except those intentionally hidden or sized at 1px by 1px (tracking pixels).
+
+[Code reference]  
+(## Tester note: CSS code references can be helpful here – delete me ##)
+{code:css}
+...
+{code}
+
+[How to fix]  
+- Ensure that text and background colors meet the minimum contrast requirement.
+- Regular Text: For regular size text less than 24px text (or 18.5px if bold), a contrast ratio of at least 4.5:1 is necessary.
+- Large Text: Anything over 24px (or 18.5px if bold) must meet a color contrast ratio of 3:1.
+Note: Partner with Designers to get appropriate colors for use.
+
+[Compliant code example]
+(## Tester note: n/a here if not applicable and is a design change and delete me ##)
+{code:css}
+...
+{code}
+
+[How to test]  
+Automated: Use an automated accessibility testing tool to test for the existence the color contrast issue. E.g axe DevTools Chrome extension, Level Access Chrome Extension, ANDI
+
+Manual: Using Chrome DevTools, inspect the text. You can click on the color swatch in the CSS pane to see the calculated color contrast if a background is defined for the container it lives within.
+
+Alternatively, you can get the foreground hex code using Chrome DevTools by inspecting the text. Using an online color contrast tool such as Deque Color Contrast tool to compare the foreground and background. https://dequeuniversity.com/color-contrast
+
+The foreground and background comparisons should meet the required WCAG minimums. 4.5:1 or 3:1 based on calculated text sizes.
+
+[MagentaA11y]  
+https://www.magentaa11y.com/how-to-test/color-contrast/
+
+[Resources]
+######
+
+[WCAG]  
+1.4.3 Contrast (Minimum) (AA)
+
+[Operating system]  
+######
+
+[Build Version]
+######
+
+[Browser]
+######
+
+[Assistive technology]  
+n/a
+
+---