Accessibility Fortification
In Progress KendoDate: 2026-03-16 | Target: Accessibility score 3/10 → 7/10
Summary
A systematic UX inspection of kendo's frontend revealed that accessibility scored 3/10 across both inspected domains (authentication flows and issue board). This is not a domain-specific gap — it is a systemic absence of accessibility infrastructure throughout the application.
Four PRs have already been merged addressing the most critical shared infrastructure issues. This campaign documents the remaining work and proposes a phased remediation plan.
Why This Matters
WCAG 2.1 Level A is the minimum bar
The Web Content Accessibility Guidelines (WCAG) define three conformance levels: A (minimum), AA (standard), and AAA (enhanced). Level A failures mean that some users are completely unable to use the application. Kendo currently has multiple Level A failures:
| WCAG Criterion | Failure | Impact |
|---|---|---|
| 2.1.1 Keyboard | Board cards and issue rows cannot be reached via keyboard | Users who cannot use a mouse cannot navigate the core workflow |
| 2.4.7 Focus Visible | Button.vue uses focus:outline-none, removing focus indicators | Keyboard users cannot see which element is focused |
| 1.3.1 Info and Relationships | Form errors not programmatically associated with inputs | Screen reader users receive no error feedback on invalid forms |
| 4.1.2 Name, Role, Value | Icon-only buttons lack accessible names | Screen reader users encounter unlabeled buttons |
These affect keyboard-only users, screen reader users, users with motor impairments, and users with low vision — conservatively 15-20% of the population.
ISO 27001 alignment
Kendo operates under ISO 27001 certification. While accessibility is not explicitly in the control set, it intersects with:
- A.5.12 / A.5.13 (Information classification and labeling) — If the application is inaccessible to certain users, information labeled for their access cannot actually reach them.
- Organizational reputation — An ISO 27001-certified product with Level A accessibility failures creates a credibility gap if audited by clients or partners who assess product quality holistically.
The fix surface is concentrated
Most accessibility gaps trace to a small number of shared components:
| Component | Issue | Blast Radius |
|---|---|---|
Button.vue | focus:outline-none removes focus indicators | Every button in the app |
InputField.vue | focus-outline-none removes focus indicators | Every text input in the app |
FormError.vue | No aria-describedby linking to inputs | Every form in the app |
InputField.vue | No aria-required passthrough | Every required field in the app |
IconButton pattern | No aria-label on icon-only buttons | ~20+ instances across all domains |
Fixing 3-4 shared components improves accessibility across every domain simultaneously.
Current State
Inspection scores
Two domains inspected (2026-03-15), five dimensions each:
| Dimension | Auth Flows | Issue Board | Trend |
|---|---|---|---|
| Domain Language | 6/10 | 7/10 | ⬆️ |
| Error States | 5/10 | 4/10 | ⬇️ |
| Empty & Loading States | 5/10 | 5/10 | Stable |
| Visual Consistency | 7/10 | 7/10 | Stable |
| Accessibility | 3/10 | 3/10 | Stable (floor) |
| Composite | 5.3/10 | 5.3/10 | Stable |
Accessibility is the weakest dimension by a margin of 2+ points.
Already fixed (PRs #509-#512)
These merged PRs established the accessibility infrastructure:
| Fix | PR | Impact |
|---|---|---|
aria-describedby infrastructure in FormError + InputField | #509 | All forms can now link errors to inputs |
focus-visible outlines on Button, DropdownButton, SelectEntry | #509, #510 | Focus indicators restored on most interactive elements |
aria-label on ~11 icon-only buttons (auth + shared) | #511 | Screen readers can identify button purpose |
aria-expanded on collapsible elements | #511 | Screen readers announce open/closed state |
aria-required infrastructure on InputField | #511 | Required fields announced to screen readers |
| Dutch error messages replaced with English (4 locations) | #512 | Error messages now in declared UI language |
| Dead CSS cleanup in auth forms | #512 | Removed unused transition CSS |
Remediation Plan
Phase 1: Shared component completion
Ready — no coordination neededFollows patterns already established in PRs #509-#512. Low risk, no design decisions.
| Item | Component | Effort |
|---|---|---|
aria-label on remaining icon-only buttons | ~4 buttons in teams/users domains | Low |
aria-required adoption on all forms with required fields | All form consumers | Low |
aria-describedby adoption on issue form fields | IssueForm.vue, SprintFormModal.vue | Low |
| Custom select ARIA roles | SearchableSelect, SingleSelect, MultiSelect | Medium |
Phase 2: Keyboard navigation
Needs ally awarenessStructural changes to how interactive elements are rendered. Touches component behavior and may affect test assertions.
| Item | Components | Effort | Notes |
|---|---|---|---|
| Board cards keyboard-focusable | DragElement.vue | Medium | Wrap in <a> or add tabindex |
| Issue rows keyboard-navigable | IssueRow.vue | Medium | Same pattern |
| Sprint row keyboard-accessible collapse | SprintRow.vue | Low | Add role="button" + tabindex + @keypress |
| Comment list semantic HTML | CommentSection.vue | Low | Change div to ul/li |
Phase 3: Error resilience
Needs design deliberationAffects user experience on error paths. Requires input on desired behavior.
| Item | Components | Design Decision Needed |
|---|---|---|
| Drag-and-drop error handling + rollback | Board.vue, Backlog.vue | What happens visually when a board move fails? |
| Sidebar inline edit error handling + rollback | IssueSidebar.vue | Revert to previous value or show error state? |
| Network error user feedback | Error middleware | Toast wording, retry option? |
| Loading indicators on form submissions | Auth forms, comment, sprint ops | Spinner placement — inside button or overlay? |
Phase 4: Polish
Low priority| Item | Scope | Effort |
|---|---|---|
| Toast message voice normalization | ~40 instances across issues domain | Medium |
| Empty state for filtered board lanes | Board.vue | Low |
| Standardize password confirmation label | 3 forms | Low |
Expected Score Trajectory
| Milestone | Accessibility Score | Notes |
|---|---|---|
| Before (2026-03-15) | 3/10 | Zero ARIA, no keyboard nav, no focus indicators |
| After PRs #509-#512 | 4/10 | Focus indicators restored, ARIA infrastructure in place |
| After Phase 1 | 5/10 | All shared components accessible, forms linked |
| After Phase 2 | 6.5/10 | Core workflows keyboard-navigable |
| After Phase 3 | 7/10 | Error paths handled, loading states visible |
| After Phase 4 | 7.5/10 | Voice consistency, empty states |
Target: 7/10 (Fortified) — matching the Visual Consistency score and bringing accessibility to parity with the rest of the application.
Related
- Kendo project overview
- Audit Logging System — ISO 27001 compliance context
- Two-Tier Authorization — Route and action-level access control