Creating Accessible Digital Content

Use a unique, descriptive title for every slide

• Use the built-in title placeholder.
• Make each title describe the purpose of that slide.
• When several slides cover the same topic, distinguish them with meaningful wording rather than repeating the same title.
• When the visible design cannot accommodate a title, use the application’s supported method for visually hiding the title rather than deleting it.

• Review the slide titles as a list or outline.
• Confirm that no title is missing, empty, or duplicated without a meaningful distinction.
• In PowerPoint, run the Accessibility Checker and review title warnings.
• In Google Slides, inspect each slide manually or use an approved accessibility add-on when one is available.

Use built-in layouts and set a logical reading order

• Begin with a built-in slide layout.
• Place content in the title and content placeholders supplied by the layout.
• Minimize manually added floating text boxes.
• Arrange objects in the sequence in which they should be announced.

• In PowerPoint, review the Reading Order Pane.
• Navigate through the slide objects with the keyboard by using the tab key.
• Confirm that the title is announced before the slide content and that related content remains together.
• Recheck the order after copying content, changing layouts, or adding new objects.

Use readable text and uncluttered layouts

• Use a familiar, uncluttered font such as Arial, Aptos, Calibri, Segoe UI, or Verdana.
• Use 24-point or larger body text as the NCDPI recommended starting point.
• Use larger text for titles and for content projected in a room.
• Shorten content or divide it across slides instead of shrinking text to make it fit.
• Avoid decorative or condensed fonts, very thin font weights, long all-capital passages, and excessive italics or underlining.
• Maintain adequate spacing and contrast.

• Identify the smallest text on every slide.
• Review the presentation in Slide Show mode.
• Consider the expected room size and viewing distance.
• Look for clipped, crowded, or overlapping text and text placed over busy backgrounds.

Describe images, charts, and visual information

• Add alternative text to meaningful visuals.
• Mark purely decorative visuals as decorative.
• Provide the key data or relationship from charts and diagrams in nearby text, speaker notes distributed to participants, or an accessible data table.
• Do not put essential information only in screenshots or images of text.

• Read the alternative text without looking at the visual.
• Confirm that complex information remains available when the visual cannot be seen.
• Confirm that automatically generated alternative text has been reviewed.

Use sufficient contrast, more than color, and descriptive links

• Apply the color and link practices from the essentials section.
• Label chart categories directly when possible.
• Use patterns, labels, or shapes in addition to color.
• Use descriptive linked text rather than raw addresses.

• Test color combinations.
• Review slides in grayscale.
• Scan only the links and confirm that their destinations are understandable.

Make multimedia and live delivery accessible

• Caption embedded videos.
• Correct automatically generated captions.
• Describe important visuals during the presentation.
• Enable live captions for live delivery.
• Provide accessible materials before or after the presentation when participants need them.

• Play every embedded media item with captions.
• Confirm that captions survive sharing, exporting, or presenting.
• Test the live-caption setup before the session.

Check and share the final presentation

• Run PowerPoint’s Accessibility Checker when using PowerPoint.
• In Google Slides, inspect each slide manually or use an approved accessibility add-on when one is available
• Complete a manual review in PowerPoint, Google Slides, and other applications.
• Share the accessible source presentation when practical.
• When PDF is necessary, use a supported export process and check the resulting PDF separately.
• Do not distribute presentations only as images or scanned PDFs.

• Open the shared version through the same route participants will use.
• Confirm permissions.
• Check reading order, links, media, notes, and any exported file.
• Do not assume that an accessible source file automatically creates an accessible PDF.

• Use styles for the document title, headings, paragraphs, lists, and quotations.
• Organize sections and subsections logically.
• Use real numbered and bulleted lists.

• Review the Navigation Pane or document outline.
• Confirm that all visual headings appear in the outline.
• Confirm that lists use built-in list formatting.

• Use Arial, Aptos, Calibri, Segoe UI, Verdana, or another familiar, uncluttered font.
• Use 12-point or larger body text as the NCDPI starting point.
• Use 1.5 line spacing and space after paragraphs.
• Use left alignment for paragraphs.
• Avoid fully justified paragraphs, long all-capital passages, and excessive italics or underlining.

• Search for text smaller than 12 points.
• Look for crowded paragraphs, repeated blank lines, inconsistent fonts, and content reduced to fit the page.
• Enlarge the document and confirm that content remains readable.

