Ada Compliance for Credit Unions: The 2026 Guide That Finally Makes Sense

Introduction: Why Accessibility Auditing Matters for Credit Unions

In 2026, credit union websites face unprecedented scrutiny regarding digital accessibility. The Department of Justice’s continued emphasis on Web Content Accessibility Guidelines (WCAG) 2.1 Level AA as the legal standard, combined with a surge in ADA Title III lawsuits targeting financial institutions, has made accessibility compliance a board-level priority for credit unions of all asset sizes. However, achieving and maintaining compliance is not a one-time initiative—it requires a systematic, repeatable accessibility auditing process that identifies barriers, prioritizes remediation, and verifies that fixes are effective.

An accessibility audit is a comprehensive evaluation of a website’s conformance against established accessibility standards, most commonly WCAG 2.2 Level AA. For credit unions, the stakes are exceptionally high. According to the FDIC’s 2025 National Survey of Unbanked and Underbanked Households, approximately 5.9 million U.S. households remain unbanked, and a disproportionate number include individuals with disabilities. Additionally, the U.S. Census Bureau reports that over 14% of American adults have a disability, representing a massive and often underserved membership demographic that credit unions are uniquely positioned to serve.

This guide provides a comprehensive, technical methodology for conducting WCAG 2.2 AA accessibility audits specifically tailored to credit union digital banking platforms. We cover automated scanning tools, manual testing procedures, screen reader verification protocols, assistive technology validation, and the reporting frameworks necessary to transform audit findings into actionable remediation roadmaps. Whether you are a credit union marketing director preparing for a website redesign, a compliance officer managing vendor risk, or a web developer implementing accessible components, this guide provides the step-by-step audit methodology you need.

The WCAG 2.2 AA Audit Framework: Understanding POUR Principles

Before diving into specific testing tools and techniques, it is essential to understand the conceptual framework that underpins every accessibility audit. The WCAG 2.2 standard, published by the World Wide Web Consortium (W3C), organizes its 86 success criteria around four foundational principles known collectively as POUR: Perceivable, Operable, Understandable, and Robust. Each principle addresses a distinct dimension of accessibility, and a comprehensive audit must evaluate success criteria across all four principles.

Perceivable: Content Must Be Accessible to the Senses

The Perceivable principle requires that all content and user interface components be presented to users in ways they can perceive. This encompasses 30 success criteria in WCAG 2.2, including text alternatives for non-text content (1.1.1), captions for multimedia (1.2.2), adaptable content that preserves meaning when presented in different ways (1.3.x), distinguishable content with sufficient color contrast (1.4.3), and the ability to resize text up to 200% without loss of functionality (1.4.4). For credit union websites, perceivability issues most commonly manifest in missing alt text on images, low-contrast text on financial forms, and inaccessible data visualizations on online banking dashboards.

Operable: All Functionality Must Be Available via Keyboard and Other Input Methods

The Operable principle demands that user interface components and navigation be operable by all users, regardless of input method. This covers 26 success criteria in WCAG 2.2, including full keyboard accessibility (2.1.1), no keyboard traps (2.1.2), adjustable time limits (2.2.1), seizure prevention through limited flash rates (2.3.1), and navigable content through logical heading structures and skip navigation links (2.4.x). WCAG 2.2 introduced a critical new success criterion: Focus Appearance (2.4.13), which requires that keyboard focus indicators have a minimum area and contrast ratio—a significant change from WCAG 2.1’s less prescriptive focus requirement. Credit union websites often fail operable criteria due to custom dropdown menus that trap keyboard users, modal dialogs without focus management, and missing skip-to-content links on account login pages.

Understandable: Content and Interface Must Be Clear and Predictable

The Understandable principle ensures that content and operation of the user interface are comprehensible. This includes 18 success criteria covering readable text through language declarations (3.1.1), predictable behavior through consistent navigation and functionality (3.2.x), and input assistance through descriptive labels, error identification, and error suggestions (3.3.x). WCAG 2.2 added Accessible Authentication (3.3.8) which requires that login processes do not rely exclusively on cognitive function tests (like memorizing passwords or solving puzzles). For credit unions, understandability issues often emerge in complex loan application forms with unclear validation errors, inconsistent navigation patterns between the marketing website and online banking portal, and login flows that lack accessible authentication alternatives.

Robust: Content Must Be Compatible with Current and Future User Tools

