Skip to main content
Productivity Workbench
  • Home
  • Workspace
  • AI Product Studio
  • Enterprise
  • Docs
Sign InGet Started

Accessibility Statement

Last updated: 6 October 2026

1. Our Commitment

MDTS UK Limited is committed to making Productivity Workbench accessible to as many people as possible, including those with disabilities. We aim to meet the Web Content Accessibility Guidelines (WCAG 2.2) at Level AA across all parts of the application.

2. Conformance Status

Productivity Workbench is partially conformant with WCAG 2.2 Level AA. Partial conformance means that some parts of the content do not fully meet all accessibility requirements. We are actively working to close the gap.

Priority is given to fixes that affect blind and low-vision users, screen-reader users (NVDA, JAWS, VoiceOver), keyboard-only users, users with motor impairments, and users with cognitive differences.

3. What We Have Already Implemented

Page structure and landmarks

  • lang="en" is set on the root <html> element
  • All three layout shells (workspace, organisation, public) include correct ARIA landmark regions: <main>, <aside>, <nav>, <footer>
  • A skip-link ("Skip to main content") is present at the top of every page for keyboard users
  • All <main> elements have id="main-content" and tabindex="-1" so the skip-link focus is correctly delivered

Keyboard and focus

  • A global :focus-visible outline ring is applied to every interactive element — it cannot be globally suppressed
  • The confirm / alert / prompt dialog, the feature edit popup, and the Studio code-repository connect dialog close on Escape
  • The Capture intent dialog, opened from any page or from the plus button in the Studio's phone tab bar, moves focus to its Draft with AI box, keeps Tab inside, closes on Escape and returns focus to the button that opened it. Its Draft with AI note is announced to screen readers when it appears, and once a draft is in, the focus moves to the title with the title and description brought into view. On a phone the dialog fills the screen with Capture and Cancel always in view, and its microphone and Draft buttons are at least 48 pixels high
  • The Studio set-up banner stays pinned to the top of the screen, but the page reserves its height, so keyboard focus moving back up the page is never scrolled underneath it. On short screens the banner stops pinning altogether.
  • The Studio toolbar stays pinned to the top of the screen on phones too, with larger buttons, and the page keeps its height clear so focus is never scrolled underneath it. Its panels open above the page and move focus in; they are not modal, so the toolbar stays usable: the button that opened a panel says it is expanded, pressing it again closes the panel, another button switches to its own, and Tab moves between the panel and the toolbar. Escape closes a panel and returns focus to its button. Groups that do not fit the width fold into menus that work with the arrow keys, and open below the toolbar rather than over it; a menu always stays inside the screen, and on a phone spans its width. The toolbar starts with the studio's trust level, a button named for it (for example "Trust level: Semi-auto") that opens a short explanation and moves focus into it, and the Delivery steps, a menu of the eight delivery phases in which the page's own phase is announced as the current step and every phase says in words whether it is done, next or upcoming. The repository panels are a single column with a visible Back button that takes focus when you open an item and returns it to that item when you go back; code, diffs and pipeline graphs scroll inside themselves, so the page never scrolls sideways
  • My Account has its own skip link and section navigation, and its Reduce motion and High contrast switches are announced once, with their on/off state, rather than repeating it
  • Reduced motion: all transitions and animations collapse to near-zero duration when prefers-reduced-motion: reduce is active
  • The public site menu is fully keyboard operable: Down / Up opens a section menu and moves between its links, Home / End jump to the first or last link, Tab or Escape closes it, and Escape returns focus to the button that opened it

ARIA and semantics

  • All layout-level icon-only buttons carry aria-label (mobile menu toggle, nav search, close, persona/team/profile dropdown triggers, workflow toggle, user avatar)
  • All popup close (✕) buttons across the application carry aria-label="Close"
  • All popup drag handles carry aria-hidden="true"
  • All popup panels across the application have role="dialog", aria-modal="true", aria-labelledby pointing to the popup heading, and tabindex="-1"
  • All section overlays (feature sections, story sections, epic and feature document overlays, inline Definition of Ready overlay) also have role="dialog", aria-modal="true", and aria-labelledby
  • Decorative emojis in layouts, popups, and section overlays are marked aria-hidden="true"
  • Persona dropdown items use <button role="menuitem">; the trigger has aria-haspopup="menu" and aria-expanded
  • The user avatar in the sidebar is a <button> with aria-haspopup and aria-expanded
  • Subscription tier cards use <button> with aria-pressed
  • Active workspace nav items carry aria-current="page"
  • The Studio sidebar marks the open page with aria-current="page" as well as by colour and weight, however the page was reached
  • The active step in the sidebar workflow guide carries aria-current="step"
  • The next set-up step in the Studio getting-started banner carries aria-current="step", and every step states in words whether it is done, next or still to do
  • Decorative emojis on all page titles (<h1 class="page-title">) across the application are wrapped in <span aria-hidden="true">
  • All sidebar navigation icons (nav item icons, search result icons, walkthrough and about links) are marked aria-hidden="true"