• Determine what the image contributes in its current context.
• Add concise alternative text to meaningful images. Describe the image’s purpose or essential information rather than every visible detail.
• Mark an image as decorative when it adds no information and performs no function. In HTML, decorative images generally use an empty text alternative: alt="".
• When an image contains essential text, provide that information as real text nearby whenever possible.
• For charts, diagrams, maps, infographics, and other complex visuals, provide a short alternative text and make the complete information available in nearby text, a list, or an accessible data table.
• For an image used as a link or button, describe the action or destination rather than its appearance.
• Review automatically generated alternative text before publishing. Do not assume an AI-generated description reflects the image’s purpose.

• Review every image.
• Confirm that complex charts and diagrams have equivalent information outside the alternative-text field.

• Use link text that identifies the destination, file, resource, or action.
• Avoid vague wording such as “click here,” “read more,” “more information,” and “go here.”
• Avoid displaying long web addresses as the linked text in digital content.
• Identify the file type when linking to a download, such as “Download the implementation guide [PDF].”
• Use consistent wording for links that perform the same action or lead to the same destination.
• Avoid using identical link text for different destinations unless the surrounding context clearly distinguishes them.
• For a linked image, make sure the text alternative communicates the destination or action.
• Avoid URL-shortening services when they obscure the destination or reduce user trust.
• When a visible web address is needed for printed use, provide it in addition to—not instead of—descriptive digital link text.
• Avoid forcing links to open in a new window unless necessary. Disclose the behavior when it cannot be avoided.

• Scan the linked text.
• Test the links and file permissions.

• Use tables only for data that has meaningful row and column relationships.
• Identify column headers and row headers when the application supports them.
• Avoid merged cells, split cells, nested tables, and blank spacer rows or columns.
• Put the table title, source, units, and explanatory notes outside the data grid.
• Use another format when the authoring application cannot communicate a complex table’s relationships accessibly.

• Navigate through the table by cell.
• Confirm that headers identify the data.
• Confirm that the table makes sense without relying on visual position alone.

• Give the file a descriptive filename.
• Set the document title and primary language when the application supports those properties.
• Use meaningful worksheet, section, or bookmark names when applicable.

• Review file properties before sharing.
• Confirm that the displayed title is meaningful.

• Use Word’s Accessibility Checker.
• In Google Docs, complete a manual review and use an organization-approved add-on when available.
• Correct issues rather than merely recording that a checker was run.

• Review checker findings.
• Complete the universal checklist.
• Check the final shared version.

• Correct the source document first.
• Use a supported Save As or Export process rather than Print to PDF when printing removes structure.
• Review the PDF’s tags, reading order, headings, lists, tables, links, images, language, and title.

• Open the PDF in an appropriate PDF accessibility tool.
• Use automated and manual checks.
• Do not rely solely on a checker result.

• Use a descriptive filename.
• Give every worksheet a short, meaningful name.
• Remove unused or empty worksheets.
• Avoid default names such as Sheet1, Sheet2, or Copy of Sheet1.

• Review the workbook title and sheet-tab list.
• Confirm that someone can understand each sheet’s purpose from its name.

• Begin at or near cell A1.
• Provide a worksheet title and short instructions.
• Identify units, data source, reporting period, abbreviations, and update date when applicable.
• Explain unusual conventions or input expectations.

• Begin in A1 and navigate through the opening cells.
• Confirm that the user receives enough context before reaching the data.

• Organize each data table as a contiguous rectangle.
• Use a single header row when possible.
• Avoid merged cells, split cells, nested tables, blank spacer rows, and blank spacer columns.
• Keep separate data sets in separate clearly labeled regions or worksheets.
• Freeze panes only as a visual aid; do not rely on freezing to communicate structure.

• Navigate through the data by row and column.
• Confirm that headers identify each value.
• Check for unexplained blank cells and interrupted data regions.

• Decide whether a blank cell means zero, not applicable, unavailable, not collected, or intentionally blank.
• Use clear text or documented codes when the distinction matters.
• Do not use “N/A” for several different meanings without explanation.

• Review blank cells and special codes.
• Confirm that the meaning is available without relying on color or visual position.

• Use readable fonts and sizes.
• Maintain sufficient text and graphical contrast.
• Use text labels, symbols, or patterns in addition to color.
• Identify input cells, calculated cells, warnings, and status with text; not color alone.

• Review in grayscale.
• Test color combinations.
• Confirm that status remains understandable when formatting is removed.

• Use descriptive link text.
• Put essential instructions in cells or an instructions worksheet rather than relying only on comments or notes.
• Make data-validation instructions and error messages specific.

• Test links and validation errors.
• Confirm that instructions are easy to locate and read.

• Give charts descriptive titles and axis labels.
• Do not rely only on color to distinguish series.
• Provide alternative text or a nearby summary.
• Keep the underlying accessible data available.
• Use a table or structured text when a chart cannot communicate all necessary detail accessibly.

• Read the chart title, labels, and description without looking at the chart.
• Confirm that the underlying data is available.

• Use text instructions to distinguish cells users should edit.
• Protect or separate formulas when appropriate.
• Explain key outputs and calculations.
• Make formula errors understandable.

• Navigate the spreadsheet without relying on visual formatting.
• Confirm that users can identify where to enter information and where results appear.

• Run Excel’s Accessibility Checker.
• Use an approved addon if available to check in Google Sheets
• Complete manual checks in Excel and Google Sheets.
• Check charts, formulas, names, links, comments, and worksheet order.
• Check any PDF export separately.

• Navigate the workbook by keyboard.
• Review every worksheet.
• Open shared links with the intended permissions.

• Write a subject that identifies the topic, action, or deadline.
• Put the main message and requested action near the beginning.
• Include exact dates rather than relying only on “today,” “tomorrow,” or “next week.”

• Read the subject without opening the message.
• Confirm that the recipient can identify the purpose and urgency.
• Confirm that deadlines and actions are easy to locate.

• Use short paragraphs and lists.
• Use built-in headings for longer messages when the email platform supports them.
• Avoid layout tables, background images, stationery, and multi-column designs.
• Use HTML or rich text only when formatting adds meaningful structure; plain text remains appropriate for simple messages.

• View the message on a phone or narrow screen.
• Confirm that it does not require horizontal scrolling.
• Confirm that the reading order remains logical.

• Use a familiar, uncluttered font.
• Use 12-point or larger body text as the NCDPI starting point.
• Use dark text on a simple, light background when possible.
• Do not rely on font color alone for meaning.
• Avoid long passages in all capitals, italics, or underlining.

• Review the message at increased zoom and in dark or high-contrast settings.
• Test any nonstandard text and background colors.

• Use the title or purpose of the destination as the link text.
• Introduce a visible URL before presenting it when Gmail or another context requires a displayed address.
• Identify file types for downloads.
• Avoid shortened URLs that obscure the destination.

• Scan only the links.
• Test every link and confirm public permissions.

• Add alternative text when the email platform supports it.
• Repeat essential information from flyers or graphics in the email body.
• Avoid image-only announcements.
• Keep logos and decorative elements from becoming repetitive screen-reader output.

• Review the message with images unavailable.
• Confirm that recipients still receive the full message.
• Verify alternative text in the final email.

• Check attachments before sending.
• Use descriptive filenames.
• Include essential information in the email body when practical.
• Confirm that Google Drive, OneDrive, or SharePoint permissions allow the intended recipients to open the file.
• Identify the file type in the link or attachment description.

• Open the attachment.
• Test shared links while signed out or from an account outside the organization when appropriate.
• Confirm that the file itself is accessible.

• Put contact information in real text.
• Avoid using a table to arrange the signature.
• Add appropriate alternative text to meaningful logos.
• Do not use an image containing all contact information.
• Avoid animated graphics and excessively small text.

• Review the signature at increased zoom and with images unavailable.
• Confirm that the name, role, phone number, and email address remain available as text.

• In Outlook, run the built-in Accessibility Checker when available.
• In Gmail, complete a manual review; do not instruct users to run a Gmail checker that does not exist.
• Check the subject, structure, links, images, attachments, and permissions.

• Send a test copy when the message is high impact or uses a complex newsletter design.
• Review the received version on desktop and mobile.

• Use plain language, sentence case, and short paragraphs.
• Put the main message and action first.

• Capitalize each word in multiword hashtags, such as #DigitalAccessibility.
• Avoid decorative Unicode characters used to imitate special fonts.
• Use emojis sparingly and avoid interrupting sentences.

• Use the platform’s alt-text feature.
• Do not rely on an automatically generated description.

• Correct automatic captions.
• Provide a transcript or linked accessible version when needed.

• Introduce the resource before a visible URL when the platform does not support linked descriptive text.
• Avoid unnecessary URL shorteners that obscure the destination.

