Life Support Services Sign in

Accessibility Statement

Last reviewed 2026-06-14. We target WCAG 2.1 level AA portal-wide.

Our commitment

Life Support Services builds this certification portal so anyone who needs to work, learn or verify a credential here can do so. We aim for the Web Content Accessibility Guidelines (WCAG) 2.1 at level AA across the entire signed-in portal, the self-paced online course player, and the public certificate verification pages.

What we test

We routinely review the Portal with:

  • Keyboard-only navigation — every interactive element must be reachable with Tab and operable with Enter or Space. A "Skip to main content" link sits at the top of every page, and multi-section pages (Dashboard, Documents, Settings) carry additional skip-to-section links.
  • Screen readers — NVDA on Windows and VoiceOver on macOS / iOS.
  • Browser zoom up to 200% — text should reflow without horizontal scroll on a 1280×800 viewport.
  • Reduced-motion preference (prefers-reduced-motion: reduce) — non-essential transitions are suppressed site-wide.
  • Contrast — body text aims for 4.5:1, large text 3:1.
  • Touch targets — controls aim for at least 44×44 px (WCAG 2.5.5).

Portal-wide patterns

As of 2026-06-14, every user-facing page in the Portal carries the same accessibility patterns. Specifically:

Semantic structure
Each page emits one <h1> reflecting the page's primary purpose and uses <h2> for major sections. The page chrome wraps the sidebar in <aside>, the topbar in role="banner", and the primary content in <main>. Breadcrumbs are a <nav aria-label="Breadcrumb"> with aria-current="page".
Page titles
The browser <title> reflects the current page and key state. The Calendar shows the month, Settings shows the active tab, and so on — so a screen-reader user reading the tab title gets the same context a sighted user gets from the breadcrumb.
Keyboard support
Tab order follows reading order on every page. Modals trap focus while open and restore focus to the opener on close. Esc closes the topmost modal, drawer, or notification panel. Skip-to-section links target the major regions of multi-section pages.
Focus indicators
Every focusable element has a visible 3 px focus ring (using :focus-visible so mouse users aren't bothered). The ring uses the Portal's orange accent token, which contrasts against both light and dark surfaces; on dark navy backgrounds (sidebar, calendar events) it picks up an additional white halo for visibility.
Notification bell
The bell button announces its current unread count (aria-label="Notifications, N unread") and toggles aria-expanded so a screen-reader user gets the same information as the red badge dot. The panel is a labelled role="dialog"; Esc closes and returns focus to the bell.
Modals
Every modal carries role="dialog" aria-modal="true" and is labelled by its visible heading. Tab cycles within the modal, Esc closes it, the close button has a meaningful aria-label, and background scroll is locked while open.
Tabs
The Settings screen uses the WAI-ARIA tabs pattern: role="tablist" on the container, role="tab" with aria-selected / aria-controls on each tab, and role="tabpanel" with aria-labelledby on each panel. Tabs are real anchors that navigate to a URL state, so they're back-button friendly. The admin-only System test tab follows the same pattern: every check row is a role="group" with a labelled Run button, the live summary uses role="status" aria-live="polite" so screen-reader users hear pass / warning / fail counts as they update, and status is conveyed via text + colour + symbol (✓ / ⚠ / ✗ / ⊘) rather than colour alone.
Forms
Every input has an associated <label for=>. Required fields display a visual "*" marker plus a screen-reader-only "(required)" string and aria-required="true". Error messages are wired to inputs via aria-describedby and include a warning icon so the affordance isn't color-only. Email, phone and similar fields carry autocomplete and inputmode attributes so mobile keyboards behave correctly.
Flash messages
Success and info messages use role="status" (aria-live="polite") so SR users hear them without interruption. Warning and error messages use role="alert" (aria-live="assertive") so failures interrupt the current reading flow.
Status indicators
Status badges that historically only used color now carry a leading symbol (check, warning triangle, info icon) so color-blind users see the same affordance as everyone else. The standing pills on the staff list (active / expiring / expired / missing) follow the same pattern.
Tables
Data tables use real <table> markup where the page structure allows, with <caption> describing what the table shows and scope="col" on column headers. Where the visual design demands a CSS-grid layout (e.g. responsive document directory), the rows carry ARIA table roles (role="row", role="columnheader", role="cell") so the semantic structure is preserved for assistive tech.
Motion
Animations are suppressed when prefers-reduced-motion is set. Nothing on the Portal auto-advances or auto-scrolls.

Online course player

The self-paced module stepper and knowledge check carry every pattern above plus a few extras specific to the player:

Stepper navigation
Arrow keys (and Home / End) move between modules in the stepper rail. The current step is announced as "Module N of M"; the active item carries aria-current="step".
Knowledge check
Each question is a <fieldset> with the question text as its <legend>. Selected answers are indicated by a check-mark icon, a fill change, and a bold label weight — not by color alone.
Live announcements
An aria-live="polite" region announces module changes and completion. Validation errors announce via the portal-wide flash pattern.

Known gaps and deferred items

We're transparent about what we haven't fixed yet. As of 2026-06-14:

  • Video captions and transcripts. Some courses include embedded audio or video lessons. The underlying data model does not yet support uploading caption tracks (WebVTT) or transcripts. Until it does, video and audio lessons carry an inline note pointing to this statement and we recommend authors include the lesson's key points in the written body text. Tracked for a future schema change.
  • Certificate PDF accessibility. Server-side certificate PDFs are rendered through dompdf. Tagging structure for assistive tech is limited. Each certificate's data is also viewable on the public verification page, which is fully accessible.
  • Phone wallet badges. The "Add to Apple Wallet" and "Save to Google Wallet" badges are the vendor-supplied SVGs and follow each vendor's branding guidelines.
  • Rich-text lesson body. Course authors compose lesson bodies in a rich-text editor. We sanitise on save but cannot guarantee that author-supplied images carry meaningful alt text. Local administrators should review course content for this.
  • Administrative inline forms. A handful of inline admin forms (for example the QuickBooks credentials form on the Billing screen) still use visual-only labels without explicit for= attributes. These are admin-only screens with low SR-user exposure and are tracked for a follow-up cleanup pass.

Mobile & small-screen support

As of 2026-06-14, every signed-in page is laid out for use on phones and tablets as well as desktops. Instructors taking attendance in the field and staff checking certifications on their phones get the same WCAG-AA patterns documented above, plus mobile-specific behaviour:

  • Breakpoints. The Portal flows across three layouts: desktop (≥1024 px), tablet (821–1023 px), and phone (≤820 px). The hard cut-over to the phone layout is 820 px so landscape phones in the 812–844 px range still get the drawer pattern.
  • Off-canvas navigation. On phones the left sidebar collapses into a drawer opened by a hamburger button in the top bar. The button carries aria-controls and aria-expanded, the drawer traps Tab focus while open, and Esc closes it and returns focus to the hamburger.
  • Sticky top bar. The top bar (brand, hamburger, notifications, sign-out) stays in place when the page scrolls so it is always reachable, and respects the iOS safe-area inset above the notch.
  • Table → card transformation. Wide data tables (staff roster, certificate registry, billing list, audit log, mail log, timesheets, user list and so on) restyle themselves as stacked cards at ≤768 px so each row is readable without horizontal scroll.
  • Mobile workflows. The attendance, hours / clock-in-out, and pass/ fail screens use thumb-sized 48 px controls, optional auto-save, and sticky-bottom action bars that sit above the iOS home-indicator inset.
  • Tap targets. All interactive controls aim for at least 44×44 px on every screen size, matching WCAG 2.5.5.
  • Scrollable tab bars. The Settings tab row scrolls horizontally on narrow screens, with the active tab scrolled into view automatically.
  • Form-zoom prevention. Form fields use a minimum 16 px font size on phones so iOS Safari does not auto-zoom on focus.
  • Reduced motion. The new drawer and sticky-bar transitions also honour prefers-reduced-motion: reduce alongside the existing site-wide rule.

Settings

Administrators can confirm the accessible course-player code path is active under Settings → Business → Course player accessibility (setting key online_course_a11y_enhanced, default on). The setting is mainly informational — turning it off only hides the in-player tips footnote. Portal-wide patterns described above are always on; there is no kill-switch.

Reporting an issue

If you find an accessibility problem we haven't listed here, please tell us. Email andrew@lifesupportservices.ca with the page URL, what you tried to do, and what happened. We aim to reply within five business days.

Standards reference

We measure against the W3C WCAG 2.1 guidelines. Provincial / federal requirements we keep in view include the AODA in Ontario and the Accessible Canada Act federally.