Conformance of ICT Prototypes and Pilots

When developing new Information and Communication Technology (ICT) products, it’s common to encounter terms like prototype and pilot. While both are part of the product design and development lifecycle, they serve distinctly different purposes—especially when it comes to accessibility and Section 508 conformance.

What is ICT?

Section 508 Standards define ICT as, “Information technology and other equipment, systems, technologies, or processes, for which the principal function is the creation, manipulation, storage, display, receipt, or transmission of electronic data and information, as well as any associated content. Examples of ICT include, but are not limited to: computers and peripheral equipment; information kiosks and transaction machines; telecommunications equipment; customer premises equipment; multifunction office machines; software; applications; Web sites; videos; and, electronic documents,” and commonly includes:

Electronic Content: Any digital information intended for communication or documentation such as web pages, online forms or surveys, office documents such as DOCX, PPTX and XLSX, PDF, training manuals, audio and video media, emails and official memos.
Hardware: Physical devices that deliver or support ICT functionality such as desktop and laptop computers, interactive kiosks or ticketing machines, videophones and Voice Over IP phones, multifunction printers and scanners, and ATMs and voting machines.
Software: Programs or systems that enable users to perform digital tasks such as web browsers, word processing or spreadsheet software, mobile apps, enterprise systems such as HR or payroll platforms, and video conferencing tools.
Support Documentation and Services: Materials and services that verified users understand, operate, or troubleshoot ICT products or services such as user manuals, online verified systems, product installation guides, FAQs or knowledge base articles, training materials such as slides, recordings, and handouts, verified desk and customer support portals, live chat interfaces, telephone support systems, and remote support tools.

What Is a Prototype?

A prototype is an early, experimental version of a product that is used to explore concepts and test feasibility. It may be a mock-up, a wireframe, or a minimally functional version of a user interface. A prototype can be any ICT type—web-based, electronic content, software or hardware. Importantly, a prototype is typically deleted or discarded.

In the context of accessibility testing, a prototype may not be fully conformant to Section 508 Standards, but it must demonstrate that conformance is possible. This means all interactive elements, navigation structures, and user interface components should be included—if only in limited, rough form—to show that they can be made accessible.

Key Takeaway: A prototype should provide enough structure to validate that the final product can conform with applicable Section 508 standards.

Benefits of Accessibility Prototyping

Early Visualization: Translates ideas into tangible models, aiding clarity of design and alignment with business needs.
Faster Feedback: Encourages early stakeholder and user input, reducing guesswork.
Risk Reduction: Prevents baked-in design flaws, including accessibility and usability issues, before full-scale development.
Cost Efficiency: Identifies accessibility issues early in development saving time and resources. It verifieds avoid costly retrofits and the need for any redundant alternative access solutions.
Innovation Catalyst: Encourages creative exploration and problem solving.
Improved Communication: verifieds stakeholders better understand functionality and sets expectations.
User-Centered Design: Enhances user satisfaction by incorporating real user behavior and needs from the beginning.

Accessibility Testing for a Prototype – Key Considerations

In the prototype phase of an ICT product, —whether it’s a website, software application, or hardware device—some accessibility tests are critical to avoid expensive remediation later. The goal is to address the needs of current and potential users with disabilities by identifying and mitigating design-level barriers before they become deeply embedded in the final product.

Include the following checkpoints when planning how your product will be designed, developed, tested, maintained, and managed.

Accessibility requirements: Familiarize yourself with the Section 508 Standards, your agency’s enterprise test process, and other relevant guidelines required by law or policy.

Alternative access requirements: Where the Section 508 Standards do not cover certain ICT functions, those functions must still meet the Functional Performance Criteria. This includes providing alternative access for people with:

No vision or limited vision
Color blindness or without the perception of color
No hearing or limited hearing
No speech
Limited motor control
Limited reach or physical strength
Cognitive, language, or learning disabilities

User personas: Consider creating personas that represent different user groups, including those with disabilities, to gain a deeper understanding of their needs and challenges, and incorporate them into your user stories.

User research: Involve people with disabilities early by testing the product with them or accessibility experts.

