Enabling Accessibility in the Modern Web
By: Lisa Kuliczkowski
Tags: QA, Experience Design, Accessibility, Engineering, Technology

Joint post with Alison Walden

One billion people worldwide experience some form of disability[1], which could be anything from a mobility issue making someone unable to use a mouse, to low vision, to hearing loss. Consider that, and consider that less than 1% of websites are accessible[2]. For most of us, accessing the web is second nature and we do not give it much thought. Imagine if none of the websites you rely on worked for the way you navigate, and you were excluded from everything on offer. This does not just affect people with permanent disabilities. People with temporary injuries, people trying to use their smartphones in the glare of the sun, or people of all ages and abilities who would not self-identify as needing an accessible website, would all benefit from accessible online experiences.

The W3C states that web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them, no matter how they navigate[3]. Most online experiences today were designed and developed with mouse users or touchscreen users in mind, but they were not tested to ensure they work for someone who uses an alternative device, such as a keyboard or a screen reader. The result is that these user groups are excluded from the experience.

How can organizations make their online experiences accessible?

Nobody wants to exclude people from accessing content based on how they access it. This is generally not the intent of professionals when they build a website, but as noted above, it is happening. It is happening a lot. However, web accessibility will happen naturally when it is built into an organization’s existing processes.

Let’s dive deeper into what these processes look like for two of my current projects. For the first client, I am the accessibility lead for the marketing team. They have very mature and robust accessibility processes. They are avoiding all the common mistakes when it comes to implementing accessibility.

Accessibility is accounted for at the very beginning

Not thinking about web accessibility until the end of the project is common and a major mistake. It is a huge misconception that a developer can just fix everything at the end. More often than not, doing accessibility at the end costs more. Think of re-doing the electrical and plumbing of a house after all the drywall has been put in. To avoid this heavy cost of rework, accessibility must be considered at all stages of a project.

This client has an internal accessibility team to help with the accessibility tasks. To ensure that the end product is compliant, the team develops an accessibility POC during the design phase. Once that POC is considered feasible, they write accessibility requirements, and the project only moves to the development stage once the accessibility team approves it. This means that before any coding is done, there must be approval from the accessibility team. During development, the developers perform accessibility testing as part of their unit testing. This includes the use of automated test tools as well as manual testing with the keyboard and a screen reader. The QA team also tests for accessibility during feature testing, pre-production testing and post-launch testing.

For content updates via the CMS, there is a similar process. Designs and copywriting undergo an accessibility review, and the campaign only advances to content authoring stage once I approve it. After the updates are authored in the CMS, the QA team performs accessibility checks as part of their validations, and I provide accessibility approval. After this, it will go to the client for reviews.

The team has experience using different assistive technologies

It is hard to build an experience that works for someone if we do not truly know how they use it. It is important for designers on the team to understand how different people navigate in order for them to design something that will work. It is also important for developers to know how to test it by navigating that same way.

On this client team, the developers, QA analysts and business analysts all know how to use screen readers and other assistive technologies. For example, during the testing stage of a project, features are also validated in Windows High Contrast Mode, which is a setting for PC to alter the colors of the foreground and background to enhance the contrast for those with low vision. The QA team also validates with a Bluetooth keyboard when testing on mobile devices.

The client validates the work for accessibility

Without accessibility training, a client will not be comfortable accepting our work. Or worse, they may create a scenario where they request changes that actually break accessibility guidelines. By investing in an internal accessibility team, this client has the skills and knowledge to confidently validate our work before it is deployed to production.

For content updates that I mentioned earlier, there is more that happens before the campaign can go live. Once our team internally approves the changes, it goes to the client marketing and brand stakeholders for review. Once they approve, there is an additional workflow that is triggered in the CMS. After the client’s marketing and brand team approves, the updates are pushed into an accessibility workflow where it is reviewed by the client’s accessibility team. If there are no accessibility issues, the content is approved to go live. If there are major accessibility issues, the updates are rejected. Our team fixes the issues, and it goes back into the workflow again. If there are minor issues, the content may be approved to go live, but the problems must be resolved within 24 hours.

The critical point to note is that the client’s accessibility team is responsible for all the content updates that go onto the site and they have the power to reject changes if there are blocking issues. Accessibility is considered first regardless of campaign timelines and hard launch dates. Accessibility is the last determining factor for the content updates to go live.

