Category: Web Accessibility

At the University of Washington, we’re committed to designing digital experiences that work for everyone. A key part of that commitment is ensuring that links and buttons—two of the most common interactive elements on the web—are used correctly and convey meaning clearly.
Although they might look similar, links and buttons serve distinct purposes. Links move users to new pages or locations, while buttons trigger an action, such as submitting a form or revealing additional content. Using each element appropriately helps all users, including those using assistive technologies, navigate and interact with confidence.

Why Meaningful Link Text Matters

Meaningful link text allows users to understand where a link will take them, even when it’s read out of context. This is especially important for screen reader users, who may browse by tabbing through links or generating a list of all links on a page.
When every link says “Click here” or “Read more,” it’s impossible to tell what any of them do. Instead, link text should:

• Be unique within the page
• Be meaningful out of context
• Indicate the destination or purpose

Try to always use link text that meets the criteria explained above. Consider the following example:

For more information about Husky Athletics, click here.

A better approach would be to rephrase the sentence so that “Husky Athletics” is the link text:

For more information, see Husky Athletics.

Also, avoid using URLs as link text unless they’re short and easily recognizable, such as uw.edu or washington.edu.

Techniques

The Links and Buttons  page on the Accessible Technology website includes detailed techniques for creating meaningful and accessible links across a variety of contexts, including HTML, Microsoft applications, PDFs, Canvas, and citations.

Want to Learn More?

• Watch for an occasional series of short talks by Alaina Foust and Jeane Marty on accessibility barriers identified by DubBot at the UW Web Council meetings. The next presentation will be at the Thursday, December 4 (9:00-10:00) session.
• Check out UW’s Digital Accessibility calendar to find meetups, Lunch & Learn events, Digital Accessible Liaisons meetings, and more!
• Find self-paced options on our recent blog post Training Options to Build Your Accessibility Skills.
• For more guidance and examples, visit UW Accessible Technology ‘s Links and Buttons web page as well as their Digital Accessibility Checklist. There you’ll find additional resources, tutorials, and best practices to help you design and maintain accessible digital content for everyone.

If you’ve ever run an accessibility audit and seen an error like: 
“ARIA hidden element must not be focusable or contain focusable elements,” 
you’re seeing one of the most common—and confusing—digital accessibility issues.

What ARIA Does

ARIA, or Accessible Rich Internet Applications, is a set of HTML attributes that help assistive technologies (like screen readers) interpret complex or custom user interfaces. One of these attributes, aria-hidden=”true”, tells assistive technology to ignore an element—to act as if it doesn’t exist in the accessibility tree.

This can sometimes be useful for things like inactive UI components. But it also comes with responsibility: 
If something “doesn’t exist” to assistive technology, users shouldn’t be able to tab into it.

Why This Error Matters

When a developer marks something as aria-hidden=”true” but leaves it focusable — say, a button, link, or input — it creates a trap for people who navigate by keyboard or screen reader.

Here’s what can happen:

• A user can tab into the hidden element.
• Their screen reader says nothing, because the element is hidden.
• They don’t know where they are or how to move forward.
• Navigation becomes confusing or even impossible.

Essentially, the user has reached a dead end.

Easy Rules to Follow

To avoid creating these barriers, follow these simple guidelines:

Do: 

• Use HTML hidden or inert attributes, instead of ARIA, for elements that shouldn’t be interacted with.
• Instead of hiding or disabling elements, leave them active and offer clear labels and error messages to help users avoid errors and understand what needs to be fixed when they make them
• Ensure that anything that must be visually hidden is also removed from keyboard focus.

Don’t: 

• Put buttons, links, or inputs inside an element with aria-hidden=”true”.
• Rely on aria-hidden alone to disable content.
• Leave off-screen menus or modals tabbable when closed

A Simple Mental Model

• If it’s aria-hidden, it should be non-interactive.
• If it’s interactive, it should not be aria-hidden.

Please note that in the guidance from the WC3, the organization that wrote the ARIA specifications. the “First Rule of ARIA” is that you should use HTML—and not use ARIA—whenever possible.

Learn More

For more guidance on using ARIA correctly, check out the University of Washington’s accessibility checklist on ARIA – Accessible Technology. It’s a great resource for understanding when (and when not) to use ARIA attributes and how to keep your web content accessible for everyone.

This post kicks off a November series on digital accessibility barriers in websites and how to fix them. Each week, we’ll explore a common issue that can make a website harder to use for people with disabilities and share practical ways to create more inclusive digital experiences.

Color can be a powerful element of design. It can create mood, highlight key information, and guide users’ attention. But when color is used without enough contrast—or as the only way to convey information—it can become a serious accessibility barrier.

What Is Color Contrast?

Color contrast refers to the difference in brightness between two colors—typically between text and its background, or between different visual elements. Good contrast ensures that people with low vision, color blindness, or other visual impairments can read and interact with your content.
For example, light gray text on a white background or blue text on a red background can be nearly unreadable for many users. Even people without diagnosed vision conditions may struggle when viewing low-contrast content on mobile devices or in bright light.

Why It Matters

When color is the only cue used to convey information, users who can’t perceive those color differences may miss important details altogether. Someone who is blind won’t know that “errors are in red.” Someone with color blindness may not be able to distinguish a red line from a green one in a chart.

Low contrast or color-only cues can affect:

• Text readability (e.g., poor contrast between text and background)
• User interface elements (e.g., faint button borders or input fields)
• Charts and graphics (e.g., multiple data lines distinguished only by color)

Inaccessible color use can make websites confusing, inconsistent, or completely unusable for a portion of your audience.

Quick Color Contrast Checks

1. Include Text with Color Indicators
   If you’re using colors like red, yellow, or green to show status (e.g., progress or alerts), always include clear text labels. For example:
   • “On track”
   • “At risk”
   • “Off track”
2. Check Font Color Contrast
   Using a new font color? Use a tool like WebAIM Color Contrast Checker to quickly test readability.
   
3. Make Chart and Graph Clear
   Add patterns and labels when you’re using color. For example:  
   

• • Label pie charts sections
  • Use patterns (like dotted or dashed lines) to differentiate lines and bars

Learn More

• For more general guidance on color contrast and accessibility,  including a list of free tools and techniques, see the UW Accessible Technology page on Color Contrast.
• DubBot Web Accessibility Checker can help you identify contrast issues on your website.
• For specific guidance on accessible color combinations within the UW palette, visit the UW Brand Colors page on Accessibility. You’ll find tools and examples to help you use UW colors in ways that remain vibrant, consistent, and inclusive across all digital platforms.