Digital architecture

Accessibility is the foundation of a solid digital strategy

Why this matters

Architects are involved early in the decision-making process for new projects.

They have great influence over databases infrastructure, development frameworks, content management system (CMS) choices and API formats.

When accessibility is not factored into decisions at this level, there is potential for expensive rework, renegotiation of contracts and costly delays.

Team commitment KPIs

What requirements must the team agree to meet if your organization is going to be successful?

What obstacles must be acknowledged and removed for digital architects to create inclusive experiences?

Core responsibilities

Can explain why accessibility is a requirement

Team members can possess varying levels of technical understanding, but all should be alert to the basic reasons accessibility is a requirement.

Accessibility target policies

At a minimum, any team needs to understand accessibility targets exist, are defined by enterprise policy and enforced by leadership.

This bare minimum adoption achieves some level of compliance, even when it’s begrudging.

However, if the reasons for accessibility policies are taken to heart in service of the customer, products can dramatically improve.

Living your organization’s values

Accessibility isn’t just the right thing to do, it’s the smartest thing to do.

Every organization has a set of values, often including core ethical tenets like treating people with respect and doing the right thing.

How does accessibility fit those values? How does ignoring accessibility breach them?

A tool for innovation

Accessible design and development builds better products for everyone. When teams put accessibility at the beginning of their processes, they create more valuable products for your enterprise.

Competitive advantage

26% of the US population has a disability that requires accommodation, making people with disabilities the largest minority in the United States. This adds up to billions of dollars in combined purchasing power.

Accessibility is the law. Designing and building accessibility into products also helps the enterprise avoid legal risk and liability due to a customer complaint.

Knows where to find internal/external policies

It will often fall to individual contributors to explain requirements and policies to others, especially to contractors or 3rd-party partners. Pointing to published policies gives weight to what otherwise might be seen as a preference.

Policies should be published in both simple and legal formats and available to share for:

  • Design systems (must accompany design system artifacts)
  • Component library (integrated in the documentation)
  • Internal company usage (typically in the company intranet)
  • External partner and procurement requirements (shareable publicly)

Can characterize automated and manual testing

Manual testing

Manual testing is precisely that: a human actually testing the experience using the screenreader and browser combinations you need to support.

Experts can deliver an organized report of defects by severity. This is a necessary tool for improving the customer experience.

Limits of manual testing

A manual test isn’t the same as a usability study, but it is effective in uncovering the issues your customers experience.

Manual testing is performed by people, and perception of what constitutes a defect can vary slightly from one tester to the next. It will be helpful for your testers to reference your severity definitions, and use uniform testing acceptance criteria.

Automated testing

Automated tests find programmatic errors, but can’t describe actual customer experiences. Just like a spell checker, automation can flag non-issues while missing legitimate problems because it can’t understand context and intention.

How to use automated scans effectively

Scanning tools quickly pinpoint syntax defects in code. Some flagged issues won’t affect the customer experience, but you should exercise scrutiny and manual testing if a web page is riddled with invalid code and errors.

Limitations of automated scans

Testing tools have value. But it’s important to understand their drawbacks. Even the most robust tools can identify less than half of the potential defects on a page.

Code can be inaccessible for a person using their keyboard or screen reader without being flagged as invalid markup by an automated tools.

Practical examples
  • Automated scans can instantaneously test checkboxes for properly associated labels and other code attributes, but can’t tell you if the labels make sense.
  • Automation tools can flag an image for missing alt text, but can’t tell you if it would be better for the screen reader to ignore a particular decorative icon.
  • Custom components, like an accordion expander, could be inaccessible with the keyboard and yet be formed of valid code that won’t raise an error.

Chooses CMS platforms with accessible publishing features

Content management system (CMS) tools should include features for adding appropriate headings, alt text for and aria-labels for controls like links or buttons. The rendered output of the CMS must be accessible.

Ensures 3rd party plugins and APIs deliver accessible content

Architects must choose accessible plugins and any application programming interface (API) that returns content must include relevant accessibility features.

For example, a search results API must include appropriate alt text for images. A plugin that delivers product reviews must be accessible.

Layered testing strategy

A layered testing strategy enables people who are building accessible products and supports systems that can automatically monitor accessibility.

Ensures test account or payment test creation is straightforward

Databases and applications should include the ability to create test accounts for all UI configurations. Test account creation should be frictionless and compatible with automated testing tools, including payment transaction testing.

Component library includes automated tests

The component library itself should have automated accessibility tests included in its build process; both to ensure accessible building blocks are available and to set the example for the rest of the organization.

Linting tools check for accessibility

As developers code, linting tools should be used to analyze code as it’s being written with little or no tolerance for accessibility syntax errors.

Support for automated accessibility regression testing

Developers should be writing regression tests for each component in the UI.

For example, a menu button will need to describe its state as expanded or collapsed. A test can be written to check for the aria-expanded attribute to toggle from false to true when focused and clicked.

Developers can run automated tests on a local environment

The same tests that are being used for CI/CD gating should also be available for developers in their local environment.

For example, if the CI/CD pipeline is automatically running a Lighthouse test on build, developers should be able to perform the same test on their local machine and come to the same results.

CI/CD/CMS can effectively gate and report accessibility metrics

On building the product in a test or staging environment, automated tests should report any defects and gate severe issues from being deployed.

Metrics should be recorded for reporting trends to leadership and timely quality reports automatically delivered to managers.

Challenges to automated testing

Testing tools require the application to be rendered to scan effectively. Public facing content usually doesn’t require user account authentication to view.

However, something like a customer account management page may require multiple test credentials for authentication for testing. This may require custom test scripting and a significant investment of development time.

Architecture KPIs

Track commitment and remove obstacles to inclusion

Download KPIs as a CSV
Core responsibilities
Layered testing strategy
Download KPIs