The Robust principle requires that content be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies. This encompasses 12 success criteria focused primarily on proper coding practices, complete start and end tags, unique IDs, and ARIA implementation. A single success criterion, 4.1.2 (Name, Role, Value), covers all HTML and ARIA attribute usage to ensure that custom components communicate their identity, state, and properties to assistive technologies correctly. Credit union websites frequently fail robust criteria due to improper ARIA attribute usage in custom interactive components, duplicate IDs generated by content management systems, and missing form input labels in dynamically loaded content.

Automated Accessibility Scanning: Tools, Configuration, and Interpretation

Automated accessibility scanning tools are the first line of defense in any accessibility audit. These tools programmatically scan web pages against a subset of WCAG success criteria that can be evaluated algorithmically. While automated tools cannot detect all accessibility issues—they typically catch only 30-40% of all WCAG violations according to WebAIM’s Million report—they provide a rapid, repeatable baseline assessment that is essential for scaling accessibility testing across large websites.

Selecting the Right Automated Scanning Tools

For credit union accessibility audits, we recommend a multi-tool approach that combines static analysis, browser-based inspection, and continuous integration scanning. The following tools represent the current industry standard in 2026:

aXe by Deque Systems is widely considered the gold standard for automated accessibility testing. Available as a browser extension for Chrome, Firefox, and Edge, as well as a Node.js module for CI/CD integration (@axe-core/cli), aXe identifies accessibility violations with minimal false positives. The tool categorizes issues by severity (critical, serious, moderate, minor) and provides clear guidance on remediation. For credit unions, aXe’s ability to scan single-page applications and dynamically rendered content is particularly valuable given the prevalence of Angular, React, and Vue.js frameworks in modern digital banking platforms. aXe can be installed via npm: npm install @axe-core/cli -g, and run against a URL with axe URL --save report.json.

WAVE (Web Accessibility Evaluation Tool) from WebAIM provides a visual, browser-based accessibility testing experience that is particularly useful for non-technical stakeholders. The WAVE browser extension overlays accessibility icons and indicators directly on the page being tested, making it easy to see where issues occur. WAVE is excellent for quick spot-checks and for educating credit union marketing and content teams about accessibility because the visual overlay makes abstract WCAG concepts concrete and visible.

Google Lighthouse Accessibility Audits are integrated directly into Chrome DevTools and provide an automated accessibility score with detailed recommendations. Lighthouse is particularly useful for its performance and site performance and search optimization capabilities, allowing credit union teams to assess accessibility metrics alongside page speed and ranking factors in a single tool. However, Lighthouse’s accessibility scoring is based on a subset of automated tests and should not be used as a comprehensive audit—a perfect Lighthouse accessibility score does not guarantee WCAG conformance.

ANDI (Accessible Name and Description Inspector) from the U.S. Social Security Administration is a free bookmarklet that reveals how assistive technologies interpret page elements. ANDI is uniquely valuable for credit union auditors because it exposes the accessible name, role, state, and properties of each interactive element—information that screen readers actually use. This tool is indispensable for verifying ARIA implementation and should be used during the manual testing phase.

Building a Representative Page Sample for Automated Scanning

Automated scanning of every page on a credit union website is rarely practical. Instead, auditors should select a representative sample of page templates and functional flows. For a typical credit union website audit, include at least:

The homepage (typically the highest-traffic page)
Online banking login page and authenticated dashboard
Membership application form (often the most complex and failure-prone page)
Loan application page for at least one product type (auto, mortgage, or personal loan)
Branch/ATM locator page
Rate and fee disclosure page
Contact us page
Site search results page
404 error page
At least three content pages with varying layouts (article, landing page, calculator)
Mobile-responsive versions of all above pages

For each page, configure the scanning tool to evaluate against WCAG 2.2 Level AA standards. Run scans at multiple viewport sizes (desktop 1280px, tablet 768px, mobile 375px) to capture responsive design issues. Save all scan results in a structured format (JSON or CSV) to enable trend analysis and remediation tracking over time.

Interpreting Automated Scan Results

Automated scan results must be interpreted with care. A common mistake among credit union teams is treating an automated scan as a final audit pass. In reality, automated tools have several important limitations:

They cannot determine if alt text is contextually appropriate—only that it exists
They cannot evaluate the logical reading order of content
They cannot assess whether error messages provide sufficient guidance
They cannot verify keyboard accessibility of complex custom widgets
They cannot validate video caption accuracy against spoken content
They cannot evaluate the comprehensibility of written content