• Use large, uncluttered text and sufficient contrast.
• Repeat essential information in the post text or on a linked accessible webpage.
• Do not use a flyer image as the only source of event information.

• Avoid rapidly flashing content.
• Provide a way to pause or stop nonessential motion when the platform permits it.

• When the platform cannot present complex information accessibly, link to an accessible webpage or document containing the complete information.
• Do not place the only registration instructions, deadline, or public notice in an inaccessible image.

• Include spoken words, speaker identification, and meaningful sounds.
• Correct automatic captions.

• Provide transcripts for audio-only content and when they improve access to video.
• Use accessible HTML or a properly structured accessible document.

• Incorporate important visual information into narration when possible.
• Add audio description when important visuals are not otherwise communicated.

• Arrange live captions and requested communication access.
• Make slides and supporting materials available accessibly.

• Give every page a descriptive title.
• Use one clear visible page heading.
• Organize sections with logical headings.
• Use the site template’s structural regions rather than recreating them in content.

• Review the browser-tab title and visible page heading.
• Review the heading outline.
• Confirm that navigation and main content regions are understandable.

• Determine what the image contributes in its current context.
• Add concise alternative text to meaningful images. Describe the image’s purpose or essential information rather than every visible detail.
• Mark an image as decorative when it adds no information and performs no function. In HTML, decorative images generally use an empty text alternative: alt="".
• When an image contains essential text, provide that information as real text nearby whenever possible.
• For charts, diagrams, maps, infographics, and other complex visuals, provide a short alternative text and make the complete information available in nearby text, a list, or an accessible data table.
• For an image used as a link or button, describe the action or destination rather than its appearance.
• Review automatically generated alternative text before publishing. Do not assume an AI-generated description reflects the image’s purpose.

• Inspect alternative text and decorative treatment.
• Confirm that charts and infographics have complete equivalent information.

• Use descriptive links.
• Identify downloadable file types.
• Make linked files accessible before posting them.
• Remove or replace outdated and duplicate downloads.

• Scan links.
• Open every download.
• Confirm public permissions and current versions.

• Use responsive templates.
• Avoid fixed-size text and layouts that prevent resizing.
• Maintain sufficient contrast.
• Do not put essential text only inside images.

• Test at 200% and 400% zoom where applicable.
• Test a narrow viewport.
• Confirm that content does not overlap, disappear, or require unnecessary two-directional scrolling.

• Ensure every interactive control works without a mouse.
• Preserve a logical focus sequence.
• Make keyboard focus visible.
• Avoid keyboard traps.

• Use Tab, Shift+Tab, Enter, Space, arrow keys, and Escape.
• Confirm that focus follows the expected task order.

• Use visible labels, clear instructions, logical grouping, and understandable errors.
• Use established accessible components instead of creating custom controls unnecessarily.
• Follow appropriate ARIA patterns when custom components are required.

• Check videos, maps, widgets, dashboards, forms, and vendor tools separately.
• Do not assume that embedding accessible-looking content makes it accessible.
• Provide an alternate route when a third-party component creates a barrier.

• Test the embedded experience from beginning to end.
• Confirm that focus enters and leaves the embedded content predictably.

• Combine automated scanning, keyboard testing, zoom/reflow review, manual checks, and assistive-technology or user testing when appropriate.
• Track defects through resolution.

• Test representative pages and complete critical user journeys.
• Recheck templates and components after site or platform updates.

• Prefer an accessible online form for recurring data collection when it supports the required task.
• Use a PDF form only when a fixed or downloadable form is genuinely necessary and can be remediated and tested.
• Consider privacy, security, authentication, mobile use, maintenance, and accessibility together.

• Complete the form on desktop and mobile.
• Confirm that the selected format supports the complete task accessibly.

• Provide a descriptive title.
• Explain why the information is being collected, who should complete the form, what information is needed, the expected completion time, and any deadline.
• Explain how information will be used or protected when appropriate.

• Review the opening instructions as a first-time user.
• Confirm that users know what to prepare before beginning.

• Use visible labels positioned consistently.
• Do not use placeholder text as the only label.
• Make sure programmatic labels match visible wording.
• Put instructions close to the relevant field.

• Navigate through the fields by keyboard or screen reader.
• Confirm that each field’s purpose is announced.

• Group related radio buttons and checkboxes under a clear question or legend.
• Use radio buttons for one choice and checkboxes for multiple choices.
• Avoid unnecessary drag-and-drop, visual ranking, drawing, or matrix interactions.
• Provide an equivalent method when a complex interaction cannot be made accessible.

