Base44 Accessibility Checklist 2026 | WCAG 2.1 AA & EAA Compliance

Base44 interfaces make heavy use of icon-only controls -- edit pencils, delete trash cans, close X buttons, kebab menus on table rows. The generated code usually renders the icon inside a button with no text and no aria-label, so a screen reader announces only 'button' with no clue what it does. In a data-table app with several icon buttons per row, the interface becomes unusable without sight.

<button onClick={() => remove(row.id)}>
  <TrashIcon />
</button>

<button onClick={() => remove(row.id)} aria-label={`Delete ${row.name}`}>
  <TrashIcon aria-hidden="true" />
</button>

Generated forms typically show a field's purpose only as gray placeholder text inside the input. The placeholder vanishes the moment a user types, is skipped by some screen readers, and its default styling fails contrast requirements. Users with memory or attention difficulties lose track of what a half-completed form is asking, and screen reader users may hear nothing at all when they land on the field.

<input type="text" placeholder="Company name" />

<label htmlFor="company">Company name</label>
<input id="company" type="text" />

When you ask Base44 for a 'clean, modern' look, it tends to produce light gray secondary text, pastel badge colors, and white text on mid-tone accent buttons. Many of these combinations land below the 4.5:1 ratio WCAG requires for normal text and 3:1 for large text, which makes the app hard to read for low-vision users and anyone outdoors on a phone.

Base44 output often ships with the browser's default focus outline suppressed by the styling framework, or replaced with a subtle ring that is invisible against the app background. Sighted keyboard users -- people with tremors, RSI, or power users -- cannot see where they are on the page, so tabbing through the app becomes guesswork.

Base44 apps are single-page applications: saving a record, filtering a list, or submitting a form updates the screen without a page reload. The generated code almost never wires these updates to ARIA live regions, so a screen reader user clicks 'Save', hears silence, and has no way to know whether the action succeeded, failed validation, or did nothing.

{saved && <div className="toast">Saved!</div>}

<div role="status" aria-live="polite">
  {saved && "Changes saved"}
</div>