Have you built a digital solution and only tackled the accessibility requirement late in the delivery lifecycle?
Perhaps your experience of achieving accessibility is a User Interface (UI) tweaked to pass a tool-based Web Content Accessibility Guidelines (WCAG) accessibility standard test?
Accessibility often suffers similarly to security; it is frequently addressed far too late in delivery lifecycles and becomes a rushed, minimal activity focussed on achieving just enough to answer, “does it pass?”. Viewed only as a “UI thing” all responsibility for accessibility compliance is placed – unfairly – on User Experience (UX) designers and front-end developers. The result is a solution that passes automated tests – but is it truly accessible?
WCAG accessibility standards provide a valuable set of standards against which to design and assess the ability of a UI to support different physical and cognitive disabilities – but it is just one factor to be considered when delivering an accessible solution. A UI that successfully meets WCAG WAI accessibility standards can still form part of an inaccessible solution – compromised by physical, security and technology factors not being considered.
Accessibility refers to the ability for everyone to use a product or service, regardless of how they interact with it.
It should try to accommodate all potential users in their different contexts of use. To do so has real benefits – better designs for everyone – a point made in Microsoft’s inclusive design approach. An accessible solution abstracts away complexity and difficulty from the user. Barriers to use are reduced, or removed, and good design delivers simpler, more efficient experiences.
All roles involved in designing and delivering a product/service have a responsibility to successfully produce truly accessible products and services. Architecture arguably has a key role to play. Given the domains that architecture covers – enterprise, solution, technical, data or security – it has an ability to contribute to successful accessible solution design. It’s typically an implicit rather than explicit consideration, so there is value in highlighting how architecture can deliver significant positive influence and impact.
How can an Architect ensure accessibility when designing a system that includes COTS products, legacy components, and bespoke modules?
Adopting a user-centered approach – Successfully addressing accessibility goes beyond good UI design; Architecture should also focus on user needs when making technology and engineering design decisions. By asking, “What does the user need?” and “How can we achieve accessibility through design?” architects can create more inclusive and innovative solutions – Accessiblity.com identified just some of the emerging technologies that offer fresh approaches. For instance, an AI-driven speech-to-text system can evolve to meet the needs of users with motor disabilities.
Align designs to an accessibility outcome – Programmes and products should treat accessibility as a continuously targeted outcome, not a pass/fail check. Enterprise Architecture tools can help track and align technology components with the target business accessibility outcomes. By integrating accessibility into early design stages, and using tools for ongoing assurance, architects ensure that it is considered throughout the delivery lifecycle, avoiding the risk of leaving accessibility to UX/front-end teams as a last-minute concern.
Understand “hard” and “soft” accessibility requirements – Architects must grasp the impact of design decisions on accessibility. This involves understanding “hard requirements” like web WCAG standards, which influence technology choices, as well as “soft requirements” that consider the user’s digital context, environment, and skills. For instance, if users wear protective gloves, a touch screen might not be suitable. This holistic consideration of accessibility helps architects make better design decisions.
Address how and where users access the service – Architects must understand where and how users will access the service to avoid excluding them. Considerations include whether access is device-specific or location-dependent, whether multiple authentication steps are necessary, and whether requirements, like installing a client certificate, might create barriers to access. Designing these fundamental access steps carefully is crucial to ensuring accessibility from the start.
Consider the whole ecosystem – Architects must ensure consistent accessibility across all components of the solution. A focus on the core UI can be undermined if integrated third-party services don’t meet the same standards. Architects should take a holistic view, ensuring that all design integrations, data, and services work together without creating accessibility gaps.
Understand how technology addresses accessibility – Architects must guide technology decisions with a clear understanding of how each choice impacts accessibility. They should know the accessibility features of COTS products, how they can be configured, and how technology can be leveraged in bespoke solutions. For instance, architects can assist development teams in using design systems or responsive frameworks to meet accessibility goals effectively.
Remember the role of data – Accessibility often requires additional metadata, such as image alt text or video transcripts, to support assistive technologies and good UI practices. Architects should ensure that data models and governance policies account for capturing, storing, and managing this metadata. Proper governance ensures compliance from the start, integrating accessibility into the solution’s data management.
Balance security vs accessibility –Security measures can sometimes hinder accessibility. For example, Multi-Factor Authentication (MFA) using Time-based One-Time Passwords (TOTP) might be inaccessible to users who struggle with SMS or authenticator apps. Alternatives like biometric authentication, hardware tokens, or push notifications can provide security while reducing barriers for users.
Protect privacy – Architecture design targeting accessibility must not compromise privacy – accessible does not mean “open”. Architects should ensure that data protection standards, such as encryption and access controls, are maintained. For example, they should design solutions to prevent screen readers from disclosing sensitive data, balancing accessibility with robust privacy measures.
Encourage early testing – Integrate automation and tools into the design, build, and deployment processes to validate accessibility from the start. Using tools to scan code and test user interfaces throughout development helps identify and fix issues early, ensuring higher quality and consistency before final deployment.
Conclusion
User behaviour and feedback will always provide the true measure of how accessible a system, service or product is. However, ensuring architecture consciously and proactively considers accessibility throughout the design and delivery lifecycle will increase the chance of delivering a solution that meets compliance standards and is truly inclusive and accessible to all your users.
If you would like to start your accessibility journey or have any questions, don’t hesitate to reach out to us. Please visit FSP and we can talk.