For each automated finding, auditors should manually verify the issue, determine its real-world impact on users with disabilities, and assess whether it represents a true WCAG failure or a false positive. The W3C’s Understanding WCAG 2.2 documentation provides detailed guidance on interpreting each success criterion and should be referenced throughout the review process.

Manual accessibility testing is the most labor-intensive but most valuable component of an accessibility audit. Unlike automated scanning, manual testing can evaluate WCAG success criteria that require human judgment, such as logical reading order, meaningful link text, and appropriate heading hierarchy. For credit union digital banking platforms, manual testing is particularly critical for evaluating complex workflows like account opening, loan applications, and fund transfers—interactions that involve multiple steps, dynamic content updates, and form validation.

The most fundamental manual test is keyboard-only navigation. Every interactive element on a credit union website must be operable using only the keyboard. To perform this test, navigate every page using only the Tab key, Shift+Tab (reverse), Enter (activate), Escape (dismiss), and arrow keys (for list navigation). Document every instance where keyboard focus becomes trapped, invisible, or skips important interactive elements.

Key areas of focus during keyboard testing include:

Login flows: Can users tab from username to password to submit without interruption? Is there a visible focus indicator on each field?
Modal dialogs: Does keyboard focus move into the dialog when it opens? Is focus trapped inside so users cannot tab behind it? Does Escape close the dialog and return focus to the triggering element?
Dropdown menus: Do all menu items receive keyboard focus? Can users expand submenus with arrow keys and collapse them with Escape?
Form controls: Can all radio buttons, checkboxes, and select menus be operated with arrow keys? Do custom styled controls maintain native keyboard behavior?
Carousels and sliders: Can users pause auto-rotating carousels and navigate between slides manually?
Video players: Can all player controls—play, pause, volume, captions, fullscreen—be reached and activated by keyboard?
Pagination: Can users navigate through search results or transaction lists using keyboard arrow keys?

Focus Order and Visual Focus Indicators

WCAG 2.2 Success Criterion 2.4.3 (Focus Order) requires that keyboard focus follow a logical sequence that preserves meaning and operability. For credit union websites, this is especially critical in multi-step forms where focus must progress through fields in the intended order. Use the tab key to traverse the entire page and verify that the focus order matches the visual layout and logical interaction sequence.

WCAG 2.2 Success Criterion 2.4.13 (Focus Appearance) was newly introduced in the 2.2 specification and requires that keyboard focus indicators have a minimum area (equivalent to the outline of a 2 CSS pixel thick perimeter) and a contrast ratio of at least 3:1 against the adjacent background. This is a significant departure from earlier versions, which only required a visible focus indicator without specifying minimum dimensions. Audit teams must now measure focus indicator thickness, area, and contrast using color contrast tools. Many credit union websites will need to update their CSS focus styles to meet this stricter requirement—a change that affects buttons, links, form inputs, and all interactive components.

Heading Structure and Semantic HTML Review

Auditors should perform a thorough review of heading hierarchy using the browser’s accessibility tree or a dedicated heading inspection tool. Headings must follow a logical descending order (h1 > h2 > h3, never skipping levels), provide descriptive labels that accurately reflect the content they introduce, and be used consistently across all page templates. The Firefox Accessibility Inspector provides an excellent tree view of the page’s heading structure, while the WAVE tool’s Structure tab highlights heading levels visually on the page.

Beyond headings, auditors should inspect the semantic structure of all page content. Proper use of landmark elements (<header>, <nav>, <main>, <aside>, <footer>), lists (<ul>, <ol>, <dl>), and data tables (<table> with <th> and scope attributes) is essential for assistive technology navigation. For credit union rate and fee disclosure pages—which frequently use visual tables created with <div> elements—semantic HTML review is particularly important.

Screen reader verification is the most critical manual testing component of an accessibility audit because it evaluates the actual user experience of people who are blind or have low vision. Unlike automated tools or code review, screen reader testing reveals how content and functionality are actually communicated through speech synthesis and braille output. For credit union websites, screen reader testing is non-negotiable given the sensitive nature of financial transactions and the trust required for members to manage their finances independently.

Configuring Screen Readers for Testing

Auditors should test with at least two different screen reader and browser combinations to account for variations in how assistive technologies interpret web content. The three most widely used screen readers in 2026 are:

NVDA (NonVisual Desktop Access) is a free, open-source screen reader for Windows that has become the industry standard for accessibility testing due to its wide adoption, frequent updates, and excellent support for modern web technologies. NVDA is the recommended primary testing tool. Test with NVDA using the Firefox browser, as this combination provides the most consistent and standards-compliant accessibility experience. Download NVDA from nvaccess.org and learn the basic keyboard commands: NVDA key (Insert or CapsLock) + Down Arrow to read continuously, Tab to move between interactive elements, H to navigate by heading, K to jump between links, and B to move between buttons.

