Practical tips to proactively manage the accessibility debt

The accessibility debt

Every digital service has accessibility issues during the development process, most also during production. Accessibility debt is the sum of the work that has to be done to fix all accessibility issues. The debt is not merely a sum of the issues, because issues vary in the amount of effort it takes to fix them. Some issues can easily be fixed, like adding a markup attribute or modifying its value. Other issues require large effort and sometimes multiple stakeholders to decide on the solution, like a major redesign of user flows and pages, a complete code refactor for UI components, or a change of brand colors. Obviously, issues also vary in their impact on users, but that’s a topic for another post.

Having zero accessibility debt is difficult, more so when digital services grow larger and more interactive. But reducing the debt to a manageable effort can be easily achieved. 

Tips to manage the accessibility debt

Minimizing the accessibility debt starts by having awareness of accessibility right from the outset of a project and deliberately throughout the entire development process and product life cycle. The accessibility awareness can come in different flavors, depending on the project and team settings. Based on our experience with the implementation of accessibility and its remediation effort, following are practical tips to get you started with.

Commit to accessibility

At the minimum, set accessibility goals and assign a person responsible for achieving the goals. The scope of accessibility is big and uncharted for most people, so can be intimidating for starters. Hence, it is recommended to focus on progress over perfection. Make sure you set achievable goals based on the knowledge and skills of the team. Check some examples of accessibility goals to start with and how to achieve them. Using the goals in the Definition of Done further reinforce the commitment. 

An accessibility champion ensures there is a systematic awareness to the implementation and verification of accessibility. This does not mean all is done by one person. Rather, this person commonly plans, coordinates, and guides the accessibility effort towards achieving the goals. They can also do it as a secondary role alongside their main role. The champion is not necessarily an accessibility expert, but needs to have a willingness to learn and share.

Use an accessible color palette

Companies can have a shorter or longer history and so are their brand colors. Some companies selected their colors way before there was global awareness of accessibility, while some newer companies may not consider accessibility when selecting. Either way, we often observe color combinations that don’t have sufficient contrast based on the Web Content Accessibility Guidelines (WCAG) Success Criterion 1.4.3: Contrast (Minimum). Since the colors are an important part of the company’s brand identity and used on all of its outlets, resolving the contrast issue often requires multiple stakeholders and time.

So start early by understanding the accessibility state of your color palette. Use a tool like Contrast Grid to get a quick overview of the color combinations that meet WCAG minimum requirements. If some combinations have insufficient contrast, consider using a darker or lighter color. WebAIM's Contrast Checker allows you to easily play with the brightness to find a suitable color. And Polypane’s Color contrast checker automatically suggests alternative colors that meet contrast requirements.

Define clear structure for content and functionality

The way the content and its functionality are structured is commonly known as information architecture (IA). It aims to help people easily find the information they are looking for or accomplish a task. IA issues are commonly basic usability problems that affect all people, let alone those with specific needs. Examples of issues include an inconsistent navigation system, multi-purpose pages, and illogical user flow for achieving a task. The sooner these issues are tackled, the less effort is needed to fix them, since they affect a large part of the service. So the accessibility debt can also incur interest the longer fixing such issues is postponed.

Start by defining a clear content structure and user flows for tasks, for instance:

• Create a sitemap - it helps to understand the organization of pages or views, the relationships between them, and creating a logical navigation system.
• Use single-purpose pages - it’s easier for people to understand the content structure and find what they’re looking for.
• Use templates for pages or views - it promotes consistency of the content structure and functionality, and also saves development effort.
• Follow conventional user flows and UI patterns - there’s no need to reinvent the wheel for common tasks. For more complex tasks, provide clear guidelines.

Implement semantic markup

A clear structure for content and functionality becomes accessible only when implemented with semantically correct markup. Semantic markup conveys the meaning of content elements to other systems, such as screen readers and search engines. It’s the core of accessible web, and thus, the source for most of the accessibility debt. In particular, unawareness to the markup of structural and functional interactive elements can result in a large renovation effort, since these elements are used throughout the whole service. 

Ensure the following elements are correctly marked-up:

• Page landmark regions - check the W3 guidelines on the markup of page regions and the labeling of regions.
• Headings - follow the W3 guidelines on the markup of headings. Use a tool like h123 Show Headings bookmarklet to quickly get an outline of the page headings and their structure.
• Other content structure elements like sections, lists, images, and tables – check the W3 guidelines on the markup of content structure elements.
• Interactive components like buttons, form controls, tabs, and accordion – if you use an external UI component library, select one that is tested for accessibility. If you develop your own components, follow the W3 guidelines and implementation examples for common UI patterns.

Test for accessibility

Last, test the accessibility of your digital service. Start early in the development process and test every new update to the UI. This way you prevent a larger debt at the end of a sprint, let alone at the end of a project. For web solutions, test on different screen sizes. If you followed the other tips, the testing and possible fixing of issues should be a small effort.

Start with cost-efficient testing using automated testing tools and manual testing with a keyboard. This will not guarantee full compliance with accessibility requirements, but will detect most common issues.

• Automated testing
  • Code linter - for example axe Accessibility Linter
  • Browser checker - for example axe DevTools (Chrome, Firefox, Edge) or Accessibility Insights (Chrome, Edge)
• Manual keyboard testing - follow WebAIM’s guidelines on testing keyboard accessibility or use Accessibility insights assisted keyboard testing walkthrough

Next steps

Once you integrate these measures into your project, raise the accessibility bar to address more potential issues. Get familiar with the digital barriers people with disabilities face, the tools and techniques they use to interact with technology. For instance, testing with a screen reader and screen zooming can help find barriers for people with visual disabilities, and ensuring accessibility of multimedia content would be helpful for people with auditory impairments.

Don’t dig yourself a big accessibility hole. Every project is an opportunity to make progress. Start applying these measures today to significantly save efforts and costs later on. 

Reach out if you want to hear more about accessibility and how Vincit can help out!