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.
Can explain why accessibility is a requirement
Team members possess varying levels of understanding.
The minimum level garners compliance. But when the reasons are taken to heart, your team’s performance can dramatically improve.
Accessibility isn’t just the right thing to do, it’s the smartest thing to do.
Living your organization’s values
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.
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.
Can characterize automated and 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 like MagentaA11y.com.
Automated tests find programmatic errors, but can’t describe actual customer experiences.
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 markups by an automated tools.
- 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 that particular 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.
Test account 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.
CMS platforms include 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.
APIs deliver accessible content
APIs that return content should include relevant accessibility features.
For example, search results should include alt text for images.
Layered testing strategy
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
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.