Image description: A conference room with a projected slide and a laptop showing the deck’s reading-order outline — the visual marker for accessible presentation production.

Reading Time: 12 minutes

Slide decks remain the single most-shared educational artefact in modern professional life — lecture notes, board updates, training modules, conference talks, internal all-hands. They are also, almost without exception, the least-accessible artefact in the same pipeline. A talk that screen-readers cannot navigate, a deck whose chart values exist only as pixels, a video clip embedded without captions, a “click to advance” interaction that ignores the keyboard: each of these is routine, and each of them quietly excludes the same group of people from the same content the rest of the audience receives. The good news is that fixing this in 2026 is no longer a research problem. It is a production-workflow problem with three good answers and one decision tree that picks between them.

This primer covers the three families of tools a working presenter actually has on their desktop — Microsoft PowerPoint, Apple Keynote, and Google Slides — plus the increasingly serious web-first alternative (Reveal.js, Slidev, Marp) that lecturers and conference organisers have begun to favour. It is not a comparison of features in the abstract. It is a production guide: which steps you take, in which order, in which tool, to ship a deck a blind student can follow with NVDA, a low-vision colleague can read at 400% zoom, a Deaf attendee can read along with embedded captions, and a keyboard-only user can navigate without ever touching a mouse. For the broader standards context, see our primer on WCAG 2.2 adoption and the European Accessibility Act, both of which now apply to educational and commercial slide-based content distributed online.

What an accessible deck needs

Before the tool-specific workflows, a baseline. An accessible slide deck has six things working at once, and none of them are optional. The first is a unique, descriptive title on every slide — this is what a screen-reader user uses to navigate from slide to slide, and what an outline-pane user relies on to find the slide they are looking for. Slides titled “Slide 4” or “Untitled” are unnavigable. The second is a correct reading order. Slides built by dropping shapes onto a canvas without using the placeholders will have a reading order that matches the order shapes were inserted, not the visual order — which means a screen reader will read a slide back-to-front, sidebar-first, footer-before-headline, or in whatever sequence the production process happened to produce. The third is text alternatives for every non-decorative image, chart, and diagram, written in language that conveys the point the image makes, not just its surface description.

The fourth is sufficient colour contrast — text on slide backgrounds at the WCAG 2.2 AA threshold (4.5:1 for body text, 3:1 for large text and meaningful graphics), checked against the actual background pixels rather than the slide master. The fifth is keyboard navigability — every interactive element a presenter expects an audience to use later (embedded poll links, branching navigation, embedded forms) must be reachable and operable with Tab, Enter, Space, and Esc alone. And the sixth is media handling — every embedded video carries either open captions burned into the file or a closed-caption track the player can switch on; every embedded audio clip has a transcript reachable from the same slide; every animation that is not strictly necessary respects the user’s reduced-motion preference at the OS level.

Each of the three desktop tools delivers some subset of these six. None of them delivers all six automatically. Picking the right tool means understanding what you have to do by hand in each one.

PowerPoint workflow

PowerPoint carries the most mature accessibility tooling of any presentation app on the market, and has done since the Microsoft 365 release cycle began folding the Accessibility Checker into the ribbon. The starting point is the checker itself, opened from the Review tab in Windows or the Tools menu on macOS. It surfaces a live, contextual list of issues — slides without titles, images without alt text, low-contrast text combinations, tables without headers, hyperlinks whose visible text duplicates the URL — and clicking any issue jumps the cursor to the offending element. The checker runs on every save by default in current builds, which is the single most useful default Microsoft has shipped in this product. Turn it off only after you understand which warnings you are choosing to dismiss.

