15.8 Accessible and Sustainable Technology Decisions
Key Takeaways
Test the configured participant journey; a vendor accessibility statement alone does not prove usability.
Compare technology impacts within a stated boundary, including travel, equipment, energy and reuse.
Acceptance criteria, fallback access and post-event evidence should be part of procurement and delivery.
Evaluate Technology Against the Event’s Outcomes
Technology procurement should begin with the event’s goals and participant tasks. A feature is useful when it enables an outcome, removes a barrier or improves a controlled process at an acceptable total cost. An app with many features can still fail if participants cannot register accessibly, use it without reliable connectivity or obtain human help. Sustainability and accessibility belong in requirements and evaluation before selection.
Identify the journey: discovery, registration, payment, travel information, on-site arrival, session participation, networking and follow-up. Ask which tasks require technology, which alternatives are needed and which systems must exchange information. Include participants, accessibility advisers, operations, IT, privacy and procurement. Distinguish a mandatory requirement from a desirable feature, and specify evidence that will show whether it is met.
Accessibility as an Acceptance Criterion
Request the vendor’s accessibility documentation and its scope, version and date. A conformance statement can support evaluation but does not prove that the event’s configured workflow is accessible. Test the actual registration form, payment integration, app, streaming player and support process. Third-party widgets can introduce barriers even when the main platform works well.
Useful checks include keyboard navigation, visible focus, meaningful labels, readable structure, text resizing, contrast, captions and clear error messages. Confirm whether the platform supports the required language and assistive technologies. Use applicable standards and representative user testing rather than treating one automated scan as complete evidence. Record defects, remediation owners and the acceptance decision.
Provide an alternative when a participant cannot use the chosen technology. Examples include a staffed registration route, printed essential information, accessible files and a way to submit questions without a smartphone. Alternatives need equivalent practical access rather than a nominal email address answered after the event. Train help staff and make the support route visible before a participant encounters a barrier.
Sustainability Beyond Paper Replacement
Digital delivery can reduce printing and travel, but it also uses equipment, electricity, networks and human support. Do not assume a virtual session or paperless app has zero environmental impact. Compare realistic options within a stated boundary: travel avoided, venues used, equipment purchased or rented, devices required and expected reuse. Quality and access also matter; excluding people to reduce a metric is not successful sustainable design.
Ask vendors about equipment lifetime, repair, rental inventory, refurbishment, packaging and responsible end-of-life handling. For badges or devices, consider quantities, recovery arrangements and reuse over several events. A reusable item provides little benefit if it is routinely discarded after one use. Specify collection ownership and an actual destination for equipment rather than relying on a recycling icon.
Avoid unnecessary digital content and processing while preserving the participant experience. Retain useful materials for an agreed period, then apply the retention schedule. Do not erase required records merely to claim reduced storage. Compare lower-bandwidth formats where appropriate, but preserve caption quality, readable details and access needs. Explain tradeoffs and assumptions in the procurement record.
| Decision | Accessibility evidence | Sustainability evidence |
|---|---|---|
| Registration platform | Tested keyboard, labels and error recovery | Data and process requirements fit actual use |
| Hybrid delivery | Captioning, accessible player and remote participation | Clear comparison of travel, venue and technology impacts |
| Badge system | Usable height, human assistance and alternatives | Quantities, no-show handling and stock recovery |
| Loaned devices | Suitable controls and accessible content | Repair, reuse, charging and return arrangements |
| Digital signage | Readable content and non-digital fallback | Power scheduling and reusable hardware |
Integrate the Requirements into the Contract
Define the supported configuration, service levels, test environment, acceptance criteria and remediation procedure. Include the responsibility for captions, support, backup exports, data ownership and deletion. Set realistic dates so unresolved defects are visible before the event becomes dependent on the system. A promise to “support accessibility” is weaker than a demonstrable requirement tied to a participant task.
Integration testing should follow a sample participant through the complete journey. Verify data mappings, duplicate handling, communication choices, identity and error recovery. A successful API response does not prove a useful result: a paid participant can still be duplicated, assigned the wrong ticket type or omitted from the access list. Use authorised test data and protect sensitive information.
A Balanced Selection Scenario
Two app vendors meet the programme’s basic requirements. Vendor A has an impressive 3D interface but the test user cannot operate key controls by keyboard and the vendor requires newly purchased loan tablets. Vendor B has a simpler interface, supports the tested accessible tasks and uses reusable rental devices with a documented return process. Compare total cost, verified requirements, support and impacts rather than scoring novelty alone.
If Vendor B still has a captioning defect, assign a remediation deadline and retest the actual player. Arrange a workable fallback in case it fails. Do not label either system universally accessible or environmentally superior without defining the tested configuration and comparison boundary. Record the remaining limitation and the decision-maker’s acceptance or rejection.
Monitor During and After Delivery
During the event, track access failures, help requests, outages and the reliability of alternatives. Give staff a clear escalation route and a way to communicate urgent changes without relying on the failed system. At closeout, verify returned equipment, data handover, retention and deletion actions, and obtain the service and impact evidence promised by the vendor.
Report both outcomes and limitations. Useful measures include completion of key tasks, unresolved access issues, device recovery, support demand and verified material or travel reductions. Compare with the original goals and use the findings to improve the next procurement. This makes technology integration accountable to accessibility, sustainability and the participant experience.
W3C’s accessibility evaluation overview explains why standards, tools and human evaluation work together. Blueprint scope was checked against the 2025 CMP International Standards on October 16, 2026.
A vendor submits an accessibility statement for its base platform, but the event adds an external payment widget. What is the strongest acceptance check?
Accept the base statement for the complete journey.
Remove every non-digital support route.
Score the vendor mainly on its newest features.
Test the configured registration-to-payment journey with appropriate technical and user evaluation.
Sections you finish are checked off in the contents.