Accessibility as a Starting Point, Not a Checklist

Understood.org serves the one in five people who learn and think differently — roughly 70 million people in the U.S. alone. Their challenges span memory, attention, reading, language, and math. The front-end team there has made it their mission to remove barriers for these users, but their commitment extends further: they aim to build products that work for everyone, combining strict accessibility with broader usability principles.

The statistics are sobering. Only 2% of all websites meet the Web Content Accessibility Guidelines (WCAG), the globally recognized minimum bar for digital accessibility. Understood treats WCAG as a floor rather than a ceiling. The standards must be baked into every step of development, not bolted on at the end. Beyond the ethical imperative, there are financial and legal reasons to take this seriously. But for this team, the motivation is simpler: users with ADHD, dyslexia, and other cognitive differences deserve the same frictionless experience as anyone else.

Merging Accessibility with Usability

The team draws a clear distinction between the two concepts. Accessibility means removing barriers to equal access — especially for neurodivergent people. Usability means making products intuitive for everyone, right from the first interaction. A physical analogy: you shouldn’t have to guess whether the door pushes or pulls. The same principle applies to buttons, navigation, and forms on a website.

Many organizations treat accessibility as an afterthought, auditing pages only when a compliance deadline looms. Understood reverses that flow. User research leads the process, informing design decisions before a single line of code is written. That approach is backed by data: Deque Systems reports that 67% of accessibility issues originate in the design phase. When designers get accessibility requirements early, downstream problems shrink dramatically.

The Developer’s Role in the Accessibility Chain

Front-end developers sit at the intersection of design intent and technical execution. At Understood, they act as guardians of consistency — ensuring that graphics, video, audio, and application logic all remain accessible across platforms. Their responsibilities include:

  • Testing features with screen readers during manual QA, refining closed captions, and checking headings, buttons, navigation, lists, and color contrast.
  • Using semantic HTML so screen readers receive meaningful structure and descriptions — avoiding redundant information or misleading image alt text.
  • Ensuring every interactive feature is keyboard accessible.
  • Confirming that dynamic updates, such as form error messages or login confirmations, are announced to assistive technology.

Designers contribute from their own perspective, asking whether color contrast passes WCAG thresholds, font sizes are legible, and layout flow remains clean. They also check light and dark modes for both function and appearance, and verify that all interactions can actually be reached and executed.

How Understood Structures the Work

The development workflow at Understood starts with user research and surveys. Insights from those studies go to designers, who share concepts with product managers. The front-end team then builds or updates the product, and designers provide feedback and request edits. This collaborative cycle means issues surface early, when they are easier to fix.

A two-team review system backs this up. Product managers run QA on every feature and test for accessibility concerns, which means accessibility is checked by two distinct groups. Engineers also work alongside product managers to prioritize tickets, applying realistic timeframes for creation and review. Lessons learned have shown how critical it is to set aside dedicated sprint time for accessibility work — it cannot survive on goodwill alone.

Every engineering ticket includes an Accessibility Audit. Time is assigned within each ticket to address whatever problems the audit reveals. Output from audits is logged page by page in a central database for the mobile app, then converted into Jira tickets with descriptions, screenshots, and story points. When a third-party tool fails accessibility checks, the team collaborates with the vendor to fix it rather than silently working around the issue.

The entire team — front-end, backend, and designers — receives accessibility training from basic through advanced levels. Team members attend conferences each year to track the evolving landscape, and they test with real users who have learning and thinking differences. Theoretical personas are no substitute for human feedback.

Questions That Drive Their Testing

Both disciplines approach accessibility with concrete questions. Developers ask whether sighted and screen reader users experience true parity, whether focus follows the proper order through every interactive element, and whether HTML markup conveys semantics intuitively. Designers ask whether contrast levels pass grace, whether the flow of a page is uncluttered, and whether visual cues match functional reality. Neither group treats accessibility as a separate layer; it is woven into each person’s quality bar.

The approach has produced wins specific to cross-team collaboration:

  • Engineers identified accessibility flaws that designers then resolved with solutions honoring the original visual direction.
  • Designers delivered guidance on color contrast, character counts, and effective typeface selection that made the engineering work faster and cleaner.

Accessibility specialists are increasingly hard to find — job postings with “accessibility” in the title grew 78% in 2021. Understood’s approach highlights why that demand exists. Digital accessibility is an ongoing process, not a destination. The reality is that it requires vigilance on every release, through every design review, and inside every ticket. For teams willing to build it into the core workflow, the payoff is products that work for everyone who encounters them.

Where Accessibility Efforts Most Often Fail

Across the projects we audit, a small set of issues accounts for the overwhelming majority of WCAG 2 failures. WebAIM’s own analysis of the most common errors puts these recurring problems at roughly 96.8% of all accessibility errors. The chart below, prepared by front-end developer Ilknur Eren for freeCodeCamp, gives a quick view of the usual suspects.

WCAG Failure Type% of home pages in 2022% of home pages in 2021% of home pages in 2020% of home pages in 2019
Low contrast text83.9%86.4%86.3%85.3%
Missing alternative text for images55.4%60.6%66.0%68.0%
Empty links50.1%51.3%59.9%58.1%
Missing form input labels46.1%54.4%53.8%52.8%
Empty buttons27.2%26.9%28.7%25.0%
Missing document language22.3%28.9%28.0%33.1%

Automated testing catches many of these cases, but fixing them well requires understanding why they matter in context. The most frequent offenders break down like this.

Missing Alternative Text for Images

The alt attribute is straightforward in principle, but it fails when written without considering the image’s purpose. Screen readers announce whatever is in the attribute; an image with an empty or meaningless alt value becomes an unhelpful “image, image” announcement that solves nothing for a non-sighted user trying to understand, say, how to exit a program. Context matters because algorithms cannot reliably interpret what an image means in a given situation.

<img src="example.png" alt="image"/>

Low-Contrast Text

For three consecutive years, WebAIM’s Million report has found low-contrast text to be the single most common accessibility issue, present on roughly 80% of sites. The fix is not technically demanding: Chrome’s free Lighthouse tool runs a color-contrast check on any page and flags the failing combinations directly.

Missing Form Input Labels

In 2021, half of the sites WebAIM reviewed lacked proper labels on form fields. Search forms are among the most frequent omissions — without a label, screen reader users have no way to know the form’s function. The HTML fix involves a visible label plus a hidden one for screen readers, often implemented in CSS like this:

<label for="searchLabel" class="sr-only">Search</label>
<input type="text" name="search" id="searchLabel>
<input type="submit" value="Search">

.sr-only{
  position:absolute;
  left:-10000px;
  top:auto;
  width:1px;
  height:1px;
  overflow:hidden;
}

Nearly half of the sites WebAIM sampled contained links with no accessible name. A social media icon, for instance, creates an empty link unless it carries a label that a screen reader can announce. Buttons fail for the same reason: a control with no text leaves the user guessing and often leaving the page. Adding text to a link is easy:

<a href="https://www.smashingmagazine.com/facebook-page">
  <i aria-hidden="true"></i>
  <span class="sr-only">Facebook</span>
</a>

.sr-only{
  position:absolute;
  left:-10000px;
  top:auto;
  width:1px;
  height:1px;
  overflow:hidden;
}

For an image inside a button, an alt attribute on that image gives the control a functional name.

<button type="submit">
  <img src="https://www.smashingmagazine.com/search.svg" alt="Search" />
</button>

Missing Document Language

Screen readers rely on the page’s declared language to choose correct pronunciation. Yet between 28% and 33% of homepages have lacked this declaration for the past three years. The remedy is a single attribute on the <html> tag:

<html lang="en">
...
</html>

What the Pattern Tells Us

Accessibility cannot be treated as an afterthought if the aim is equal access for everyone. The recurring errors listed above are not exotic — they are fundamental markup details that get skipped under time pressure. Manual review should be part of any usability pass, with dedicated time set aside for accessibility checks and clear communication with product managers and designers about the requirements. Ongoing technical training, plus interviews and surveys of people who use assistive technology, keeps those requirements grounded in real use rather than assumed behavior.

Further Reading

Smashing Editorial