VoiceOver is built into macOS and iOS and is the second most important screen reader for testing. VoiceOver is particularly relevant for credit union websites given that a significant percentage of members access digital banking on Apple devices. VoiceOver uses a unique interaction model called Direct Touch on iOS, where users touch the screen and hear the element description before double-tapping to activate. Test with VoiceOver using Safari, as Apple’s browser provides the best compatibility. Enable VoiceOver by pressing Command+F5 on macOS or navigating to Settings > Accessibility > VoiceOver on iOS.

JAWS (Job Access With Speech) from Freedom Scientific remains the most widely used screen reader in enterprise and government environments, despite its commercial cost. While JAWS usage in the consumer market has declined relative to NVDA, a comprehensive audit should include at least limited JAWS testing given its prevalence among older adults and in financial services environments. Test with JAWS using Chrome or Edge browsers.

For each critical user flow on the credit union website, auditors should perform these screen reader tests:

Page load announcement: Does the screen reader announce the page title immediately upon loading? Are important pre-load messages communicated through live regions?
Heading navigation: Can users navigate the page by headings using the H key? Is the heading hierarchy logical and descriptive?
Landmark navigation: Can users jump between page regions (navigation, main content, footer) using landmark navigation shortcuts?
Link context: When tabbing through links, is the purpose of each link clear from its text alone, without requiring surrounding context?
Form field announcements: When entering form fields, do screen readers announce the label, required state, input type, and any pre-populated values?
Error announcements: When form validation errors occur, are error messages dynamically announced through ARIA live regions?
Dynamic content updates: When content on the page changes without a full reload (e.g., loan calculator results, fund transfer confirmation), is the updated content announced to screen reader users?
Modal dialog management: When a dialog opens, is focus moved to the dialog and is its purpose announced? When it closes, is focus returned to the triggering element?
Status messages: Are success messages, loading states, and progress indicators communicated to screen readers?

Screen reader testing findings should be documented with detailed instructions for reproduction, including the screen reader and browser combination used, the exact key presses required to encounter the issue, the incorrect announcement verbatim as spoken by the screen reader, and the expected correct announcement. This level of detail is essential for developers who may not be familiar with screen reader behavior and need precise guidance for remediation.

Color Contrast and Visual Accessibility Testing: Tools and Methodologies

Color contrast failures are among the most common accessibility issues identified on credit union websites. WCAG 2.2 Success Criterion 1.4.3 (Contrast Minimum) requires that text and images of text have a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). Success Criterion 1.4.11 (Non-text Contrast) extends this requirement to user interface components and graphical objects, requiring a 3:1 contrast ratio for focus indicators, form input borders, icons, and chart elements.

Contrast Testing Tools

The WebAIM Color Contrast Checker is the most widely used free tool for evaluating text contrast ratios. Enter foreground and background color values (hex, RGB, or HSL) and the tool calculates the ratio and indicates whether it passes or fails WCAG AA and AAA requirements at various text sizes. However, this tool only evaluates solid color combinations—it cannot assess contrast in gradients, images of text, or complex backgrounds.

For evaluating real-world contrast on live web pages, the Color Contrast Analyzer browser extension (available for Chrome, Firefox, and Edge) allows auditors to click on any page element and see its computed color values, contrast ratio, and pass/fail status against WCAG criteria. This is particularly useful for credit union websites where CSS frameworks like Bootstrap or Tailwind may apply layered color values that are difficult to extract manually.

The Accessible Color Palette Generator from Deque Systems helps design teams pre-validate color palettes before implementation. By inputting brand colors and desired text sizes, the tool generates a matrix of compliant color combinations. Credit union brand guidelines should be reviewed against this tool to identify which official brand color combinations pass accessibility requirements—many credit union brand palettes need slight adjustments to meet contrast standards without sacrificing brand identity.

Testing Non-Text Contrast

Non-text contrast testing requires manual inspection of all user interface components. For each interactive element—buttons, form inputs, focus indicators, chart data points, and information graphics—verify that the visual information conveying the element’s state or purpose has at least a 3:1 contrast ratio against adjacent colors. Common credit union non-text contrast failures include:

