Accessibility for Project Managers - what you can check

Stuart Harland

10 May 2025

Accessibility - it isn’t just a developer’s job

When people talk about accessibility on the web, some assume accessibility is just job or concern for developers or designers only - something tackled with mark-up, fancy code, or colour choices. But the truth is, creating an accessible product is a team effort, and project managers are in a perfect position to make a big difference.

You don’t need to know WCAG inside-out or test with lotd of assitive tech to spot potential issues or keep accessibility in mind throughout a project. In fact, many useful things you can do happen well before anyone touches any code.

This article is for anyone involved in shaping and delivering a project - whether you’re a project manager, account handler, or dealing with content. It shares a few practical ways you can help support accessibility right from the start.

Kick-off - set expectations and ask the right questions

It’s essential to factor accessibility in from the earliest planning stages. That means bringing it up in briefs, requirement gathering sessions, and kick-off meetings - not waiting until QA, when fixing things is harder, slower, and definitely more costly.

What to do:

• If it isn’t already, raise accessibility as a requirement and explain why it matters - it helps avoid last-minute fixes and shows the client you’re thinking about quality, inclusion, and reach from the start.
• Make sure WCAG 2.2 compliance is included as part of the project quality expectations - WCAG is a benchmark for what ‘accessible’ means, and helps align the whole team on what to aim for.
• Check that timelines allow space for proper testing, including accessibility checks at different stages (design, front-end, pre-go-live etc.) - rushing through testing means accessibility issues often get missed or flagged too late to fix easily.
• Encourage the client (and your team) to think beyond legal compliance (inclusion, usability, audience reach) - it’s not just about ticking boxes, accessibility improves the experience for everyone.

What to flag:

• Any notion that accessibility is ‘extra’ or ‘nice to have’.
• Overly tight deadlines that leave no time for feedback or sufficient iteration.
• Clients making assumptions like ‘but our users won’t need this’ - accessibility benefits everyone.
• Projects with no clear QA or review phase.
• Teams relying on automated tools only for their accessibility checks.

During content planning

Content plays a huge role in accessibility, and many common issues can be avoided with early planning - whether it’s unclear structure, inaccessible media, or relying on content that never gets updated.

What to check:

• When planning content and layout - are headings being thought about in a structured logical order (H1, H2, H3)? - Headings aren’t just visual - they help users (and screen readers) understand the structure of the page and can be used for page navigation.
• Is there important content embedded only in images (e.g. planned use of infographics with no summary)? - If important content is locked into an image, some users will miss it - always provide the text version too.
• Are animations or auto-playing videos going to be used - do they flash, loop, or distract? - Movement can cause problems for some users - it should be optional, kept brief, and never overwhelming.
• Are descriptions or transcripts being provided for images, videos, and audio? - These additions support users who can’t see or hear the media and go a long way to help with SEO too.

What to flag:

• Placeholder content (e.g. ‘Lorem Ipsum’) that risks going live without updates - always try to get real-world content from the client to use upfront.
• Jargon-reliant or overly complex language instead of more straightforward alternatives.
• PDFs or documents being used for crucial information instead of web content. These can often be inaccessible and need checked too, or converted for the web.
• Plans to use video/audio with no transcripts or captions.
• Images with no planned alternative text or meaningful descriptions.

During design & development

You don’t need to be a designer or developer to know when something might be difficult to read, interact with, or understand. Even a quick review can help catch usability issues early.

What to check:

• Is text large and clear enough? - If users have to zoom in or strain to read, it’s a huge barrier - especially on smaller viewports.
• Does the colour contrast make things easy to read? Use tools like WebAIM’s Contrast Checker or browser extensions like Silktide Accessibility Checker. - Low contrast is one of the most common accessibility issues and is easy to catch with simple tools.
• Are buttons, links, and interactive elements easy to spot and large enough to tap? - Small buttons are extremely frustrating - especially for mobile or touch users.
• Are there visual cues beyond colour (e.g. underlines on links, text to accompany icon use)? - Relying on colour alone can confuse people with visual impairments - add extra cues that things are interactive.
• Are there vague calls-to-action or links with text like ‘click here’ or ‘read more’? - Links should make sense on their own, so be clear about what the user will get when they click or interact.
• Is there use of text over image backgrounds? Is there enough contrast? - Text on busy background images can easily become unreadable, so always check contrast and clarity.
• Do videos auto-play? Do carousels automatically rotate? Are any animations overly distracting? - Give users control over any movement - it helps them focus and avoids causing sensory overload.
• Is there a visible focus state indicator on all interactive elements? Tab through the page to check these. - Keyboard users rely on visible focus to navigate, so if it’s missing, the site can become unusable. This is often overlooked.

What to flag:

• Use of low-contrast colours or very light colour text.
• Interfaces that rely on hover alone - which don’t work on touch devices.
• Overcomplicated UI patterns with no clear interaction model.
• Forms with hidden labels or icon-only buttons.#
• Use of vague action text like ‘click here’

During testing and sign-off

By the time a site or feature hits testing, many accessibility issues may already be baked in - but that doesn’t mean you can’t still catch and raise them. Even some very basic manual testing can highlight common problems.

What to do:

• Try navigating the site using just a keyboard (using Tab, Shift + Tab, Enter, Esc). Can you reach everything on a page? - Not everyone uses a mouse, so if you can’t get to something with just a keyboard, others can’t get to it either.
• Use free accessibility tools like WAVE or axe DevTools to scan pages and flag issues. - These tools catch common issues quickly and are great for a first review, even if you’re not technical.
• Check any site forms (search, contact forms, newsletter sign-up etc.). Are clear labels visible? Do error messages appear clearly and helpfully? Are required fields marked upfront? - Good form design helps everyone, and confusing forms are a huge barrier for many users.
• Test common journeys for interruptions or confusing interactions (e.g. pop-ups or modals that won’t close, elements that disappear when focused). - Watch out for anything that traps users or breaks the flow - it’s frustrating to get stuck in a task or journey.

What to flag:

• Interactive elements that can’t be focused or activated with a keyboard.
• Missing labels or confusing form errors (e.g. ‘Oops, something went wrong’ with no detail or context).
• Popups or overlays that trap keyboard users or ones that don’t close properly.
• Forms that don’t announce errors or updates properly to screen readers.
• ‘Keyboard traps’ in custom UI components/elements - e.g. mega-menus, dropdowns, or modals you can’t tab out of or close easily.

Post-launch

Accessibility doesn’t end at go-live. Many sites are maintained over months or years, and features continue to evolve. As a project manager, you can help make sure accessibility continues to be considered as the project evolves.

What to do:

• Encourage accessibility checks during updates or adding post-go-live features - Accessibility isn’t a one-off task, so keep it in mind for future changes and additions.
• Monitor support tickets or analytics for signs of usability issues - Repeated user issues or drop-offs could point to hidden accessibility problems.
• Encourage feedback that includes users with diverse needs - Feedback from a wide range of users helps uncover issues you might not spot internally.
• Raise accessibility as a strength in case studies and reporting - It shows clients that your team cares about quality, inclusion, and doing things the right way.

What to flag:

• Bring up any updates made directly by clients or third parties that have had no accessibility review.
• New components or third-party plugins that haven’t been tested.

Conclusion

You don’t need to be overly technical to make a real impact. Just by keeping accessibility in view throughout the project - from early scoping and planning through to testing and launch - you can help steer things in a more inclusive direction.

Asking thoughtful questions, spotting potential issues early, and making space for accessibility along the way just leads to better outcomes for everyone. It improves quality, and helps the output reach more people. Most importantly, it shows that you care - not just about delivering the project, but about making it work for anyone who wants to actually use it.

References & Tools

• WCAG 2.2 Guidelines
• WebAIM Contrast Checker
• WAVE Accessibility Tool
• axe DevTools by Deque
• Silktide Accessibility Checker
• NVDA Screen Reader