Update issue templates - STRR Accessibillity

Added a new template for STRR Accessibility Fixes.

.github/ISSUE_TEMPLATE/strr---accessibility-fixes-.md

@@ -0,0 +1,108 @@
+---
+name: 'STRR - Accessibility Fixes '
+about: MoSCoW Prioritization of Accessibility Fixes
+title: "[Epic Title]: Accessibility Fixes"
+labels: ''
+assignees: ''
+
+---
+
+# [Epic Title]: Accessibility Fixes
+
+## **Context**
+Provide a brief overview of the current accessibility issues. Outline how these issues are impacting the user experience, particularly for users with disabilities or those using assistive technologies. Explain how fixing these issues aligns with accessibility standards (e.g., WCAG 2.1, Section 508) and contributes to overall product inclusivity and compliance.
+
+> **Note:** This epic is focused on addressing accessibility concerns. **General design and layout fixes** should be tracked separately in a different epic to ensure clear separation of tasks.
+
+<details>
+<summary><strong>MoSCoW Prioritization Definitions</strong></summary>
+
+The MoSCoW method helps prioritize fixes based on their urgency and impact on accessibility. Below are instructions for how to classify each type of fix:
+
+### **Must Have**
+"Must Have" accessibility fixes are **critical** for ensuring users with disabilities can successfully interact with the product. These issues should be categorized as "Must Have" if they prevent users from accessing essential features or completing key tasks. A fix is "Must Have" if it meets any of the following criteria:
+- Blocks users who rely on assistive technologies (screen readers, keyboard navigation, etc.) from completing key tasks.
+- Violates key accessibility standards (e.g., WCAG A/AA criteria) and causes significant barriers for users.
+- Results in functionality or content being inaccessible, misleading, or difficult to understand for users with disabilities.
+
+**Example**: A form field lacks appropriate ARIA labels, making it impossible for screen readers to identify.
+
+### **Should Have**
+"Should Have" accessibility fixes are **important** but do not completely block access. These issues may cause confusion or difficulty for users with disabilities, but they can still complete tasks. Addressing these issues will improve overall accessibility but is not urgent enough to block the release.
+
+- Improves the experience for users with disabilities without entirely hindering their ability to complete tasks.
+- Fixes minor accessibility issues that cause frustration or slight confusion but do not result in total inaccessibility.
+
+**Example**: Insufficient color contrast in some UI elements that makes it harder for users with low vision but does not make content unreadable.
+
+### **Could Have**
+"Could Have" accessibility fixes are **nice-to-have** improvements that enhance usability but have a minimal impact on functionality. These fixes can be deprioritized if time is constrained, as they do not block access but still contribute to overall accessibility.
+
+- Improves the user experience by making the product more accessible, but the absence of this fix does not cause significant barriers.
+- Enhances accessibility beyond compliance, providing a smoother or more inclusive experience.
+
+**Example**: Adding more descriptive alt text to decorative images that are already marked as non-essential for screen readers.
+
+### **Won't Have**
+"Won't Have" fixes are explicitly excluded from the current sprint or release cycle. These are low-priority fixes or accessibility enhancements that do not significantly improve access or usability and can be revisited later.
+
+- Not necessary for this sprint or release, as the issue does not cause major accessibility barriers.
+- Deemed unnecessary at this stage due to time constraints or alignment with business goals.
+- Fixes that may be reviewed later, based on resource availability.
+
+**Example**: Refining the keyboard focus order for secondary navigation menus that are already accessible in their current state.
+
+</details>
+
+## **MoSCoW Prioritization Fixes**
+
+### **Must Have**
+- [ ] Critical fix 1  
+  - [ ] QA Tested
+- [ ] Critical fix 2  
+  - [ ] QA Tested
+- [ ] Critical fix 3  
+  - [ ] QA Tested
+
+### **Should Have**
+- [ ] Important fix 1  
+  - [ ] QA Tested
+- [ ] Important fix 2  
+  - [ ] QA Tested
+
+### **Could Have**
+- [ ] Optional fix 1  
+  - [ ] QA Tested
+- [ ] Optional fix 2  
+  - [ ] QA Tested
+
+### **Won't Have**
+- [ ] Not included fix 1  
+- [ ] Not included fix 2  
+
+## **Impact Assessment**
+Summarize the potential impact these accessibility fixes will have on the product and user experience. Include any risks or dependencies (e.g., alignment with WCAG, Section 508, or other legal accessibility requirements).
+
+## **Design Assets**
+- **Figma Designs**: [Insert link to relevant Figma files with accessibility annotations]  
+- **Miro Board**: [Insert link to Miro board for brainstorming accessibility solutions]  
+
+
+## **Stakeholder Review**
+- **Design Team Review**: @mention design team members here  
+- **Accessibility Expert Review**: @mention accessibility lead for review  
+- **Product Owner Review**: @mention product owner for sign-off  
+- **Technical Architect**: @mention TA lead for feasibility checks (if applicable)
+
+## **Acceptance Criteria**
+- [ ] All critical "Must Have" accessibility issues are resolved before the story is closed.  
+- [ ] Accessibility fixes align with the relevant WCAG or legal accessibility standards.  
+- [ ] Stakeholder approvals are obtained, including final design and usability sign-offs.  
+
+## **Scalability Considerations**
+- [ ] Accessibility considerations can accommodate future product changes or additional features.
+- [ ] Product is fully accessible across different devices (desktop, tablet, mobile).
+
+## **Risk & Dependencies**
+- [ ] Identify any risks in deploying these accessibility fixes, especially close to release deadlines.  
+- [ ] Dependencies on other epics, tasks, or systems are accounted for.