Content Creator Pathway

What it means in practice

Aim for CEFR B1 or B2 for most consumer content — that's a Flesch-Kincaid score in the 60 to 70 range. For banking, government, or healthcare, the bar moves higher: B1, FK 70+, simpler if you can. The exact target depends on your audience but the principles don't change. Shorter sentences. Common words. Active voice. One idea per paragraph. Avoid jargon in anything customer-facing. When a term genuinely can't be avoided — two-factor authentication, KYC, opt-in — define it the first time you use it, inline, in plain words. If the term appears on multiple pages, link to a glossary entry. Don't expect users to discover a glossary they had to go looking for. Watch out for institutional language. 'Customers are requested to ensure that all required documentation is submitted in a timely manner' is six words longer than 'Please send us your documents on time' and tells the reader less. Cut it. The Readability Checker on this site gives you a Flesch-Kincaid score on any pasted-in text. The CEFR Checker is more specific to language proficiency levels and is essential for banking content under EBA guidelines. Run anything you're about to publish through one of them and watch for the outliers.

Common pitfalls

• ×Corporate-speak used because it 'sounds professional'. Professional writing is clear writing. Everything else is decoration.
• ×Long sentences with multiple clauses, multiple commas, and parenthetical asides nobody asked for. Break them up.
• ×Defining jargon in a footnote at the bottom of the page where the readers who needed it will never see it.

How to verify it

Run your draft through the Readability Checker. Look at the Flesch-Kincaid score. Anything under 50 is too dense for general audiences and needs editing. The CEFR Checker gives you a level rating from A1 to C2, which is the more useful frame for non-native English readers — and that's your audience for any consumer service in the EU. For banking-specific content, the CEFR B2 readability checklist on this site cross-references regulatory requirements against readability targets. It's the standard reference for EBA-aligned customer communications.

What it means in practice

The test for alt text isn't 'what's in the image'. It's 'what would I say if I couldn't show it'. For a hero photo of a product on a marketing page, the answer is usually 'a model wearing the new running shoe in red'. For a chart, it's the conclusion the chart is meant to show: 'Quarterly revenue grew 12% in Q3, with the largest increase in EMEA'. For an icon next to a button already labelled 'Delete', the answer is empty alt — the icon is decorative because the visible label is already doing the work. Three categories cover almost everything. Functional images (icons inside buttons, logos that link to the home page): describe the function, not the appearance. Informative images (photos that add meaning to the text, charts, diagrams): summarise the information the image is carrying. Decorative images (background patterns, generic stock photos that don't add meaning): empty alt, no exceptions. Length: most informative alt text fits in one or two sentences. If you need more than that, you've got a complex image and you should provide a long description either in the surrounding text or as a linked detailed description, with a short alt that summarises and points at the long version. Never start alt text with 'image of' or 'picture of'. The screen reader already announces it as an image. You're wasting the user's time.

Common pitfalls

• ×Auto-generating alt text from a filename or an AI caption and shipping it without review. Both produce alt text that technically exists and tells the user nothing.
• ×Using the same generic alt on every product image — 'product photo'. The user gains nothing over an empty alt and now the screen reader is reading it out loud anyway.
• ×Treating decorative images as if they need real alt text. A decorative background with `alt="abstract blue swirls"` adds noise to the screen reader output for no benefit at all.

How to verify it

Run the Alt Text Quality Checker on your published pages. It scores alt text against four common failure modes — missing, generic, filename-only, too long — and gives you a per-image action list. Then do the manual test: read the page out loud, saying the alt text where each image is, instead of looking at the picture. Does the page still make sense? Where it doesn't, the alt is wrong. Where the alt sounds repetitive or pointless, the alt is either wrong or the image is decorative and the alt should be empty.

What it means in practice

One H1 per page, describing what the page is actually about. Then H2s for the major sections, H3s nested under H2s where a section breaks down further, and so on down. Don't skip levels — jumping from H2 to H4 makes the page outline unparseable. And don't use heading tags for visual styling. If you want a smaller, lighter caption, use a styled paragraph. The heading text itself matters. 'Introduction' tells the reader nothing at all. 'How AccessibilityRef helps you meet the EAA' tells them everything. Good headings work as a table of contents — a screen reader user who pulls up the heading list should be able to navigate the page from that list alone. For long-form content (articles, blog posts, role guides, documentation), aim for a heading every 200 to 400 words. Less than that and you're fragmenting the reading. More than that and you lose people who scan. Match the visual rhythm of the page to the structural rhythm of the headings. Check your CMS templates for hidden heading bugs. A common one: a sidebar widget contains an H2 for the widget title, but the widget appears below the page H1, breaking the outline. The fix is to drop the widget down to H3, or rework the template so widgets sit outside the main content tree entirely.

