For your accessibility file. Print this page or save it as a PDF. The living version stays at this URL and is revised as the product evolves.

AccessPoint Accessibility Conformance Report

WCAG 2.1 Level A / AA — self-assessment. This report covers the AccessPoint application. The accessibility statement for this website is at realizer.io/accessibility.

ProductAccessPoint — the Microsoft 365-native platform for public-sector access, privacy, and responsible AI
Version evaluated2.0.73
Report date2026-08-20
VendorRealizer Services Inc.
Contactrealizer.io/support/contact
Standard appliedWeb Content Accessibility Guidelines (WCAG) 2.1, Levels A and AA (w3.org/TR/WCAG21)
Report formatModeled on the ITI VPAT® 2.5 WCAG edition (self-assessed; not an ITI-certified VPAT)

Product description and scope

AccessPoint is an enterprise access-to-information / privacy case-management application. The user interface is a SharePoint Framework (SPFx) web part (React 17 + Fluent UI 8) hosted inside SharePoint pages and as a Microsoft Teams personal tab, backed by an ASP.NET Core API in the customer's Azure tenant. This report covers:

  1. The application UI — the SPFx web part (≈400 React components: dashboards, case panels, settings, reports).
  2. The document viewer — an API-served page embedding the Syncfusion EJ2 PDF Viewer in an iframe, including AccessPoint's own redaction-overlay layer.
  3. Generated document outputs — PDFs (correspondence letters, certificates, response/evidence packages, converted uploads) and Excel exports, reported in their own section because they are consumed outside the application.

Host and third-party reliance. The SharePoint page / Teams client owns the page <title>, <html lang>, and page-level skip navigation; conformance for that chrome is Microsoft's (see Microsoft's published ACRs for SharePoint Online and Teams). UI primitives (buttons, panels, dialogs, grids, tooltips) are Fluent UI 8; PDF rendering, the viewer toolbar, and Office/HTML→PDF conversion are Syncfusion EJ2. Where a behavior is entirely internal to a vendor component, the remarks say so — refer to the vendor's accessibility documentation for those internals. This report covers how AccessPoint uses those components and everything AccessPoint builds itself.

Authored content caveat. Tenants configure their own tag colors, choice labels, and correspondence templates, and users upload arbitrary documents. Conformance of tenant-authored content (e.g., a low-contrast custom tag color, an inaccessible uploaded PDF) is outside the product's control; the product's own defaults are what is assessed here.

Evaluation methods

This self-assessment combines three evidence sources, all against version 2.0.73:

  1. Static code review of the full frontend source (≈400 components, per-element JSX analysis — label/ARIA coverage counted per control type, not sampled), the server-generated viewer page (HTML/JS), and every document-generation path. Contrast ratios were computed from source values with the WCAG relative-luminance formula for both the light theme and the product's dark-theme token set; Fluent UI behavior was verified against the shipped library source (focus traps, live regions, spinner announcement conditions) rather than assumed.
  2. Independent adversarial verification — a second, independent five-dimension review attempted to refute every claim in this report: re-sweeping all controls for names, independently recomputing every contrast pair, and line-auditing the viewer, keyboard, and timing implementations. The tables reflect the verified state.
  3. Runtime browser verification on a live SharePoint deployment (2026-08-20): keyboard walkthroughs (grid row-open via Enter, Escape dismissal, focus restoration after panel close), live ARIA-state inspection (combobox aria-expanded/aria-activedescendant/aria-selected tracking arrow keys; lang attributes; heading levels; reorder hints), tooltip Escape dismissal, and the report-workspace viewport clamp (verified rendering at a 984 px viewport). This included a simulated screen-reader pass: a walk of the Chromium accessibility tree — the same tree NVDA/JAWS consume on Chrome — across the dashboard, data grid, search, pickers, and pinned-tile surfaces, verifying role, name, state, and reading order at every node (e.g., grids expose named grid/columnheader/gridcell structure with sort and reorder hints; chart images announce their actual data; progress bars carry text companions), plus a page-wide sweep of all focusable elements for missing accessible names (162 focusables on the busiest surface — all named; the only nameless focusables found belong to SharePoint's own chrome).

Ongoing enforcement: the SPFx lint gate runs a curated eslint-plugin-jsx-a11y rule set (valid ARIA props/roles, alt text, required role attributes, no positive tabindex, aria-activedescendant focusability, valid lang) plus an in-house rule requiring ariaLabel on every Spinner — all at error severity, so violations fail the build in CI.

Not performed (see Known limitations): screen-reader interoperability testing (NVDA/JAWS/VoiceOver), automated runtime scans (axe), and a 320 px / 400 % zoom pass (the reflow mechanisms are code-verified and runtime-verified at 984 px).

Terms

  • Supports — the functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation.
  • Partially Supports — some functionality of the product does not meet the criterion.
  • Does Not Support — the majority of product functionality does not meet the criterion.
  • Not Applicable — the criterion is not relevant to the product.

Summary of results

LevelSupportsPartially SupportsDoes Not SupportNot Applicable
A (30 criteria)22305
AA (20 criteria)18002

How the product meets the guidelines. Every form control carries a programmatic name sourced from the same localized strings as its visible label (verified by sweep: ~1,330 controls, all named); all 305 icon-only buttons and every per-row switch carry explicit labels that include the row's item name where controls repeat; all 465 loading spinners announce via role="status"; save/validation outcomes announce through ~170 deliberate live regions plus Fluent MessageBar semantics. Keyboard operation is systematic: clickable cards and rows implement the role/tabIndex/Enter-Space pattern, grids open rows on Enter, every reorder surface has a keyboard alternative (Alt+Arrow with focus restoration, or menu items) persisting through the same handlers as dragging, document-viewer redaction marks are focusable, labeled, activatable, and geometry-adjustable by keyboard — including a keyboard path for free-form region redaction (a "Place redaction box" command drops a default-sized box on the current page, which the keyboard geometry controls then move and resize) — and single-character shortcuts are active only while their surface holds focus. Mixed-language content — a headline feature of this multilingual product — carries lang markup on the app root, translated fields, and correspondence rendered in the requestor's language. The status/state color system is centrally engineered with computed AA ratios in both themes, and both type-ahead search controls implement the ARIA 1.1 combobox pattern (runtime-verified).

Known remaining gaps (each detailed in its criterion row): multi-series charts on small dashboard tiles distinguish series by hue alone for sighted users (full-size charts carry legends; the data is exposed in text form); some secondary background actions fail silently; and a minority of search/filter fields present placeholder-only visible labeling (their programmatic names are complete). The most significant open assessment task is screen-reader interoperability testing.

Table 1: WCAG 2.1 Level A

CriterionConformanceRemarks and explanations
1.1.1 Non-text ContentSupportsImages carry alt text and decorative icons are hidden from AT. Meaningful indicators carry text/ARIA equivalents: the document unread dot is role="img" with a localized label (plus a text-based filter facet), settings-catalogue Active/Default state icons and translation-state icons are labeled from localized strings, every loading spinner (465 instances) announces via ariaLabel (lint-enforced), in-viewer redaction overlays are labeled focusable controls, and charts expose data-bearing accessible names (chart type + measure + total + top values, locale-formatted).
1.2.1 Audio-only / Video-only (Prerecorded)Not ApplicableThe product contains no audio or video. Uploaded media files are stored and downloaded without in-product playback; captured records replace embedded media with text placeholders.
1.2.2 Captions (Prerecorded)Not ApplicableNo time-based media.
1.2.3 Audio Description or Media Alternative (Prerecorded)Not ApplicableNo time-based media.
1.3.1 Info and RelationshipsSupportsEvery form control carries a programmatic label (sweeps report zero unnamed controls; custom-field editors expose required state). Panels and dialogs expose programmatic titles; detail and settings surfaces use real headings (266 <h3>+ across 92 files), semantic lists and tables, and labeled nav/region landmarks; data grids ride Fluent DetailsList semantics; the My Day dashboard exposes a programmatic heading hierarchy and the risk heat map is a semantically correct table with fully self-describing cells. Advisory, not a failure: the app relies on the SharePoint/Teams host for page-level landmarks rather than adding its own main/toolbar landmark.
1.3.2 Meaningful SequenceSupportsContent order in the DOM matches the visual reading order; no CSS-based reordering is used.
1.3.3 Sensory CharacteristicsSupportsInstructions reference controls by their visible labels; the one color-worded instruction ("Amber/Red thresholds") names on-screen field labels.
1.4.1 Use of ColorPartially SupportsThe dominant pattern is color + icon + text: status chips carry glyph and text, overdue/due-soon dates pair an icon with the tinted pill and the date, the unread dot and risk heat map have full text/ARIA equivalents, tag chips always carry label text, and catalogue state indicators carry text equivalents. Remaining gap: multi-series charts on small dashboard tiles distinguish series by hue alone for sighted users (full-size charts include legends and per-point callouts; report sections render data tables; every chart exposes a data-bearing accessible name).
1.4.2 Audio ControlNot ApplicableNo audio.
2.1.1 KeyboardSupportsInteractive content is systematically keyboard-operable: clickable cards/rows implement role/tabIndex/Enter-Space, grids open rows on Enter (runtime-verified), upload drop zones have a keyboard path, every reorder surface has a keyboard alternative (Alt+Arrow with focus restoration or menu items — including grid column reorder and resize) persisting through the same handlers dragging uses, and in the document viewer overlay marks are focusable and activatable with Alt+Arrow move / Alt+Shift+Arrow resize on editable marks through the same commit path as the pointer. Free-form region redaction over non-text content has a keyboard path: the Redact menu's "Place redaction box" command drops a default-sized box centred on the current page into the same confirm flow as a pointer drag, and the saved mark is then moved and resized with the keyboard geometry controls; text-matching patterns, whole-page rules, and the fully keyboard-operable side-panel review lifecycle (accept, dismiss, flag, withdraw, approve) cover the other creation and review paths.
2.1.2 No Keyboard TrapSupportsFluent focus-trap defaults are never overridden; panels and dialogs dismiss with Escape and restore focus (runtime-verified: Escape returns focus to the originating grid row); layered-panel Escape handling is explicitly engineered. The viewer iframe is exitable with Shift+Tab (Escape pressed inside the iframe does not close the hosting modal; the close button remains reachable).
2.1.4 Character Key ShortcutsSupportsThe two single-character shortcut sets (redaction viewer R/H/C and [ / ]; Documents tab / and f) are active only while keyboard focus is within their owning surface — the criterion's focus-scoping condition — and remain suppressed during text entry. All other shortcuts are chorded (Alt+Arrow etc.) or component-scoped.
2.2.1 Timing AdjustableSupportsNo session or inactivity limits exist; authentication renews silently; no user work is lost to timers. Success/informational toasts auto-dismiss after 3–6 s but pause while hovered or focused and resume with the remaining time; errors persist until dismissed; all toasts are announced via a persistent polite live region.
2.2.2 Pause, Stop, HideSupportsNo moving, blinking, scrolling, or auto-advancing content. Background polls update in-flight process status only and self-stop; a global prefers-reduced-motion rule disables all transitions and animations.
2.3.1 Three Flashes or Below ThresholdSupportsNo flashing content; the only animation is standard spinners/fades.
2.4.1 Bypass BlocksSupportsThe host (SharePoint/Teams) supplies page-level skip mechanisms. In-app primary navigation is a single-tab-stop tablist followed directly by content; headings and labeled landmarks support AT navigation.
2.4.2 Page TitledSupportsPage titles are owned by the hosting SharePoint page / Teams tab; in-app panels and modals carry programmatic titles, and the document-viewer pages emit localized titles. (Observation: in-app SPA navigation does not update the host title.)
2.4.3 Focus OrderSupportsFocus follows DOM order (no positive tabindex anywhere); modal surfaces use Fluent's untouched initial-focus/trap/restore behavior, supplemented by an explicit focus-return hook and focus preservation across keyboard reordering (runtime-verified).
2.4.4 Link Purpose (In Context)SupportsLinks and row actions are contextualized by their accessible name or the enclosing row/card that names the item; generic "View"/"Open" affordances are row-scoped buttons.
2.5.1 Pointer GesturesSupportsOnly single-pointer clicks and drags are used; no multipoint or path-based gestures.
2.5.2 Pointer CancellationSupportsAll activations complete on the up-event; the only down-event listeners initiate drags (essential) or manage focus.
2.5.3 Label in NameSupportsAccessible names and visible labels are sourced from the same localized strings; controls that add context to their name (status/priority chips, per-row toggles) contain the visible text within the accessible name.
2.5.4 Motion ActuationNot ApplicableNo motion-actuated functionality.
3.1.1 Language of PageSupportsThe host page declares the document language; the product defaults its UI locale to the host culture, and tags its own root when the user selects a different language (see 3.1.2). Viewer iframe pages declare their own <html lang>.
3.2.1 On FocusSupportsThe only onFocus handlers re-open a combobox suggestion list and pause a toast's dismiss timer; no context changes on focus.
3.2.2 On InputSupportsNo input auto-submits or navigates; all commits are explicit button activations.
3.3.1 Error IdentificationPartially SupportsValidation and save errors are identified in text via Fluent errorMessage (programmatically associated, announced) and MessageBars inside always-mounted aria-live regions, with a shared server-error helper; the reasons a submit button is disabled are rendered as inline text in polite live regions. Remaining gap: ~160 secondary actions swallow failures silently (no user-visible feedback for non-critical background fetches).
3.3.2 Labels or InstructionsPartially SupportsVisible persistent labels are the norm (~90 % of inputs); required fields use Fluent required (asterisk + aria-required); complex flows carry instructions; every control has a programmatic name. Remaining gap: a minority of controls (~56, mostly search/filter boxes and sub-dialog inputs) present placeholder-only visible labeling, which disappears once a value is entered.
3.3.3 Error SuggestionSupportsError messages state the correction (date-range, over-length with limit and count, URL format); missing required fields are enumerated by name; the bulk data importer returns a downloadable per-row error report supporting correction and safe re-submission.
3.3.4 Error Prevention (Legal, Financial, Data)SupportsDestructive operations (bulk delete, retention purge) require explicit count-bearing confirmations with severity warnings, and the server independently re-checks purge eligibility; data import is gated behind a reviewable validation report and is create-only/skip-on-match; e-signed attestations present the full signed text for review and pass through second-party approval; fee payments are recorded via an explicit confirm dialog.
4.1.1 ParsingSupportsAll markup is TSX (duplicate attributes / malformed nesting are compile errors); a single dangerouslySetInnerHTML renders the held sign-off letter's stored HTML (composed in-tenant); generated ids use Fluent's unique-id utilities.
4.1.2 Name, Role, ValueSupportsFluent components expose correct roles/values; 100 % of icon-only buttons and per-row toggles carry explicit ariaLabels (per-row actions include the row's item name so repeated controls are distinguishable); custom picker rows expose checkbox state without duplicate tab stops; the language picker exposes listbox/option semantics; both type-ahead search controls implement the ARIA 1.1 combobox pattern — combobox role/expanded/haspopup/controls on the wrapper, aria-activedescendant and listbox/option ids on the input — with expanded state, active-option tracking, and Escape behavior runtime-verified. In-viewer redaction overlays are labeled, focusable role="button" controls; the accessible side panel additionally lists every mark with status, exemption, and the full action set.

Table 2: WCAG 2.1 Level AA

CriterionConformanceRemarks and explanations
1.2.4 Captions (Live)Not ApplicableNo time-based media.
1.2.5 Audio Description (Prerecorded)Not ApplicableNo time-based media.
1.3.4 OrientationSupportsNothing restricts display orientation (no orientation locks or restricting media queries in the app or Teams manifest).
1.3.5 Identify Input PurposeSupportsNearly all data-entry fields concern third-party requestors (out of this criterion's scope). The fields that collect the signed-in user's own information — the attestation signature name and title — carry autocomplete="name" and autocomplete="organization-title".
1.4.3 Contrast (Minimum)SupportsText color is engineered to AA with computed ratios in both themes: the central status-badge palette measures 5.77–8.23:1 (light) and 6.94–8.21:1 (dark); theme status-token pairs measure 4.75–8.21:1 on their tints and ≥5.2:1 on white; body text uses theme slots (≥6.4:1); informative secondary text uses neutralSecondary (6.46:1); user-configured tag colors are never used as text color. Every token pair was independently recomputed during verification. Tenant-configured tag/data colors remain authored content outside product control.
1.4.4 Resize TextSupportsTypography scales with browser/OS zoom; no fixed-height text clipping was found; truncation is ellipsis/line-clamp with the full content available elsewhere; tab bars collapse into an overflow menu on resize.
1.4.5 Images of TextSupportsNo images of text; the only text-bearing images are exempt brand logotypes (SVG).
1.4.10 ReflowSupportsDetail panels open full-viewport; ~19 breakpoint rules collapse toolbars; shell containers set min-width: 320px; wide report matrices scroll in their own containers; data grids scroll horizontally (permitted for data tables). The report-builder workspace clamps to min(1180px, 100vw) (runtime-verified rendering at exactly the viewport width on a narrow window); the redaction workspace pairs a PDF canvas (two-dimensional by nature) with a user-togglable side rail. A dedicated 320 px / 400 % zoom pass remains on the assessment backlog (Known limitations).
1.4.11 Non-text ContrastSupportsMeaningful graphics meet 3:1 in both themes: unread dot 4.53:1, heat-map marks, decision-chip borders, stock Fluent control borders 6.46:1, the catalogue default-star token 4.55:1 light / 9.55:1 dark, state icons 6.46:1, and the combobox active-option indicator (2 px theme-primary outline, 4.5:1).
1.4.12 Text SpacingSupportsLayouts are content-height driven; applying the 1.4.12 spacing overrides expands pills, cards, and rows without clipping or overlap.
1.4.13 Content on Hover or FocusSupportsAll hover-triggered content routes through Fluent tooltips — hoverable and persistent by design, and dismissable with Escape (runtime-verified: Escape dismisses the open tooltip without moving the pointer). Some tooltip hosts are non-focusable text spans, so their tooltip content appears on pointer hover only; the underlying information (e.g., a truncated title) remains available through the element's accessible name.
2.4.5 Multiple WaysSupportsRecords and views are reachable via persistent tab navigation, a global cross-entity search, notification-feed links, and shareable deep links; site-level navigation is host-provided.
2.4.6 Headings and LabelsSupportsHeadings and labels are descriptive and localized; panel titles name the record or task.
2.4.7 Focus VisibleSupportsFluent components keep default focus rectangles; class-styled custom interactive rows carry explicit 2 px :focus-visible outlines; keyboard-reorder rows rely on the browser-default focus indicator (nothing suppresses it); the only three outline: none rules substitute a visible alternative indicator; viewer overlay marks carry an explicit 3 px focus outline.
3.1.2 Language of PartsSupportsMixed-language content carries lang markup throughout: the web part root is tagged with the active UI language (covering a user-selected language that differs from the host page's declaration — runtime-verified), translated-field display and editing surfaces are tagged with each content's language, letters composed in the requestor's language are tagged with the merge language (carried on the sign-off payload so held letters tag correctly at review), language names ("Français", "Deutsch") carry their own lang, and full-page fallback views are tagged. All attributes are state-bound and update on language toggle. Letters submitted for sign-off by product versions predating the stored merge language render untagged.
3.2.3 Consistent NavigationSupportsNavigation is rendered from single shared components (app shell, panel navigation header, shared catalogue list), so ordering and placement are consistent by construction.
3.2.4 Consistent IdentificationSupportsSame-function controls are implemented once and reused with centralized localized labels and a documented verb convention.
3.3.3 Error SuggestionSupportsSee Table 1 (3.3.3): correction-bearing messages, enumerated missing fields, and the importer's per-row error report.
3.3.4 Error Prevention (Legal, Financial, Data)SupportsSee Table 1 (3.3.4): count-bearing confirmations, server-side re-checks, validate-first import, and second-party attestation review.
4.1.3 Status MessagesSupportsSave/validation outcomes, toasts, and long-running generation/import states announce through a deliberate live-region pattern (~170 aria-live regions) plus MessageBar's native semantics; a persistent polite live region hosts global toasts; every Spinner (465 instances) sets ariaLabel, which is what makes Fluent render its role="status" announcement — enforced by an error-severity lint rule. (Best-practice note: the global search conveys result availability through combobox state rather than an explicit result-count announcement.)

Generated document outputs (PDF and Excel)

Documents the product generates are consumed outside the application, so they are reported separately rather than folded into the tables above.

OutputStatusRemarks
Generated PDFs (correspondence letters, attestation certificates, response packages, evidence packages, ROPA exports, converted uploads)Partially Supports (opt-in)An administrator-controlled setting (Documents:TaggedPdf, default off) enables tagged (accessible-structure) output for Word-sourced PDFs (correspondence/letterhead letters, incident letters, converted Word uploads) and HTML-sourced PDFs (converted emails, record captures, certificates) via the PDF library's auto-tagging. Tag quality depends on source structure and has not been validated with PAC/veraPDF, so no PDF/UA conformance is claimed. Merged export packages (response packages, evidence exports) remain untagged regardless of the setting — the merge path drops structure tags; adopting the library's tag-preserving merge API is a scoped item on the roadmap. Redacted response PDFs intentionally remove withheld content (essential by function); scanned inputs pass through as image-plus-OCR-text-layer at best.
Excel exports (report builder, statistical returns, data-transfer workbook)Partially SupportsNamed, localized worksheets (including the statistical-return sheet name in all 11 languages), styled header rows, and typed, localized cell data; the data-transfer workbook includes an instructions tab and in-cell dropdowns. Remaining: no defined tables/named ranges, and a few fixed in-sheet labels ("Total", period captions) are English-only.

Organizations with PDF/UA obligations for outbound correspondence should account for this in their own remediation processes (e.g., post-processing) until tagged output is validated and the export-merge item on the roadmap lands.

Known limitations of this assessment

  1. No live screen-reader sessions yet. The evidence base includes a simulated screen-reader pass over the Chromium accessibility tree (role/name/state/reading-order at every node — the input NVDA/JAWS consume), but not live NVDA/JAWS/VoiceOver sessions, which additionally exercise browse-vs-focus modes, verbosity, and screen-reader-specific quirks. The items most worth a live AT pass: the ARIA 1.1 combobox shape across screen readers, chart data-point tab order, and focus restoration after server-reloading lists.
  2. No automated runtime scans (axe) and no dedicated 320 px / 400 % zoom pass. The reflow mechanisms are code-verified and runtime-verified at a 984 px viewport.
  3. Vendor internals not re-audited. Syncfusion EJ2 PDF Viewer internals (canvas rendering, text layer, toolbar semantics) and Fluent UI internals are assessed only as used; refer to vendor accessibility documentation.
  4. Point in time. This report describes version 2.0.73 as of 2026-08-20 and should be revised when the product changes materially.

Roadmap (open items)

  1. Live screen-reader sessions (NVDA/JAWS, plus the 320 px / 400 % zoom sweep) — the largest remaining assessment task; the accessibility-tree simulation is done, and a concrete checklist for the live pass is in Known limitations.
  2. Non-color series differentiation for multi-series charts on small dashboard tiles (1.4.1).
  3. Surface silently-swallowed secondary errors (~160 background fetches with no user-visible failure feedback) (3.3.1).
  4. Tagged-PDF program: validate opt-in tagged output with PAC/veraPDF before enabling by default; refactor merged export packages to the PDF library's tag-preserving merge API, then re-validate the redaction burn-in path.
  5. Minor polish: persistent visible labels for the ~56 placeholder-only fields; localized strings for the Fluent ColorPicker's internal inputs; role refinement on keyboard-reorder-only rows; localize the remaining fixed Excel labels; a locale-tunable chart-summary template key.

Legal disclaimer

This document is a good-faith self-assessment provided for information purposes; it is not a certification, guarantee, or legally binding commitment of conformance. Realizer Services Inc. will update this report as the product evolves. "VPAT" is a registered trademark of the Information Technology Industry Council (ITI); this report follows the structure of the VPAT WCAG edition but was not prepared or reviewed by ITI.

Source: www.realizer.io/accessibility/conformance-report · Product version 2.0.73, assessed 2026-08-20 · See also the accessibility statement and the procurement pack.