Beyond the Browser: Applying WCAG to Documents, Apps, and Software

By Shannon (Conformance Specialist & Front End Developer) and Rick (Lead Auditor & AT User), Accessiblü

Digital accessibility extends far beyond web browsers, yet many organizations struggle to apply WCAG principles to their PDFs, mobile applications, and desktop software. After years of testing and remediating non-web content across industries, we’ve developed proven strategies for implementing WCAG2ICT effectively. This guide shares our real-world experience in making all digital content accessible, not just websites.

The Critical Gap in Digital Accessibility Compliance

Rick: As a full-time JAWS user and lead auditor, I encounter this disconnect between web and non-web accessibility daily. I can navigate perfectly accessible websites, then encounter PDFs that my screen reader cannot interpret, mobile apps without keyboard support, desktop software that ignores assistive technology, and so forth. It defeats the entire purpose of digital accessibility.

Shannon: We recently worked with a university that had invested significantly in making their main website WCAG 2.2 Level AA compliant. They were proud of this achievement—rightfully so. But when we expanded our testing to their student portal, we discovered that course syllabi, assignment sheets, and reading materials posted as PDFs were completely inaccessible.

These documents lacked proper headings, had no reading order defined, and form fields for assignment submissions were unlabeled. The students could navigate to these resources but couldn’t actually use them. Essentially, the university was telling students with disabilities that y’all are welcome on our campus website, but the actual educational materials remain off-limits.

Rick: The impact extends beyond individual frustration. When testing a sports arena’s digital ecosystem for a major league team, we found fans interacting across multiple touchpoints: downloading PDF ticket guides, using the mobile app for concessions ordering, accessing seating charts, what have you. Each touchpoint either reinforces or undermines your accessibility commitment. If fans can buy tickets on an accessible website but can’t use the mobile app to order food at their seats, you’ve only solved part of the problem.

Understanding WCAG2ICT: The Framework for Non-Web Accessibility

Shannon: WCAG2ICT (Web Content Accessibility Guidelines applied to Information and Communication Technology) provides the authoritative framework for applying web accessibility principles to non-web content. Published as a W3C Group Note and updated in August 2025, it translates WCAG 2.0, 2.1, and 2.2 success criteria for documents and software applications.

The framework operates through systematic word substitution. Where WCAG references “web page,” WCAG2ICT substitutes “non-web document or software.” Where WCAG mentions “set of web pages,” it becomes “set of documents” or “set of software programs.” This translation enables consistent application of accessibility principles across all digital platforms.

Rick: WCAG2ICT eliminates the guesswork that I’ve seen plague so many organizations. When testing desktop applications, I know exactly how keyboard navigation requirements apply. When evaluating PDFs, the success criteria for reading order, language settings, form labels, and so forth are clearly defined. It provides the consistency that both developers and users need. Without this framework, every organization would be interpreting WCAG differently for non-web content, creating chaos for users who rely on consistent accessibility implementation.

Document Accessibility: Technical Requirements and Implementation

Structural Integrity and Semantic Markup

Shannon: Proper document structure forms the foundation of PDF accessibility. Real headings must replace formatted text, proper lists must replace manual numbering, and table headers must include appropriate scope definitions. These aren’t aesthetic choices—they’re functional requirements for assistive technology compatibility.

We evaluated a 300-page curriculum guide for a midwestern state’s department of education. Every heading was manually formatted with bold text and an increased font size. Visually, it appeared perfectly organized with a clear hierarchy. Programmatically, it was 300 pages of undifferentiated content.

Teachers using screen readers couldn’t navigate between sections, couldn’t understand the document structure, couldn’t efficiently find specific grade-level standards. The remediation required converting every fake heading to proper semantic markup—a process that took weeks but could have been avoided with correct initial authoring.

Reading Order and Navigation Flow

Rick: Document reading order often differs drastically from visual presentation. When reading order isn’t properly defined, my screen reader might announce a sidebar in the middle of a paragraph, footnotes before the main text, captions separated from their images, what have you. The content becomes incomprehensible.