Accessibility requirements are documented

This may seem obvious, but for companies who are not doing accessibility right, expected screen reader behavior and keyboard functionality are not documented. One cannot blame a developer for not supporting use cases that were not described in the requirements. Without documenting the requirements, there is no way to test if people are building things the right way, because the right way has not even been defined.

For this client, accessibility requirements are documented by the client’s internal accessibility team. The requirements are saved in a Jira ticket and linked to the main Jira ticket where all of the other related information is kept. Keeping requirements together with the other information necessary for feature development makes them easy and readily available for anyone who needs them.

For this company, accessibility requirements are what we refer to generally as “requirements”. Take a moment to think about that — when you hear “requirements”, do you think of accessibility requirements? They are not “extra requirements” to add at the end. Functional requirements, business requirements, accessibility requirements — these are all requirements and they are all treated with the same importance.

The client has persons with disabilities to validate what is built

We can all learn to use screen readers and other assistive technologies, but we will never be power users unless we use them all of the time. To get the best insights and ideas, we need to tap into people with disabilities who are power users who can provide insights about how to best design our experiences.

This client has employed persons with disabilities on their team. The developers work with them to resolve issues and improve experiences. This helps to validate the product and closes the loop from the beginning of the accessibility POC and requirement documentation phases. They can get immediate feedback to make adjustments, and they can be confident that what they launch will be accessible. This also provides valuable learnings for the future. The team is equipped with the knowledge and experience to avoid the same accessibility issues they faced before.

Enabling accessibility when it is new to an organization

How do companies that are new to accessibility get started? For my other project, the client does not have accessibility integrated into their processes. Our engagement is to re-design and re-platform their North American sites to a new CMS. As the accessibility lead on the project, I am infusing accessibility to each stage to ensure it is considered at all times.

The team does not have a lot of experience with accessibility. So the first thing I did was create accessibility guidelines for them to follow. I created guidelines for designers, copywriters, content authors, developers, and QA analysts.

As designs are produced, I am reviewing designs to catch issues early on before development. This can be done even earlier if possible, such as when wireframes are produced. Accessibility feedback for designs should be documented and shared with the designers in order for them to make changes.

During the requirements phase, the product owners collect and communicate the requirements for a feature, and I write accessibility requirements for the feature. I write requirements for HTML markup, custom widgets, and screen reader requirements, to name a few. They are documented in the same place as the other requirements, and they are reviewed and approved by the client’s accessibility lead.

Accessibility testing is performed by the QA team and me. Accessibility defects are logged, prioritized, and fixed. Accessibility testing is done during development sprints with functional testing to catch issues as early as possible. Closer to launch, I plan to assess holistically, page-by-page when content is created and authored. At every stage of the project, accessibility is being incorporated; we are not waiting until the end where it will be more difficult to add in.

The client is looking to Publicis Sapient for guidance on how to maintain compliance moving forward. They have recently formed an internal accessibility team, which is a major key to success. Publicis Sapient is going to lead various accessibility training sessions for all stakeholders of digital, which includes what accessibility is, screen reader training, and accessibility training for specific disciplines. The training will set a foundation for them to incorporate accessibility into their processes.

“Accessibility First”

Everything discussed about accessibility in this article lends itself to the idea of “accessibility first”. When we put accessibility first, we create accessible experiences for everyone, and it happens naturally. We all know what mobile first is, now it is about accessibility first.

The moral of this story is that when it comes to helping our clients with web accessibility, sometimes it is going to rain, and sometimes it is going to pour. Sometimes our clients will come to the table with all of the organizational processes in place to enable web accessibility. But other times, we will need to help. We will need to help bring about the required process changes to enable accessibility in our clients’ organizations. Regardless of where a company is on their accessibility journey, there is always a role we can play to help them be successful in creating accessible experiences that are inclusive and benefit everyone.

References

[1] https://www.worldbank.org/en/topic/disability#:~:text=Results-,One%20billion%20people%2C%20or%2015%25%20of%20the%20world's%20population%2C,million%20people%2C%20experience%20significant%20disabilities.

[2] https://www.perrill.com/why-accessibility-should-be-a-top-priority-for-every-business-website/

[3] https://www.w3.org/WAI/fundamentals/accessibility-intro/