Slide titles are managed through the Outline view (View, Outline) and through the slide master’s Title placeholder. Using the placeholder rather than a free-floating text box is what gives the title its semantic role — both the Accessibility Checker and downstream screen readers identify titled slides by the placeholder’s identity, not by the visible text. If your deck’s titles are typeset using free-floating text boxes for design reasons, you can keep the design but add an invisible placeholder title by moving the placeholder off-canvas (Selection Pane, set position to negative coordinates) — the title still exists in the accessibility tree and counts for screen-reader navigation, even though the audience never sees it. The Microsoft documentation describes this as the “off-slide title” pattern; the checker accepts it.

Reading order is the second pillar. Open the Selection Pane (Home, Arrange, Selection Pane in Windows; Arrange menu on macOS) and read the list of shapes from bottom to top — that is the order a screen reader will encounter them. Drag shapes within the pane to reorder. PowerPoint 2024 added a dedicated Reading Order Pane that visualises the order numerically over each shape on the slide and lets you reorder by drag-and-drop directly on the canvas; if your Microsoft 365 build is current enough to show that pane, use it instead.

Alt text on images is set by right-clicking the image, choosing Edit Alt Text, and writing one to two sentences of editorial alt — the point of the image, not its pixel content. PowerPoint’s autogenerated alt text is opt-in and labelled as such in the pane; it is a starting point, not a finished product, and the checker will warn you if you ship a slide where the only alt text is “Description automatically generated.” For charts built in PowerPoint, alt text should summarise the chart’s argument in one sentence and quote its top two or three values — “Bar chart showing 2026 conference attendance up 18% from 2025, led by EMEA and APAC regions” is better than “Bar chart.” For data-heavy slides, ship the underlying data as a hidden but reachable table in the speaker notes, or as a linked spreadsheet in the appendix, so a screen-reader user can read the numbers in addition to the chart’s gist.

Embedded video is the single most common compliance failure in PowerPoint decks. The Insert, Video, Insert Captions workflow accepts WebVTT files (.vtt) and binds them to the embedded clip; once attached, the captions render in PowerPoint’s built-in player and travel with the file when the deck is shared, emailed, or uploaded. If your source video has burned-in open captions, the checker still flags the file as needing a caption track — add a minimal VTT anyway, because the file is what downstream tooling will read. Hyperlinks should have visible text describing the destination (“Read the 2026 EAA enforcement report”), not the bare URL.

PowerPoint’s export pipeline preserves most of the accessibility metadata when you export to PDF — provided you use File, Export, Create PDF/XPS (Windows) or File, Save As, PDF with the Best for electronic distribution and accessibility option selected (macOS). Exporting via Print to PDF strips the tags and produces an inaccessible flat PDF; this is the most common silent failure in the entire workflow.

Keynote workflow

Keynote ships with materially less accessibility tooling than PowerPoint, and the gap has not closed materially since the 13.x release cycle. There is no equivalent of the Accessibility Checker — Keynote does not run a slide-by-slide audit, does not surface a per-slide reading-order pane, and does not warn the user when a slide lacks a title. The slides themselves carry stronger VoiceOver integration than PowerPoint did a decade ago, but the production workflow for getting an accessible deck out of Keynote is more manual at every step.

Slide titles are added through the Title placeholder in the slide master or as a regular text box used consistently across the deck. Keynote’s outline view (View, Outline) reads from the Title placeholder, so building decks against the master rather than building from blank slides is the single biggest leverage point. Reading order is managed via the Arrange inspector — the Back/Front controls in Keynote’s stacking model double as the reading-order controls, with shapes sent further back read first. There is no dedicated reading-order pane; you have to keep a mental model of the stack, or build complex slides up from a known-correct base.

Image alt text in Keynote is set through the Format inspector’s Image tab under the Description field — write the same editorial alt you would in PowerPoint. Chart alt text uses the same mechanism. Keynote does not warn about missing alt text. The only way to verify a deck’s alt-text coverage in Keynote is to walk every slide manually, or to export to PowerPoint format (.pptx) and run Microsoft’s Accessibility Checker against the export — a workflow several large universities have adopted as their gating step for lecture decks built in Keynote.

