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.
Avoiding legal risk
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.