Forms

  • Auth forms (login and register) include autocomplete attributes: email, current-password, and new-password
  • All type="number" inputs include inputmode="numeric" so mobile keyboards show a numeric pad

Tables

  • scope="col" has been applied to every<th> element across all data tables, report tables, matrix tables, and comparison tables in the application
  • Every data table now has a <caption class="sr-only"> element that identifies the table's purpose to screen-reader users — covering all report tables, capacity tables, PI planning boards, skills matrices, work-intake tables, league charts, user-journey breakdowns, portfolio tables, org reports, and comparison tables

Forms

  • Required fields on login, registration, feature edit, story edit, and quick-add forms show a visible * marker beside the label — requirement is conveyed by both colour and symbol, not colour alone
  • All required inputs carry aria-required="true"
  • Auth forms include autocomplete attributes: email, current-password, and new-password
  • All type="number" inputs include inputmode="numeric" so mobile keyboards show a numeric pad

Live regions

  • The global toast container has aria-live="polite"; error toasts use role="alert" and success toasts use role="status"
  • All "Saved ✓", "Published ✓", and "Token saved ✓" confirmation spans carry role="status" and aria-live="polite" — screen readers announce them when they appear
  • On a Studio Work Package, the pull-request review toggle is a keyboard-operable native button. If an open pull request closes, its automatic collapse is announced politely; a session choice to keep it open is preserved.

Sprint board

  • Sprint board cards now display a visible icon + status label (e.g. 🔨 In Progress) — status is no longer conveyed by card border colour alone
  • Column header icons carry aria-hidden="true"; column label text is already visible
  • Story edit buttons on sprint cards carry a unique aria-label="Edit [story title]"

Studio Ideas Board

  • Everything on the collaborative canvas can be done from the keyboard: Tab moves through elements in reading order, arrow keys move the selection (Shift for larger steps), Alt+arrows resize, Enter edits, Ctrl+G groups and Delete removes
  • Single-key tool shortcuts (such as N for a note) only act while the canvas itself has focus, so they never fire while typing elsewhere (WCAG 2.1.4)
  • The Outline view presents the whole board as a list with every canvas action — edit, strike out, collapse, move into a group, link and remove — as a full alternative to dragging (WCAG 2.5.7)
  • Each element's accessible name includes its author, its state (struck out, locked, emphasised) and its connections, such as "causes Slow releases"; the connector drawing itself is hidden from assistive technology
  • Colour pens are never the only signal, text on every pen colour and on custom colours clears 4.5:1 in light and dark themes, and additions by other people are announced politely, at most once every five seconds
  • Reactions and votes work from the keyboard as well as the pointer: R opens a searchable reaction picker, + and − add or take back a vote, and the Outline view offers the same actions for every element
  • New boards start from a template gallery that behaves as a radio group: arrow keys move between templates, and each one is described in text
  • A facilitator's timer has a text alternative that says what it is for and how long is left, but is not read out every second: only "one minute left" and "time is up" are announced
  • The lock button is named for what it will do — Lock board, or Unlock board once the board is locked; when a board is locked, participants are told in text, and the actions they can no longer take are disabled rather than hidden
  • When a facilitator brings everyone to their view, a message says who moved the board and offers a button back to where you were
  • Board settings and "Ask to join" use labelled radio groups and fields, move focus into the dialog as it opens, and close with Escape

Reports — metric bars

  • All colour-coded progress bars (metric bars) across every report page carry aria-hidden="true" — the percentage value and threshold rating (Good/Warning/Poor) are conveyed in adjacent visible and sr-only text instead