Common pitfalls

• ×Using H4 for the page title because it 'looks the right size'. The CSS is your job. The heading level is for structure.
• ×Skipping levels (H2 → H4) because there happens to be no H3 in the current section. Either add an H3 or restructure the section.
• ×Multiple H1s on one page. Pick one. Demote the rest.

How to verify it

Run the Heading Structure Analyser on the page. It renders the H1-H6 tree as a hierarchy and flags every skipped level, every empty heading, every duplicate H1. The Pro version scans up to 20 URLs at once, which is the right tool for content audits across a section of the site. As a manual sanity check, turn off CSS in the browser and read the page. The unstyled view should look like a coherent outline. The structure should be obvious from the heading sequence alone.

What it means in practice

Every video gets captions. Auto-generated captions from YouTube or anywhere similar are a starting point, not the finished article — the error rate is too high for anything professional. Edit the auto-captions to fix names, technical terms, and timing. Human caption review runs about €1 to €3 per minute of video. For anything that gets real reach, it's worth every cent. Audio description (1.2.5) is the harder one. It's spoken narration of visual information that isn't carried by the dialogue — facial expressions, scene changes, on-screen text. For corporate video with a single speaker on camera, you usually don't need it because the dialogue is doing all the work. For documentaries, drama, or anything visual-heavy, it's required. Provide a transcript for every video. Transcripts are the cheapest accessibility feature you can add to video. They also help with SEO, in-page search, and users in environments where they can't play audio. Put the transcript on the same page as the video, not behind a separate link. For live audio (1.2.4 — webinars, live broadcasts, customer events), you need real-time captioning. Auto-captions don't meet the bar. You need a professional captioner or a high-quality re-speaking service. Plan and budget for this up front.

Common pitfalls

• ×Treating YouTube auto-captions as compliant. They sit below the accuracy floor for anything professional and they regularly get critical words wrong.
• ×Putting the transcript on a separate page reachable only by a small link nobody clicks. Users won't find it. Put it on the same page as the video, collapsed if you have to.
• ×Forgetting audio description on visual-only content. A documentary about a museum exhibit with no narration is unusable for blind users until you add audio description.

How to verify it

For every video on the site, three checks: does it have captions, are the captions accurate, is there a transcript on the same page? For live events: is real-time captioning booked, have you tested the captioning workflow end to end, what's your fallback if the captioner drops out? The Video & Media Checklist on this site walks through every Annex I and EN 301 549 Chapter 7 requirement for media content. It's the canonical reference for audio-visual production.

What it means in practice

The cheapest fix is to publish content as HTML instead of PDF. HTML is naturally responsive, naturally screen-reader friendly, and far easier to update. Reserve PDF for documents that genuinely need to be printable, signable, or archived in a fixed layout. Even then, make the PDF accessible. For any PDF you do publish, the requirements are: a tagged PDF so the document structure is exposed to screen readers, a logical reading order, real text content rather than scanned images of text, alt text on every image, document title metadata, language metadata, and accessible form fields where you have any. Microsoft Word and Adobe InDesign both produce tagged PDFs if you set the export options correctly. Acrobat Pro can fix existing PDFs. For PDFs you receive from third parties — vendor terms, contracts, regulator submissions — the obligation is the same. If you genuinely can't make a third-party PDF accessible, host an HTML version alongside it and link to both. Matterhorn Protocol is the de facto checklist for PDF/UA conformance. Run it on every PDF you publish, or use the Document Auditor on this site for a quick first pass. The PDF Accessibility Checklist gives you the manual verification steps.

Common pitfalls

• ×Publishing scanned images as PDFs. The screen reader sees nothing, the user gets nothing. OCR before you publish.
• ×Exporting from Word without 'Document structure tags for accessibility' enabled. The resulting PDF looks fine and is completely invisible to screen readers.
• ×Publishing forms as PDFs without making the form fields tabbable and labelled. Sighted mouse users can fill them in. Nobody else can.

How to verify it

Open the PDF in Acrobat Pro and run the built-in accessibility check. It catches the obvious issues — missing tags, missing alt, missing title, missing language. Then open the PDF in a screen reader and try to read it top to bottom. The reading order should match the visual layout, the alt text should make sense, the form fields (if any) should be labelled. For batch checking, the Document Auditor on this site processes PDFs and Word files locally and gives you a per-document accessibility report.