How to Build Accessible Software?

Shilpa Prabhudesai

Today’s world is digital-first, and software is its gateway to information, services, and opportunities. However, not all people can access software, especially millions of differently-abled people. The reason is that software is not designed for them with accessibility in mind.

It is very important to consider accessibility when designing software to ensure inclusivity so that every person can access it. Presently, accessibility is a moral responsibility and a business advantage.

This article delves into software accessibility and explores how to build accessible software, covering its principles, best practices, tools and technologies, and standards.

What is Software Accessibility?

It is the ability of software to allow people with diverse abilities, including those with special visual, cognitive, neurological, and motor needs, to use it effectively.

Accessible software not only helps differently-abled individuals but also benefits people in temporary or situational contexts, such as a noisy room, a broken arm, or poor lighting.

It is the concept of designing software products, services, and environments used by as many people as possible, bringing in inclusivity. It eliminates the barriers and provides equal access, enabling everyone to independently interact with, understand, and benefit from a system, whether it’s a physical space like a building or a digital entity like a website.

A good accessible software benefits everyone with a more inclusive and user-friendly experience, regardless of users’ abilities or circumstances.

Why does Software Accessibility Matter?

Accessibility is essential when building software as it allows users of all abilities to access it with a practical user experience. The importance of accessibility is summarized below:

• Inclusivity & Equal Opportunity: The main goal of accessible software is to ensure no one is excluded from using a product or a service because of their physical, cognitive, or sensory limitations.
• Improved Usability: Products and services are designed to be easy to use and understand by people with a wide range of abilities, including those using assistive technologies.
• Compliance: Digital accessibility is enforced by laws like the Americans with Disabilities Act (ADA) and standards such as Section 508 in the U.S. and EN 301 549 in the EU. Read more: How to Build an ADA-compliant App.
• Broader Market Reach: Businesses attract a wider audience, including people with disabilities, situational impairments (e.g., watching videos in a noisy room), and temporary limitations (e.g., fractured arm). This enhances the software’s business value.
• Innovation and Better Design: Accessible software encourages diverse perspectives, creating more robust products with fresh ideas and better design.
• Ethical Responsibility: It is imperative to ensure that the product or service is available to everyone and does not create barriers for any specific section.
• Enhanced Brand Reputation: Accessible software reiterates the commitment to customers and users, encouraging positive brand recognition and enhancing customer loyalty.

Key Elements of Accessibility

The following are the key elements that should be considered while designing an accessible software:

• Design with Accessibility in Mind: Consider accessibility parameters in the initial design phase, paying attention to color contrast, font sizes, keyboard navigation, and other aspects affecting users with special needs.
• Semantic HTML: Using semantic HTML markup ensures proper structure and navigation. It helps screen readers and other assistive technologies interpret content correctly.
• Keyboard Accessibility: The entire functionality should be operable via the keyboard alone, as users with motor disabilities may rely on keyboard navigation. Hence, all interactive elements should be accessible through the keyboard.
• Alternative Text and Captioning/Transcript for Media: All images should have a descriptive alternative text to aid users who are visually impaired and rely on screen readers to understand content. Captions should be included for audio and video content, and transcripts should be provided for podcasts and other non-text content. This helps users who are not able to hear access the information.
• Testing and Feedback: Regularly test the platform with users of diverse accessibility needs to gather feedback on accessibility issues and address them.

Principles of Accessible Software Design

Developers should follow these design principles, often abbreviated as POUR: Perceivability, Operability, Understandability, and Robustness, when designing accessible software.

1. Perceivability

The following considerations are to be given for a design to be perceivable:

• Present information differently so that content is perceivable by users with diverse sensory abilities. For example, provide text alternatives for non-text elements (e.g., alt text for images).
• Make content adaptable for users, such as resizing text or using sufficient color contrast (minimum 4.5:1 ratio for body text).
• Offer captions and transcripts for audio and video content.
• Support multiple sensory modalities (sound, visuals, haptics).

2. Operability

Consider the following suggestion for a software to be operable:

• Provide full keyboard navigation for all interactive elements.
• Allow enough time for users to read and use content. Avoid time-dependent tasks where possible, or provide adjustable time limits.
• Design touch targets that are large enough for people with motor impairments.
• Prevent motion-triggered actions or enable diverse input methods for users, such as speech recognition software or adaptive switches.

3. Understandability

Software should be understandable for it to be accessible. Consider the following:

• Make content readable and understandable by using plain language and avoiding jargon.
• Ensure predictable and consistent navigation and UI patterns.
• Provide input assistance, such as auto-suggestions and error prevention.
• Label form fields and provide instructions for their handling, wherever required.
• Provide error prevention and handling to avoid and correct mistakes.

4. Robustness

Accessible software is identified by its robustness. Consider the following for robustness:

• Content should be compatible with current and future user tools, including screen readers, voice input software, and other assistive technologies.
• Use web standards to ensure content works across various browsers, devices, and platforms without depending on proprietary technologies.
• Keep code updated to remain compatible with evolving technologies.

Software Accessibility Standards and Guidelines

Developers should follow globally recognized accessibility standards and guidelines for building effective accessible software. These standards are explained here.

WCAG (Web Content Accessibility Guidelines)

WCAG is an international set of technical guidelines for making web content, apps, and other digital products accessible to differently-abled people. The standard has been developed by the World Wide Web Consortium’s (W3C) Web Accessibility Initiative (WAI).

Success criteria for WCAG are grouped into three levels (A, AA, and AAA), with Level AA being a common target for many organizations. WCAG 2.1 and the newer WCAG 2.2 define success criteria organized under four accessibility principles:

• Perceivable: Information and user interface components must be presented in ways users can perceive.
• Operable: User interface components and navigation must be operable by all users through various input methods.
• Understandable: Content and controls for the operating user interface should be transparent, understandable, and predictable.
• Robust: The software should be compatible with assistive technologies and robust enough that it can be interpreted reliably by a wide variety of user agents.

Americans with Disabilities Act (ADA) Accessibility Standards

The ADA standard applies to new construction, alterations, and additions to certain facilities. It covers public accommodations, commercial facilities, and state and local government facilities. The ADA is based on minimum guidelines from the U.S. Access Board and issued by the U.S. Department of Justice (for most facilities) and the Department of Transportation (for public transportation facilities).

Platform-Specific Guidelines

These are the specific guidelines for mobile apps, specifically Android and iOS. Platform-specific guidelines mainly include:

• Apple’s Human Interface Guidelines for iOS.
• Google’s Material Design Accessibility for Android.
• Microsoft’s Accessibility Development Guidelines for Windows.

Other Standards

Some of the other accessibility standards available are:

• Integrated Accessibility Standards Regulation (IASR): This is a Canadian regulation setting standards in areas like information and communications, transportation, employment, public spaces, and customer service.
• Banking Sector Guidelines: These are the specific guidelines that address accessibility requirements within the banking sector, focusing on physical access and design.

Accessibility in Software Development: Best Practices

Best practices in the Software Development Lifecycle (SDLC) include precise requirements and planning, effective communication, DevOps and CI/CD integration, automated testing, robust security measures, version control, code reviews, continuous learning, documentation, and focus on developer experience to ensure high-quality, secure, and efficiently delivered software.

Here are the best practices for each SDLC phase:

1. Planning and Requirements

• Start with well-defined accessibility with other requirements and thorough planning to avoid misinterpretations.
• Involve accessibility early in the cycle; don’t treat it as an afterthought.
• Engage with diverse users to shape requirements.
• Adopt agile practices to promote flexibility, collaboration, and iterative development, which helps adapt to changing needs.

2. Design

• Create accessible wireframes and prototypes to implement software design.
• Use color responsibly; do not rely on color alone to convey information.
• Ensure scalable typography with reflow support.
• Incorporate accessibility into design systems and pattern libraries.

3. Development

• Use semantic HTML and other roles appropriately.
• Ensure logical heading hierarchy and document structure.
• Test for keyboard-only navigation at every stage.
• Validate forms with accessible error messages and clear labels.
• Optimize developer workflows and enhance developer experience to increase productivity and focus on building.
• Use version control systems (like Git) effectively for safe collaboration and a reliable project history.
• Implement standardized code review processes to catch defects early, ensure code quality, and facilitate knowledge sharing.
• Employ Continuous Integration and Continuous Deployment (CI/CD) to automate the building, testing, and deployment of software.

4. Testing

