Accessibility Statement

Last updated: 3 November 2026, for DirectoryPoint 1.0.0

What this statement covers

The DirectoryPoint app, in the package directorypoint.sppkg: the SharePoint web part, the SharePoint full-page app, the Microsoft Teams tab and the Microsoft Teams personal app, and the four Viva Connections dashboard cards (Find someone, Your favourites, New joiners and Celebrations today). Help in DirectoryPoint links to this page, under Guides and support.
This website, directorypoint.app, which has its own section and checks below.
Not covered: SharePoint, Microsoft Teams and Viva Connections themselves, which have Microsoft's own accessibility statements, and AI agents your organisation lists, which have their makers' own.

Standard and approach

DirectoryPoint is built and tested against the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA. That is the target we test against, not a certified claim: no independent audit has been done yet, and the known gaps are listed below. An organisation can ask us for this statement when it assesses DirectoryPoint for its own accessibility duties.

How DirectoryPoint is built

Fluent UI. Microsoft's Fluent UI v9 controls, the same family as SharePoint and Teams, each with its own keyboard and screen reader behaviour. DirectoryPoint adds no custom control where Fluent has one.
Colours from the theme. Colours come only from Fluent's theme tokens (no raw colours except the brand mark), so SharePoint's light and dark sections, the site's theme colour (used only when white text on it reaches 4.5:1), the Teams default, dark and high contrast themes and Windows high contrast (forced colours) are all followed. Nothing is said by colour alone: presence, badges (External, Agent, Sample, New joiner), answers in Who's Who and chosen collections carry words or icons too.
Initials. People without a photo, and every fictional person, get their initials on a colour; the initials' colours were checked for contrast in every theme.
Keyboard. Tab and Shift+Tab move between controls; arrow keys move inside tab lists, menus and the org chart tree; Enter and Space activate; Escape closes a dialog, drawer or quick view and returns the keyboard to the control that opened it. Ctrl+K or "/" opens search from anywhere. When a page changes because of a button inside another page, the keyboard moves to the new page's heading, never to the page body. Lists that lose a row (a removed favourite, an accepted kudos, a decided change request) keep the keyboard in place.
The Discover deck (WCAG 2.5.1, 2.5.7 and 2.5.8). Every swipe has a visible button (Undo, Skip, Open, Save) and a key (S, X, O, Z, L and the arrow keys), each action is announced in words, buttons are at least 24 by 24 pixels, vertical scrolling is never taken over on touch screens, and with reduced motion the card crossfades instead of flying.
The org chart has two views: the drawn chart and an accessible tree (arrow keys, Enter to centre on a person, P to open their profile), which is the default on narrow screens and for screen readers.
Labelled screens. One navigation landmark with the current page selected, each page in a region named after it, dialogs and the profile drawer with their titles, and row buttons that name their row ("Open the profile of ..."). Two DirectoryPoint web parts on one page keep unique landmark names and IDs.
Status in words. Result counts, saves, errors and every change are spoken once through one polite live region, and repeated words are spoken again.
Reflow. Text and layout reflow from 320 px wide (WCAG 1.4.10): one column, the navigation's More menu, tables in their own labelled scrolling regions and wrapping tab lists; nothing scrolls the whole page sideways. Text follows browser zoom.
Motion. Only short page transitions and the deck's card, all following the device's reduced-motion setting.
Time. Nothing times out while someone is reading or typing; Who's Who has no clock (only a minimum answer time that stops guessing from scoring); messages that disappear repeat what the live region already said.
The Viva Connections cards are Adaptive Cards drawn by SharePoint, Viva Connections and Teams, so their focus order, keyboard and screen reader behaviour are the host's. DirectoryPoint gives every card element words: each person row's action is named "Open the profile of (name) in DirectoryPoint", initials images have empty alternative text next to the name, and every button has a text title.

What is tested, and how often

Accessibility checks of the DirectoryPoint app
Check	How	When
Automated rules (axe-core 4.10.3)	Each screen rendered with an in-memory SharePoint and Microsoft Graph: set-up wizard, shell and navigation, Home, People with filters, the profile, the org chart (chart and tree), Discover and every deck, Favourites and collections, Celebrations, Agents (Find help, cards, Manage, CSV import), Settings (every section), Help and the tour, Data health, change requests, external contacts, the snapshot, Who's Who, offices and departments, About you and the name recorder, Kudos and Usage; in light, dark, Teams dark and Teams contrast	Every build; a failure stops the release
Landmarks on every page	Every page drawn inside its named region, with the landmark rules of axe	Every build
Visual snapshots	Every screen over the Demo directory in five themes (web light, web dark, Teams default, Teams dark and Teams contrast), at 1366, 430, 375 and 320 px and with forced colours, opened in Edge and Firefox, with axe in the page	In each Experience quality pass
Keyboard walk-throughs	The main tasks by keyboard only, live on our test site: search, profile, org chart tree, the deck, favourites and collections, Who's Who, kudos, settings and help	In each Experience quality pass
Reflow	Every page at 320 px live: nothing past the edge, no whole-page sideways scroll	In each Experience quality pass
Contrast	Text against its painted background, live, in light and the Teams themes; badges and initials colours in the dark and contrast themes	In the quality passes before 1.0

Automated rules in the test runner cannot compute colour contrast (it has no layout), so contrast is checked in real browsers; the landmark "region" rule is off there because a web part always sits inside SharePoint's own landmarks. Automated rules find many problems but not every one, which is why the known limits below include what has not yet been checked by hand.

Known limits

What does not work well yet, and what to use instead
Area	Limit	What to use instead
The name recording	Recording needs a microphone; Teams on phones cannot record	The phonetic spelling is plain text beside the name and always shown; recording is optional, and Teams on a phone links to the SharePoint page
The drawn org chart	A chart of boxes and lines	The accessible tree view of the same chart (List view), and every person's manager and reports on their profile
Usage trends	Bar charts are pictures of numbers	"Show as a table" gives every number in a table, and each tile states its total in words
Photos	Photos have no description beyond the person's name	The name, job title and department are always next to the photo
Screen readers	Names, roles and states are checked in the page and by axe; a full run with NVDA, JAWS, Narrator and VoiceOver has not been done yet	Planned for the first update. Please report any problem (below)
Windows high contrast in Teams	Teams' own contrast theme and forced colours are covered by tests and snapshots, not yet seen live inside the Teams desktop app	Planned for the first update
Viva Connections cards	Their keyboard and screen reader behaviour is the host's (Adaptive Cards in Viva Connections and Teams)	The same people and actions on the DirectoryPoint page
SharePoint and Teams	The page around DirectoryPoint (SharePoint's navigation, Teams' own frame) is Microsoft's	Microsoft's accessibility statements for SharePoint and Teams

This website

Plain HTML from our server, with a skip link, one main heading per page, landmarks for the header, navigation, main content and footer, and a visible focus outline on every link and button.
Every page reflows at 320 px without sideways scrolling, text can be enlarged with the browser, and colours meet the AA contrast ratios in light and dark mode. In Windows high contrast, buttons and cards keep their outlines.
Screenshots and drawn product pictures have a text description of what they show, and decorative icons are hidden from screen readers. Screenshots show fictional people only, as initials.
Any short animation of a drawn picture plays once, only when your device allows motion, and finishes within five seconds. With reduced motion none plays at all. Screenshots never move.
Questions and answers use the browser's own disclosure control, which works with the keyboard and screen readers.

Accessibility checks of this website
Check	How	When
Automated rules (axe-core: WCAG 2.0, 2.1 and 2.2 at A and AA, and best practice)	Every page at 320, 375 and 1280 px, in light and dark mode, in a real browser	Every release, and again on the live site after each update
Reflow	No sideways scroll and nothing cut off on any page at 320 and 375 px	Every release, and after each update

Report a problem

Tell us through DirectoryPoint support and say it is about accessibility, or email info@apps365ltd.com. Please say which page or screen, what you were trying to do, and the browser or assistive technology you use, if you know it.