Embedded video in Keynote does not support a separate caption track. If your source video does not carry burned-in open captions, you must either re-encode the video with captions baked in before inserting it into Keynote, or replace the embed with a linked-out reference that points to a captioned video hosted on a captioning-aware platform (YouTube, Vimeo, your institution’s media server). Keynote will silently include uncaptioned video in an exported PDF; the checker that does not exist cannot warn you about it.

Where Keynote earns its place is in design-heavy decks built for keynote talks rather than for redistribution. Its typography, layout, and animation quality are still the best in the desktop-presentation market — when the deck is essentially a stage prop and the substantive content lives in a separately-distributed paper, transcript, or web page, Keynote produces a stronger live experience and the accessibility burden shifts to the companion document. If the deck itself is the deliverable, PowerPoint is the better choice.

Google Slides workflow

Google Slides has improved substantially since the 2024 accessibility refresh that added a per-slide accessibility menu, alt-text suggestions powered by Gemini-class image models, and a contrast-checking overlay accessible from Tools, Accessibility. The 2024 refresh also added reading-order controls to the Arrange menu — for the first time in the product’s lifetime, Slides authors can set explicit reading order rather than relying on shape-creation order. Adoption of these features inside large enterprise tenants has been faster than Microsoft initially expected, partly because Slides decks are already overwhelmingly cloud-hosted and benefit immediately from the server-side checker.

The mechanics are familiar to anyone coming from PowerPoint. Titles are managed through the master layout’s Title placeholder. Alt text is set through Format options, Alt text, with the same one-to-two-sentence editorial rule. Reading order uses the Arrange, Order menu, with the new 2024 reading-order pane visible from Tools, Accessibility, Reading order. Video embedding from Google Drive or YouTube respects whatever caption track the source carries, and a slide containing an uncaptioned video raises a warning in the accessibility pane.

Where Slides still trails PowerPoint is in chart accessibility (the auto-generated chart alt text is shorter and less context-aware), in complex master inheritance (deeply-customised master layouts produce harder-to-debug reading-order trees), and in offline workflows (the accessibility checker requires the document to be online, which is a problem for users editing on planes or in restricted environments). For a 2026 enterprise that has standardised on Workspace and ships decks primarily as shared Google Slides links rather than as downloaded files, the Slides workflow is now substantively comparable to PowerPoint. For an organisation that ships decks as .pptx attachments or as exported PDFs, PowerPoint still has the edge.

Web-first decks: Reveal.js, Slidev, Marp

The most interesting development in presentation accessibility in 2025 and 2026 has been outside the three big desktop apps entirely. A cluster of web-first presentation frameworks — Reveal.js (the long-standing JavaScript framework), Slidev (a Vue-based tool aimed at developers), and Marp (a Markdown-first generator that compiles to HTML, PDF, or PPTX) — produce slide decks as HTML documents, which means the accessibility properties of HTML are inherited rather than emulated. The semantic structure is real, not synthesised; the keyboard navigation is the browser’s, not the slide app’s; and the screen-reader output is whatever NVDA, JAWS, or VoiceOver would produce for any well-built web page.

The implications are practical. A Reveal.js deck served from a URL is, by default, navigable with arrow keys, Tab, Enter, Space, and the same browser shortcuts a sighted user already knows. Each slide is a section element with a heading — H1 for the deck, H2 for each slide title — so a screen-reader user can jump from heading to heading the way they would on any web page. Images carry alt attributes written in the Markdown or HTML source. Charts rendered with Chart.js, D3, or any SVG library carry whatever ARIA roles and live-region announcements the chart library exposes; for accessible-chart libraries like Highcharts Accessibility or amCharts, that includes screen-reader-readable data tables generated automatically alongside the visual chart.

