img:is([sizes=auto i],[sizes^="auto," i]){contain-intrinsic-size:3000px 1500px} /*# sourceURL=wp-img-auto-sizes-contain-inline-css */

糖心少女

Skip to content

Keyboard Accessibility: An Essential Part of Inclusive Design

When we talk about digital accessibility, topics like color contrast, meaningful link text, and alt text often come to mind. But an equally critical, yet sometimes overlooked, piece is ensuring that websites and applications are fully usable without a mouse. Many people rely on keyboard navigation due to mobility disabilities, while others simply prefer it for efficiency. Whatever the reason, keyboard accessibility is fundamental to an inclusive digital experience.

Unfortunately, keyboard access can break easily when custom widgets or scripts override native browser behavior.聽That鈥檚聽why every interactive element 鈥 links, buttons, form fields, menus, dialogs 鈥斅爉ust be reachable and operable using the keyboard alone. Equally important is a visible, consistent focus indicator, so users always know where they are on the page.

The good news:聽testing for聽keyboard accessibility is聽relatively聽simple. Try navigating your site using only the Tab,聽Shift+Tab, Enter, and arrow keys. Can you reach and聽operate聽everything? Is focus easy聽to聽see? The answers reveal a lot.

To learn more, including recommended techniques and related , visit the Accessible Technology web page on Keyboard Accessibility.

Additional posts in the Web Accessibility Series:

Web Accessibility Series: Why Properly Marking Up Lists Matters

One of the simplest鈥攁nd most frequently overlooked鈥攚ays to improve web accessibility is to correctly format groups of related objects, or lists. Whether you鈥檙e 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鈥攁nd to find examples from common authoring tools鈥攙isit 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

For people who can鈥檛 see images鈥攕uch as those relying on audible screen readers鈥攁lternative 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 鈥渋mage鈥 and then reads the alt text aloud, making visual content accessible to everyone.

Alt text should be succinct鈥攋ust 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鈥攕uch as text embedded in flyers, graphics, or logos鈥攂ecause 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鈥檛聽require alt text but they do need to be identified as decorative, so screen readers know to skip them.

鈥═别肠丑苍颈辩耻别蝉

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?

Additional Posts in the Web Accessibility Series:

Creating Meaningful Links and Buttons on Websites聽

At the 糖心少女, we鈥檙e committed to designing digital experiences that work for everyone. A key part of that commitment is ensuring that links and buttons鈥攖wo of the most common interactive elements on the web鈥攁re 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鈥檚 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 鈥淐lick here鈥 or 鈥淩ead more,鈥 it鈥檚 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 鈥淗usky Athletics鈥 is the link text:

For more information, see Husky Athletics.

Also, avoid using URLs as link text unless they鈥檙e 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聽

If聽you鈥檝e聽ever run an聽accessibility audit聽and seen an error like:聽鈥ㄢARIA hidden聽element聽must not be focusable or聽contain聽focusable elements,鈥澛犫▂ou鈥檙e seeing one of the most common鈥攁nd confusing鈥攄igital 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鈥攖o act as if it doesn鈥檛 exist in the accessibility tree.

This can sometimes be useful for things like inactive UI components. But it also comes with responsibility: 鈥↖f something 鈥渄oesn鈥檛 exist鈥 to assistive technology, users shouldn鈥檛 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鈥檚聽what can happen:

  • A user can tab into the hidden element.
  • Their screen reader says nothing, because the element is hidden.
  • They don鈥檛 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:

顿辞:听

  • Use HTML hidden or inert attributes, instead of ARIA, for elements that shouldn鈥檛 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.

顿辞苍鈥檛:听

  • 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

  • 滨蹿听颈迟鈥檚听aria-hidden, it should be聽non-interactive.
  • If it鈥檚 interactive, it should not be aria-hidden.

Please note that in the guidance from the WC3, the organization that wrote the ARIA specifications. the 鈥淔irst Rule of ARIA鈥 is that you should use HTML鈥攁nd not use ARIA鈥攚henever possible.

Learn More

For more guidance on using ARIA correctly, check out the 糖心少女鈥檚 accessibility checklist on聽ARIA 鈥 Accessible Technology.聽It鈥檚聽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

This post kicks off an ongoing series on digital accessibility barriers in websites and how to fix them. Each week, we鈥檒l 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鈥攐r as the only way to convey information鈥攊t can become a serious accessibility barrier.

What Is Color Contrast?

Color contrast refers to the difference in brightness between two colors鈥攖ypically 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鈥檛聽perceive those color differences may miss聽important details聽altogether. Someone who is blind聽won鈥檛聽know that 鈥渆rrors 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鈥檙e聽using colors like red, yellow, or green to show status (e.g., progress or alerts), always include聽clear聽text labels. For example:

    • Green check 鈥淥n track鈥
    • Yellow alert sign 鈥淎t risk鈥
    • Red x mark “Off track鈥
  2. Check Font Color Contrast
    Using a new font color?聽Use聽a聽tool聽like聽聽to quickly test readability.
  3. Make Chart and Graph Clear
    Add patterns聽and labels聽when聽you鈥檙e聽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: