Accessibility

WCAG posture

No stated compliance level.

Automated checks

• No eslint-plugin-vue-a11y configured (no ESLint at all in repo)
• BootstrapVue's components are reasonably accessible by default (proper ARIA roles, keyboard nav for b-dropdown, b-modal, b-nav)

What BootstrapVue gives us

• <b-modal> traps focus, supports Esc, has aria-modal, aria-labelledby
• <b-dropdown> supports keyboard nav (arrows, Esc)
• <b-form-input> + <b-form-group> automatically associates labels via for/id
• <b-table> exposes proper <table> semantics

These are baseline-good.

Risks

• Custom modals using <div> soup rather than <b-modal> defeat the accessibility benefits. Audit by searching for position: fixed or position: absolute in pages/.
• Form fields without <label> if engineers use raw <input> instead of <b-form-input> + <b-form-group>.
• Color contrast — undocumented; visual design likely needs auditing.
• Focus management on route change — Nuxt doesn't shift focus on navigation; screen-reader users lose their place.
• No "skip to content" link — keyboard users tab through the Navbar on every page.
• Polotno editor — internal accessibility unknown; treat as a third-party widget with its own a11y story.

What this audit doesn't cover

• Manual keyboard-only testing
• Screen-reader testing (NVDA, JAWS, VoiceOver)
• Color contrast measurement

For an internal tool used by sighted staff, lower priority. For external audits / RFP responses, this is a gap.

Recommendations

ID	Recommendation	Effort
A-1	Add eslint-plugin-vue-a11y to the (not-yet-existing) ESLint config	Small
A-2	Add a "skip to main content" link in layouts/default.vue	Trivial
A-3	Add focus reset on route change	Small
A-4	Spot-check 5-10 pages for <b-form-input> usage; replace raw <input>	Medium
A-5	Run a color-contrast pass on assets/css/common.css brand colors	Small
A-6	Document an a11y target (WCAG 2.1 AA) in README, even if aspirational	Trivial