Open mbertucci opened 2 weeks ago
Out for review to merge to main https://github.com/bcgov/entity/pull/23499
Please add your planning poker estimate with Zenhub @qudsia-khan-fw
@shaangill025 @avni-work - Please approve this PR to update our templates.
Not sure if I'm missing a step here but tagging you since I set this up days back now.
[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.
MoSCoW Prioritization Definitions
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.MoSCoW Prioritization Fixes
Must Have
Should Have
Could Have
Won't Have
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
Stakeholder Review
Acceptance Criteria
Scalability Considerations
Risk & Dependencies