Focus indicator rings that blend into the background color
Form input borders that are too light against white backgrounds
Dropdown arrow icons that lack sufficient contrast
Rate comparison chart bars that are indistinguishable from adjacent bars
Disabled buttons rendered in very light gray that cannot be distinguished from the background
Calendar date picker highlights on current selected dates

Color-Only Information Cues

WCAG Success Criterion 1.4.1 (Use of Color) prohibits using color alone to convey information. Auditors must review every instance where color communicates meaning and verify that an alternative identifier is provided. On credit union websites, common violations include:

Required form fields marked only with red asterisks (add “required” text label)
Transaction types in online banking distinguished only by color (add icon or text label)
Positive/negative financial indicators shown only in green/red (add directional arrows or text)
Map markers for branches and ATMs colored differently without text labels

Forms and Input Accessibility Testing for Digital Account Opening

Forms are the most accessibility-critical components on credit union websites, as they serve as the primary mechanism for membership applications, loan requests, fund transfers, and account management. A form that is inaccessible effectively excludes users with disabilities from accessing essential financial services—a violation of both regulatory requirements and ethical obligations.

Form Label Verification

Every form input must have a programmatically associated label. The most reliable method is using a <label> element with a for attribute that matches the input’s id. Auditors should verify that every input in every form on the website has such a label. Using the browser developer tools’ Accessibility panel, inspect each input element to confirm that the accessible name property contains the expected label text. Common failures include:

Relying on input hint text inside form fields as the only visible label, which fails WCAG since hint text disappears on focus and often lacks sufficient color contrast

ar on focus and often lack sufficient contrast

Adjacent text that looks like a label but is not programmatically associated
Icon-only buttons (like search magnifying glass) without accessible names
Dynamically added form fields rendered without labels
Date pickers with separate month/day/year fields without individual labels

Error Validation and Recovery

When form validation errors occur, the error message must be programmatically associated with the offending input and announced to screen reader users. WCAG Success Criterion 3.3.1 (Error Identification) requires that errors be described in text, while 3.3.2 (Error Suggestion) requires specific suggestions for correction where possible.

Auditors should test error handling for each of these scenarios on credit union membership and loan application forms:

Submitting an empty required field
Entering an invalid email format
Entering a Social Security number with incorrect digit count
Entering a date in an unexpected format
Entering an amount that exceeds the maximum allowed
Mismatched password confirmation fields
Invalid routing or account numbers for ACH funding

For each error scenario, verify that the error message is visually proximal to the input, is announced by screen readers (typically via aria-describedby or aria-errormessage), and provides specific guidance on the required correction (e.g., “Please enter a valid 9-digit routing number” rather than simply “Invalid entry”).

Credit union account opening and loan application forms frequently span multiple steps or pages. Auditors must verify that step indicators are accessible, form data is preserved when navigating between steps, focus management is correct when advancing and retreating through the workflow, and progress is communicated to assistive technologies through aria-valuenow on a progress bar or visible step count text.

With mobile devices accounting for over 60% of digital banking sessions according to J.D. Power’s 2025 U.S. Banking Mobile App Satisfaction Study, mobile accessibility testing is essential for credit union websites. WCAG 2.2 applies to web content regardless of device, and many success criteria have specific implications for mobile interfaces.

Touch Target Size and Spacing

WCAG 2.2 Success Criterion 2.5.8 (Target Size Minimum) requires that touch targets be at least 24 by 24 CSS pixels, while WCAG 2.5.5 (Target Size) at Level AAA recommends 44 by 44 CSS pixels. While AAA targets are not required for AA compliance, the 24×24 minimum (added in 2.2) is now mandatory. Auditors should measure the actual rendered size of all touch targets on mobile viewports, including buttons, links, form inputs, accordion headers, and icon controls. Special attention should be paid to tightly packed navigation links, social media icons, and the frequently-too-small “close” button on mobile overlays.

Touch targets that are smaller than 24×24 CSS pixels must have sufficient spacing around them (at least 24px in each dimension) to prevent accidental activation. Auditors should also test for adjacent targets that may be incorrectly triggered due to insufficient spacing—a common issue on credit union rate tables and transaction lists.

Gesture Testing

WCAG Success Criterion 2.5.1 (Pointer Gestures) requires that all functionality that can be operated by complex gestures (such as swipe, pinch, or multi-finger taps) also be operable through simple gestures or single-pointer activation. On credit union websites, test for:

Swipeable carousels that also provide arrow button navigation
Pull-to-refresh that can also be triggered by a visible refresh button
Drag-and-drop sorting that can also be accomplished with select-and-move controls
Pinch-to-zoom on documents and statements that also provides zoom buttons