I recently tested a school district’s policy manual where the two-column layout hadn’t been properly tagged. JAWS read across both columns instead of down each column, creating sentences like “Students must follow all from 8:00 AM to 3:00 PM school rules and regulations including proper during regular school hours.” The actual text read “Students must follow all school rules and regulations including proper [column break] from 8:00 AM to 3:00 PM during regular school hours.” This kind of error makes documents unusable for screen reader users, and so forth.

Language Settings and Metadata

Shannon: Every document requires proper language definition in its metadata, not merely mentioned in the text. This enables screen readers to apply correct pronunciation rules. We discovered this issue when working with a school district serving a large Spanish-speaking population. Their Spanish documents were tagged as English in the metadata, causing screen readers to mangle every word. Rick demonstrated how “biblioteca” was being pronounced as “bib-lee-oh-TEE-cah” instead of the proper Spanish pronunciation. The fix required only a metadata adjustment, but the impact on usability was transformative.

Interactive Elements and Form Accessibility

Rick: I regularly encounter forms with fields labeled ‘Text1,’ ‘Text2,’ and so forth. JAWS announces ‘Text one, edit’ for what might be a name field, address field, or anything else. When testing scholarship application forms for that university client, we found students with disabilities couldn’t complete applications independently because they couldn’t determine what information belonged in each field. Proper labeling isn’t optional—it’s essential for form completion.

Mobile App Accessibility: Platform-Specific Considerations

Native Components and Platform APIs

Shannon: Mobile digital accessibility compliance depends heavily on proper use of platform-specific accessibility APIs. Native components inherently support VoiceOver, TalkBack, and other assistive technologies. Custom components require significant additional development to achieve equivalent functionality.

When we tested that sports team’s mobile app, the development team had built a beautiful custom interface for selecting seats and ordering concessions. Unfortunately, they’d bypassed the native iOS and Android components entirely. The result? VoiceOver users couldn’t select seats, couldn’t add items to their cart, couldn’t complete purchases. The visual experience was stunning, but the accessibility was non-existent.

Rick: When developers use native iOS or Android components, the accessibility generally works. When they build custom UI frameworks, assistive technology support becomes hit-or-miss. I’ve tested applications that were completely invisible to VoiceOver because they rendered everything to a canvas element, bypassing platform accessibility APIs entirely, what have you. The sports app required a complete rebuild of their custom components to expose proper roles, states, and properties to assistive technology—months of work that could have been avoided.

Keyboard Navigation and Alternative Input Methods

Shannon: Mobile keyboard support remains critically important despite touch-first interfaces. Users rely on Bluetooth keyboards, switch controls, and keyboard-like assistive technologies for navigation and input. Every interactive element must be reachable and operable without touch interaction.

Rick: I test every app with a keyboard as part of my standard process. Can I reach all interactive elements? Does the focus move logically? Can I activate all the controls? The arena’s app completely broke under keyboard navigation—focus disappeared after selecting a menu item, navigation became impossible in the seating chart, and the app actually crashed when trying to submit an order using the Enter key. Many developers don’t realize that keyboard support on mobile devices is essential for users with motor disabilities, users of switch controls, and so forth.

Focus Management and Visual Indicators

Shannon: Focus indicators serve essential navigation functions, particularly for users with low vision or motor disabilities. While designers sometimes resist visible focus indicators for aesthetic reasons, they’re non-negotiable for accessibility. We work with design teams to create custom focus indicators that align with brand guidelines while maintaining clear visibility. For the sports team app, we implemented focus indicators using their team colors—a thick border in team purple with a white outline for contrast. The designers were happy, and users could actually see where they were in the interface.

Target Size and Touch Accessibility

Rick: WCAG 2.2’s target size requirements (24×24 CSS pixels minimum) reflect real-world usability needs. We demonstrated to the arena app developers how their tiny “Add to Cart” buttons caused abandonment. Fans couldn’t reliably tap them while walking to their seats, seniors struggled with the precise touches required, users with tremors couldn’t hit the targets, what have you. Increasing target sizes improved both accessibility and sales—accessibility as good business, not just compliance.

Desktop Application Accessibility: Enterprise Considerations

Platform Accessibility APIs and Screen Reader Compatibility

