Accessibility checklist for company websites: careers, PDFs, investor pages and forms

An accessibility checklist for company websites: navigation, careers and job applications, PDFs and annual reports, video, forms, cookie banners and statements.

FixReports editorial team7 min read

A company website rarely sells anything directly, so accessibility problems on it are easy to overlook. But it is where people apply for jobs, investors read annual reports, journalists find press releases and customers look for contact details, and each of those tasks can be blocked by a barrier: a job application that can't be completed with a keyboard, an annual report published as an untagged PDF, a video without captions, a cookie banner that traps focus. This checklist goes through WCAG 2.2 Level AA by the sections most corporate sites have, with what to check in each.

Key points

  • WebAIM found detectable WCAG failures on 95.9% of the top one million home pages in 2026; low-contrast text (83.9%) and missing alt text (53.1%) were the most common (WebAIM (opens in a new tab)).
  • WCAG applies to documents published on a site, such as PDFs, as well as to web pages; W3C publishes techniques for making PDFs accessible (W3C (opens in a new tab)).
  • Prerecorded video needs captions (1.2.2, Level A) and audio description where the visuals carry information not in the audio (1.2.5, AA) (W3C (opens in a new tab)).
  • In 2022 guidance, the US Department of Justice said the ADA applies to the web offerings of businesses open to the public, without setting a specific technical standard (ADA.gov (opens in a new tab)).
  • W3C provides guidance and a free generator for writing an accessibility statement (W3C (opens in a new tab)).

Why does accessibility matter on a company website?

Because the visitors who depend on it are often the ones you most want to reach: candidates, customers, partners and investors. The World Health Organization estimates that 1.3 billion people, about one in six, experience significant disability (WHO (opens in a new tab)). Many more use a keyboard instead of a mouse, zoom text, or read in bright light on a phone.

There is also a compliance angle, which varies by country and by who the site serves. Public sector bodies in the EU must meet the Web Accessibility Directive; businesses selling to EU consumers may fall under the European Accessibility Act; in the US, the Department of Justice has said the ADA applies to the web offerings of businesses open to the public (ADA.gov (opens in a new tab)). A purely business-to-business site may fall outside some of these laws, but larger customers increasingly ask suppliers about accessibility. Our guides on the European Accessibility Act and ADA demand letters explain the context; this isn't legal advice.

What should you check on every page?

These problems come from the shared templates, so fixing them once fixes the whole site:

  • Contrast: body text at least 4.5:1 against its background, large text 3:1 (1.4.3). Light grey text and white text on brand colors are the usual failures. The color contrast checker tests any pair of colors.
  • Keyboard: every link, menu and button reachable with Tab and usable with Enter or Space, with a visible focus indicator (2.1.1, 2.4.7). Mega menus and carousels are frequent problems.
  • Skip link and landmarks: a way to jump past the header to the main content (2.4.1), and header, nav, main and footer landmarks.
  • Headings: one H1 per page and a logical heading structure (1.3.1), so screen reader users can scan the page.
  • Link text: links that make sense out of context, not “Read more” repeated ten times (2.4.4).
  • Language: the lang attribute on every page, and on passages in another language (3.1.1, 3.1.2), so screen readers pronounce them correctly.
  • Zoom and reflow: content usable at 200% zoom and at 320 pixels wide without horizontal scrolling (1.4.4, 1.4.10).

How do you make careers pages and job applications accessible?

The careers section is where barriers have the clearest consequences: a candidate who can't complete an application can't be considered.

  • Job listings: filters and search must work with a keyboard and announce result counts to screen readers (4.1.3).
  • Application forms: every field needs a visible label (3.3.2), errors must be described in text (3.3.1), and file upload buttons must have accessible names.
  • Time limits: if the form times out, warn people and let them extend the time (2.2.1).
  • Third-party applicant tracking systems: many companies use an external system for applications. Ask the vendor for its Accessibility Conformance Report, test the application flow yourself with a keyboard, and offer an alternative way to apply, such as email, listed on the careers page.
  • Assessments and video interviews: check that any online test or video interview tool supports screen readers, captions and extra time on request.

How do you publish accessible PDFs and annual reports?

