Religious-organization websites operate under a legal and ethical posture different from any other sector. The legal status varies: in the United States, houses of worship are not categorically exempt from the Americans with Disabilities Act, but the case law is uneven and several circuits treat religious entities more leniently than other public accommodations; the Rehabilitation Act applies to congregations that accept federal funds (including PPP loans, FEMA disaster aid, USDA food-program funding, and DOJ community-grant money); state laws including the California Unruh Act apply broadly and have been used against congregations with public-facing services or fee-charging programs; the European Accessibility Act applies to any digital service offered to EU residents including livestream worship for diaspora communities. The user population tilts heavily toward the audiences that depend on accessibility most: older congregants who cannot drive to in-person services, members with hearing loss who depend on captions for the sermon livestream, blind members navigating the online prayer-request form, neurodiverse worshippers who attend remote services because in-person sensory load is overwhelming. The workflows that recur across the sector—sermon livestreaming and archived recordings, weekly bulletins as PDF, online giving and tithing through Tithe.ly or Pushpay, event registration through Planning Center or Realm, member portals, prayer-request submission, daily-devotional and study-group resources—are each capable of excluding the very congregants the institution exists to serve. This guide covers the legal landscape, the sector-specific accessibility failures, and a concrete compliance checklist for individual congregations as well as multi-site denominations and parachurch ministries.

Legal Requirements

Key Accessibility Issues in Religious Organizations & Houses of Worship

Sermon Livestreams Without Captions or Sign-Language Interpretation

Sermon livestreaming has become near-universal since 2020 and is the single highest-reach digital service most congregations operate. The vast majority of livestreams ship with no captions and no sign-language interpretation. Deaf and hard-of-hearing congregants—who in religious communities are disproportionately likely to be older and to have relied on the in-person community for meaning—are entirely excluded. Archived recordings of the same services on the church YouTube channel typically carry only auto-generated captions, which routinely mistranscribe the names of biblical figures, Hebrew or Arabic terms, theological vocabulary, and proper nouns of community members.

How to fix:

Enable real-time captioning on the livestream platform (YouTube Live auto-captions are a baseline; professional CART for major holidays and high-attendance services). Recruit and budget for a sign-language interpreter for at least one Sunday or sabbath service per month, with the interpretation framed in a separate camera stream or picture-in-picture. Edit auto-generated captions on archived sermons before publishing, with special attention to proper nouns and theological vocabulary. Post a transcript of the sermon within one week.

Online Giving and Tithing Forms With Inaccessible Payment Flows

Online giving is now the primary income source for most congregations and typically runs through Tithe.ly, Pushpay, Givelify, Subsplash Giving, or Planning Center Giving. The embedded giving widgets vary widely in accessibility. Recurring failures: amount-selection buttons that are <div> elements without role="button" or keyboard support; recurring-gift schedule selectors using a custom calendar with no keyboard alternative; payment-method tabs (card, bank, Apple Pay, PayPal) that fail screen-reader switching; CAPTCHA on the giving form blocking blind users from completing their gift.

How to fix:

Demand a current VPAT from your giving-platform vendor; switch vendors if the live flow fails screen-reader and keyboard testing. Where vendor-side fixes are slow, deploy the giving form as a hosted page on the vendor's own domain (vendor liability) rather than embedded. Provide a clearly-labeled alternative giving channel: a phone number, a mailing address, and a text-to-give shortcode. Replace CAPTCHA with honeypot fields or Cloudflare Turnstile.

Weekly Bulletins, Service Programs, and Liturgy as Image-Only PDFs

The weekly bulletin, the high-holiday liturgy, the wedding and funeral programs, and the denominational-meeting handouts are nearly always distributed as PDFs. A substantial fraction of those PDFs are scanned images of typeset documents or are exported from print-design tools without tagging, which makes them unreadable by screen-reader software. A blind member following along with the liturgy is unable to do so independently. Children's-ministry curricula and adult-study materials have the same problem at higher volume.

How to fix:

Generate bulletins from a tagged source (Word with proper headings exported to PDF, or Google Docs exported to PDF with structure preserved) rather than from print-design software without tagging. When a print-designed bulletin is required, run it through Adobe Acrobat Pro's accessibility checker and tag the document before publishing. Provide an HTML version of the same bulletin on the church website as the primary format and a PDF as the secondary download. Liturgical responses, hymn lyrics, and scripture readings must be in the HTML version.

Event Registration and Member Portals With Inaccessible Multi-Step Forms

Planning Center, Realm, Subsplash, ChurchTrac, and other church-management systems power event registration (VBS, retreats, mission trips, small-group sign-ups), member portals, and volunteer scheduling. Their embedded forms are frequently complex multi-step flows with custom field types (payment, T-shirt size selection, dietary restrictions, child-allergy fields) that lose screen-reader users between steps and fail keyboard-only interaction. Family-registration flows that require adding multiple children compound the failure.

How to fix:

Choose the hosted form on the vendor domain over the embedded form when the option exists. Test the live registration flow with NVDA or VoiceOver before each major event. Provide a phone-and-paper alternative registration channel; document it in the accessibility statement. For multi-child or family registrations, ensure focus is moved to the new field group when an additional child is added and that the cumulative form state is announced to assistive technology.

Prayer-Request Submission Forms and Pastoral-Care Contact That Lack Accessible Confirmation

Prayer-request submission forms are deeply intimate digital experiences and are often the single highest-stakes form on a religious-organization site. They frequently lack proper labels, fail to confirm submission accessibly (the user has no way to know whether the prayer request was actually sent), and require image CAPTCHAs that exclude blind users. The pastoral-care contact form has the same problems.

How to fix:

Use visible <label> elements for every field. Confirm submission via a polite live region announcement and redirect focus to a clearly-named confirmation page. Replace image CAPTCHAs with honeypot fields or Cloudflare Turnstile. Provide a direct phone number and email address for prayer requests as a documented alternative.

Compliance Checklist

  • Sermon livestreams include captions (auto-captions baseline, professional CART for major services) and offer sign-language interpretation at least monthly
  • Archived sermon recordings have human-edited captions and a published transcript within one week of recording
  • Online giving form is keyboard- and screen-reader-accessible end to end; alternative channels (phone, mail, text-to-give) are documented
  • Weekly bulletins and liturgical materials are published in HTML as the primary format; PDFs are tagged and accessibility-checked
  • Event registration and member portal forms are tested with a screen reader before each major event
  • Prayer-request and pastoral-care contact forms have labels, accessible spam protection, and accessible success confirmation
  • Color contrast meets 4.5:1 for body text and 3:1 for UI components and large text across the site
  • Site has been audited against WCAG 2.2 AA within the past 12 months and findings tracked to remediation
  • Accessibility statement is published with contact channel for accommodations and last review date
  • All embedded vendor widgets (giving, registration, livestream) have a current VPAT or documented accessibility commitment from the vendor

Further Reading

Other Industry Guides