Responsive Zoom and Reflow

WCAG Success Criterion 1.4.10 (Reflow) requires that content be presented without loss of information or functionality when viewed at 400% zoom on a 1280px wide viewport—effectively a 320px CSS viewport width. Auditors should load each critical page at 400% zoom in the browser’s responsive design mode and verify that:

Content is presented in a single-column layout without horizontal scrolling
All text remains readable without truncation or overlapping
All form inputs remain usable at the reduced width
Navigation menus convert to a collapsed/hamburger pattern without losing links
Tables and data grids are not truncated or broken on reflow

PDF and Document Accessibility Verification

Credit unions distribute a vast number of documents through their websites: account agreements, loan disclosures, fee schedules, privacy policies, monthly statements, and regulatory notices. These PDF documents must be accessible to members using assistive technologies. While a full PDF accessibility audit is a specialized skill, the following checks should be performed during a comprehensive audit.

PDF Tag Structure Verification

Accessible PDFs include a hidden tag tree that defines the document’s structure, reading order, and semantic roles—similar to the HTML DOM for web pages. Using Adobe Acrobat Pro’s Accessibility Checker or PAC (PDF Accessibility Checker) from the Swiss organization Zugang für alle, auditors should verify that:

The document has a defined tag tree (not an untagged scanned image)
Reading order in the tag tree matches visual reading order
Headings are tagged as heading elements with correct hierarchy (H1, H2, H3)
Tables include proper table headers and scope attributes
Lists are tagged as list elements with list items
Links are tagged with correct destinations and meaningful link text
Form fields in interactive PDFs have labels and tooltips

Document Language and Title

Every PDF document must specify its primary language in the document properties and have a descriptive title that is set in the document metadata (not just the filename). Auditors should verify that the title appears in the document properties dialog and that the language setting matches the document’s written language—a frequent issue for bilingual credit union documents.

Scanning vs. Native PDFs

Many credit union PDFs are scanned images of printed documents. These are fundamentally inaccessible because the text content is not machine-readable. Auditors should identify all scanned PDFs on the website and flag them for OCR (optical character recognition) processing and tag structure remediation. True accessible PDFs require either a source document that was authored with accessibility features (created in Word, InDesign, or similar software with proper heading styles, alt text on images, and table header specifications) or a scanned document that has undergone OCR cleanup and manual tag structure verification.

Video and Multimedia Accessibility: Captions, Transcripts, and Audio Descriptions

Credit union websites increasingly use video content for member education, product demonstrations, leadership messages, and community engagement videos. Each video must be accessible to users who are deaf or hard of hearing (through captions and transcripts) and users who are blind or have low vision (through audio descriptions).

Caption Verification

Auditors should review the accuracy and completeness of captions on every video published on the credit union website. Accurate captions are critical for compliance with WCAG Success Criterion 1.2.2 (Captions – Prerecorded) and 1.2.4 (Captions – Live). Caption verification should include:

Accuracy of spoken words (no misspellings or incorrect replacements)
Timing synchronization (captions appear and disappear in sync with spoken audio)
Speaker identification for videos with multiple speakers
Description of important non-speech audio (music, sound effects, phone ringing)
On-screen text inclusion that is not spoken aloud
Proper capitalization and punctuation for readability

WCAG Success Criterion 1.2.2 does not specify whether captions must be open (always visible) or closed (toggleable), but closed captions are strongly preferred as they allow users to choose whether captions are displayed. Verify that the video player’s caption toggle is keyboard accessible and persists across browser sessions.

Transcript Provision

Every video must have an associated descriptive transcript that includes all spoken dialogue and descriptions of important visual information. WCAG Success Criterion 1.2.3 (Audio Description or Media Alternative – Prerecorded) at Level A requires either audio descriptions or a full text transcript, while Level AA (1.2.5 Audio Description – Prerecorded) requires audio descriptions for video content. Providing both is the best practice. Transcripts should be available as HTML on the same page as the video or as a downloadable, accessible PDF.

Audio Description Testing

Audio descriptions provide narration of important visual content that is not conveyed through the main dialogue track. Auditors should verify that audio descriptions are available for all prerecorded video content and that they accurately describe actions, characters, scene changes, on-screen text, and other visually conveyed information without overlapping with the main audio track. For credit union videos, audio descriptions should narrate on-screen product demonstrations, chart data, and text overlays that appear during the video.

ARIA Implementation Auditing: Roles, States, and Properties Verification

Accessible Rich Internet Applications (ARIA) is a technical specification that supplements HTML to provide additional semantic information to assistive technologies. While ARIA can dramatically improve accessibility when used correctly, it can also create significant barriers when implemented improperly—a phenomenon described by the “First Rule of ARIA: Don’t use ARIA if you can use a native HTML element that already has the semantics built in.”

ARIA Audit Protocol

For each custom interactive component on the credit union website, auditors should verify:

Roles are correct: Each custom component uses an ARIA role that accurately describes its function (e.g., role="tab" for tab controls, role="dialog" for modal overlays, role="progressbar" for loading indicators)
States and properties are accurate: Interactive components communicate their current state through ARIA attributes (aria-expanded for collapsible sections, aria-pressed for toggle buttons, aria-selected for tab panels, aria-hidden for off-screen content)
Live regions are configured correctly: Dynamically updating content uses aria-live regions with appropriate politeness settings (aria-live="assertive" for time-sensitive updates like error messages, aria-live="polite" for non-urgent updates)
ARIA is not redundant: Native HTML elements like <button>, <nav>, and <main> do not have redundant ARIA roles applied
ARIA validation: No orphaned ARIA references—aria-labelledby and aria-describedby values must reference existing IDs

Testing with the Accessibility Tree

Every major browser’s developer tools include an Accessibility panel that exposes the computed accessibility tree for each element. This is the most reliable way to verify ARIA implementation because it shows exactly what information the browser exposes to assistive technologies. Using Chrome DevTools > Elements > Accessibility or Firefox DevTools > Accessibility Inspector, select each interactive element and verify that:

The accessible name is correct and meaningful
The role matches the intended function
All relevant states (expanded, selected, disabled, pressed) are accurately reported
Keyboard interactions are exposed through the correct keyboard event handlers

Building the Accessibility Audit Report: Findings, Severity Ratings, and Remediation Roadmaps

The audit report transforms raw findings into actionable guidance for the credit union’s leadership team, design team, and development team. A well-structured report ensures that accessibility issues are understood, prioritized, and addressed efficiently.

Report Structure

A comprehensive accessibility audit report should include the following sections:

Executive summary: A high-level overview of the audit scope, methodology, key findings, and overall WCAG conformance level for non-technical stakeholders including the credit union’s board and executive team
Scope and methodology: Detailed description of pages tested, tools used, testing dates, and the WCAG version and conformance level evaluated
Overall findings: Summary statistics including total issues found, issues by severity level, issues by WCAG principle, and issues by page template
Detailed findings: Each issue documented with WCAG success criterion reference, issue description, affected component, screen reader or tool output verbatim, expected behavior, severity rating, and remediation guidance with code examples
Remediation roadmap: Prioritized list of remediation tasks organized by sprint or implementation phase, with estimated effort and recommended owner
Compliance score: A quantitative assessment of current conformance with WCAG 2.2 AA
Appendices: Complete test logs, automated scan output files, and verification testing results

Severity Rating Framework

Issues should be rated on a four-tier severity scale:

Critical: Complete barrier to access for one or more user groups. Examples include keyboard traps, missing form labels on required fields, and content that triggers seizures. Remediation required before launch of any new feature.
Serious: Significant difficulty but not complete barrier. Examples include low contrast text, missing heading structure, and unlabeled interactive controls. Remediation required within one sprint cycle.
Moderate: Notable inconvenience or reduced efficiency. Examples include redundant ARIA attributes, suboptimal heading hierarchy, and inconsistent navigation patterns. Remediation recommended within two sprints.
Minor: Best practice improvements. Examples include slightly imperfect color contrast at larger text sizes, non-critical ARIA validation warnings, and semantic markup improvements. Remediation as time permits.

Prioritization Framework

Remediation priorities should balance severity, user impact, traffic to the affected page, and effort required. High-traffic pages like online banking login, membership application, and the homepage should receive priority remediation regardless of issue severity, as they affect the widest user base. Low-traffic informational pages may accept slightly longer remediation timelines for minor issues.

Continuous Accessibility Monitoring: Integrating Audits into Development Workflows

Accessibility is not a one-time audit milestone—it is an ongoing quality practice that must be integrated into the credit union’s digital governance, content management, and development workflows. A single accessibility audit provides a point-in-time snapshot that becomes outdated as soon as new content or features are deployed. Continuous monitoring ensures that accessibility remains a priority throughout the website lifecycle.

CI/CD Integration

