What is Accessibility-First Web Design?
Jan 20, 2025 • 5 Minute Read • Ari Moros, Senior Visual Designer

The idea of making a site accessible is not something new. What's new and what we have been seeing over the past several months is how designers and experience architects are approaching the story they are trying to tell with their designs. The more the experience team understands about the technicalities of ADA standards, the more approachable, semantic and accessible your site will be which, in turn, will provide more unique visits, a greater experience on mobile and polished SEO practices. These are just some of the things that inherently improve when implementing accessibility standards.
The Web Content Accessibility Guidelines (WCAG) were created by the non-profit World Wide Web Consortium (W3C). WCAG consists of a series of guidelines for making web content accessible. WCAG 1.0 was introduced in 1999, and has since been superseded by WCAG 2.0, published in 2008. The latest release is version 2.1 which was made official on June 5th, 2018. WCAG 2.1 mostly focuses on mobile technology, accessibility for people with low vision, and people with cognitive disabilities.
WCAG comes in three levels: A, AA and AAA; where A is the weakest and AAA the strongest. Level A conformity has a minimal impact but also minimal effect. It allows browser readers to more effectively navigate a site, but it doesn’t make a site compliant to the level the Department of Justice wants to see. The happy medium – and the one to keep on your radar is level AA. Level AA is not so light as to leave a large number of folks with disabilities behind, and not so restrictive as to greatly affect your site’s look, feel and functionality.
To summarize the different levels:
When implementing accessibility standards, a large effort is put on the front end engineers to make sure they understand the rules and to know how to implement them within any given context. For example, a modal window. You see them everywhere on sites and you might think it's a simple component. When surrounding the modal with accessibility guidelines, it becomes a bit more complicated. For instance, if someone is visually impaired, you have to ask yourself these questions:
There are many attributes and pieces of code we will write in order to tell a screen reader what is happening on every move a user is making and, most importantly, what context they are in - whether it's a modal, piece of text, headline, button, etc...
Quality assurance is imperative when a site is implemented with WCAG 2.1 standards. Outlined below are three stages of testing that we do to ensure your site is meeting the WCAG guidelines that are required.
There are multiple tools that can be used to rake your page and give you a bug count as well as an accessibility grade. Some tools will also provide suggestions on how you can fix the issues it finds. Since dynamic content is a big part of a CMS, it’s important for the tool you choose to be able to run on a regular basis and provide reports in case someone enters some non-compliant content. Any problems should be fixed immediately to avoid any potential legal issues.
Visually impaired customers will come to your site and expect to have the same experience as anyone else. These customers need to be able to navigate through the site with ease and never question where they might be in a multi-step process, a form, primary navigation, etc. We use industry standard screen readers to ensure that we can mock the way disabled customers might navigate your site and check that everything makes sense.
Manual testing is equally as important as non-visual testing. We follow a very specific matrix when testing pages manually.
A few examples might be: