Skip to content
Accessibility at the UW

Category: Web Accessibility

Web Accessibility Series: Why Properly Marking Up Lists Matters

Post categories: Web Accessibility

One of the simplest—and most frequently overlooked—ways to improve web accessibility is to correctly format groups of related objects, or lists. Whether you’re creating a web page, a Canvas module, or a digital document, if the content represents a collection of related items, it should be built using the list tools provided in your editor.

This small step has a big impact. When lists are explicitly defined, screen readers can announce that a list is present and tell users how many items it contains. This helps people who are using assistive technology quickly understand the structure of the page. It also enables efficient navigation, allowing users to jump between items with a single keystroke.

In HTML, this means using semantic list elements such as <ul> for unordered lists, <ol> for ordered lists, and occasionally <dl> for definition lists. In authoring tools like WordPress, Drupal, Canvas, Microsoft Word, and Google Docs, these features appear as toolbar buttons for bulleted, numbered, or multilevel lists. Using them improves consistency, clarity, and accessibility.

To learn more—and to find examples from common authoring tools—visit the Lists web page on the Accessible Technology website.

Want to Learn More?

Additional posts in the Web Accessibility Series:

Why Alt Text Matters for Web Accessibility

Post categories: Accessible documents Web Accessibility

For people who can’t see images—such as those relying on audible screen readers—alternative text, or alt text, is essential. Alt text provides a brief, meaningful description that communicates the purpose of an image. When a screen reader encounters an image, it typically announces “image” and then reads the alt text aloud, making visual content accessible to everyone.

Alt text should be succinct—just enough to convey the core idea without overwhelming the user. Simple images like photos or logos need alt text, and most authoring tools make it easy to add. Complex images, such as charts or diagrams, often require more detailed explanations than alt text alone can provide. In these cases, include a longer description elsewhere on the page so users can fully understand the information.

Avoid using images of text—such as text embedded in flyers, graphics, or logos—because they create significant barriers. Images of text cannot be read by assistive technologies, often display poorly on mobile devices, and become blurry when users with low vision zoom in or enlarge them. High-quality text remains crisp and customizable; images of text do not.

Decorative images such as icons don’t require alt text but they do need to be identified as decorative, so screen readers know to skip them.


Techniques

The Images web page on the Accessible Technology website includes detailed techniques for creating meaningful and accessible links across a variety of contexts, including HTML, Canvas, WordPress, Drupal, and Microsoft and Google applications.

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 UW Web Council meetings. The next presentation will be on 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 Images web page as well as their Digital Accessibility Checklist, where you’ll find additional resources, tutorials, and best practices to help you design and maintain accessible digital content for everyone.

Additional Posts in the Web Accessibility Series:

Creating Meaningful Links and Buttons on Websites 

Post categories: 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?

Additional Posts in the Web Accessibility Series:

Understanding ARIA Hidden Elements and Accessibility Barriers 

Post categories: Web Accessibility

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.

Additional Posts in the Web Accessibility Series:

Color Contrast: Why It Matters for Web Accessibility

Post categories: Web Accessibility

This post kicks off an ongoing 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:

    • Green check “On track”
    • Yellow alert sign “At risk”
    • Red x mark “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

Additional posts in the Web Accessibility Series: