13. Building Accessibility into Your Workplace

Accessibility lasts when it stops being a special task and becomes the normal way your office works — and when your own colleagues with disabilities can do their jobs without barriers.

Make it routine, not an afterthought

  • Create accessible templates for documents, slides, and emails, with heading styles, fonts, and contrast already set — so every new file starts accessible.
  • Add an “accessibility” step to your publishing and sign-off routine (use the master checklist and the Excel tool that accompanies this handbook).
  • Set sensible defaults: real heading styles, a readable font size, and a reminder to add alt text.

Support employees with disabilities

  • Ask about access needs — when people join and as an ongoing question — rather than assuming. Let them tell you what works for them.
  • Make sure the systems staff use every day (intranet, HR portal, shared drives, chat, time-sheets) work with a keyboard and a screen reader. If they don’t, raise it with your IT team or the vendor.
  • Provide internal documents in the format each person needs — accessible PDF, large print, or plain text.
  • Run accessible meetings: captions on, agendas and slides shared in advance (Chapter 9).

Buy accessible tools

You cannot make a tool accessible after you have bought it, so build accessibility into procurement:

  • When choosing software or a platform, ask the vendor for a VPAT / Accessibility Conformance Report, and prefer tools that support screen readers, keyboard use, and captions.
  • Pilot the tool with the people who will rely on assistive technology before you commit.

Questions to ask a vendor

Copy these into your tender, RFP, or purchase form, and weigh the answers — vague replies are a warning sign.

  • Standard & evidence: Which version and level of WCAG does the product meet — we require 2.1 / 2.2 Level AA — and can you share a current VPAT / Accessibility Conformance Report?
  • Real-user testing: How do you test for accessibility, and do you test with people who use assistive technology?
  • Independent audit: Has a third party evaluated the product’s accessibility?
  • Coverage by need: How well does it work for people who are blind or low-vision, Deaf or hard of hearing, or have limited mobility, dexterity, or speech — specifically, not just “it’s accessible”?
  • Mobile: Are your mobile apps built and tested for accessibility too?
  • The “accessible mode” trap: If there is a separate accessible mode or alternate interface, can a person using assistive technology turn it on independently? (One inclusive interface is better.)
  • Fix guarantee: If we find accessibility problems, will you fix them before go-live, on an agreed timeline? Put it in the contract.
  • Experience & roadmap: What accessibility experience does your team have, and do you have an accessibility roadmap?
  • References: Can you give reference customers who cared about accessibility, that we can contact?

Publish an accessibility statement

Tell people you are committed to accessibility and give them a way to reach you. A short accessibility statement — on your website, or pinned on your main channel — builds trust and is increasingly expected by law (the EAA, the ADA) and by funders.

  • State your commitment and the standard you aim for (WCAG 2.1 / 2.2 Level AA).
  • Note any known limitations you are still working on.
  • Give a way to report a barrier or request another format — an email, phone number, or form — and a timeframe for replying.

Give it an owner and keep going

  • Name an accessibility focal point (or a small group) responsible for templates, training, and questions.
  • Train new staff on these basics, and review your content periodically with the checklist — accessibility is ongoing, not a one-time fix.

Workplace checklist

  • Accessible templates exist for documents, slides, and emails.
  • Accessibility is a step in your sign-off routine.
  • Staff are asked about access needs; needs are met in the right format.
  • Everyday internal systems work by keyboard and screen reader.
  • New software is checked for accessibility (VPAT) before purchase.
  • Accessibility is a condition in the contract (a remediation guarantee before go-live).
  • An accessibility statement is published with a way to report barriers.
  • An accessibility focal point is named; reviews happen regularly.