Automated accessibility scanning should be integrated into the continuous integration and continuous deployment pipeline. Tools like axe-core can be configured as a test step in GitHub Actions, GitLab CI, or Jenkins pipelines to fail builds when new accessibility issues are introduced. Configure the CI scan to run on every pull request and block merges when critical or serious issues are detected. This approach, known as “accessibility shift left,” catches issues at the development stage when they are cheapest and fastest to fix.

Content Management System Governance

Credit union websites built on content management systems (CMS) like WordPress, Drupal, or Sitecore require content-level accessibility governance. Implement automated checks at the content authoring level to flag common issues before publication:

Require alt text on all uploaded images (enforced at upload time)
Flag heading levels that skip hierarchy
Validate link text against “click here” and “read more” patterns
Check table usage for proper header markup
Verify PDF uploads for basic accessibility properties

Regular Audit Cadence

Credit unions should establish a regular accessibility audit cadence:

Daily/Weekly: Automated CI/CD scans catch regressions from development changes
Monthly: Automated scanning of all public-facing pages for trend analysis
Quarterly: Manual keyboard and screen reader testing of critical user flows
Annual: Comprehensive third-party accessibility audit with full manual testing, user testing with people with disabilities, and updated VPAT documentation

Vendor and Third-Party Component Accessibility Assessment

Credit union websites typically integrate numerous third-party components: online banking platforms, chatbot solutions, loan origination systems, document e-signature tools, identity verification services, and analytics trackers. Each third-party component introduces potential accessibility barriers that the credit union is ultimately responsible for—the ADA and Section 508 hold the financial institution accountable for the accessibility of all digital properties, regardless of whether components are built in-house or procured from vendors.

VPAT Review Process

Every third-party vendor should provide a current VPAT (Voluntary Product Accessibility Template) documenting their product’s conformance with WCAG 2.2 AA. Auditors should review VPATs critically:

Verify the VPAT covers the specific version of the product being used
Identify any “Partially Supports” or “Does Not Support” entries
Ask vendors for remediation timelines for identified gaps
Request a demo of keyboard and screen reader accessibility of the specific integration
Include VPAT compliance as a contractual requirement in all vendor agreements

Integration Testing

When third-party components are embedded within the credit union’s website, the interaction between the host page and the third-party iframe or widget must be tested for accessibility. Verify that:

Keyboard focus enters and exits embedded components correctly
Screen readers can access content within iframes
Modal overlays from third-party tools do not trap focus
Custom branded components maintain contrast and touch target requirements
Authentication flows through third-party identity providers remain accessible

Conclusion: Making Accessibility Auditing a Core Credit Union Digital Practice

Accessibility auditing is not a compliance checkbox exercise—it is a fundamental practice for ensuring that credit union websites serve all members equitably. When conducted thoroughly and integrated into ongoing digital governance, accessibility audits identify barriers that affect not only users with disabilities but also members using mobile devices, older adults, users with temporary impairments, and anyone in suboptimal environmental conditions like bright sunlight or noisy environments.

For credit unions, the business case for accessibility auditing is compelling. Accessible websites rank higher in search engine results, have lower bounce rates, convert more visitors to members, reduce legal risk exposure, and demonstrate the cooperative values that differentiate credit unions from megabanks and fintech competitors. The approximately 14% of U.S. adults with disabilities represent a membership demographic that is currently underserved and deeply loyal to institutions that serve them well.

The audit methodology outlined in this guide—combining automated scanning with manual code review, keyboard testing, screen reader verification, contrast analysis, and comprehensive reporting—provides a rigorous framework for achieving and maintaining WCAG 2.2 AA compliance. By investing in this process, credit unions not only fulfill their legal obligations under the ADA but also advance their mission of financial inclusion and member-centric service.

Remember that accessibility is a journey, not a destination. The most successful credit union digital teams embed accessibility auditing into their weekly workflow, treat audit findings with the same priority as security vulnerabilities, and view continuous improvement as the measure of their commitment to accessible member experiences. Start with a comprehensive baseline audit, establish your continuous monitoring cadence, and build accessibility expertise within your team. Every accessibility issue you identify and fix brings your credit union closer to the goal of truly inclusive digital banking for all.

This article was brought to you by GrafWeb CUSO – Building the future of digital credit unions.

Credit Union Website Accessibility Audit: Complete WCAG 2.2 Testing Guide

The Credit Union Website Accessibility Audit: A Complete Technical Guide to WCAG 2.2 AA Testing, Screen Reader Verification, and Assistive Technology Validation for Digital Banking Platforms in 2026-2027