Define the presentation’s purpose and scope
First, decide what the audience should understand or be able to do after the presentation. For example, the goal might be to explain how colleagues can spot potential barriers on a web page and consider what improvements to assess. Be clear about the audience, too: designers, developers, content creators, and managers may draw different conclusions from the same example.
The presentation’s length, setting, and the audience’s familiarity with the topic all affect its scope. In a short session, explain a few key concepts using one example; in a longer session, allow participants time to examine the example. Don’t present the session as a guarantee of legal compliance or a complete technical audit. Your aim is to make user experience and improvement decisions easier to understand.
Build the narrative around a user task
Choose a specific task someone would do on the web, such as registering for an event or searching for a product. Then show where the task might become difficult. Relate topics such as form field labels, how information and errors are presented, keyboard navigation, and the use of color to the task you chose. Rather than loading each slide with many rules, follow the sequence “potential barrier → effect on the user → improvement to consider.”
W3C WAI’s accessible design tips include conveying information in ways other than color, providing clear labels for form fields, and considering alternatives for visual content. You can use these as design points to explore through an example, rather than as guaranteed solutions: W3C WAI: tips for accessible design.
If you discuss WCAG, specify which version and scope you’re covering; this presentation is not a substitute for a conformance assessment. A 2025 W3C WAI announcement describes ongoing work on WCAG 2 and WCAG 3, and notes that WCAG 3 is still in a lengthy development process. Check the latest status before your presentation: W3C WAI update announcement.
A concrete example: registration form
The following five-slide sequence is a hypothetical example for a short briefing of about 10 minutes. Adjust the timing and level of detail to suit your presentation.
- Slide 1 — Purpose: Introduce the question “Can a visitor complete a registration form using a keyboard?” as the focus of the session.
- Slide 2 — User task: Briefly describe the hypothetical scenario in which a visitor fills out and submits the form. Don’t reduce users to a single experience.
- Slide 3 — Potential barriers: In the example form, one field’s label is unclear, an error message is shown only in red, and it is difficult to find the next field when navigating by keyboard. Discuss the kinds of uncertainty these issues might cause.
- Slide 4 — Improvement options: Suggest making the label clearer, using explanatory text as well as color to convey an error, and examining whether focus can be tracked while navigating by keyboard. Present these as options to assess, not as verified results.
- Slide 5 — Review: Try the example using a keyboard; review the labels and error message. If possible, get feedback from people with different ways of using the web. State the scope of the review and the limits of its findings.
Design slides with accessibility in mind
Using one main message per slide and writing headings that describe the content can make the presentation easier to follow. Small text, cramped layouts, and poor contrast with the text can make content harder to understand. If you use color to encode information, convey it with a label or explanation as well. Consider the purpose of each image: think about adding a suitable description for an image that conveys meaning, and avoid describing a decorative element with unnecessary text.
The technical options available depend on the presentation tool and file format you use. Don’t assume a particular menu is available in every version; check your tool’s current documentation for steps to set up heading structure and reading order, and add image descriptions. For tables, see the guide to improving accessibility in presentation tables; for arranging reading order in PowerPoint, see the related guide.
Plan how you’ll review the presentation
Don’t judge the presentation solely by whether it looks visually organized. Review it from beginning to end, checking whether the main message on each slide, its links, and image descriptions are clear. If your presentation file and setup allow it, navigate using a keyboard and check whether the sequence makes sense. Ask whether the audience is expected to infer important information from color or visual placement alone.
If you use an automated checking tool, treat its findings as one part of the review process; don’t claim that it proves on its own that the presentation is accessible. Clearly distinguish what you reviewed in the example, the scope of that review, and points that have not yet been verified. W3C WAI’s 2026 announcement points to different presentation and video resources, including accessibility standards and user stories: W3C WAI presentation and video resources.
Common presentation problems
Trying to fit too many concepts into one session: Limit the scope to one user task; leave detailed technical topics for additional resources.
Communicating a message only through color or images: Express the same information in text, too, and examine the example with different usage conditions in mind.
Treating a checklist as sufficient validation: Use the checklist for regular reviews, and plan additional checks, such as trying the task using a keyboard or getting user feedback. W3C’s presentation on inclusive digital transformation also emphasizes a user-focused approach rather than a checklist approach: W3C WAI presentation summary.
Presenting an example solution as a definitive result: Present a recommendation as an option to consider; don’t claim that a page is accessible without reviewing or testing it.
Final checklist
- Are the audience, purpose, and scope clear?
- Is the example built around a defined web task and its potential effects on users?
- Is information conveyed in ways other than color, and are the text and layout easy to understand?
- Are images, headings, and links considered in context?
- Have keyboard navigation, labels, and error messages been reviewed in the example?
- Are assumptions, limitations, and unverified points clearly stated?
Do I have to mention WCAG in the presentation?
No. You can explain user barriers and improvement decisions through a concrete example. If you discuss standards, specify the version and scope you cover, and check the latest information with the relevant W3C source.
Is an automated accessibility check enough to validate the presentation?
Don’t assume that it is sufficient on its own. Review the findings; also examine the slide sequence, keyboard navigation, and whether the example is understandable from a user’s perspective.
← Back to blog