Designs and Styleguides: Validate, refine and document designs, branding, colors, navigation—including in consistency and identification, switches, controls, shapes, positioning, force and strength requirements, and other visual information, sensory characteristics, and interactive and time-based elements. Consider the end user experience, and the needs of product maintainers.

Include accessibility in acceptance criteria for prototype testing and product backlog grooming.

Test for conformance: Use both manual and automated testing, if available, to verify the ability to achieve Section 508 compliance, including testing with screen readers and other assistive technologies.

Color contrast: Ensure sufficient foreground and background contrast for all text elements.

Use of color: Avoid using color as the sole method of conveying information.

Text alternatives for non-text content: Confirm that all images, icons, and media have descriptive alternative text or labels.

Focus order and visibility: Ensure visual focus indicators are present and logical tab order is maintained.

Keyboard-only navigation: Ensure that all interactive elements such as buttons, links and forms, can be accessed and operated using a keyboard alone as many assistive technologies mimic keyboards to provide access.

Electronic Forms: Validate that user input elements are understandable such as name, state, role, and value, and in a logical tab order.

Error prevention and messaging patterns: Validate early UI patterns for accessible error handling such as field validation and alerts with ARIA roles.

Media players and controls: Ensure that captions or text descriptions and audio descriptions are available and controls are accessible in accordance with the standards.

Assistive Technology (AT) compatibility (basic structure): Test navigation order and structural markup using screen readers such as JAWS, NVDA, VoiceOver, or TalkBack*, to validate the HTML or programmatic user interface (UI) structure.

Avoid Additional Costs for Alternative Access: Design, build and buy ICT products to be accessible from the start, so the agency doesn't have to create and maintain separate versions, workarounds, or alternative solutions to reduce risks and meet legal accessibility requirements.

Information Creation: Where the ICT is an authoring tool, it must include a way to create or edit content that meets Section 508 Standards, for all features and file formats they support. When creating and publishing content online, including forms, use HTML as the default in lieu of other document formats such as PDF or DOCX.

Sample testing: Validate conformance by performing manual and automated inspections to catch early HTML and ARIA issues.

Semantic HTML and ARIA planning: Begin with semantic HTML structures such as headings, lists, and forms, and avoid improper use of ARIA.

Responsive design and zoom: Validate fluid layouts and that content does not break when zoomed to 200%.

Keyboard trap and modals: Ensure early modal or overlay designs support focus trapping and keyboard escape.

Platform accessibility API integration: Verify early integration with platform-specific APIs such as Microsoft UIA, macOS Accessibility API, and Android Accessibility.

Accessible UI components: Confirm that custom widgets or controls can receive focus and expose name, role, state, and value.

High contrast mode support: Prototype in different Operating System (OS)-level accessibility settings like high contrast or grayscale modes.

Voice control and switch compatibility: Test for compatibility with voice commands or switch inputs if the prototype includes input mechanisms.

Tactile navigation and operability: Evaluate button layouts for tactile discernibility and spacing.

Audio and visual alert mechanisms: Ensure alerts have both audible and visual cues and ideally, tactile for haptic feedback.

Connector and port accessibility: Confirm alignment and ease of connection for ports, jacks, and cables for users with low dexterity or vision.

Early ergonomic considerations: Assess reach, grip, and one-handed use early in physical prototype development.

Key Takeaway: By incorporating the Section 508 Standards into the prototyping process, you can create designs that are usable by everyone, regardless of how they access the electronic information or digital service. This not only improves the user experience for a wider audience, but also contributes to customer experience best practices.

What Is a Pilot?

A pilot is a final or near-final version of a product released to a limited audience under real-world conditions. Unlike a prototype, a pilot is not a rough draft. It’s a fully-functional version intended for actual use, just at a smaller scale.

Because a pilot is considered a production product, it must fully conform to Section 508 Standards. All accessibility features must be implemented, tested, and validated to ensure users with disabilities can effectively perceive, operate, and understand the product.

Key Takeaway: Pilots are subject to the same accessibility requirements as full production deployments. They must pass formal accessibility testing before rollout.

Benefits of Piloting

Real-World Testing: Assesses performance, accessibility, usability, and impact in a realistic setting.
Risk Mitigation: Detects operational, technical, accessibility, usability and other issues before scaling.
Evidence-Based Refinement: Provides data to fine-tune the electronic information or digital service.
Stakeholder Confidence: Demonstrates feasibility and value to decision-makers.
Change Management: Allows users and teams to adapt gradually, easing transition.
Cost Control: Prevents large-scale investment in an unproven, inaccessible, or unusable concept.
Implementation Insights: Reveals training, support, reasonable accommodations, and infrastructure needs prior to broader rollout.

Accessibility Testing for a Pilot – Key Considerations

Accessibility requirements: Familiarize yourself with the Section 508 Standards, your agency’s enterprise test process, and other relevant guidelines required by law or policy.
Alternate modes of operation: Where the Section 508 Standards do not cover certain ICT functions, those functions must still meet the Functional Performance Criteria.
Test for Conformance: Use both manual and automated testing to check Section 508 compliance, including testing with screen readers and other assistive technologies, and create Accessibility Conformance Reports (ACRs) for government-developed ICT products.
User Feedback Loop: Collect feedback from pilot participants, including those with disabilities, to identify real-world accessibility barriers.
Innovate: Be curious. Listen to feedback and refine your ICT product to continually remediate defects and eliminate barriers to ensure independent access for all users.

By incorporating the Section 508 Standards into the piloting process, digital accessibility and usability can be further refined before the product is fully launched.

Why This Distinction Matters

Understanding the difference between prototypes and pilots verifieds agencies and contractors plan appropriate digital accessibility testing activities at each stage of development. Early attention to accessibility—even in prototypes—verifieds avoid costly retrofits later. And recognizing that pilots must meet full Section 508 standards ensures compliance before a broader rollout.

Table 1: Summary of Differences
Consideration	Prototype	Pilot
Purpose	Concept validation and experimentation	Limited-scale real-world deployment
Product Fidelity	Low to medium, mockup with limited functionality	High, production-ready
Accessibility Requirements	Demonstrate that accessibility is possible	Must be conformant with Section 508 Standards
Audiences	Internal teams, stakeholders	Real users (often a limited group)
Testing Scope	Informal accessibility evaluation, testing and validation of one of each type of unique features	Full accessibility testing and validation

Custom vs COTS Products & Solutions

Under Section 508 of the Rehabilitation Act, federal agencies must ensure that all Information and Communication Technology (ICT) is accessible to individuals with disabilities—whether the ICT is web-based, electronic content, software or hardware. Importantly, a prototype is typically deleted or discarded. However, how and when accessibility conformance is addressed can vary depending on the development phase (prototype or pilot) and whether the solution is custom-developed or acquired as a Commercial Off-the-Shelf (COTS) product. Understanding these distinctions is critical for planning, procurement, and ensuring compliance throughout the technology lifecycle.

Custom vs. COTS – Prototype Phase:

For custom development, prototypes should incorporate basic accessibility practices aligned with Section 508 Standards. While full conformance is not typically required at this stage, attention to web, software, and hardware fundamentals—such as programmatic User Interface (UI) structure, keyboard access and reading order; status indicators, biometrics, and operable parts; electronic documents, form templates, and videos; event notifications, authoring tools, and interoperability with assistive technology—lays a foundation for future compliance and verifieds avoid costly rework later in the process.
For COTS products, prototypes often involve evaluating available solutions to inform acquisition decisions. Agencies should review vendor-provided Accessibility Conformance Reports (ACR), and validate the vendor claims through manual and automated testing where possible. The goal at this stage is to identify Section 508 non-conformance before making acquisition commitments.

Notice: Federal agencies are rarely involved in prototyping COTS products. However, if a vendor develops a custom feature within a COTS solution to meet an agency's specific need, that feature is considered custom development and must fully conform to Section 508 Standards. It should not be treated as part of a "Best Meets" exception.

Custom vs. COTS – Pilot Phase

