ADA Compliance in Online Notarization: Accessibility Requirements

Remote online notarization promises convenience and expanded access. But that promise rings hollow if the technology itself creates barriers for people with disabilities.

Approximately 27% of American adults live with some type of disability. Among them, cognitive disabilities are the most common, followed by mobility limitations, hearing difficulties, and vision impairments. When RON platforms are designed without accessibility in mind, they exclude millions of people from services that were meant to make notarization easier.

This guide covers what RON platforms must provide under the Americans with Disabilities Act, what WCAG standards apply, specific accommodations for different disability types, and how to distinguish legal requirements from optional best practices.

The Legal Foundation: ADA and Digital Accessibility

The Americans with Disabilities Act (ADA), enacted in 1990, prohibits discrimination against people with disabilities in all areas of public life. While the original law predates the modern internet, courts and the Department of Justice have consistently held that ADA requirements apply to digital services.

Title III: Public Accommodations

Title III of the ADA requires businesses open to the public to provide “full and equal enjoyment” of their goods, services, and facilities to people with disabilities. This includes providing “auxiliary aids and services” necessary for effective communication.

RON platforms—whether operated by notary service companies, title companies, or technology providers—generally qualify as public accommodations under Title III. They offer services to the public and must therefore ensure those services are accessible.

The DOJ’s Position on Web Accessibility

The Department of Justice has consistently maintained that websites and digital services fall under ADA coverage. In April 2024, the DOJ published a final rule specifically addressing web accessibility for state and local governments (Title II), requiring compliance with WCAG 2.1 Level AA by April 2026 or 2027 depending on the entity’s size.

While this rule directly applies to government entities, it signals the DOJ’s direction on digital accessibility standards and reinforces WCAG 2.1 Level AA as the expected benchmark for all covered entities.

Section 508 for Government-Related Services

RON platforms serving federal agencies or government-funded entities must also comply with Section 508 of the Rehabilitation Act. Section 508 requires that electronic and information technology be accessible to people with disabilities. The current Section 508 standards reference WCAG 2.0 Level AA.

WCAG 2.1: The Technical Standard

The Web Content Accessibility Guidelines (WCAG), published by the World Wide Web Consortium (W3C), provide the technical specifications for digital accessibility. While WCAG itself is not a law, it has become the de facto standard referenced in accessibility litigation, enforcement actions, and regulations.

WCAG 2.1 Level AA is the current benchmark for accessibility compliance. It includes 78 success criteria organized around four principles, known by the acronym POUR:

Perceivable

Information and user interface components must be presentable in ways users can perceive. This means content cannot rely solely on a single sense:

Text alternatives. All non-text content (images, buttons, icons) must have text alternatives that screen readers can announce.

Captions and transcripts. Video content must include synchronized captions. Audio-only content needs transcripts.

Color independence. Information cannot be conveyed through color alone. Color-coded status indicators must also include text or symbols.

Contrast ratios. Text must have sufficient contrast against backgrounds—at least 4.5:1 for normal text, 3:1 for large text.

Operable

Interface components and navigation must be operable by all users:

Keyboard accessibility. All functionality must be available using only a keyboard. No feature can require a mouse, trackpad, or touchscreen.

No time traps. Users must have control over time limits. If a session times out, users must receive warning and the ability to extend.

No seizure-inducing content. Nothing can flash more than three times per second.

Navigation aids. Skip links, proper heading structure, and focus indicators must help users navigate.

Understandable

Information and interface operation must be understandable:

Readable content. Language must be identified programmatically. Reading level should be appropriate for the audience.

Predictable behavior. Pages must behave consistently. Similar functions should work the same way throughout.

Error prevention. Forms must help users avoid and correct errors through clear labels, validation, and error messages.

Robust

Content must be robust enough to work with current and future assistive technologies:

Valid code. HTML must be properly structured so assistive technologies can parse it correctly.

Name, role, value. Custom interface elements must communicate their purpose and state to assistive technologies through proper coding.

What RON Platforms Must Provide

Given the ADA’s requirements and WCAG’s technical specifications, here is what RON platforms must address:

Screen Reader Compatibility

Screen readers are software applications that convert on-screen text and elements into speech or Braille output for users who are blind or have low vision. RON platforms must be fully navigable and usable with screen readers.

Required elements:

• All buttons, links, and interactive elements must have accessible names that screen readers can announce
• Form fields must have associated labels
• Status changes (such as “document signed” or “verification complete”) must be announced to screen reader users
• Navigation must follow a logical order
• All content—including document text displayed during signing—must be accessible

Common failures:

• Unlabeled buttons (screen readers announce only “button” with no indication of function)
• Images without alt text
• Custom controls built without proper ARIA attributes
• Modal dialogs that trap focus or are not announced
• Dynamic content that changes without notification

Keyboard Navigation

Users with motor disabilities, visual impairments, or other conditions may rely entirely on keyboards. RON platforms must support complete keyboard operability.

Required elements:

• Every interactive element must be reachable via Tab key
• Focus indicators must be visible so users know where they are
• Interactive elements must respond to Enter or Space keys
• No keyboard traps (users must be able to navigate away from any element)
• Logical tab order following visual layout

RON-specific considerations:

• Document navigation must work with keyboard controls
• Signature application must be keyboard-accessible
• Video conference controls (mute, camera, end session) must be keyboard-operable
• Identity verification processes must not require mouse-only interactions

Video Accessibility for Deaf and Hard of Hearing Users

RON inherently involves live video communication between the notary and signer. This creates specific accessibility obligations for users who are deaf or hard of hearing.

Required accommodations:

The ADA requires “effective communication,” which means the platform must support methods that work for deaf and hard of hearing users. Options include:

Sign language interpreters. For users who communicate via American Sign Language (ASL), the platform must be able to accommodate a qualified sign language interpreter in the video session. This may require:

• Multi-party video capability (notary, signer, interpreter)
• Adequate video quality for clear sign language visibility
• Sufficient bandwidth for smooth interpretation

Real-time captioning. Live captions (also called Communication Access Realtime Translation or CART) convert spoken words to text in real time. Platforms should either:

• Integrate with captioning services
• Support third-party captioning tools
• Provide built-in automatic speech recognition with manual correction capability

Text-based communication. Written communication can serve as an alternative for some interactions:

• Chat functionality within the video session
• Ability to communicate instructions via on-screen text
• Written confirmation of verbal statements

Interpreter requirements vary by state. Colorado, for example, requires that sign language interpreters serving deaf, hard of hearing, or deafblind individuals hold valid certification from the Registry of Interpreters for the Deaf (RID) or equivalent certification approved by the state commission. For remote notarizations, the interpreter must appear via the platform’s audio-video technology.

Accommodations for Low Vision

Users with low vision (partial sight) may need different accommodations than users who are fully blind:

Required elements:

• Text resize capability (content must remain usable when text is enlarged 200%)
• Zoom compatibility (content must not break when browser zoom is used)
• Sufficient color contrast throughout the interface
• No information conveyed through color alone
• Scalable graphics and icons

RON-specific considerations:

• Document viewing must support magnification
• Signature placement must be visually clear at various zoom levels
• Video interface controls must be large enough to see and click
• Identity verification processes must accommodate screen magnification

Cognitive Accessibility

Cognitive and learning disabilities affect how people process information. While WCAG addresses some cognitive accessibility concerns, additional guidance from the W3C’s Cognitive and Learning Disabilities Accessibility Task Force (COGA) provides supplemental recommendations.

Core requirements:

• Clear, simple language in instructions
• Consistent navigation and layout
• Error prevention and clear error messages
• No unnecessary time pressure
• Help features available throughout the process
• Predictable behavior (no unexpected actions)

RON-specific considerations:

• Multi-step processes should include progress indicators
• Instructions should be concise and scannable
• Important actions should require confirmation to prevent accidental errors
• Session timeout warnings should allow users to extend time
• Critical information should not disappear automatically

Additional COGA recommendations (best practices, not strict requirements):

• Provide alternative login methods that do not require complex passwords or memory-intensive security questions
• Avoid CAPTCHA or provide accessible alternatives
• Use familiar design patterns
• Allow users to customize display preferences
• Provide help in multiple formats (text, video, examples)

Motor and Mobility Accommodations

Users with motor disabilities may have difficulty with precise mouse movements, sustained holding, or rapid actions.

Required elements:

• Large click targets (minimum 44×44 pixels per WCAG 2.1)
• No features requiring dragging, hovering, or complex gestures without alternatives
• Sufficient time for all actions
• No features requiring simultaneous actions
• Support for alternative input devices (switch controls, voice input)

RON-specific considerations:

• Signature capture must accommodate alternative input methods
• Document navigation should not require precise clicking
• Video call controls should be accessible without fine motor control
• Identity verification should not require actions difficult for users with tremors or limited dexterity

What Platforms Must Provide vs. What’s Optional

Understanding the distinction between legal requirements and best practices helps platforms prioritize their accessibility efforts.

Legally Required

These elements are necessary for ADA compliance:

Best Practices (Recommended but Not Strictly Required)

These elements exceed minimum requirements but significantly improve accessibility:

State-Level Considerations

Some states have accessibility requirements beyond federal law:

California: The Unruh Civil Rights Act has been interpreted to require website accessibility. California Assembly Bill 434 requires state entities to meet WCAG 2.1 Level AA standards.

New York: New York City requires city agency websites to meet WCAG 2.0 Level AA, and state courts have been active in website accessibility litigation.

Colorado: State law specifically addresses interpreter qualifications for deaf and hard of hearing individuals, including requirements for RON sessions.

RON platforms serving customers in multiple states should comply with the most stringent applicable requirements.

The Notary’s Role in Accessible Service

While platform providers bear primary responsibility for technical accessibility, individual notaries also have obligations.

Providing Auxiliary Aids

When serving signers with disabilities, notaries may need to provide or facilitate accommodations:

For deaf or hard of hearing signers:

• Arrange for qualified sign language interpreters
• Use written communication when appropriate
• Ensure video quality sufficient for lip reading if the signer uses that method
• Allow additional time for interpreted communication

For signers with visual impairments:

• Describe document contents verbally when requested
• Ensure screen sharing is compatible with screen readers
• Allow time for signers using assistive technology
• Confirm understanding without requiring visual verification

For signers with cognitive disabilities:

• Use clear, simple language
• Provide step-by-step guidance
• Allow extra time for processing
• Confirm understanding at each step
• Never rush or pressure

Journal Documentation

When accommodations are provided, notaries should document them in their journal entries:

• Type of accommodation provided
• Name and credentials of any interpreter used
• Method of communication employed
• Any unusual circumstances related to the accommodation

This documentation protects both the notary and the signer by creating a clear record of how accessibility needs were met.

Refusing Service

The ADA prohibits refusing service based on disability. A notary cannot refuse to notarize for someone simply because they have a disability or require accommodations. Refusal is only appropriate when:

• The signer cannot be properly identified
• The signer does not appear to understand the transaction (regardless of disability status)
• The notarization would require the notary to engage in unlawful activity
• Providing the accommodation would fundamentally alter the nature of the service or create undue burden (a high bar to clear)

Testing and Compliance Verification

RON platforms should regularly test accessibility through multiple methods:

Automated Testing

Automated tools can identify approximately 30-50% of accessibility issues:

• WAVE (Web Accessibility Evaluation Tool)
• axe DevTools
• IBM Equal Access Accessibility Checker
• Lighthouse (built into Chrome DevTools)

Automated testing catches obvious issues like missing alt text, insufficient contrast, and improper heading structure.

Manual Testing

Human testing is essential for issues automation cannot detect:

• Screen reader testing with JAWS, NVDA, and VoiceOver
• Keyboard-only navigation testing
• Color contrast verification in context
• Form and error message review
• Focus order and indicator verification

User Testing

Testing with people who have disabilities provides insights no other method can:

• Users who are blind testing with their preferred screen reader
• Deaf users testing video accessibility features
• Users with motor disabilities testing with their assistive devices
• Users with cognitive disabilities evaluating clarity and simplicity

