Standard Accessibility Features

Client-First
1

I was wondering what Finsweet includes as standard in their builds when it comes to accessibility.

In their 2022 review of web accessibility litigation, Accessibility.com found a 143% year-over-year increase in the number of companies that received multiple lawsuits. The report also predicts a 200% increase in 2023.
source

The WCAG (Web Content Accessibility Guidelines) on w3.org has 3 levels of compliance - A, AA and AAA.
There are 30 pre-requisites to comply for just level A, their lowest tier of compliance.
source

A lot of these rules demand a large increase in dev time for something most clients wont notice or care about even though it’s important. It also adds a lot of added stress and complexity to every project.

From what I can tell from developer forums, developers find the WCAG standards inaccessible to read and understand, in large part to the lack of concrete visual examples. The general advice is to not chase perfection but give an honest try to make the website more accessible.
example

The Client-First docs mention various accessibility features such as browser zoom, text zoom, aria-labels for screen reader support, focusability, html semantics, visually-hidden elements and keyboard navigation. This is a lot of accessibility features but its not exhaustive of every requirement for WCAG.

I know that every client and every build is different, but is what is described in the client first docs everything Finsweet includes as standard when developing websites for clients?

As this does not include everything for WCAG compliance, do Finsweet’s clients have to sign an indemnification clause for accessibility? Is there time put aside to explain accessibility to clients?

Any insight here would be a huge help, thanks a lot!

2

Hey Rory, great question.

We do not have any formal implementation process for accessibility for client projects. We follow strict accessibility standards when our clients ask us to. Our team is familiar with accessibility through Finsweet’s tools and content supporting it. However, not every developer on our team is an expert.

Why don’t we make every project fully accessible by default?

Following all of the rules of accessibility is challenging and very time consuming. Some clients want to pay for that extra time and knowledge. Some clients do not. As much as we want to implement highly accessible sites for every project, we can not operate our business at a loss.

We are always ready to build a site that follows strict accessibility standards, but only when the client is able to pay for the time it takes to do it. We will suggest the accessibility service to any lead/client whose project qualifies. Most clients who ask about accessibility are required to follow accessibility best practices. In this case, these clients are very open and forward about getting our top developers implement a fully accessible project.

3

Hey Joe, thanks so much for taking the time to answer!

This makes a lot of sense. Building more time-efficiently on most projects, but having the resources ready to implement full accessibility features if the client requires it and is willing to pay more for the additional dev time.

How would you decide which projects qualify?
Do you not bring up accessibility at all for the clients you don’t think qualify?