Next week is the 14th annual Global Accessibility Awareness Day (GAAD). This tradition was founded in 2011 with the goal of getting more people to think about and apply web accessibility practices to include users with disabilities.
Though it seems web accessibility is a priority in product development, almost 95% of home pages include WCAG conformance failures, such as low-contrast text or missing alt text, according to WebAIM.
Digital products failing to comply with WCAG standards ostracize users with disabilities. These users can range from a person with low-vision, a person who cannot use a mouse, or even a person who is colorblind. “Inclusive design” has been a buzzword in the tech industry for some time — it’s time to not only talk about this design approach for clout, but to actually do it.

Why is GAAD important?
Have you ever heard any variation of the following two phrases?
- “We just don’t have time to go back and fix the accessibility issues.”
- “The website works for me; I don’t think we have much to worry about.”
Though web accessibility continues to be a “trendy” topic, accessibility failure rates are still high (and disappointing). It is costly to go back and fix accessibility issues like keyboard accessibility or color contrast issues; but without fixing the problems, some users cannot use your website.
As a UX designer who is able-bodied (or doesn’t identify with having a disability), it can be easy to forget about users who don’t use the web the same way. For instance, let’s say you use your mouse to move a Trello card by dragging and dropping it from “Not started” to “In-progress.” A user who can only use their keyboard cannot move the card by dragging and dropping; they must have an alternative way to get the same results.
The traditional design approach doesn’t include users with disabilities, but all designers can change that by fostering an accessibility-first mindset and knowing common (but preventable) issues they should be on the lookout for. Let’s look at the current state of web accessibility, review common accessibility issues, then look at free tools to incorporate into your design practice.
What’s the current state of web accessibility?
WebAIM (Web Accessibility in Mind) published results from their “WebAIM Million” for 2025. The report is a web accessibility audit where one million home pages of top websites are tested for WCAG (Web Content Accessibility Guidelines) compliance.
Almost 95% of the million home pages tested in the report included WCAG conformance failures. To detect these failures, WebAIM used a mix of automated testing with the WAVE API tool in addition to manually testing (it is impossible to catch all accessibility issues with only automated testing).

Though this report shows a slight decrease in the percentage of homepages with accessibility issues from last year (down 1.1%), it also shows a trend that home page’s average complexity increases each year. So as more and more design elements are added to home pages, they become more prone to accessibility issues.
What were the most common accessibility issues found?
96% of the detected accessibility issues fall into 6 buckets. Here are the buckets from most to least common:
- Low-contrast text: 79.1%
- Missing alternative (alt) text for images: 55.5%
- Missing form input labels: 48.2%
- Empty links: 45.4%
- Empty buttons: 29.6%
- Missing document language: 15.8%

Not only were these buckets the prevalent accessibility issues found in the this WebAIM report, they’ve also been the most common for the last 5 years — showing a pattern of not addressing (and continuing to create) the same issues year after year.
What kind of user impact do these accessibility failures cause?
Low-contrast text: If a user with low-vision can’t read faint text, they can’t get the information they need. Any text smaller than 18 PT (or less than 14 PT bold) must have a color contrast ratio of 4.5:1 with its background so more people can read the text.
Missing alt text for images: When an image shows important information, a user who consumes content through a screen reader must be able to get that information in some other form. If an image doesn’t include alternative text (through an alt attribute), the screen reader may only read the image’s file name or nothing at all.
Missing form input labels: Let’s say a user with a screen reader is filling in a webpage’s form. If multiple input fields don’t include a label element to associate the label with the field, the screen reader will only read what the field control is (I.E., “Input” or “Select”); so the user won’t get any context or instructions for what information is requested.
Empty links: Empty links occur when an image is used as a link, but the image doesn’t include alt text. They can also occur if an element including a link is deleted without modifying the HTML. As a screen reader user navigates a web page, the screen reader will tell the user they’ve landed on a link, but the user won’t get context like what the link does.
Empty buttons: Similar to empty links, empty buttons do not describe the function of the button. So when a screen reader user is navigating a web page, the screen reader will announce the button, but the user won’t be made aware of what the button does (I.E., submits a form or logs in). So the user is forced to trigger the button to find out what it does.
Missing document language: When a webpage’s primary language isn’t specified, screen readers may misinterpret the text — hurting users who aren’t native speakers or need translation. A screen reader user may hear mispronounced words or grammar, which blocks their ability to understand the content.
Design to prevent common accessibility issues
It’s actually quite easy to prevent and fix these common accessibility issues. Given the bulk of issues detected were from the 6 buckets discussed previously, digital products could dramatically improve accessibility if they all addressed these problems.
Though some of these issues are caused by how designs were implemented, designers still have responsibility in how they handover designs to their developers.
With the following techniques, designers can proactively create accessible content as well as advocate for accessible implementation with recommendations. After designs have been implemented, designers should QA a testing environment or live product for accessibility issues to flag for remediation ASAP.
Let’s review a designer’s responsibilities and how they can QA for each accessibility bucket.
Low-contrast text
Designer’s responsibilities:
- For images of text and any text smaller than 18 PT (roughly equivalent to 24 PX), make sure the color contrast has a ratio of at least 4.5:1
- For text larger than 18 PT (or 14 PT bold), make sure the color contrast has a ratio of at least 3:1
- The only exceptions to this color requirements are logotypes, inactive/ disabled UI controls, or any pure decorative element (I.E., divider lines)
How to QA websites for low-contrast text:
- Manually check your design’s color using contrast checker tools like WebAIM or with Figma’s native color contrast tool
- Run an automated accessibility testing tool (like Silktide) on your browser-based product to flag color contrast issues that should be double-checked

Missing alt text
Designer’s responsibilities:
- Write recommended alt text for each image used on a web page (under 150 characters)
-
For images, suggest using the alt attribute on the
element
-
For SVGs, suggest giving the SVG role="img"and using a
attribute (I.E., ) - If the image is purely decorative, suggest using a null alt attribute (alt="")
How to QA websites for missing alt text:
- Manually read the alt text for images to ensure it’s descriptive of the image and ensure any decorative images doesn’t have alt text
- Run an automated accessibility testing tool on your browser-based product to flag any image or SVG that doesn’t include alt text, and isn’t marked as decorative