Project Management Software Accessibility: What to Check

What does accessibility mean for project management software?

project management software accessibility is a key topic in modern project management and teamwork. Accessible project management software can be operated end to end without a mouse, read correctly by a screen reader, understood without relying on color, and used at 200% zoom or on a narrow screen. The practical target is WCAG 2.2 Level AA.

That is a functional definition, not a legal one. Accessibility is not a settings panel bolted onto a product; it is whether a specific person can create a task, reassign it, read its history, and export a report. If any step in the core loop fails, the tool is inaccessible for that person regardless of how many other screens pass.

Which standards actually apply?

WCAG 2.2 is published by the W3C and organised into four principles: perceivable, operable, understandable, and robust. Each success criterion carries a level: A (minimum), AA (the common legal and procurement benchmark), or AAA (enhanced, rarely required in full).

Three legal frameworks show up in PM software purchases:

• EN 301 549 is the European harmonised standard for accessible ICT. It incorporates WCAG 2.1 AA for web content and sets requirements for software and documents.
• The European Accessibility Act (Directive (EU) 2019/882) has applied since 28 June 2025. Its scope is consumer-facing products and services such as e-commerce, banking, e-books, and transport — a B2B project tool is usually outside it directly. But if you sell into EU public bodies, EN 301 549 tends to appear in the contract regardless.
• Section 508 applies to US federal agencies. In practice it means vendors are asked for a VPAT, now usually published as an Accessibility Conformance Report.

The pattern is consistent: buyers ask for WCAG 2.2 AA evidence, and vendors either have it or improvise.

Which WCAG 2.2 criteria break most often in PM tools?

The failures cluster. In our review of the criteria that matter for boards, task lists, and timelines, a dozen do most of the work. Note the levels carefully — a checklist that mixes A, AA, and AAA without labels is a checklist nobody can enforce.

Two rows deserve emphasis because they are new in 2.2 and rarely handled: 2.5.7 does not ban drag-and-drop, it requires an equivalent single-pointer path such as a “Move to column” menu. 2.5.8 does not demand large buttons everywhere, but any target under 24×24 must be spaced so that a 24 px circle centred on it does not intersect a neighbouring target.

What is AAA, and should you demand it?

AAA criteria are enhanced requirements, and some are impossible to apply to all content — 1.4.6 asks for 7:1 text contrast, and 2.5.5 asks for 44×44 CSS pixel targets. Full AAA conformance is not a realistic procurement requirement for a complex web application.

Two AAA criteria are still worth naming as design goals: 2.5.5 Target Size (Enhanced) at 44×44, and 2.4.13 Focus Appearance, which defines a minimum visible focus indicator. Treat them as differentiators, not deal-breakers, and never let a vendor claim “AAA compliant” without specifying which pages and which version.

Why is the board the hardest screen?

The board concentrates almost every hard accessibility problem into one view: spatial layout, drag interaction, color-coded status, live updates, and dense targets.

Drag-only reordering is the classic failure. Moving a card between columns is a pointer gesture with no keyboard equivalent unless the product exposes one. A menu item, a keyboard grab-and-move mode, or a position field all satisfy 2.5.7. Nothing else does.

Virtualized lists render only visible cards for performance. Screen readers then meet a list that changes size as they navigate, and “3 of 47” announcements become unreliable. Fixing this needs explicit item counts, stable roles, and careful use of `aria-setsize` and `aria-posinset`.

Color-coded status fails 1.4.1 whenever the only difference between “blocked” and “at risk” is hue. A label, an icon, or a pattern is required, and it helps colour-blind users too.

Live updates fail 4.1.3 when a card moves or a filter changes and nothing is announced. A polite live region saying “Moved to In Review, position 2 of 6” is the difference between a usable board and a silent one.

Sticky chrome fails 2.4.11 when the focused row scrolls under a fixed header. It is a small CSS fix with a large effect for keyboard users, and it is one of the most commonly missed 2.2 additions.

> Practical tip: When a vendor demos a board, ask them to move a card with the keyboard only, then ask what a screen reader announces after the move. The pause before the answer tells you as much as the answer.

How do you test a tool in under an hour?

Test the core loop, not the marketing site. Sign up for a trial, create a project with three columns and six tasks, and run these checks in order. Each has a pass condition you can record.

Stage 1 — keyboard sweep (15 minutes). Unplug the mouse.

1. Tab from the browser address bar to “create task”. Pass: reachable, logical order, visible focus at every step.
2. Create a task, assign an owner, set a due date, add a comment. Pass: all fields reachable and editable, no keyboard trap in the modal.
3. Move a task between columns without dragging. Pass: a menu, shortcut, or position field exists.
4. Delete the task. Pass: confirmation dialog is keyboard operable and focus returns sensibly.

Stage 2 — zoom and reflow (10 minutes).

1. Zoom to 200%. Pass: no clipped text, no overlapping controls, no lost functionality.
2. Set the window to 320 CSS px wide (or 400% zoom on a 1280 px screen). Pass: main content reflows without horizontal scrolling.
3. Check text spacing tolerance by applying a bookmarklet that increases line height and letter spacing. Pass: nothing overlaps.

Stage 3 — contrast and targets (10 minutes).

1. Sample five text colours and three status chips with a contrast checker. Pass: text ≥4.5:1 (≥3:1 for text 18pt or 14pt bold), UI boundaries and icons ≥3:1.
2. Measure the three smallest clickable controls in the card menu. Pass: ≥24×24 CSS px, or spaced so 24 px circles do not intersect.

Stage 4 — screen reader smoke test (10 minutes).

1. With NVDA on Firefox or VoiceOver on Safari, navigate to the board. Pass: columns and cards announce name, status, and assignee.
2. Move a card and listen. Pass: the change is announced without moving focus.
3. Submit an invalid date. Pass: the error is announced and says how to fix it.