• Perform automated accessibility checks with tools like testRigor, Axe, Lighthouse, or WAVE.
• Conduct manual testing for nuances automation misses.
• Test with assistive technologies, such as screen readers (NVDA, JAWS, VoiceOver), magnifiers, and speech recognition.
• Run usability studies with participants with special needs.
• Utilize automated testing to run predefined test sets, improve code reliability, and ensure consistent quality.

5. Deployment and Maintenance

• Maintain continuous accessibility testing in CI/CD pipelines.
• Provide training and documentation for ongoing accessibility practices.
• Gather feedback from users regularly and act on it.
• Encourage a culture of continuous learning and improvement to keep up with evolving technologies, WCAG, legal standards, and maintain technical skills.
• Use data and metrics to guide decisions, refine processes, and drive improvements in code quality and delivery.
• Deploy changes in small, incremental batches to reduce the risk associated with new features and ensure stable releases.

Tools and Technologies Used for Accessible Software

The following table summarizes the tools and technologies used for different purposes in accessible software development and testing:

Accessibility in Different Contexts

Ensuring accessibility differs between applications. Here, we present general guidelines for common types of applications.

Web Applications

• Consider accessibility solutions from the beginning of the development process.
• Follow semantic HTML and WCAG strictly.
• Ensure responsive design works with zoom and screen magnification.
• Avoid flashing animations that can trigger seizures.
• Use automated tools like testRigor to find common issues, supplementing it with manual testing.

Mobile Applications

• Respect system-level accessibility settings, including text size, contrast, and dark mode.
• Use platform accessibility APIs, such as UIAccessibility for iOS and TalkBack for Android, and tools like Google Accessibility Scanner (Android) and Apple Developer Accessibility (iOS) to identify and fix accessibility issues.
• Design for voice input and gesture navigation.
• Follows WCAG standards in the development process.
• Test the app with assistive technologies such as screen readers, voice commands, and other tools to ensure it works correctly.

Desktop Software

• Use built-in OS features like Windows keyboard shortcuts, which allow remapping.
• Use specific developer tools and frameworks to build accessible software.
• Support screen readers like Narrator (Windows) or VoiceOver (macOS).
• Ensure applications adapt well to high-contrast modes.
• Use accessibility testing tools like Microsoft’s Accessibility Insights to help developers identify and fix accessibility issues in Windows applications before release.

Common Accessibility Pitfalls to Avoid

Here are some of the drawbacks of accessible software:

• Insufficient Color Contrast: Low or insufficient contrast between text and background makes content unreadable for users with visual impairments or color blindness. Choose high-contrast colors for text, buttons, and backgrounds.
• Poor Keyboard Accessibility: Users who cannot use a mouse need to navigate with a keyboard. All interactive elements in accessible software should be keyboard accessible, and focus indicators should be visible.
• Non-Descriptive Links: Links like “Click Here” don’t provide context for screen reader users. Use descriptive links so users know where the link will take them.
• Missing or Poor Alt Text: Visually impaired users rely on alternate text to understand images. Provide descriptive alt text for images or use an empty alt attribute (alt=””) for decorative images.
• Using Color to Convey Information: Using colors to convey errors or other vital information excludes users with color vision deficiencies. Instead, use text, patterns, or other cues to communicate meaning.
• Non-Semantic HTML: Using <div> or <span> for interactive elements like buttons or navigation instead of semantic HTML elements like <button> or <nav>.
• Inaccessible Forms: Unlabeled form fields, improper tab order, and uncommunicated error messages make forms difficult for many users. Associate <label> tags with their corresponding input fields.

Future of Accessible Software

Emerging technologies like artificial intelligence (AI), voice interfaces, and AR/VR bring new challenges and opportunities. Accessibility must evolve to ensure inclusive use of these innovations:

• AI-driven tools can provide real-time captioning and alt text generation for images.
• VR/AR accessibility guidelines are being developed to ensure equitable immersive experiences.
• Personalized accessibility features will adapt software behavior to individual user needs.

Conclusion

Building accessible software is not a one-time checkpoint; it’s an ongoing commitment to inclusivity, usability, and quality. By applying best practices across the development lifecycle, using tools, following standards like WCAG, and encouraging an accessibility-first culture, organizations can develop products that empower everyone.

When the software is designed for inclusivity, it not only help people with special needs but improves all experiences.

“We spent so much time on maintenance when using Selenium, and we spend nearly zero time with maintenance using testRigor.”

Keith Powe VP Of Engineering - IDT