Although our accessibility audit process remains the same for any digital asset, audits for software aren’t the same as audits for websites. Desktop applications control their own interface directly – they draw their own buttons, menus, and text fields using the operating system’s tools. Websites, on the other hand, send HTML code to a browser that interprets and displays it. This fundamental difference affects how we evaluate and which accessibility issues we encounter.
When applying the Web Content Accessibility Guidelines (WCAG) to software, we need to interpret web-specific terms and concepts for a non-web context. For example, “page” might mean a window or dialog box, and “link” might translate to any clickable control. Some success criteria rarely apply to software, while others need special consideration. Understanding these differences ensures your desktop software audit accurately evaluates accessibility in a way that makes sense for standalone applications.
Table of Contents
What Is Software?
Software is any application, script, or program that runs on a device. Software can be used for device operations or task execution.
Think of Microsoft Word, Adobe Photoshop, or your accounting software – these are all examples of software we audit.
For accessibility auditing purposes, software includes any program that has a user interface and doesn’t depend on a separate viewer to present its content. Programs without any user interface, like background drivers are not audited. If there’s nothing for a user to see or interact with, there’s no content to make accessible.
Software includes:
- Desktop applications you install on your computer
- Standalone programs that run without a browser
- Software components of hardware devices (like the interface on a kiosk)
- Platform software like operating systems
- Mobile apps that function independently
Why Software Audits are Different from Website Audits
Here’s the key distinction: websites need a browser to work. The website provides the content, and the browser displays it. They’re two separate things working together. Software doesn’t work this way – it’s self-contained. The program you’re using is both the content and the mechanism for displaying that content.
Think of it like the difference between a DVD movie and a streaming service. With a DVD, you need a DVD player (like a browser) to watch the movie (like web content). But software is more like having a projector with the movie built right in – it’s all one integrated system.
This difference matters because WCAG was written with websites in mind, assuming there would always be that separate browser or viewer involved. When we audit software, we have to account for this fundamental difference in how the technology works.
Another major difference is how we define what to audit. With websites, we can easily identify individual pages – each URL is typically one page. But you can’t slice up software the same way. When we audit Microsoft Excel, we’re auditing the entire program as one unit, not individual spreadsheets or menu screens. The whole software program becomes our unit of evaluation.
The way software communicates with assistive technologies like screen readers is also different. Websites use HTML code that browsers and assistive technologies know how to interpret. Software uses something called platform accessibility services – these are built-in features of Windows, Mac, or other operating systems that help software communicate with assistive technologies. It’s a completely different technical approach to achieving the same objective.
How WCAG Applies Differently to Software
While WCAG principles remain relevant for software, applying the success criteria requires interpretation and adaptation. The four principles – Perceivable, Operable, Understandable, and Robust – still provide the foundation, but specific criteria need translation.
Web-specific terms need replacement when applied to software. Where WCAG says “web page,” we interpret this as “software” or “software program.” Where it refers to “a set of web pages,” we interpret this as “a set of software programs” – though sets of software that meet this definition appear to be extremely rare in practice.
Some success criteria that seem straightforward for web content become more complex for software. Take Success Criterion 2.4.1 Bypass Blocks, which requires a mechanism to bypass blocks of content repeated on multiple web pages. For software, this would only apply to content repeated across multiple software programs in a set. Since sets of software programs are extremely rare, this criterion often doesn’t apply. However, being able to bypass blocks of content repeated within software is still considered best practice.
Success Criterion 1.4.10 Reflow presents another interesting case. Web content can typically reflow when zoomed or when viewport dimensions change. But software often has more frequent cases where two-dimensional layout is essential for usage or meaning. Complex user interfaces with toolbars that need to remain visible while manipulating content are common in software but less common on websites.
Programmatic relationships work differently too. In software, programmatic determinability is best achieved through the use of accessibility services provided by platform software to enable interoperability between software and assistive technologies. This is quite different from the DOM-based approach used for web content.
While there is an unevenness in applying some WCAG success criteria to non-web assets, we still apply the WCAG principles of Perceivable, Operable, Understandable, and Robust (POUR) generally. For success criteria that are non-applicable, the practical takeaway is that the asset (software in this case), meets or “passes” and is deemed conformant for those criteria.
Step 1: Define Your Technical Standards
Before auditing any software, you must establish which technical standard you’ll use for evaluation. In most cases, this will be one of three versions of the Web Content Accessibility Guidelines:
- WCAG 2.0 AA
- WCAG 2.1 AA
- WCAG 2.2 AA
Although different digital assets may have different interfaces and functionality compared to websites, WCAG principles and success criteria still provide the foundation for evaluation. While not every success criterion may apply directly, the core principles of perceivable, operable, understandable and robust (POUR) remain relevant across all digital formats.
Step 2: Establish Your Test Environments
Define the environments where you’ll conduct the audit. This includes:
- Operating systems (Windows, macOS, iOS, Android)
- Devices (desktop/laptop, smartphone, tablet)
- Assistive technologies (screen readers like NVDA, JAWS, VoiceOver, TalkBack)
Platform software may provide device independent input services to applications that enable operation via a keyboard interface. When software supports such a device-independent service of the platform, and the software functionality is made fully operable through the service, then keyboard-related success criteria would be satisfied.
Step 3: Determine Your Audit Scope
For software, scope typically includes the primary screens, user flows, and unique functionality. You’ll want to ensure all screens that receive the most use or contain critical functionality are included in the audit. Since the unit of evaluation is the whole software program, you need to identify representative samples of functionality that cover the main user tasks.
Step 4: Conduct the Evaluation
A comprehensive software audit employs multiple methodologies:
Screen Reader Testing
Test with screen readers to ensure all functionality and content is accessible to users who are blind or have low vision. For software, this means verifying the application properly uses accessibility services provided by platform software.
Keyboard Testing
Ensure all functionality is operable through a keyboard interface. Note that this doesn’t imply software always needs to directly support a keyboard or provide a virtual keyboard – it means functionality should be accessible through the keyboard interface provided by the platform.
Visual Inspection
Review visual elements for sufficient color contrast, appropriate text sizing, clear focus indicators, and proper use of color.
Code Inspection
Examine how the software implements accessibility features. Standard user interface components on most accessibility-supported platforms already meet many success criteria when used according to specification. Custom components need extra attention.
Step 5: Compile Your Audit Report
After identifying all accessibility issues, compile them into a comprehensive report including:
- Issue description
- Location within the software
- Applicable WCAG success criterion
- Testing environment where issue was found
- Related code (if applicable)
- Screenshots or screen recordings
- Recommendations for fixing the issue
Special Considerations
Software with closed functionality – where users can’t attach, install, or use assistive technology – requires special consideration. Examples include kiosks, ATMs, or medical devices. These may need built-in accessibility features that function as assistive technology.
Remember that for software, the application of some WCAG 2 success criteria would be different for content embedded in software versus content in a document viewed through a separate user agent. The software itself provides the user agent function, which changes how certain criteria apply.
An accessibility audit remains necessary to conclusively identify all accessibility issues in your software. This thorough manual evaluation ensures your software provides equal access to users with disabilities while properly accounting for the unique ways WCAG applies to non-web ICT.
Are you looking for a provider to audit your software?
We’re happy to help. Send us a message below or contact us and we’ll be right with you.
