Skip to content

Responsibility

Right from the get-go of any project, it's crucial that everything we produce is user-friendly - from the interfaces we design to the content we generate, and the overall experience we create for users. By ensuring accessibility from the outset, we can sidestep the need for extensive rework later down the line. This principle holds true for every member of the team, regardless of their role or expertise in the project's lifecycle.

Who is responsible

Managers and our product owners should make sure that accessibility is part of the “house rules” and allocate resources to make it happen. The scenarios and specifics described below are general guidelines but the information is still valid. Your experience may vary.

The team of UX designers are responsible for conducting user research and usability testing that includes people with disabilities. We need to ensure that their needs are equally reflected in the work we put out. This includes:

  • The user & business needs assessment
  • The information architectures
  • The wireframes
  • The interaction designs
  • The mockups for the prototypes
  • The design system
  • Anything else you put out. It all needs to be designed for accessibility.

The content writers and editors are responsible for producing an accessible content strategy and accessible content structure. They also need to make sure their writing is accessible by doing things like writing to a certain grade level, using readability best practices, and writing alternative text (or “alt text”) that correctly convey the information provided to sighted people by non-text content, like photos or infographics.

Alt Text

Issues with alt text (missing alt text, or poorly written alt text that's not helpful) is one of the biggest problems on the internet. WebAIM provides a really good article on what to do.

Developers on the team (or working with our team) are responsible for semantic coding using accessibility best practices. In particular they must comply with the latest version of the WCAG Level AA in all the code they write. (The same design can be marked up to be completely accessible or completely inaccessible, depending on the developer's knowledge of and compliance with accessible patterns, methods and solutions.) Also, they need to regularly run accessibility checks, as they are developing the digital product and through its release.

There may be other people on the team with other roles, and they too are responsible for:

  • Doing their part of the process with accessibility in mind.
  • Following the accessibility guidelines and best practices.
  • Making sure their accessibility efforts are in sync with the rest of the teams, so that it all comes together as a cohesive, well-communicated, accessibility effort.

When accessibility is a default part of our team's standard process, then we won't forget or accidentally exclude it.

More information

The W3C community has provided the 61 Success Criteria found in WCAG 2.0 into smaller checklists, one for each team member/stakeholder: Accessibility Responsibility Breakdown

The Australian Broadcasting Commission has a PDF poster that outlines some team members' accessibility responsibilities: Accessibility: Tips for Teams. (pdf)

Accessibility intersects with concepts like inclusion, universal design, and addressing the digital divide. These broader concerns encompass various challenges faced by users, including geographic location, economic background, education level, language, age, gender, and more - disability being just one aspect.

However, accessibility has a sharper focus: ensuring people with disabilities can access and use digital products effectively. The accessibility movement prioritizes the needs of this community, encompassing both recognized and non-diagnosed disabilities.

Interestingly, efforts towards accessibility often benefit not just people with disabilities but also those facing other barriers mentioned earlier. This connection to broader inclusion efforts strengthens the case for accessibility, even while maintaining its core focus on individuals with disabilities.

Building a Strong Business Case for Accessibility

In today's digital landscape, accessibility is no longer just the right thing to do - it's a smart business decision. Here are a few compelling reasons why:

Minimize Legal Risk: Lawsuits against inaccessible websites and digital products are on the rise. WCAG compliance helps mitigate this risk by demonstrating a commitment to accessibility standards.

Reputation Matters: Consumers are increasingly aware of and supportive of brands that prioritize inclusivity. Demonstrating a dedication to accessibility through user-friendly design builds brand loyalty and strengthens your reputation for social responsibility.

Expanding Your Market Reach: The global disability community represents a significant market segment often overlooked. Studies by the Pew Research Center estimate that one in five adults in the US has a disability, translating to a potential market share in the trillions of dollars. By making your products and services accessible, you tap into this vast and growing market.

SEO Benefits: Search engines like Google prioritize websites that are well-structured and follow best practices. Accessible websites often adhere to these principles, potentially improving your search engine ranking and driving organic traffic.

Enhanced User Experience for Everyone: Accessibility features like clear navigation, captions on videos, and proper keyboard functionality benefit all users, not just those with disabilities. This focus on usability leads to a more positive user experience for everyone, potentially increasing customer satisfaction and loyalty.

Investing in accessibility is an investment in your brand, your legal standing, and your overall market reach. By creating inclusive digital experiences, you open doors to a wider audience, strengthen your reputation, and ultimately, build a stronger business.

Back to top