Accessibility and help
Using HALEPM
Use the left navigation and toolbar commands. Open Settings from the gear icon.
Accessibility conformance statement
Statement date: 1 October 2026. Standard: WCAG 2.1, level AA. Status: Partially conformant. Some parts of the content do not yet fully conform to the standard; they are listed below.
Prepared by the delivery team from its own testing, not an independent audit. It will be reviewed whenever an accessibility item in the delivery register changes.
Scope
- Covered:
- the HALEPM portal, the 20 pages under
/halepm/, including the sign-in page and this statement's own page. Both colour themes and all three text sizes are covered; - the React app, which is to replace the portal: its six views (Project Center, Schedule, Issues, Dashboard, Resources and My Timesheet) and every Admin & Settings screen. It has one colour theme. It is checked by the automated scan and, since 1 October, by keyboard tests: skip link, visible focus, and focus in its dialogs and editor panel. The "What works" table below describes the portal; the React app's known gaps are listed under Known limitations.
- the HALEPM portal, the 20 pages under
- Not covered: exported files and reports, whose accessibility has not been assessed.
How conformance was assessed
- Code review and automated scan: on 24 September, a code review of every portal page, and an axe-core scan against the WCAG 2.1 A and AA rules in both themes.
- Automated checks in CI, on every change, in Chromium and WebKit (
frontend/e2e/accessibility.spec.ts,frontend/e2e/visual-contrast.spec.ts,frontend/e2e/react-accessibility.spec.tsandfrontend/e2e/react-keyboard.spec.ts):- every signed-in page and the sign-in page against the WCAG 2.1 A and AA rules that axe-core can test;
- the React app's six views, its New Project form and resource editor while open, and every Admin & Settings screen, against the same rules; a view that fails to load its data fails the check;
- colour contrast in both themes;
- twelve dialogs, panels and menus checked for contrast while open, each opened with fixed test data; a popup that fails to open fails the check;
- colour contrast while hovering, for every hover style that changes a text or background colour, in both themes;
- text in SVG charts, measured against what is drawn behind it, which axe-core does not check;
- keyboard behaviour: the skip link, dialog focus, and the schedule grid, in the portal and the React app;
- a visible focus ring;
- table captions and row headers.
- Limits of the automated checks: they cover perhaps a third to a half of WCAG's success criteria. The rest need manual testing.
- No screen reader has been used against the portal or the React app yet.
What works
| Area | Status |
|---|---|
| Page language, landmarks, and a named main heading on every page | Conforms |
| Labels and accessible names for every form control | Conforms |
| Skip link as the first Tab stop; no forced Tab order; scrolling areas reachable by keyboard | Conforms |
| Visible keyboard focus on every page | Conforms |
| Dialogs and slide-in panels: focus moves in, stays inside, Escape closes, focus returns | Conforms; all seven dialogs tested from the keyboard |
| Colour contrast of text in both themes, including open dialogs, panels and menus, hover states, and chart text | Conforms |
| Status shown by shape as well as colour on status dots | Conforms |
| Table captions and row headers | Conforms, except the schedule grid (below) |
| Schedule task grid by keyboard: arrow keys, Home, End, Enter or F2 to edit | Conforms |
| React editor Gantt by keyboard: move, resize and link bars from a focused bar | Conforms; each keyboard action tested in CI on Chromium and WebKit since pull request #94. The portal Gantt is read-only |
| Status messages: toasts, inline errors, and changing status text are announced to screen readers | Conforms; errors as alerts, the rest as polite status messages, checked in the browser on 11 pages |
Known limitations
| Limitation | WCAG criteria | Plan |
|---|---|---|
| The Gantt chart has no text equivalent of its timeline | 1.1.1 | A11Y-04 |
| The schedule grid's header row is a separate table, so column headers are not associated with cells | 1.3.1 | A11Y-05: build plan task 3.1, the accessible treegrid |
| Exported files and reports have not been assessed | 1.3.1 and others | A11Y-06 |
| No testing with a screen reader (NVDA, JAWS or Narrator), in the portal or the React app | All | A11Y-01 |
The A11Y numbers are items in the remediation backlog, docs/accessibility/remediation-backlog.json: the one prioritized list of open accessibility work. CI fails if a limitation here has no open item there.
Outside HALEPM's control, and so not assessed: elements the browser draws itself, such as the native confirmation prompts, the tooltips shown from a title attribute, and scrollbars. Their colours come from the browser and the operating system, not from the portal.
Reporting a barrier
If something in HALEPM is hard or impossible to use, raise a request with the ServiceNow Service Desk and name HALEPM as the application. Say which page, what you were trying to do, and which browser and assistive technology you use.
- Response times follow the Service Desk's published SLAs for the request category.
- While a barrier is being fixed, the Service Desk provides a workaround where one is possible, case by case.
- Escalation follows the Service Desk's standard escalation policy.
Where this statement lives
This file is the source of record. It is published in the portal as the Accessibility and help page, /halepm/accessibility.html, reached from the Help button and from the sign-in page, and needs no sign-in. node scripts/accessibility-statement.js generates that page from this file, and CI fails if the two differ.