Most CV advice assumes one kind of reader: a sighted recruiter skimming a PDF on a big monitor. Some of the people who open your file listen to it instead, through a screen reader that follows the structure stored inside the document rather than what the page looks like. And some of the people writing CVs use a screen reader themselves, which means they cannot see what their own template is doing to their words.
This guide is for both. An accessible CV is the same document, built so the text underneath matches the text on top.
Reading order: the fix that pays twice
A screen reader does not look at your page. It reads text in the order that text is stored in the file. On a single-column CV, that order usually matches what you see. On a two-column template, it often does not.
Picture a common layout: a narrow left column with contact details, skills and languages, and a wide right column with experience. Inside the file, the text may be stored line by line across both columns, so a listener hears "Python, Senior Data Analyst, SQL, Acme Logistics, Spanish, March 2021 to present". Or the sidebar is stored last, after two pages of bullet points, and your phone number is the final thing anyone hears.
Here is the part most people miss. An applicant tracking system reads the file in much the same way: it pulls out the text layer and works through it in stored order. So a CV that scrambles for a screen reader tends to scramble for the parser too. We cover the parsing side in our guides to ATS parsing rules and to tables in CVs, so I will not repeat them here. The point is simple: fixing reading order helps a human listener and the software that decides whether a human sees your file at all.
The safest option is a single column. If you love your sidebar, keep it short, and test it with the methods at the end of this article.
Real text, not pictures of text
Anything that is a graphic is silent unless someone gave it a text alternative, and CV templates almost never do. The usual offenders:
- Skill bars and star ratings. Four and a half dots out of five means nothing to a screen reader. Write "Advanced", or better, name what you built with the skill.
- Icons standing in for labels. A small phone glyph next to a number works visually, but if the icon is the only label, the listener just hears digits. Write "Phone" and "Email" as words, or let the number speak for itself.
- Names and headings flattened into images. Some design tools turn a decorative header into a picture on export. Your name then disappears from the text layer, which is a strange result for a document whose whole job is to make your name stick.
- Scanned CVs. A scan is one large image. Without text recognition, there is nothing to read.
A quick test for any element: can you select it with your cursor and copy it as letters? If not, it is a picture, and a screen reader will skip it.
Contrast, and colour doing all the work
Pale grey text on white looks refined and is hard to read for a lot of people. Use dark text on a light background. The Web Content Accessibility Guidelines set a minimum contrast ratio of 4.5 to 1 for normal body text, and a free online contrast checker will tell you in seconds whether your palette clears it.
The subtler problem is colour carrying meaning by itself. A template that marks your current role in green and past roles in grey, or flags "core skills" only with a coloured dot, loses that information for colour-blind readers and for every screen reader user. Say it in words: "Current role", "Core skills". Colour on top of text is fine. Colour instead of text means part of your audience never gets the message.
Structure that a screen reader can navigate
Headings as real heading styles
People who use screen readers rarely listen to a document from top to bottom. They jump from heading to heading, the way a sighted reader skims. That only works if your section titles are marked as headings in the file.
Making "Experience" bold and two points larger is a visual cue only. Applying your word processor's built-in heading styles creates real structure that survives export. Use one level for main sections and a second level for employers or job titles if you want them to be jump targets. Do not skip levels to get a look you like; change the style instead.
Descriptive link text
A raw web address read aloud is a long string of letters, slashes and dots. "Click here" is worse, because a listener who pulls up a list of links hears "click here, click here, click here". Name the destination: "Portfolio: data visualisation projects", "LinkedIn profile". The link still works, and it reads cleanly on paper, where nobody can click anything anyway.
Tables used for layout
Plenty of templates use an invisible table to push dates to the right and job titles to the left. Screen readers announce tables as tables, with row and column counts, and the reading order can hop between cells in ways that make no sense out loud. Right-aligned tab stops do the same visual job without the table.
Tagged PDFs, and why "Save as PDF" is not one thing
A tagged PDF carries a hidden structure layer: this is a heading, this is a list, this is a paragraph, read them in this order. Screen readers rely on that layer. An untagged PDF forces the reader to guess from where the text sits on the page, and that guessing is where scrambled columns come from.
Different apps produce very different PDFs from the same document. A word processor exporting with tags or accessibility options enabled usually carries your heading styles and reading order into the file. Printing to PDF through a generic print driver often throws that structure away and gives you a flat, untagged file. Online design tools vary a lot, and some export each page as a single image. Same CV, same look on screen, completely different file underneath.
So look for the export option in your app that mentions tags, document structure or accessibility, and switch it on. Then test the result rather than trusting the checkbox. If you generate your CV from your LinkedIn profile with a tool like Postulit, the same habit applies: check the exported file, not the preview.
How to test your own CV
Two free checks catch most problems.
- The plain-text paste. Open your PDF, select all, copy, and paste into a plain text editor. What you see is roughly the order a screen reader and a parser will follow. If your contact details land at the bottom, or two columns interleave line by line, you have found the problem.
- Listen to it. On Windows, install NVDA, a free screen reader. On a Mac or iPhone, VoiceOver is already built in. Open the PDF and let it read. Then try jumping by heading. If the reader cannot find your sections, your headings are only bold text.
If you use a screen reader every day, the paste test is also a fast way to vet a template before you commit to it, since the visual layout makes promises you cannot check by sight. Download the template, type a short dummy entry, export it, and listen. If it scrambles with dummy text, it will scramble with yours.
Whether to mention a disability on your CV at all is a separate decision with its own article; this one is only about making the file readable.
An accessible CV and a parser-friendly CV are mostly the same document. Fix the reading order once and you have fixed it for both readers.
The ten-minute fix
Open your current CV and work through this in order. Move to a single column, or confirm with the paste test that your sidebar reads in a sensible place. Replace skill bars and icon-only labels with words. Apply real heading styles to every section title. Rename each link so it says where it goes. Export with tags enabled, paste the result into a plain text editor, and then listen to it once with NVDA or VoiceOver.
If it sounds right read aloud, it will work for the recruiter who listens and for the software that screens before anyone reads.