Colour and visual

  • Status badges combine colour with visible text labels — information is never conveyed by colour alone
  • Every page on this public website has been tested with axe-core against the WCAG 2.0, 2.1 and 2.2 Level A and AA rule sets, and currently reports no violations. This covers all 31 public pages, including this one.
  • Muted body text and the accent colours used for phase badges, links and callouts were re-stepped so they clear 4.5:1 against the tinted card and callout backgrounds they sit on — not just against plain white
  • Your email address in My Account is shown in the standard muted text colour rather than your organisation's brand colour, so it stays readable whatever brand colour is chosen
  • The work package title block uses the page's own text colour on the card surface. The brand colour is only a bar along the top, so a light brand such as orange no longer puts white text on a pale background
  • On a work package, the dialog for adding a package to implement first returns keyboard focus to its button when it closes and announces an error once. The sample review line on the passport shows its own open and closed marker, and opens by itself when you are the person who can record the review
  • The Studio getting-started banner shows its step labels at full strength rather than faded, and highlights the next step with body text on a light tint of the theme colour, so it clears 4.5:1 in every theme
  • Links inside body paragraphs are underlined, so they are never distinguished from surrounding text by colour alone
  • In the AI Product Studio, connecting a repository through the GitHub App says every state in words with what to do next, and the result of a connection, a verification or a connection test is announced as it arrives. Its success and failure text now takes its colour from the theme's own text colour, so it clears 4.5:1 in light and dark themes alike; the tick or cross beside it is decoration and is not read out
  • In the AI Product Studio, the intent and work package maps are drawings with a second reading: every card says its state in words, the same order is given as a numbered list, and links in that list are underlined. Arrows are routed round the cards and clear of the lane titles
  • Icon buttons that show a symbol such as ✕ take the colour of the text around them, so they stay visible on the dark themes
  • @media (forced-colors: active) fallbacks ensure badges, status pills, required-field markers, and save-confirmation indicators remain visible in Windows High Contrast mode
  • Charts on the AI Delivery Lifecycle page pair every colour with a direct label, a legend, and a visually-hidden data table carrying the underlying figures

Touch targets

  • Icon buttons (.btn-icon and .btn-icon-sm) enforce a minimum size of 24×24 CSS pixels via min-width, min-height, and centred flex layout — meeting WCAG 2.5.8
  • The public header's Enterprise sub-menu control also meets the 24×24 minimum

AI Product Studio on a phone

  • On a phone the Studio has a tab bar at the bottom of the screen for its main pages, with a Menu tab that opens the full menu. Each tab is at least 64 by 55 CSS pixels, and the tab for the open page is marked by weight and a bar as well as being announced as current. The Intent and Package tabs go back to the last one you opened, and say so to a screen reader
  • Opening the menu from Menu moves the focus into it. Escape, the Menu tab or a tap outside closes it and returns the focus to Menu. The page behind cannot take the focus while the menu is open, and the closed menu is out of the tab order
  • On a phone each item of a work package's Definition of Ready and Definition of Done is laid out down the screen, so its words are read in full at 320 CSS pixels wide (WCAG 1.4.10)
  • Nothing is hidden beneath the tab bar: a control that takes the focus is scrolled clear of it (WCAG 2.4.11)
  • The Ideas Board fills a phone's screen and is moved with one finger and zoomed with a pinch. The zoom buttons zoom without a pinch, and the Outline lists every element on the board and brings any of them into view
  • An intent's page is five tabs. The arrow keys move along them, Home and End go to the ends, and each tab says where its part stands in words as well as an icon. A part you leave keeps what you typed in it
  • Compact view, on by default on a phone, puts the Studio's explanations behind ⓘ buttons and its less used filters behind a Filters button. Each ⓘ and the Filters button opens by tap, click or keyboard, says whether it is open, and closes on Escape with the focus back on it. The Filters button says how many filters are in use. It can be turned off from the Studio menu or on Account › Accessibility

Reflow

  • The Studio getting-started banner reflows down to 320 CSS pixels wide: its list of set-up steps wraps onto new lines instead of scrolling sideways, and it no longer forces the page wider than the screen (WCAG 1.4.10)
  • Every page of the signed-in application that can be opened directly (163 pages across workspaces, studios, organisations and system administration) has been checked at 320 CSS pixels wide, equivalent to 400% zoom on a typical laptop, and none scrolls sideways. Tab rows wrap, side panels stack above the main content, and card grids drop to a single column.
  • Filter bars on list pages, such as Features, move their main action onto its own line at narrow widths, so the page still fits a 320-pixel screen when a wider system font is in use
  • A table wider than the screen, such as the Intent Pad's List view on a phone, scrolls sideways inside its own box; the page around it stays the width of the screen

AI Assistant controls

  • The AI Assistant trigger button carries aria-label="Open AI Assistant" and is hidden from the accessibility tree when the AI capability is disabled
  • The AI guidance popup is a proper role="dialog" with aria-modal="true" and aria-labelledby pointing to the popup heading, and closes on Escape
  • The undo AI button carries aria-label="Undo last AI change"; it is disabled (not hidden) when there is nothing to undo so its state is correctly conveyed to assistive technology
  • AI status messages (thinking spinner, error messages) use role="status" and aria-live="polite" so screen readers announce them when they change
  • The unsaved-changes modal (shown when navigating away with pending AI changes) uses role="alertdialog" and aria-modal="true"

4. Known Limitations

The following issues are known and on our roadmap. We welcome reports if you encounter additional barriers.

Keyboard access

  • Focus is not yet trapped inside open popups — keyboard focus can escape behind the backdrop
  • Most edit popups do not yet close on Escape. Focus is not moved into the dialog when it opens, so the key is not received. Use the close button in the popup header until this is fixed.
  • Drag-and-drop on sprint boards, feature boards, and story maps has no keyboard-accessible alternative (move up / move down / change column)
  • The Studio Ideas Board canvas has not yet been checked with axe-core
  • In the AI Product Studio, the three-dots actions menu on boards, intents, workstreams and work packages, the delete dialog, the merge dialog and the archive view are built to be used from the keyboard: the arrow keys, Home, End and Escape work in the menu, and each dialog holds focus and closes on Escape. We have not yet tested them with a screen reader, so we do not claim they conform. Please tell us if they do not work for you.
  • On a work package's Coding tab (named Delivery before October 2026), the implementation plan's dialogs (approve, ask for changes, reject) and the dialog that closes a coding run move focus in as they open and close on Escape, and the planning modes on the Dispatch panel are a labelled group of radio buttons, each with its reason when it cannot be chosen. Focus is not held inside these dialogs, and we have not yet tested them with a screen reader, so we do not claim they conform.
  • The month field in the Studio archive view has no calendar picker in desktop Firefox and Safari. It becomes a plain text box that takes a month typed as YYYY-MM. The Previous month and Next month buttons, and the list of months that have items, work in every browser.

ARIA labelling

  • Some forms use label text without explicit for / id pairs — association relies on label wrapping only

Forms

  • Some forms use label text without explicit for / id pairs — association relies on label wrapping only
  • Validation errors do not yet reference the failing field via aria-describedby or use role="alert"
  • Icon buttons inside edit popups do not yet carry individual aria-label attributes
  • Keyboard focus is not yet trapped inside open popups

Tables

  • Complex pivot / cross-tab tables (e.g. the PI planning team×sprint board with dynamic column headers) may not be fully navigable by screen readers — consider providing a linearised view or summary

Colour and visual

  • The automated sweep described above covers this public website only. Pages inside the signed-in application have not yet been swept to the same standard, and we expect some contrast issues remain there.
  • The muted-text colour has been corrected across the seven light branding themes. The five dark themes (Geeky, Midnight, Charcoal, Nebula and Carbon) have not yet been fully audited for WCAG 4.5:1 contrast. We are fixing dark-theme issues page by page as we find them.
  • In five of the twelve branding themes (Fun, Geeky, Hobby, Creative and Carbon), the text on primary buttons does not yet reach 4.5:1 contrast against the button colour. The Professional, Minimalistic, Ocean, Sunset, Midnight, Charcoal and Nebula themes are not affected.
  • Our 320-pixel check used new, mostly empty workspaces and studios. Pages holding a lot of data, wide tables and boards in particular, may still need horizontal scrolling at that size. Pages for individual records have not yet been checked.
  • Automated testing catches roughly a third to a half of accessibility problems. A clean axe-core result is a floor, not a guarantee — we still rely on manual keyboard and screen-reader testing, and on reports from you.

5. Browser and Assistive Technology Support

We aim to support the following combinations:

Supported browser and screen reader combinations
BrowserScreen ReaderOperating System
Chrome (latest)NVDA 2024+Windows
Edge (latest)JAWS 2024+Windows
Safari (latest)VoiceOvermacOS / iOS
Firefox (latest)NVDA 2024+Windows

The application relies on JavaScript for all core functionality. If JavaScript is disabled, the application will not function.

6. Requesting an Accessible Format

If you need information from Productivity Workbench in a different format — such as accessible PDF, large print, audio recording, or plain text — please contact us:

  • Email:contact@productivityworkbench.com
  • We will respond within 5 working days.

7. Reporting Accessibility Issues

We welcome feedback on accessibility barriers you encounter. Please report any issues to contact@productivityworkbench.com with a description of the barrier, the page URL, and the assistive technology you were using.

8. Enforcement Procedure

If you are dissatisfied with our response to an accessibility concern, you can contact the Equality and Human Rights Commission (EHRC) if you live in England, Scotland, or Wales; or the Equality Commission for Northern Ireland (ECNI) if you live in Northern Ireland.

9. Contact Us

  • Email:contact@productivityworkbench.com
  • Website:productivityworkbench.com
  • Company: MDTS UK Limited, registered in England and Wales
Productivity Workbench
HomeProduct WorkspaceAI Product StudioFeaturesSmall TeamsBusinessEnterpriseDelivery LifecycleVibe Coding CurseTrust CentreStatusChange LogPricingAbout UsBrandDocsSign InCreate Account
Privacy PolicyTerms of UseTrust CentreSecurityAccessibility

© 2026 Productivity Workbench. Built for Product Owners, by Product Owners.

© MDTS UK Limited · A bespoke website by MDTS

Build v0.3.2 · deployed 2026-10-19T23:52:31Z