Annual reports, sustainability reports, brochures and policy documents are often published only as PDFs, and many are untagged: a screen reader reads them as one block of text, or not at all.

  • Prefer HTML for important content. A web page is easier to make accessible, works better on phones and is easier to search.
  • If you publish a PDF, tag it. Export from the source document (Word, InDesign) with tags enabled, so headings, lists, tables and reading order are kept. The PDF/UA standard (ISO 14289) defines accessible PDFs.
  • Check the essentials: a document title, the document language, alternative text for charts and images, real table headers, and a logical reading order. Adobe Acrobat Pro has a built-in accessibility checker; PAC is a free checker for Windows.
  • Scanned documents are images of text and need OCR and tagging, or an HTML version.
  • Financial tables: mark up header rows and columns; in HTML, use <th> with scope.

What about video, webcasts and podcasts?

  • Captions for all prerecorded video with speech (1.2.2, A), and for live webcasts (1.2.4, AA). Automatic captions need checking: names, numbers and technical terms are often wrong.
  • Audio description where important information is only visual, such as text on slides that the speaker doesn't read out (1.2.5, AA). Often the simplest fix is for the speaker to describe the slide.
  • Transcripts for podcasts and audio-only content (1.2.1, A).
  • Player controls: an embedded player must be operable with a keyboard, and sound that plays automatically for more than three seconds needs a way to pause or stop it (1.4.2).

W3C's guide to making audio and video accessible covers planning, captions and description (W3C (opens in a new tab)).

How do you make contact forms, maps and locations accessible?

  • Forms: labels, clear error messages, and no CAPTCHA that relies only on reading distorted text or solving puzzles; offer an alternative (W3C (opens in a new tab)).
  • Contact details as text: phone numbers, email addresses and office addresses written in the page, not only in an image or a map.
  • Maps: an embedded map is hard to use with a screen reader; the address and directions in text are the accessible alternative.
  • Chat widgets: check that they can be opened, used and closed with a keyboard, and that they don't cover focused content (2.4.11).

Often, because they appear first and sit on top of everything else.

  • The banner must be reachable and usable with a keyboard, and Tab must be able to leave it (2.1.2, No Keyboard Trap) (W3C (opens in a new tab)).
  • Its buttons need clear names and sufficient contrast; “Reject” must be as easy to find as “Accept”.
  • It must not hide the focused element on the page behind it (2.4.11).

Our scans start on your home page with the cookie banner still showing, because that is what a keyboard user meets first, and report a focus trap if Tab can't get past it.

Do you need an accessibility statement?

Public sector bodies in the EU must publish one. For companies it is usually voluntary, though the European Accessibility Act requires covered services to provide information about how they meet its requirements. A good statement says which standard you aim for, known limitations, how people can report a problem or ask for content in another format, and when it was last reviewed. W3C publishes guidance and a free generator (W3C (opens in a new tab)).

Write it honestly: claiming full compliance after an automated scan is a risk in itself, because automated tests can't check everything.

How should you test a company website?

  1. Run an automated scan of the home page, a careers page, a news article, the contact page and any form. Our free accessibility checker tests key pages in a real browser against WCAG 2.2 A and AA, and the alt text checker lists every image on a page.
  2. Test with a keyboard: navigate the menu, apply for a job and submit the contact form using only the keyboard.
  3. Check documents: open your most important PDFs with a screen reader or a PDF accessibility checker.
  4. Watch your videos with captions on and the sound off.
  5. Ask people with disabilities to try the key tasks; it reveals problems no checklist predicts.

Frequently asked questions

Does WCAG apply to PDFs?

Yes. WCAG applies to web content, including documents published on a site. W3C publishes specific techniques for meeting WCAG in PDF files.

Our careers site is run by a third party. Is it our responsibility?

From a candidate's point of view, it is your application process. Ask the vendor for an Accessibility Conformance Report, test the flow, and offer an alternative way to apply. Whether you have legal responsibility depends on your jurisdiction.

Do automatic captions meet WCAG?

Only if they are accurate. Automatic captions often get names, numbers and terms wrong; review and correct them before relying on them.

Is an accessibility overlay enough for a corporate site?

No. Overlays don't fix the underlying code, documents or videos. See our guide on accessibility overlays and the FTC's order.

Which standard should a company website aim for?

WCAG 2.2 Level AA is the current version and the usual target; many laws and policies still reference WCAG 2.1 AA, which a site meeting 2.2 AA also meets.

Sources

All guides