1
Darken the primary blue
SERIOUS1.4.3 AA · brand token
White-on-blue and blue-on-white text measure 4.23:1, a hair under the 4.5:1 minimum. A slightly darker blue token clears contrast everywhere the color is used across the app.
Logged-in product (departments.sharedwork.com) · Single screen · WCAG 2.2 Level AA.
This is a single in-app screen (the "Task List – All Workspaces" view), scanned live through an authenticated session. It is a snapshot, not an app-wide audit. The interactive workflows where accessibility usually breaks — project and task editors, the calendar/Gantt, drag-and-drop, approvals/markup, modal dialogs, and settings — were not covered and should be audited separately. Only structural and styling data was captured; no project or personal content was read.
axe-core plus structural heuristics catch roughly a third to a half of WCAG issues, and even less for an application, where keyboard operation, focus management, live updates, and custom widgets dominate. A manual keyboard + screen-reader pass is required before any conformance claim or VPAT.
On its own, the Task List screen is in reasonably good shape. The one AA blocker is the brand-blue contrast (4.23:1, just under 4.5:1); the rest are moderate structural items (missing H1, heading skips, unlandmarked regions, untitled utility iframes, a legacy table header). Good fundamentals are already present — language, zoom, landmarks, named controls, alt text. No conclusion about the application as a whole can be drawn from one screen — see scope note above.
White-on-blue and blue-on-white text measure 4.23:1, a hair under the 4.5:1 minimum. A slightly darker blue token clears contrast everywhere the color is used across the app.
Add one clear <h1> per view and keep heading levels sequential (three level-skips here). This is the backbone screen-reader users navigate by.
Wrap the 9 unlandmarked regions in appropriate landmarks and give the 4 utility iframes titles (or hide them from assistive tech). Both are template-level fixes.
Fix the table header association (and mark true layout tables as presentation), and add the one missing field label and control name.
"Fails" = axe-confirmed violation; "Needs review" = axe couldn't decide automatically; "Heuristic" = flagged by structural check, confirm in context. Expand a row for evidence and fix.
| Issue & fix | ||||
|---|---|---|---|---|
| SERIOUS | Brand-blue text below AA contrast White text on the Workzone blue, and that blue used as text on white, fall just under the 4.5:1 minimum for normal text. | 1.4.3 Contrast (Minimum) Level AA | 4 | Fails |
Evidence: White on #0b80cb = 4.23:1 and #0b80cb on white = 4.23:1 (need 4.5:1). Example: left-nav labels. Plus 9 more spots flagged for manual review where the background couldn't be auto-detected. Fix: Darken the primary blue token slightly (e.g., toward #0a6ba8 or darker) so it clears 4.5:1 wherever it appears. One token change fixes it app-wide. | ||||
| SERIOUS | Utility iframes have no title Four iframes on the page have no title attribute, so assistive tech announces them as unnamed frames. | 4.1.2 Name, Role, Value Level A | 4 | Fails |
| SERIOUS | Table header not tied to data cells A <th> in a legacy table has no associated data cells, so its row/column relationship is ambiguous to screen readers. | 1.3.1 Info and Relationships Level A | 1 | Needs review |
| MODERATE | Content outside landmarks Nine blocks of content sit outside <main>/<nav>/<header>/<footer> landmarks, making structural navigation harder. | Best practice (landmark regions) Level — | 9 | Fails |
| MODERATE | Heading levels skip Heading levels jump (e.g., h2 to h4), which breaks the outline screen-reader users navigate by. | Best practice (supports 1.3.1) Level — | 3 | Heuristic |
| MODERATE | Isolated unlabeled field / unnamed control Among visible controls, one form field had no programmatic label and one button/link had no accessible name. Low count, but worth confirming manually. | 3.3.2 Labels / 4.1.2 Name, Role, Value Level A | 2 | Heuristic |
| MODERATE | No top-level heading (H1) The page has 17 headings but no <h1>, so there is no single top-level anchor for the screen. | Best practice (supports 1.3.1 / 2.4.6) Level — | 1 | Fails |
The document sets <html lang="en">.
The viewport does not disable pinch-zoom (supports 1.4.4 / 1.4.10).
No positive tabindex values — focus follows a natural sequence.
main and nav landmarks exist on the screen.
Every visible image carried an alt attribute.
26 of 27 visible buttons/links, and 2 of 3 visible fields, are properly named/labeled.
We ran axe-core 4.10.2 (WCAG 2.0/2.1/2.2 A & AA rulesets) plus structural heuristics against one authenticated screen of the Workzone application, then re-counted control/label issues against visible elements only (the app hides many inputs and menu items that assistive tech also skips, so raw DOM counts overstate the problem). Only element structure, ARIA, and computed colors were read — no on-screen text, field values, or record data.
One screen out of a large application; and automated tooling cannot judge keyboard-only operation, focus order and visibility, screen-reader announcements, dynamic/live-region updates, drag-and-drop, or custom widgets. The editors, calendar/Gantt, approvals, dialogs, and settings are unaudited and are where the real risk usually sits.
Audit a representative set of core workflows and pair it with a manual keyboard + screen-reader pass. Combined with the separate marketing-site audit, that body of evidence can support a VPAT / ACR (WCAG 2.2 AA & Section 508). For higher-ed procurement, the application is the higher-priority surface.