Shannon: Desktop desktop application accessibility requires proper integration with platform accessibility APIs: Windows UI Automation, macOS Accessibility APIs, or Linux’s ATK/AT-SPI. These APIs enable communication between applications and assistive technologies.

We tested a gradebook application used by several school districts where the developers had created their own rendering engine. The application looked professional and functioned well visually, but it completely bypassed Windows UI Automation. Teachers and administrators using screen readers couldn’t access student data, couldn’t input grades, couldn’t generate reports. The vendor initially claimed it was “accessible” because it had keyboard shortcuts, not understanding that keyboard access without screen reader support isn’t accessibility.

Rick: I regularly test enterprise applications that bypass platform APIs entirely. They might look professional, but JAWS sees nothing—no controls, no text, no structure. It’s equivalent to displaying everything as an image. Users dependent on screen readers, magnification software, voice control, and so forth cannot use these applications at all. That gradebook application required a complete architectural change to expose information through proper accessibility APIs.

Custom Controls and Interaction Patterns

Shannon: When building custom controls, developers must essentially recreate all the accessibility features that native controls provide automatically. That custom dropdown needs to announce its expanded state, support arrow key navigation, and communicate selected values. The custom data grid needs to expose row and column headers, support table navigation commands, and announce cell contents. It’s significant additional work that teams often underestimate. We spent three months helping the gradebook vendor properly implement accessibility for their custom grade entry grid—work that wouldn’t have been necessary with standard controls.

Status Messages and Live Regions

Rick: I tested a document management system for the department of education that provided no auditory feedback for upload success or failure. Sighted users saw subtle color changes and toast notifications; I heard nothing. Teachers uploading lesson plans didn’t know if their materials had been submitted successfully, administrators couldn’t tell when reports had finished generating, and so forth. After implementing proper status announcements through live regions, the application became usable for screen reader users while actually improving the experience for all users through clearer feedback.

Closed Functionality: Embedded Systems and Kiosks

Shannon: When assistive technology cannot be connected—such as with kiosks, ATMs, or embedded systems—applications must provide built-in accessibility features. We consulted with a stadium that was installing new ticketing kiosks. Since visitors couldn’t connect their own assistive technology, we helped implement built-in screen reading capabilities, high-contrast display options, and tactile navigation markers. The kiosks now provide audio output through both speakers and headphone jacks, support multiple languages, and include adjustable speech rates.

Rick: These closed systems require creative solutions. The stadium kiosks needed to work for everyone—including people who are blind, have low vision, are deaf, have motor disabilities, what have you. We implemented a multi-modal interface: touchscreen with large targets, physical buttons with braille labels, audio instructions, visual indicators, and timeout extensions. It required more initial investment but resulted in kiosks that all fans could use independently.

Implementation Strategy and Best Practices

Comprehensive Content Inventory

Shannon: Begin by cataloging all non-web content. When we started with the university, they thought they had “a few PDFs” to review. The actual inventory revealed over 10,000 documents across departments, plus three mobile apps, five desktop applications, and dozens of interactive kiosks. You can’t fix what you don’t know exists. We helped them build a comprehensive inventory system that tracked document ownership, usage frequency, and accessibility status.

Risk-Based Prioritization

Rick: Focus remediation efforts on high-impact, frequently-used content. That syllabus template used by every professor takes precedence over archived newsletters. Student-facing mobile apps require immediate attention; internal administrative tools might follow in subsequent phases. For the school districts, we prioritized IEP forms and parent communication documents—materials that absolutely must be accessible for legal and ethical reasons. Prioritize based on actual user impact, legal risk, business value, what have you.

Assistive Technology Testing Protocols

Shannon: While automated testing identifies many issues, comprehensive accessibility validation requires testing with actual assistive technology. We maintain testing environments with JAWS, NVDA, VoiceOver, TalkBack, Dragon, and other assistive technologies because each reveals different issues. Automated tools might catch missing alt text, but they won’t catch when your reading order turns a coherent paragraph into word salad. They’ll flag color contrast issues but won’t tell you if error messages are actually announced to screen reader users.

Documentation and Governance

Rick: Document all accessibility decisions, particularly for edge cases. When we determined that the university’s individual course PDFs weren’t a “set” for WCAG purposes, we documented the rationale. When the arena app required alternative approaches for certain interactions, we recorded those decisions. This documentation supports both ongoing maintenance and potential audits, and so forth. It also helps new team members understand past decisions without rehashing every discussion.

Process Integration

Shannon: The most successful organizations we work with treat accessibility like security—built into every stage rather than added afterward. The department of education now requires accessibility training for all content creators. Document authors learn proper structuring techniques before creating their first PDF. Developers understand platform accessibility APIs before writing code. Designers consider focus indicators and target sizes from initial mockups. This proactive approach costs far less than reactive remediation.

Measuring Success and Continuous Improvement

Establishing Metrics

Rick: Track both compliance metrics and user experience indicators. The university now monitors the percentage of documents meeting WCAG2ICT requirements, but they also track support tickets related to accessibility, user satisfaction scores from students with disabilities, time to complete tasks using assistive technology, what have you. Combining quantitative compliance data with qualitative user feedback provides a complete picture.

User Feedback Integration

Shannon: The organizations that excel at non-web accessibility actively involve users with disabilities in testing and feedback. The sports team regularly invites fans with disabilities to test new features before release. The school districts include teachers and parents who use assistive technology in their review processes. When you include actual users, y’all discover issues that technical testing might miss—like the stadium app feature that technically met WCAG but required users to navigate through seventeen screens to order a hot dog.

Ongoing Monitoring and Maintenance

Rick: Digital accessibility requires continuous attention. Every app update can introduce new barriers. Every new document type needs accessibility consideration. Platform updates can break existing accessibility features, and so forth. We help clients establish regular testing cycles, typically quarterly for critical applications and annually for stable content. The university now tests all new course materials before each semester, the arena tests their app before each season, and the school districts review documents before each academic year.

The Business Case for Comprehensive Accessibility

Shannon: Organizations implementing WCAG2ICT across all digital content report multiple benefits beyond compliance. The university saw support tickets decrease by 40% after making course materials accessible—benefiting all students, not just those with disabilities. The sports team increased merchandise sales through their accessible app. The school districts reduced paper costs by making digital documents usable for everyone.

Rick: Companies that truly commit to digital accessibility compliance across all platforms don’t just avoid lawsuits—they build better products. Accessible design principles improve usability for everyone. Clear document structure helps all readers. Proper form labels reduce errors for every user. Adequate target sizes benefit seniors, people using devices one-handed, anyone in a moving vehicle, what have you. These accessibility features become usability enhancements that improve the experience for your entire user base.

Conclusion: Accessibility Without Boundaries

Shannon: WCAG2ICT provides the framework for extending accessibility beyond web browsers to encompass all digital content. Through systematic application of these principles, organizations can create truly inclusive digital experiences that work for all users, regardless of ability or the technology they use. After years of testing and remediation across universities, school districts, sports venues, and government agencies, we’ve seen that comprehensive accessibility is achievable. It requires understanding WCAG2ICT, committing to proper implementation, and maintaining focus on user needs.

Rick: Every PDF, every app, every piece of software represents a choice. You can either include or exclude users with disabilities. WCAG2ICT gives you the roadmap for inclusion. My experience, both professional and personal, confirms that following this roadmap leads to better products, satisfied users, and genuine digital inclusion. When that university student can read their course materials, when that sports fan can order concessions from their seat, when that teacher can access the gradebook, what have you—that’s when digital accessibility truly succeeds.

At Accessiblü, we specialize in helping organizations implement WCAG2ICT across their entire digital ecosystem. Our managed accessibility operations approach provides continuous testing, identification, and remediation support for websites, documents, applications, and software. We don’t just identify problems—we work alongside your teams to solve them in real-time.

Shannon, based in Norman, Oklahoma, leads conformance testing and front-end development at Accessiblü, bringing deep technical expertise to complex accessibility challenges. Rick, our Bryan, Texas-based lead auditor, brings over 50 years of lived experience as a visually impaired assistive technology user to every assessment. Together, they’ve helped dozens of organizations achieve comprehensive digital accessibility across all platforms.