Common Accessibility Failures in RON Platforms

Based on general web accessibility audits and digital signing platform reviews, common issues include:

Document Viewer Problems

• PDF content not accessible to screen readers
• No keyboard navigation within documents
• Signature fields not properly labeled
• Zoom/magnification breaks document display

Video Conference Issues

• Controls not keyboard accessible
• No support for third-party captioning
• Insufficient video quality for sign language interpretation
• No text-based communication alternative

Identity Verification Barriers

• Knowledge-based authentication questions with time limits too short for users with cognitive disabilities
• Facial recognition not working well with assistive devices
• CAPTCHA without accessible alternatives
• Photo capture requiring precise positioning difficult for users with motor disabilities

Form and Navigation Issues

• Unlabeled form fields
• Error messages not associated with fields
• No skip links for long pages
• Inconsistent navigation patterns
• Focus traps in modal dialogs

Implementing Accessibility: Practical Steps

For RON platform providers serious about accessibility:

Immediate Actions

1. Run automated accessibility scans on all platform pages
2. Test keyboard navigation through complete user flows
3. Verify screen reader compatibility with at least one major screen reader
4. Check color contrast throughout the interface
5. Review all images and icons for alt text

Short-Term Improvements

1. Add ARIA labels to custom components
2. Implement visible focus indicators
3. Ensure all video content has captions
4. Provide text alternatives for any audio instructions
5. Create accessibility statement describing current status and plans

Long-Term Strategy

1. Incorporate accessibility into development process (not as an afterthought)
2. Train all team members on accessibility principles
3. Conduct regular accessibility audits
4. Establish user testing program including people with disabilities
5. Monitor for regressions when updates are deployed

Liability and Litigation Risks

The consequences of accessibility failures extend beyond ethical concerns. Legal exposure is substantial and growing.

Increasing Litigation

Website accessibility lawsuits have increased dramatically in recent years. Plaintiffs’ attorneys actively target businesses with inaccessible digital services, and RON platforms are not immune.

Common claims include:

• Failure to provide effective communication (ADA Title III)
• Discrimination in provision of services
• Violation of state accessibility laws (California Unruh Act, New York accessibility requirements)
• Breach of contract or negligent misrepresentation (if accessibility was promised but not delivered)

Settlement and Judgment Costs

Accessibility litigation settlements typically include:

• Monetary damages to plaintiffs
• Attorneys’ fees (often substantial)
• Mandatory accessibility remediation
• Ongoing monitoring and reporting requirements
• Potential injunctive relief

Even winning a lawsuit is expensive. Defending accessibility claims requires expert testimony, detailed technical analysis, and significant legal fees.

Proactive Compliance Benefits

Organizations that proactively address accessibility enjoy several advantages:

• Defense against claims (documented good-faith efforts matter)
• Lower remediation costs (fixing issues during development is cheaper than retrofitting)
• Competitive advantage (accessibility as a market differentiator)
• Reduced litigation risk (fewer grounds for claims)

Accessibility Statements and Policies

RON platforms should publish clear accessibility statements that:

Describe Current Accessibility Status

Be honest about where you are. State which standards you follow (WCAG 2.1 Level AA), what testing you have conducted, and known limitations.

Provide Contact Information

Give users a clear path to request accommodations or report accessibility problems:

• Dedicated accessibility email address
• Phone number with TTY or relay service information
• Expected response time for accessibility inquiries

Explain Available Accommodations

Document what accommodations the platform supports:

• Interpreter participation procedures
• Alternative verification methods
• Extended time options
• Available assistive technology compatibility

Commit to Ongoing Improvement

Accessibility is not a one-time project. Commit to:

• Regular accessibility audits
• User feedback incorporation
• Continuous improvement goals
• Training for development and support teams

Training Requirements

Accessibility cannot succeed without trained personnel at every level.

Developer Training

Developers need to understand:

• Semantic HTML and proper document structure
• ARIA attributes and when to use them
• Keyboard interaction patterns
• Screen reader behavior and testing
• Color contrast requirements
• Focus management in dynamic interfaces

Designer Training

Designers should know:

• Color contrast requirements and checking tools
• Touch target size minimums
• Focus indicator design
• Accessible typography (font size, spacing, line length)
• Cognitive load reduction techniques
• Inclusive design principles

Customer Support Training

Support teams must be prepared to:

• Recognize accessibility-related inquiries
• Explain available accommodations
• Escalate accessibility issues appropriately
• Communicate respectfully about disability
• Document accessibility feedback

Notary Training

Notaries performing RON should understand:

• Legal obligations under the ADA
• How to work effectively with interpreters
• Alternative communication methods
• Documentation requirements for accommodations
• When and how to provide extra time or assistance

The Business Case Beyond Compliance

Accessibility is not just about avoiding lawsuits. Accessible design benefits everyone:

Aging population: As users age, they may develop vision, hearing, motor, or cognitive challenges. Accessible platforms serve them better.

Temporary disabilities: A broken arm, eye surgery, or medication side effects can temporarily create accessibility needs.

Situational limitations: Bright sunlight, noisy environments, or holding a baby can create temporary need for accessibility features.

Better SEO: Accessible sites tend to rank better because search engines value clear structure, alt text, and clean code.

Larger market: The disability community represents significant purchasing power and loyalty to accessible brands.

Reduced support costs: Clear, accessible interfaces reduce user errors and support requests.

Frequently Asked Questions

Does the ADA apply to RON platforms?

Yes. RON platforms generally qualify as public accommodations under Title III of the ADA, which requires businesses to provide full and equal access to services for people with disabilities. This includes providing accessible digital interfaces.

What accessibility standard should RON platforms follow?

WCAG 2.1 Level AA is the current benchmark. The DOJ references WCAG in enforcement actions, and the April 2024 rule for state and local governments specifically requires WCAG 2.1 Level AA compliance.

How do deaf signers participate in RON sessions?

RON platforms must accommodate qualified sign language interpreters (via multi-party video) or real-time captioning services. Some platforms also support text-based chat as supplemental communication. The specific accommodation depends on the signer’s preference and communication method.

Must RON platforms provide automatic captions?

Automatic captions for live video are a best practice but not strictly required. What is required is the ability to accommodate captioning services or interpreters when requested. Pre-recorded video content, however, must have accurate captions.

Can a notary refuse to serve someone with a disability?

No. Refusing service based on disability violates the ADA. Notaries must provide reasonable accommodations. Refusal is only appropriate for legitimate reasons unrelated to disability, such as inability to verify identity or clear signs that the signer does not understand the transaction.

What are common accessibility failures in RON platforms?

Common issues include PDF documents not accessible to screen readers, video controls not keyboard-accessible, identity verification processes with inadequate time limits, missing alt text on buttons and images, and insufficient color contrast.

Who is responsible for accessibility; the platform or the notary?

The platform provider is primarily responsible for technical accessibility of the software. Individual notaries are responsible for providing appropriate accommodations during sessions, such as allowing interpreters or providing extra time. Both share responsibility for ensuring people with disabilities receive equal service.

What should I do if a RON platform is not accessible?

Users can file complaints with the Department of Justice Civil Rights Division or pursue private litigation. Platform operators should conduct accessibility audits and remediate issues promptly to avoid legal exposure.

Conclusion:

ADA compliance in online notarization is not optional. RON platforms must be accessible to people with disabilities, and the technical standard for that accessibility is WCAG 2.1 Level AA.

The core requirements are straightforward:

• Screen reader compatibility so users who are blind can navigate and use all features
• Keyboard accessibility so users who cannot use a mouse can complete notarizations
• Video accessibility so users who are deaf or hard of hearing can participate in live sessions with interpreters or captioning
• Visual accessibility so users with low vision can see and interact with content
• Cognitive accessibility so users with learning or cognitive disabilities can understand and complete the process

Platforms like Bluenotary that prioritize accessibility from the start create better experiences for all users while meeting their legal obligations. Those that treat accessibility as an afterthought risk both litigation and the exclusion of millions of potential customers.

Accessibility is not a feature to be added later. It is a fundamental requirement for equitable service.