Web Accessibility Guidelines for Architects

Since the web is fundamentally designed to work for all people, regardless of language, location, or ability, all websites and applications should be accessible by a diverse group of people with a wide range of needs. The unfortunate truth, though, is that many applications aren’t built with accessibility in mind. As a result, they interact poorly with the tools and technology that people with disabilities rely on.

While companies don’t intend to provide inadequate accessibility solutions, in many cases they simply don’t understand that doing so can have an adverse effect on their customers and may also cost them business opportunities with prospective customers. Companies that do understand these things often still view accessibility as an issue that only gets addressed during testing, which can lead to large numbers of unresolved issues that stakeholders don’t consider to be show-stoppers for a project to go live. As architects, we need to be aware of the accessibility requirements for any projects we’re involved with and advocate for their inclusion at every project stage, from planning through testing.

Plan

During the earliest stages of your project, think about who will be using your application, what their accessibility needs might be, and how to address those needs. Some questions to consider are:

• Where are your users located?
• How will they be accessing your application?
• Do they all speak the same language?
• Are they likely to have physical or mental disabilities that will make it difficult to use your application or website? What are those disabilities?
• Do any of the countries your organization does business in mandate that certain accessibility standards are met?

Remember that the World Wide Web Consortium (W3C) maintains a baseline set of Web Content Accessibility Guidelines that you should apply to every project. The reason you should be asking the questions above isn’t to determine whether or not you need to incorporate accessibility at all, but rather to identify any additional actions you may need to take, such as:

• Incorporating special hardware or software into your designs.
• Planning for additional development cycles to ensure that all accessibility needs are addressed.
• Including people who have the additional accessibility requirements you’ve identified as project stakeholders and asking them to help craft requirements, brainstorm ideas, and weigh in on design decisions.

Design

Salesforce publishes Accessibility Conformance Reports (ACRs). These industry-standard documents explain how our software meets accessibility standards. We also continue to introduce accessibility features with each new release. Make sure to review our ACRs and release notes prior to the start of any project and document any additional requirements that don’t seem to be addressed out-of-the-box. Identify design standards to be adhered to throughout the project and consider creating an overall set of standards that can be used as a reference to ensure consistency across all of your organization’s projects.

Also remember that designing for accessibility is an ongoing effort. As you iterate through your design changes, review them against your standards to ensure that the user experience is at least as accessible as it was in your previous iterations. Waiting until the end of your design or build phase and trying to retrofit components to improve accessibility will not only increase your overall project costs and complexity, but it will also increase the likelihood of accessibility-related gaps in your end-to-end processes.

Build

In the past, the only way that Salesforce developers could ensure that accessibility requirements were fully met was to override components and replace their existing behavior with an improved experience for their intended audience. Today, Lightning Web Components have native support for Web Content Accessibility Guidelines, which helps to reduce the need for accessibility-related customizations significantly. Overrides can still be used to address any additional requirements that go beyond the standard Salesforce offerings, but architects and developers need to take accessibility guidelines into account when recommending or using them. An override can replace the existing functionality of a component; and a poorly designed override can make the component less accessible. It can also result in the need for future modifications if Salesforce ever updates the component to include additional accessibility-related functionality.

If you have existing sites and applications that were built with earlier versions of components and your developers used overrides to implement accessibility-related features, you can reduce technical debt by creating a plan to migrate to newer components that have native support for accessibility features and removing overrides that are no longer necessary wherever possible.

Test

Several automated solutions for accessibility testing are available. Automated testing will likely never cover 100% of your accessibility requirements, but it will help to identify some of the most common issues. To ensure compliance with accessibility standards, include tools like these in your test plan. Be sure to account for the time it might take your team to learn how to use the tools and complete required manual (along with automated) testing to validate accessibility. Then, adjust your project timelines accordingly.

Variations in your testing environment itself may affect test results as well. Different accessibility testing tools are designed to focus on different areas of accessibility and may uncover different issues. Also, not all browsers and screen readers work the same way. It can be extremely difficult to predict exactly which browsers people are going to use to view your site or what their specific accessibility needs might be, so you should plan to run multiple tests using different combinations of tools and browsers.

When it comes to user acceptance testing, a best practice is to include users with accessibility needs in your testing process. Even if you invest in the best tools available, failing to solicit feedback from people with actual disabilities can result in critical gaps related to how practical it is for someone with a disability to complete required tasks. If you don’t have access to a community of users with accessibility needs, you can enlist third-party testing firms that specialize in accessibility testing by people with disabilities.

Conclusion

By following the processes outlined here and placing web accessibility at the forefront of your organization’s digital transformation roadmap, you can inspire customer trust and confidence while promoting equality. You’ll also see better adoption rates and greater productivity from users who depend on systems being accessible. Your applications and websites will appeal to the highest possible percentage of your audience, helping to increase your potential market. And lastly, you’ll have more confidence that your organization is in compliance with accessibility-related legal requirements.