Accessibility is About People [6/6]

Hey, there!

Digital experiences are for people. It's important to serve peoples' diverse abilities and needs by creating accessible websites and web applications. From keyboard and screen reader accessibility to safe motion design and meaningful content structure, there are numerous opportunities to make inclusive experiences. Centering disability in the conversation helps to underscore what accessibility is all about: ensuring that disabled people can access your sites.

You build digital experiences with people, as well. Humans are social creatures. Sometimes you have to find the right strategies to persuade organizations, groups, and individuals to foster accessibility. Being an advocate can be gratifying and it also can be exhausting. Understanding different personality types and motivations can bolster your arguments and help you find success with accessibility in a variety of scenarios.

This final email of the Testing Accessibility email course will speak to the people side of accessibility. You should come away from it with a deeper understanding of the purpose for accessibility in digital spaces and how to prevent barriers to access from shipping. You'll learn about accessibility as a legal requirement and how breaking projects down into smaller parts can make it easier to improve access in a larger system. As individuals trying to make a difference with accessibility, small, consistent achievements can add up to big change over time.

Civil rights to access

People with disabilities have a right to access the Internet. Accessibility was part of the initial design and intent of the World Wide Web, according to Tim Berners-Lee: “the power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.” And yet, the current state of accessibility is a "rather dismal picture" according to WebAIM and its project tracking accessibility on the top 1 million websites.

There are legal requirements for accessibility depending on the domain or locale, which people with disabilities often leverage to uphold their rights to access. There have been many website accessibility cases brought to the courts from the US private sector, including Target, Winn-Dixie, and Domino's (which almost reached the Supreme Court!). As a developer, you may work on projects that include accessibility requirements aligned with laws but often not. There is still risk associated with not including accessibility in a project, in addition to it being unethical.

"The carrot vs. the stick"

Building something with accessibility in mind can enable users and lower the chances of legal action being taken when someone encounters a barrier on your website. So why isn't accessibility included in projects? The simplest reason is ableism. But it is also often an issue of education and awareness. Other times, it is an issue of perceived cost on the part of stakeholders. They may not be convinced the investment to design and develop for accessibility is worth it.

To convince people with different mindsets to adopt accessibility, sometimes you have to employ different strategies. By approaching with curiosity, you could learn more about what would motivate someone the most.

Some will respond to a cool factor, like dangling a carrot, because they are inspired and encouraged to do the right thing with more information. "I can make a beautifully-designed component that works with the keyboard and screen readers? COOL!" These personalities are examples of when accessibility education and awareness shared with a spirit of collaboration and humility can accomplish wonderful things. Carrots.

Others less motivated by altruism or innovation for accessibility may require more of a stick approach, such as a legal requirement or financial risk. They may respond to competitive pressure, potential missed sales opportunities, or the cost of design and technical debt. You could stress with them the impact on budgets and timelines to redo a project or defend it in court for accessibility, which are significant.

Communicating business value and risk assessment

For any project aiming for public sector procurement, such as government or education, accessibility is crucial. By investing in accessibility up front through design, development, and documentation, teams can avoid costly rewrites and scrambling later. Market pressure can also have an impact. If your competitor gets sued for inaccessibility, you'll have another reason to include it in your own app. Accessibility that goes beyond compliance to instill it as a core value can make your product more usable and competitive.

There is also the issue of missing revenue from people with disabilities who are excluded from using an inaccessible website or app. Share this with folks concerned with finance: the total after-tax disposable income for working-age people with disabilities in the US is about $490 billion, which is similar to that of other significant market segments, such as African Americans ($501 billion) and Hispanics ($582 billion) according to the American Institutes for Research (AIR).

Estimation and scoping for accessibility

Estimation in software development is hard. It can still play a useful role for accessibility in your projects. By estimating the time necessary to make components accessible from the start, you can quantify what it will cost to deliver quality work on time. You can also compare your up-front estimates to the impact of a total rewrite post-launch: the dreaded "what would it take to make this app accessible?" Because accessibility has to be considered throughout the software development lifecycle, rewrites can inflate budgets into something much more costly than what it would have taken to build it right once.

Enterprise teams recommend padding estimates by up to 30% to give accessibility the time and attention it requires. It's possible your organization could be more lean and efficient at achieving accessibility. However, this could be a good first metric to make sure your project meets expectations with varying accessibility expertise among team members. Aim to underpromise and overdeliver. You can always improve your estimates as an organization over time.

Breaking chunks of work down into smaller tasks and estimating time for each piece can help. Code prototyping can also provide data for how long something might take by evaluating feasibility before committing to a direction. Keep the scope focused on what's relevant even though it can be tempting to want to fix all accessibility issues right away. Your estimates will be more accurate if the work isn't affected by scope creep. Your managers will appreciate keeping on schedule. This is also where the 30% padding can help, to allow time for items that you may not have anticipated.

How WCAG applies to a team process

By including accessibility in your "definition of done", you can surface detailed requirements that teams agree upon and use to hold each other accountable. You don't have to come up with these detailed requirements all on your own, however. The Web Content Accessibility Guidelines, or WCAG, are standardized success criteria for how digital experiences should work for accessibility. This standard is continually updated and evolved to reflect the needs of people with disabilities through decades of industry research and testing. WCAG success criteria can be very helpful for explaining how and why a component should work with the keyboard or a screen reader, or how to make something more readable.

Aiming for compatibility with WCAG in addition to usability testing with people with disabilities can set your projects up nicely for accessibility. WCAG is also the technical foundation of many public legal policies around the world. In the US, for example, Section 508, which requires that the federal government procure and create accessible technology, incorporates WCAG 2.0 success criteria. The European Commission's Web Accessibility Standard and the Accessible Canada Act also mandate that websites and apps meet WCAG requirements. Be sure to check the version required to meet compliance in a specific locale. The most current, stable version as of this writing is still WCAG 2.1, with WCAG 2.2 in public draft.

Modern accessibility testing tools incorporate WCAG success criteria through labels, links, and tags, such as "WCAG 4.1.2" in the Accessibility Insights extension. When collaborating on accessibility with other team members, be sure to validate ruleset and tooling versions to work from the same set of criteria.

You can also export and upload results to JIRA or other bug trackers from many accessibility tools. By making sure to include WCAG violations in your issues, you can tie them back to industry standards. Those standards can be upheld by your organization as part of an accessibility statement and any VPATs (Voluntary Product Accessibility Template, often created for Section 508). By doing this work as you go along, you'll have a better understanding of how accessibility is being met in an application and prevent a scramble when it's time to sell your product to someone who requires accessibility.

Wrapping up this email series

Hopefully as a result of this course, you have plenty of tips for improving accessibility within your world. Remember that disability is the reason for accessibility and work to eliminate barriers to access. It can be overwhelming to tackle everything with accessibility at once, so breaking it down into smaller tasks can help. Approach accessibility with curiosity and humility because there's always more to learn, particularly from people with perspectives different from your own. Collectively, our attention to accessibility will mean we've left the world better than we found it.

I'll leave you with something to think about (and feel free to click here to reply with your answer). How would you persuade your manager to include accessibility in current and upcoming sprints/iterations? If there is a lot of design and/or technical debt to achieve accessibility, what would you prioritize as the most high-impact items to tackle first?

Thanks for reading,
Marcy Sutton