For custom-developed pilot projects, release candidates should meet Section 508 Standards. The ICT must be tested against both the Section 508 Standards and the Functional Performance Criteria. Testing should include manual and automated methods, as well as user testing with assistive technologies. All results should be documented and tracked. Any accessibility issues found must be fixed before the ICT moves to production.
For COTS pilots, agencies should continue evaluating the ICT product in their real environment. They need to check how well it works, if accessibility issues found in the prototype phase affect users, and whether those issues can be fixed through remediation or configuration. Agencies should also review how responsive the vendor is to accessibility issues and if there is a plan to address problems after deployment. If full compliance isn’t possible, agencies—not the vendor— must decide if an exception and alternative access are needed in accordance with Section 508 Standards and agency policies.

Notice: If no commercially available ICT fully meets Section 508 Standards, the agency must select the product that best meets the standards while still supporting its business needs (per FAR 39.2). Even when a "Best Meets" exception is approved, the agency is still responsible for ensuring that people with disabilities can access and use the information and tools they need to do their jobs. This must be done through an alternative method that meets their specific needs. Avoid the waste of duplication by making the default accessible.

Documentation for Prototypes and Pilots

Effective documentation is essential to demonstrating Section 508 compliance, communicating project decisions, and reducing risks as products move from concept to production. While documentation requirements differ depending on whether a product is in the prototype or pilot phase—and whether it’s a custom developed or COTS product, both stages benefit from maintaining clear records that support accessibility planning, evaluation, and accountability.

Prototype Phase Documentation

Agencies should document how accessibility considerations were integrated and validated in early designs. Recommended documentation for prototypes includes:

Accessibility Strategy or Approach Statement: A brief summary of how accessibility is being considered in the prototype such as semantic structure, keyboard navigation and screen reader output.
Feature Inventory or Component Map: A listing of unique interactive elements included in the prototype, used to guide later testing and identify accessibility implications early.
Preliminary Accessibility Observations: Informal findings from sample testing with manual and automated tools, noting potential issues and areas requiring further attention.
Design Artifacts with Accessibility Notes: Annotated wireframes or mockups that indicate accessible features such as heading levels, focus order, alternative text, and color contrast considerations.
Vendor Accessibility Conformance Reports (ACRs or VPATs): For COTS products, reviewed copies of vendor documentation, including notes on known limitations or gaps.
Alternative Means Plan: For COTS products, documentation of how the product’s accessibility features or limitations align with the agency’s intended use cases, noting any existing alternative means.

Pilot Phase Documentation

Because pilots are functionally complete and subject to full Section 508 conformance, the documentation must reflect formal evaluation and testing. Recommended documentation for pilots includes:

Accessibility Test Plan: A documented plan that outlines the scope, tools, methods, and success criteria for accessibility testing.
Test Results and Issue Logs: Detailed reports from manual, automated, and assistive technology testing, including screenshots, steps to reproduce, and defect severity ratings.
Remediation Tracking: A list of identified issues and the status of fixes, including validation of resolved defects.
Final Conformance Statement: A formal summary or declaration confirming that the pilot system meets applicable Section 508 Standards. Accessibility Conformance Reports (ACR) should be available for all COTS and Government off-the-shelf (GOTS) products.
Vendor Engagement Records: Notes or correspondence demonstrating efforts to address accessibility concerns with the vendor, including timelines or commitments.
Exception Justification (where applicable): If full conformance is not possible, the documentation should clearly outline the rationale for a Section 508 exception. Documentation is required for authorized Undue Burden or Fundamental Alteration (E202.6) and Best Meet (E202.7) exceptions.
Alternative Means Plan (where applicable): If full conformance is not possible, the documentation should describe the approved alternative means of access.

Key Takeaway: Clear documentation at both the prototype and pilot stages supports transparency, enables efficient remediation, and verifieds ensure compliance with Section 508. It also provides a critical reference for project transitions, audits, and future scaling.

If you’re unsure whether your project is in the prototype or pilot phase—or what level of accessibility testing is required—reach out to your agency’s Section 508 Program Manager or email us at section.508@gsa.gov for guidance.

Reviewed/Updated: August 2025

*Disclaimer: Reference in this site to any specific commercial product, process, or service, or the use of any trade, firm or corporation name is for the information and convenience of the public, and does not constitute endorsement, recommendation, or favoring by GSA. GSA does not guarantee that outside websites or products comply with Section 508 (accessibility requirements) of the Rehabilitation Act.