Public-comment docket software meets WCAG only if a specialist audits at the end of the PI, which then stalls release. What should the Scrum Master/Team Coach coach?
Select an answer to reveal the explanation.
Short Explanation
An accessibility specialist who shows up after the docket is frozen is a toll booth at the city limit. Build WCAG into the work as it moves. End-of-PI audits stall the release; dropping the bar just ships a door residents cannot use.
Full Explanation
Accessibility is built-in quality, not an end-of-PI specialist gate. When public-comment docket software meets WCAG only if a specialist audits after feature freeze, release stalls and inaccessible civic participation slips through until the audit. The Scrum Master/Team Coach should coach accessibility throughout the flow—standards in DoD, incremental checks, and shared ownership—so WCAG work does not become a phase-gate surprise.
Keeping accessibility as a phase-gate audit after features freeze fails by concept: late gates create release bottlenecks and expensive fixes. Dropping WCAG from the Definition of Done to protect the demo date fails by concept by sacrificing inclusive public access for a calendar win. Filing all accessibility defects as a future PI epic and shipping inaccessible fails by concept because it knowingly delivers noncompliant civic software.
Exam caveat: SAFe built-in quality includes nonfunctional concerns such as accessibility for public systems; deferring them to specialist end-gates is an anti-pattern. Specialist expertise still helps, but it should enable the team continuously—not only after freeze.
Operational check: add WCAG-related checks to DoD for docket stories, run incremental accessibility scans or reviews each iteration, involve the specialist as a coach earlier, and measure end-of-PI accessibility defect piles shrinking.