• Navigate the group by keyboard.
• Confirm that the group question and each option are announced together.

• Identify required fields in text and programmatically.
• Do not rely on color or an asterisk without an explanation.
• Explain expected date, phone, identification, or other formats before input.

• Review required fields without relying on color.
• Enter information in an unexpected format and confirm that instructions remain available.

• Identify the field with the problem.
• Explain what went wrong and how to correct it.
• Preserve previously entered information.
• Move or direct focus to the error summary when the platform supports it.

• Submit the form with empty and incorrect fields.
• Confirm that errors are announced, associated with fields, and correctable.

• Maintain logical tab order and visible focus.
• Avoid keyboard traps.
• Permit users to extend or turn off time limits when required.
• Ensure that content reflows on smaller screens.

• Complete the full form using only a keyboard.
• Test increased zoom and a mobile-sized viewport.
• Test any timeout warning and extension control.

• Confirm successful submission in text.
• Explain what happens next.
• Provide a confirmation number, receipt, copy, or contact method when appropriate.
• Make status messages available to assistive technology.

• Complete a real or test submission.
• Confirm that the success message and next steps are clear.

• Use respondent or preview mode.
• Test normal submission, errors, save-and-return, attachments, authentication, and confirmation.
• Include assistive-technology or user testing for high-impact forms.

• Complete every major path from entry through confirmation.
• Test from outside the organization when the form is public.

• Organize modules, topics, weeks, or units consistently.
• Use meaningful page, assignment, module, and file names.
• Provide a clear starting point.
• Remove outdated, duplicate, and unpublished content that users may still encounter.
• Use current and unambiguous dates.

• View the course as a student.
• Confirm that the next action and navigation pattern are predictable from one module to the next.

• Use the LMS rich-content editor for material that is primarily read online.
• Apply headings, lists, links, tables, images, and media accessibly.
• Avoid uploading a PDF or document when an accessible native page would serve the task better.

• Review the page structure and keyboard access.
• Test the page on a narrow screen and at increased zoom.

• Apply the essentials guidance for headings, links, images, contrast, and readable text.
• Do not rely on color, indentation, or visual position alone.
• Keep complex visual information available in text or data.

• Review the heading outline.
• Scan links and alternative text.
• Review the page without images and color.

• Check Word, Google, PowerPoint, PDF, spreadsheet, and other files before uploading.
• Use descriptive filenames.
• Remove inaccessible duplicate versions.
• Provide HTML or another accessible format when it better supports the task.

• Open each file from the student view.
• Confirm permissions and accessibility in the final format.

• Correct captions.
• Provide transcripts and visual descriptions as needed.
• Confirm that embedded players are keyboard accessible.

• Watch with captions.
• Operate the player without a mouse.
• Confirm that the captions remain available after embedding.

• Write clear instructions and evaluation expectations.
• Use accessible question types.
• Avoid making drag-and-drop, visual matching, drawing, or timed interactions the only way to respond when an equivalent cannot be provided.
• Ensure accommodations, extended time, attempts, and availability settings are applied correctly.
• Make rubrics, feedback, and results accessible.

• Complete the activity in student view.
• Test keyboard navigation, errors, submission, and feedback.
• Verify accommodation settings with a test account when feasible.

• Review accessibility evidence before adoption.
• Test the actual product and the specific tasks students must complete.
• Do not treat an ACR, VPAT, vendor statement, or presence in an app marketplace as proof of accessibility.
• Establish an alternate path when a tool creates barriers.

• Complete critical tasks by keyboard and with appropriate assistive technology.
• Review the tool again after major updates.

• Review content after copying a course, importing a package, changing themes, or migrating between LMS platforms.
• Confirm that headings, links, media, dates, files, and tool integrations still work.

• Run through each module after import.
• Do not assume accessibility survives migration.

• Run the LMS accessibility checker when one is available.
• Correct identified issues.
• Complete manual checks for content and interactions outside the checker’s scope.
• Test the student journey.

• Compare checker results with a manual review.
• Inspect external tools, embedded content, uploaded files, and complex assessments separately.

• Tell students and staff where to report inaccessible course content.
• Identify who owns corrections and how urgent access needs will be addressed.
• Provide an accessible alternative promptly while a systemic correction is made.

• Follow the reporting route as a user.
• Confirm that it is accessible and monitored.