Stage 5 — account and session (5 minutes).

1. Log in with a password manager. Pass: autofill works and paste is allowed.
2. Idle on a half-filled form for 30 minutes. Pass: a warning appears with an option to extend.

Fourteen checks will not prove conformance, but they catch the issues that make a tool unusable — which is the decision you are actually making.

What do the numbers look like?

Three worked examples, all arithmetic on stated assumptions.

Example 1: contrast is measurable, not subjective

White `#FFFFFF` has a relative luminance of 1.0. Mid-gray `#767676` computes to about 0.181, giving a contrast ratio of (1.0 + 0.05) ÷ (0.181 + 0.05) = 1.05 ÷ 0.231 = 4.54:1, which passes AA for normal text by a hair.

The lighter `#999999` computes to about 0.319, giving 1.05 ÷ 0.369 = 2.85:1 — a fail for normal text and even for large text. One shade is the difference between a label readable in sunlight and one that is not, which is why “it looks fine on my monitor” is not a test.

Example 2: target size and spacing are geometry

A card menu uses 20×20 px icon buttons with 2 px gaps. Each is under 24×24, so 2.5.8 applies its spacing exception: a 24 px circle centred on each target must not intersect its neighbour.

The centres are 20 + 2 = 22 px apart. Two 24 px circles need at least 24 px between centres to avoid intersecting, so 22 px fails. Either raise the buttons to 24×24 or increase the gap to 4 px so centres sit exactly 24 px apart — and prefer the larger target, because tangent circles are the minimum, not the goal.

Example 3: the cost of one excluded teammate

A 30-person team includes one person with a tremor who needs keyboard-only operation. If the board forces drag-and-drop, she spends about 45 minutes a day asking colleagues to update her tasks. That is 3.75 hours a week, or roughly 180 hours a year.

At a $65 loaded hourly rate, that is about $11,700 a year of lost capacity — before counting the colleague’s interruption cost or the retention risk. A procurement clause asking for 2.5.7 support costs an email and a conversation. The comparison is not close.

What should you ask the vendor?

Ask for evidence, not adjectives. Five questions separate mature vendors from confident ones.

1. Do you have a current accessibility conformance report? Look for a VPAT 2.5 INT or an ACR that names WCAG 2.2 Level AA, the product version, and the audit date. A report from 2019 citing WCAG 2.0 answers a different question.
2. Who performed the evaluation, and what was the method? A third-party audit with manual assistive-technology testing is stronger than an automated scan. Automated tools catch a minority of issues; the WebAIM Million 2026 analysis found 95.9% of the top million home pages had detectable WCAG failures, and those are only the detectable ones.
3. What are the known gaps, and when will they close? Every real product has gaps. A vendor with no gaps either has not tested or is not telling you.
4. Is the mobile app covered? A conformant web app and an unlabelled mobile board is a common split.
5. Do you test with disabled users, and is there a public accessibility statement with a contact route? Statements with a feedback channel create accountability; badges do not.

Put the answers in the contract, not the meeting notes. A clause requiring WCAG 2.2 AA for the procured modules, a current ACR at renewal, and a remediation plan for Severity 1 issues is short and enforceable.

What is a realistic target?

Set WCAG 2.2 AA for the web application and the mobile apps, with a documented list of exceptions, an owner, and a remediation date. That is what auditors, public-sector buyers, and internal accessibility teams expect.

Document exceptions honestly: a Gantt chart may offer a table-view alternative instead of full reflow, which is acceptable if stated and usable. What is not acceptable is an unqualified conformance claim that collapses at the first keyboard test.

If your organisation has no accessibility policy, start with four sentences: AA target, annual audit, published statement, named owner, and a route for users to report barriers. That beats a 40-page framework nobody reads.

What are the most common mistakes?

• Buying an overlay widget. Overlays do not fix missing keyboard support or broken semantics, and they are widely criticised by disability advocates. They change the symptom in a screenshot, not the experience.
• Accepting a VPAT without reading the remarks column. The remarks are where “partially supports” lives, and “partially supports” usually means “does not.”
• Forgetting the mobile app. Field teams use phones; a keyboard-perfect desktop client with an inaccessible mobile board still excludes people.
• Treating AAA as the bar. Demanding 44 px targets and 7:1 text everywhere stalls procurement without helping users more than solid AA work.
• No named owner after purchase. Accessibility decays with every redesign unless someone owns the regression tests.

Where does Doitify fit?

Doitify brings tasks, sub-tasks, boards, calendars, documents, and reports into one workspace, which is exactly the kind of surface where accessibility has to be designed rather than added.

We are not going to claim conformance in an article, and you should not accept such a claim from any vendor. Run the fourteen checks above on a trial, and ask us — as you would ask anyone — for the current accessibility documentation, the known gaps, and the remediation dates. Doitify is our product, so weigh that bias; if your organisation has a hard AA requirement, the conformance report and your own test matter more than any product page.

Conclusion

Accessibility in project management software is a procurement decision with a long tail. The wrong choice is invisible in a demo; it appears months later as one teammate who cannot move a card.

Use WCAG 2.2 AA as the bar, check the criteria that break boards — 2.5.7, 2.5.8, 2.4.11, 2.1.1, 1.4.3, 4.1.3 — and run the fourteen checks on a trial before you sign. Ask for a dated conformance report with named gaps, and put the requirement in the contract with an owner and a review date.

The test costs less than an hour. The alternative is discovering the problem after someone has already built a workaround around your software.

If this post on project management software accessibility was helpful, you might also enjoy Project Management Software for Digital Agencies: 2026 Guide and Workplace Productivity Statistics for 2026.