Slidev’s developer-oriented audience has produced an unusually strong accessibility default set: heading semantics inherited from Markdown, alt text required at the source-file level (the compiler warns on bare image tags), and a keyboard-navigation layer that works without configuration. Marp’s strength is in plain-Markdown decks compiled to HTML or PDF — the same source produces both a screen-reader-navigable web deck and a tagged PDF, with no second authoring pass. Reveal.js sits between them: the most flexible, the largest plugin ecosystem, the deepest pool of third-party accessibility plugins (Reveal Accessibility, reveal-a11y, the published WCAG-2.2-conformance theme).

The trade-offs are real. Web-first decks require a browser to present — no local file double-click, no email-the-pptx workflow, no offline laptop fallback that does not require setup. They reward authors comfortable with version control and continuous deployment; they punish authors who want to drag a chart from Excel into a slide and call it done. For a single talk shared as a URL after the fact, this is a clear win. For a quarterly board update that is going to be emailed to a director who will open it on a flight, this is the wrong tool.

Where web-first decks have begun winning is in recurring contexts. University lecture series that publish a whole semester of slides as a single navigable site. Conference programmes where every talk’s deck is linked from the schedule and lives at a permanent URL. Engineering tech talks where the source repository is itself the version of record. In each of these contexts the HTML semantics survive — search engines index the slide content as text, screen readers traverse it as a document, and the maintenance burden of staying accessible across the series falls to the framework rather than to each individual author.

A decision tree

The three families of tools each earn their place in a different production context. The simplest version of the decision is a three-way split based on what the deck is actually being used for.

For a one-time talk that needs to be emailed, opened on a colleague’s laptop, or exported to a tagged PDF for distribution, choose PowerPoint. The Accessibility Checker is mature, the export pipeline preserves tags, and the audience-side tooling (the PowerPoint web viewer, the iPad app, the Office Mobile reader) all read tagged PowerPoint correctly. Allow ninety minutes of audit time per hour-long deck; budget the time and use it.

For a recurring lecture series, a conference programme, or any context where the deck collection lives at a URL and is browsed as a corpus, choose a web-first framework. Slidev for developer-heavy audiences and Markdown-comfortable authors; Marp for plain-Markdown teams that need both HTML and tagged PDF from the same source; Reveal.js for the largest plugin ecosystem and the most design flexibility. The accessibility properties are inherited from the browser, not emulated, and the maintenance burden falls to the framework rather than to each author.

For a design-heavy keynote talk where the deck functions as a stage prop and the substantive content lives in a separately distributed document, choose Keynote, accept the thinner accessibility tooling, and put your audit budget into the companion document instead. Walk every slide manually for alt text. Export to .pptx and run the checker as a final pass. Ship the companion document (a paper, a transcript, a web summary) as the canonical accessible version.

For collaborative cloud-first organisations that already live in Google Workspace, Google Slides is now a viable PowerPoint alternative for the same use cases. The 2024 accessibility refresh closed most of the historical gap; the remaining gaps are around chart alt text, complex masters, and offline editing. For decks that will be shipped as shared links rather than as downloaded files, the workflow is comparable to PowerPoint.

Final thoughts

The pattern underneath every recommendation in this primer is the same: the tool sets the accessibility floor, but the author sets the ceiling. PowerPoint’s checker will catch the missing alt text; it will not write a useful alt text for you. Keynote’s lack of a checker will not stop you from writing a deck that is fully accessible — it will just stop you from being told when you have failed. The web-first frameworks inherit HTML’s accessibility properties — they do not enforce them. Every tool in this guide will let you ship a deck that excludes part of your audience. The choice of tool changes which mistakes are easy to make, not which mistakes are possible.

If you are introducing a new accessibility workflow into a team that does not have one, start with the tool the team is already using, turn on its checker, and audit one existing deck against it as a calibration exercise. Move to a different tool only after the team has internalised the six baseline requirements — titles, reading order, alt text, contrast, keyboard, media — and is asking for capabilities the current tool cannot deliver. The cost of changing tools mid-stream is high; the cost of staying on a tool whose workflow you have outgrown is higher.