Why accessibility matters

Opening script: Our organization has a purpose. Accessibility helps the people we serve reach that purpose. A website, document, or video can be the route into a service. If someone cannot use that route, they may be unable to participate independently. Invite the audience to think about an important task people need to complete. These are illustrative consequences, not measured outcomes for any organization. Source: W3C WAI, Introduction to Web Accessibility, https://www.w3.org/WAI/fundamentals/accessibility-intro/ .

Say: The event may welcome everyone, but the way we invite people can still exclude someone. These are invented examples, not findings about your organization. The improvements address different needs. Text alternatives convey meaningful image content, keyboard support enables interaction without a mouse, and text feedback avoids relying on color alone. Source: W3C WAI, Accessibility Principles, https://www.w3.org/WAI/fundamentals/accessibility-principles/ .

Say: Disability is not one experience, and needs can overlap or change. We cannot infer what someone needs from appearance. Ask people how they prefer to receive information and use feedback to identify barriers. Captions can also help someone in a noisy room, but disability access remains the central purpose. Avoid asking an audience member to disclose a disability. Source: W3C WAI, Introduction to Web Accessibility, https://www.w3.org/WAI/fundamentals/accessibility-intro/ .

Say: We do not need to promise a particular financial return to make a case. Connect accessibility to this organization’s actual goals: participation in programs, use of information, or effective service. W3C describes potential benefits for reach, innovation, brand, and risk management. Outcomes depend on the work and should be measured locally. The statements about templates and workflow are proposed operating practices, not guaranteed savings. Source: W3C WAI, The Business Case for Digital Accessibility, https://www.w3.org/WAI/business-case/ .

Explain: W3C organizes web accessibility around four principles: perceivable, operable, understandable, and robust. These examples introduce the principles rather than cover every requirement. For an image, the right text alternative depends on its purpose. For a video, captions do not replace every other media requirement. Use appropriate standards and testing for the actual content. Source: W3C WAI, Accessibility Principles, https://www.w3.org/WAI/fundamentals/accessibility-principles/ .

Say: A website may work well while an attached document blocks the task. Create accessible source files, then check the exported version. OCR alone does not establish an accessible reading order or complete document accessibility. Automated checkers can identify some issues, but manual review remains necessary. Describe your organization’s document workflow here. Source: W3C WAI, Introduction to Web Accessibility, https://www.w3.org/WAI/fundamentals/accessibility-intro/ . Practical examples apply its principles to documents.

Say: This presentation supports a decision to act. It does not determine legal compliance. Requirements differ across public entities, businesses, employment, education, and funding arrangements. Do not assign one WCAG version or deadline to every organization. State and local governments should consult the current DOJ Title II guidance and their responsible adviser. Review current requirements before presenting. Sources: U.S. Department of Justice, https://www.ada.gov/resources/web-guidance/ and https://www.ada.gov/resources/small-entity-compliance-guide/ . W3C WAI, Introduction to Web Accessibility, https://www.w3.org/WAI/fundamentals/accessibility-intro/ .

Say: We can be honest about limits and still make a concrete commitment. Propose a bounded first project with named responsibilities. A pilot is a planning approach, not an exemption from obligations or a reason to postpone individual access needs. Record issues outside the pilot and route urgent requests promptly. These are recommended practices for discussion, not a quote or cost estimate.

Say: This is a proposed sequence to adapt, not a promise that all accessibility work will finish in 90 days. Select a realistic scope and assign time before work begins. Compensate participants when appropriate and provide accessible ways to give feedback. Use expert help for issues beyond the team’s skills. Finish the pilot with an evidence-based next step and a continued process for handling access needs.

Say: Count activity, but also check the result. Running a checker or attending training does not prove that someone can use a service. Use appropriate automated tools plus manual checks and user feedback. Document what you tested, what you did not test, and the limitations. The pilot should produce a clear account of progress rather than a blanket claim of compliance. Source: W3C WAI, Introduction to Web Accessibility, https://www.w3.org/WAI/fundamentals/accessibility-intro/ .

Sources checked October 21, 2026. W3C WAI: https://www.w3.org/WAI/fundamentals/accessibility-intro/ ; https://www.w3.org/WAI/fundamentals/accessibility-principles/ ; https://www.w3.org/WAI/business-case/ . U.S. Department of Justice: https://www.ada.gov/resources/web-guidance/ ; https://www.ada.gov/resources/small-entity-compliance-guide/ . Current law and guidance can change. Recheck legal sources before presenting. Reuse: You may copy, adapt, and present this resource. Keep attribution and © Common Ground Accessibility 2026. Adapt the request slide for your organization. Do not describe the presentation as certification or legal advice.