Forem: patrick clancey

Unlocking Hidden Content: An Introduction to hidden='until-found'

patrick clancey — Wed, 10 Sep 2025 11:00:36 +0000

The value 'until-found' for the hidden HTML attribute is supported by Chrome and Firefox at the time of writing. Also, support has been added to Safari TP and is expected to land this year.

Before we look at the 'until-found' value specifically, let's quickly recap what the hidden attribute does when it's added to an HTML element. This attribute tells the browser that the element's contents are not currently relevant and should not be presented to the user. Commonly, the browser will then apply the CSS style display: none, totally hiding the element. In contrast, when hidden='until-found' is applied, this tells the browser that the contents are relevant, but should not be visible initially. Despite being visually hidden, its content remains discoverable by the browser (although not in the DOM and not in the accessibility tree). So, the browser's "Find in Page" and deep linking functionality will still work.

<div hidden>
 <p>Hello, I'm totally hidden and cannot be found.</p>
</div>
<div hidden="until-found">
 <p>Hello, I'm invisible, but can still be found!</p>
</div>

When a user searches for and finds text within such an element, the browser automatically reveals it and scrolls it into view. This feature improves initial page load times by deferring content rendering while maintaining a seamless search experience. It's ideal for progressively disclosing content like collapsible sections that users might search for.

In a nutshell, content within an element that has the hidden attribute (or CSS display: none) will not be found by the browser and cannot be deep linked to. Whereas content within an element with hidden='until-found' is discoverable and can be linked to.

Interactive Components

Hidden content is a fundamental feature of interactive components such as accordions, carousels, and tabbed interfaces. These popular UI patterns offer several advantages including:

Space Optimisation: Simply stacking all content vertically can lead to extremely long, overwhelming pages that require excessive scrolling, making them hard to navigate and boring. These components allow you to condense content by showing only a portion of it at a time.
Well-Structured Content: Monolithic blocks of text or images can be difficult for users to scan, understand, and navigate. Key information might get lost. Grouping related information into a collapsible section helps provide a clear, logical structure for content, making it easier for users to find what they're looking for.
Enhanced User Experience: Long, static pages can be boring and increase cognitive load, which can lead to user fatigue or abandonment. Interactive components and progressive disclosure make the page feel more dynamic, less daunting, and quite frankly, more 'fun'.
Aesthetic Appeal: These components contribute to a cleaner aesthetic. They can make a page look less cluttered and more professional.

The Problem

Let's take a look at what problems hidden='until-found' solves.

Despite the benefits of interactive components, traditional hidden content presents a significant accessibility challenge, it's simply not discoverable by browsers.

This invisibility creates a disproportionate burden for several user groups. For example, visually impaired users, who often rely on screen readers and the browser's "Find in Page" functionality, are particularly affected.

Similarly, users with motor control issues face additional obstacles when navigating interactive components that hide content.

When content is hidden using conventional methods, search functions cannot locate relevant information severely limiting these users' ability to find what they need.

These limitations create a fundamental tension: the very components designed to improve user experience for some can simultaneously erect barriers for others. This is precisely the problem that hidden='until-found' was designed to solve.

Implementation Example

In the following tabbed component example, which is implemented using hidden='until-found', we can see how content becomes both searchable and linkable.

Developer notes

In the above example, instead of using a classname (commonly using the CSS display: none property), we are using the hidden='until-found' attribute. When content is 'found' by the browser, it dispatches a JavaScript event called beforematch, and the content is shown. In the case of a tab component, we can't have two tabs visible at the same time, so we listen for the beforematch event, and when it fires, we need to manually hide whichever tab is not required.

There is one obvious difference between hidden and hidden='until-found' any block-level styles on the element like border or padding won't be visible when the hidden attribute is used, but WILL be when hidden='until-found' is applied. This is because the browser will typically only hide the element's contents and not the element itself. Not a big deal, but still something to bear in mind if you are going to be working with an existing codebase.

WCAG: Empty Links

patrick clancey — Thu, 17 Apr 2025 11:40:53 +0000

The European Union has implemented new accessibility regulations with a compliance deadline of June 28th, 2025. Many companies are proactively taking steps to meet these standards to avoid penalties and ensure their digital platforms are accessible to all users.

Introduction

The European Accessibility Act (EAA) - Directive 2019/882, which establishes a comprehensive set of accessibility rules for digital offerings within the EU market, is going to come into effect next year. The deadline for compliance with this new legislation is June 28th, 2025. WCAG 2 Level AA is widely recognised as a benchmark for achieving EAA compliance.

With this in mind, I'm taking a look at some of the most common accessibility issues according to The WebAIM 2024 report on the accessibility of the top 1,000,000 home pages, who they affect, and how to fix them.

In this post, I'll explore empty links — their impact, who they affect, and how to fix them.

Why empty links matter

Firstly, let's take a quick look at a couple of fairly typical examples.

<!-- Links with graphics with no alt -->
<a href="/Canine_hip_dysplasia">
   <img src="/doberman.png">
</a>
<!-- Links icons content with no text content -->
<a href="https://bsky.app/">
   <i class="icon icon--bluesky"></i>
</a>

Links containing icons, images without alt text or simply empty lead to confusion for users of assistive technologies. WebAIM 2024 report on the accessibility of the top 1,000,000 home pages found that almost half of the pages tested contained empty links (or buttons).

The lack of any text label on these controls means that assistive technologies can't determine where links go.

To add an accessible text to the link there are a couple of options

<!-- use alt text -->
<a href="/Canine_hip_dysplasia">
   <img alt="Canine hip dysplasia" src="/doberman.png" ...>
</a>

<!-- use an aria label -->
<a href="https://bsky.app/" aria-label="Bluesky">
   <i class="icon icon--bluesky"></i>
</a>

<!-- use a visually hidden text -->
<a href="https://bsky.app/">
   <i aria-hidden="true" class="icon icon--bluesky"></i>
   <span class="visually-hidden">Bluesky</span>
</a>

(for visually-hidden example see bootstrap visually-hidden helper)

Who is impacted by missing link text?

Missing link text creates significant barriers for several groups of web users.

For example; it affects people who are blind or have severe visual impairments who rely on screen readers. When these users encounter a link without text, their screen reader simply announces "link" without any context about where it leads.

Voice control users, such as people with motor disabilities or temporary injuries, also struggle significantly. They need to be able to say the name of a link to click it, but they can't activate a link that has no name.

Users with cognitive disabilities also find unnamed links particularly challenging. They need clear, consistent navigation to make sense of websites, and unlabelled links create unnecessary mental work.

Related WCAG guidelines

Other related issue

Alt text doesn't describe the link target

<!-- 
    A link with graphic where the alt describes 
    the image not the link target 
-->
<a href="/Canine_hip_dysplasia">
   <img alt="Doberman dog asleep in a wicker basket" ...>
</a>

In this case, the alt text should describe the link target not the image itself. e.g.

<a href="/Canine_hip_dysplasia">
   <img alt="Canine hip dysplasia" ...>
</a>

Duplicate adjacent links

<!-- 
    A link which duplicates an adjacent link, 
    for example so users navigating with a 
    pointer can click on the image 
-->
<a href="/Canine_hip_dysplasia">
   <img alt="Canine hip dysplasia" ...>
</a>
<a href="/Canine_hip_dysplasia">
   Canine hip dysplasia
</a>

In this case the links should be combined so there is only one link. And the image should not have an alt value.

<a href="/Canine_hip_dysplasia">
   <img alt="" ...>
   Canine hip dysplasia
</a>

In some rare cases, where you are providing links for pointer users and you can't combine the links, you may have to resort to removing the duplicate form the accessibility tree.

<a href="/Canine_hip_dysplasia" 
    tabindex="-1" 
    aria-hidden="true">
   <img alt="" ...>
</a>
<a href="/Canine_hip_dysplasia">
   Canine hip dysplasia
</a>

With this technique pointer users can click on the image and keyboard users don't have to tab though duplicate links.

Links out of context

Links that lack context e.g. "Read more".

<p>
  Canine hip dysplasia is one of the most 
  common musculoskeletal conditions that 
  affect our canine companions
</p>
<p>
  <a href="/Canine_hip_dysplasia">
   Read more
  </a>
</p>

To add context we can use visually hidden text or aria-label. For example;

<p>
  Canine hip dysplasia is one of the most 
  common musculoskeletal conditions that 
  affect our canine companions
</p>
<p>
  <a href="/Canine_hip_dysplasia" 
    aria-label="Canine hip dysplasia. Read more">
    Read more
  </a>
</p>

Adding context is important for screen reader users as they often navigate by listing all the links on a page. If all they hear is "read more, read more, read more," they have no idea where each link leads. They lack the visual context that sighted users have.

Conclusion

All links having accessible text ensures everyone, including screen reader users and those with cognitive disabilities, can understand the link's purpose and destination, leading to improved navigation and a better user experience.

Providing accessible link text is generally easy and often only requires small coding change, using ARIA attributes or visually hidden text when the visual text isn't sufficient. It's a fundamental accessibility practice that significantly enhances website usability for many users with minimal effort.

Tip

To see how a link will be announced by screen readers open your browsers devtools panel, highlight the link you want to inspect, open the accessibility tab and look for the value in the "Name" section.

WCAG: Alternative Text for Images

patrick clancey — Wed, 16 Oct 2024 13:04:34 +0000

Introduction

In this post, I'll be looking at the image alternative (alt) text, why it's important, who it affects, and how to fix it.

Why alt text matters

Alt text plays a crucial role in making the web more inclusive for all users, especially those who are visually impaired. It’s not just about filling out an attribute in your HTML code; it’s about ensuring every user can experience the full content of your site, regardless of their ability to see the images.

Who is impacted by missing or poor alt text?

The absence of alt text, or poorly written alt text, impacts several user groups, including:

Screen Reader Users: Screen readers rely on alt text to interpret and vocalise the content of an image. Without alt text, users won’t know what the image represents, missing out on essential information.
Users with Cognitive Disabilities: Descriptive alt text helps users with cognitive disabilities better understand the context of the image within the webpage.
Low Bandwidth Users: Alt text can be beneficial for users with slow internet connections, as it provides a text-based description of an image when it fails to load.
Search engines: Search engines use the alt text to understand what an image represents. Proper alt text helps improve your website's search rankings.

By omitting alt text on images that convey meaning, you risk creating a frustrating and exclusionary experience for these users.

WCAG alt text guidelines

The WCAG provides clear guidelines to ensure alt text is used effectively. Below are some key criteria that must be followed to meet accessibility standards:

WCAG 1.1.1: Non-text Content (Level A) All non-text content, including images, must have an alt text description unless the image is purely decorative.
WCAG 2.4.4: Link Purpose (In Context) (Level A) When an image is used as a link, the alt text should describe the link’s purpose, not just the image.
WCAG 2.5.3: Label in Name (Level A) Any image used as a control (e.g., buttons) must have alt text that matches the label presented to users.

WCAG offer clear standards for implementing alt text, primarily under WCAG 1.1.1: Non-text Content. This criterion ensures that all non-text content, including images, has a text alternative. Here are some key principles to follow:

For images that convey important information, provide descriptive alt text.
For decorative images that don’t add meaningful content, use empty alt attributes (<img alt="" ... or just <img alt ...), so screen readers skip over them.
Avoid redundancy: Don’t include phrases like "image of" or "photo of" in your alt text—this is implied.
Avoid duplication: Don't duplicate adjacent text

The alt attribute is non-negotiable for accessibility

Every <img> tag must include an alt attribute, without exception. While the attribute doesn't always require a value—decorative images should use an empty alt —the attribute itself is mandatory. Failing to provide an alt attribute results in a critical accessibility issue, as screen readers will announce a graphic and some will then read the image’s file path (src) or file name, which offers no meaningful information to users.

Identifying Decorative Images: When to use an empty alt attribute

Not all images on a webpage serve a functional or informative purpose. Some images are purely decorative, added for visual appeal without contributing meaningful content to the page. For these images, you should include an empty alt attribute, which tells screen readers to ignore the image, allowing users to focus on the content that matters. For help see the WAI images decision tree

How to write effective alt text

When writing alt text, it’s essential to consider the purpose of the image and its context within the page. Here are a few best practices:

Be concise but descriptive: Summarise the content of the image in a brief, meaningful way.

<!-- DON'T DO THIS -->
<img src="accounts.jpg" alt="accounts">

<!-- DO THIS INSTEAD -->
<img src="accounts.jpg" 
    alt="Our company accounts team posing in front of the Berlin office">

Include relevant information: If an image conveys complex information (e.g., a chart or diagram), summarise the key insights it provides.

<img src="sales_chart.png" alt="Line graph showing a 25% increase in sales over the last quarter">

Leave alt text empty for decorative images: If an image is purely decorative and does not convey important information, use an empty alt attribute.

<img src="border.png" alt="">

Testing alt text for accessibility

Verifying the presence and quality of alt text can be done both manually and through automated testing:

Manual Testing: Try navigating your website with images disabled or better still with a screen reader and observe how well the alt text conveys the image content.
Automated Tools: Tools like Axe DevTools, WAVE, or Lighthouse can automatically flag images without alt text or those with potentially problematic alt descriptions.

Alt text for complex images

Sometimes, images are more complex and can't be fully described in a short piece of text. For these cases, consider linking to a detailed description:

<img src="graph.png" alt="Graph showing Q3 earnings. Full description below">
<a href="#full-description">Read full description of the graph</a>
...
<div>
  <a id="full-description"></a>
  Detailed description of the Q3 earnings here...
</div>

Note: the longdesc attribute is no longer recommended and shouldn't be used.

Video content: Accessibility considerations

Under WCAG 1.1.1: Non-text Content, videos are also non-text elements and must be made accessible, just like images. Videos can be informative, decorative, or both, but they must be handled properly to ensure that all users can engage with their content. Video accessibility is out of scope of this post. But for more information on this topic see Making Audio and Video Media Accessible

Conclusion

Alt text is a small but essential part of creating accessible and inclusive websites. By following WCAG guidelines and best practices, you can ensure that users relying on screen readers, users with cognitive disabilities, and those with poor connectivity can still fully engage with your content. In addition to fulfilling the legal requirements of the upcoming EAA, providing thoughtful and well-written alt text makes your website more usable and welcoming to everyone.

WCAG: The Unseen Impact of Missing Labels

patrick clancey — Tue, 27 Aug 2024 06:18:03 +0000

Introduction

In this post, I'll be looking at the missing label, why it's important, who it affects, and how to fix it.

Missing Labels on HTML Forms: A Recipe for Confusion and Exclusion

HTML forms without proper labels can be quite challenging for many users. It may seem like a minor mishap to omit these labels, but in reality, it becomes a major accessibility hurdle for diverse user groups. This lack of direction leads to confusion and frustration, making it difficult for users to interact effectively with the website or application.

Who is Impacted by Missing Form Labels?

Missing form labels impact a large number of users. Here's why:

Screen reader users: Screen readers rely on labels to identify form fields and provide context. Without labels, users are left guessing what information to input or even what a button does.
Users with cognitive disabilities: Clear labels are crucial for users who may have difficulty understanding complex instructions or remembering information.
Users with motor disabilities: Some people can take advantage of speech recognition software that translates the user's spoken words into language that the computer can understand. Having visible labels which are programatically linked with the relevant form elements is critical for the software to link the users commands with the correct input field.
Users with low vision: Labels must have sufficient contrast and be easily distinguishable from the surrounding content and positioned close to their respective input fields for easy association.

The Importance of Labels: More Than Just Words

Labels serve as vital signposts in the user's journey through a form. They:

Provide context: Labels tell users what information is being requested in each field.
Guide interaction: They clarify the purpose of each field and how to interact with it.
Improve comprehension: Clear labels make forms easier to understand and complete accurately.
Enhance accessibility: Properly implemented labels are crucial for users who rely on assistive technologies.

WCAG Guidelines for Form Labels

The Web Content Accessibility Guidelines (WCAG) provide clear guidelines for labelling form elements:

WCAG 1.3.1: Info and Relationships (Level A): Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
WCAG 2.4.6: Headings and Labels (Level AA): Headings and labels describe topic or purpose.
WCAG 3.3.2: Labels or Instructions (Level A): Labels or instructions are provided when content requires user input.

Identifying and Fixing Missing Labels

Thankfully, identifying missing labels is relatively straightforward:

Manual testing: Carefully review all forms and CTAs (Call To Action) on your website and ensure each field has a visible and descriptive label.
Automated testing: Accessibility testing tools like WAVE, Axe, and Lighthouse can automatically detect missing labels and other accessibility issues.

Once identified, fixing missing labels is usually a simple matter of adding the appropriate HTML:
(note: to keep the examples short, I'm not adding the autocomplete attribute, but by rights, they should be included on form elements that request personal information)

<!-- DON'T DO THIS -->
<p>
  <strong>Name</strong>
  <input type="text" name="name">
</p>

<!-- Use a label, with a 'for' attribute -->
<label for="name">Name</label>
<input type="text" id="name" name="name">

Best Practices for Effective Form Labels

Writing Clear and Concise Form Labels

Use plain, simple language and avoid jargon. e.g.

<!-- Simple descriptive label -->
<label for="email">Email address</label>
<input type="text" id="email" name="email">

Using Descriptive Language for Form Labels

Labels should accurately describe the information being requested. e.g.

<!-- Describe what data is required -->
<label for="phone">Telephone number</label>
<input type="text" id="phone" name="phone">

Properly Associating Labels with Input Fields

Use the <label> element with the for attribute linked to the corresponding input's id or for multi fields (like radio buttons) use aria-labelledby. e.g.

<!-- Use a label, with a 'for' attribute -->
<label for="name">Name</label>
<input type="text" id="name" name="name">

<!-- Use a 'aria-labelledby' attribute for 
  multi-field input group -->
<fieldset>
  <!-- Legend with ID for referencing -->
  <legend id="petLegend">Insure your pet</legend>

  <label id="catLabel" for="cat">Cat</label>
  <!-- Cat radio button with aria-labelledby attribute -->
  <input type="radio" id="cat" name="pet" 
    aria-labelledby="petLegend catLabel">

  <label id="dogLabel" for="dog">Dog</label>
  <!-- Dog radio button with aria-labelledby attribute -->
  <input type="radio" id="dog" name="pet" 
    aria-labelledby="petLegend dogLabel">
</fieldset>

Ensure all CTAs have labels

Either add text to the CTA (visually hide it if it's not needed, e.g. if the CTA displays as an icon) or use the aria-label attribute. Consider a 'close' icon on a search panel;

<!-- DON'T DO THIS -->
<button class="close-search-icon"></button>

<!-- add text (can be visually hidden) -->
<button class="close-search-icon">
  <span class="visually-hidden">
    Close Search
  </span>
</button>
<!-- or aria-label -->
<button class="close-search-icon" 
  aria-label="Close Search"></button>

Visually distinct and placed appropriately

Ensure labels have sufficient contrast and are easily distinguishable from the surrounding content. Also, position labels close to their respective input fields for easy association.

Conclusion: Labels are Non-Negotiable

Missing labels are a common accessibility issue with a significant impact on user experience. By following WCAG guidelines and implementing best practices, we can create forms that are accessible, usable, and inclusive for everyone. Remember, clear and descriptive labels are not just a nice-to-have, they are essential for creating a truly accessible web.

WCAG: Good contrast, good vibes!

patrick clancey — Fri, 26 Jul 2024 08:45:46 +0000

The new accessibility recommendations from the EU are important guidelines that we should be mindful of. While the value is widely acknowledged, not everyone might have acted on it yet. Now, with a concrete deadline in place - June 28th, 2025 - it becomes an essential task to undertake. Many companies have already begun improving their websites' accessibility. Since contrast often tops the list of common accessibility failures, let's delve into this particular challenge.

Introduction

The European Accessibility Act (EAA) - Directive 2019/882, which establishes a comprehensive set of accessibility rules for digital offerings within the EU market, is going to come into effect next year. The deadline for compliance with this new legislation is June 28th, 2025.
With this in mind, I'm going to take a look at some of the most common accessibility issues according to The 2024 report on the accessibility of the top 1,000,000 home pages and how to fix them.

In this post, I'll be looking at contrast, why it's important, who it affects, and how to fix it.

Low Contrast - Who Does It Impact?

A better question might be, who doesn't it impact? The group that won't be affected by low contrast are those using screen readers to access the website. However, for everyone else who relies on visual cues to navigate the site, contrast plays a crucial role. Therefore, it's safe to say that nearly all visually-dependent users will be impacted by the level of contrast on a website.

At some time or another, we all face issues with our sight, whether it's persistent (e.g., old age, hypermetropia), temporary (e.g., conjunctivitis, hay fever), or situational (e.g., sunny day, phone in low battery mode).

Having said that, people with colour blindness or other visual impairments are particularly affected by low contrast. It's important to follow the WCAG recommendations and ensure that our interfaces have sufficient contrast to be usable by everybody.

WCAG Contrast related Success Criterion

There are four WCAG SC specifically related to contrast levels, they are;

Testing for compliance

Firstly, we need to know what issues we have and where they are, so they can be prioritised. Thankfully, contrast is one accessibility issue that can usually be picked up by accessibility tools. There is a good list on Web Accessibility Evaluation Tools List. Ideally we want a tool like pa11y running against a dev server to surface issues way before they go live. For manual testing, a personal favourite of mine is the axe DevTools chrome extension. Also worth a mention is the stand-alone Colour Contrast Analyzer (CCA)

Once you have identified any low contrast elements, you can prioritise fixing them. Starting with elements commonly used across your site. For example, if you have a contrast issue with your global navigation that needs fixing ASAP. Same goes for any CTAs, like form buttons or link texts. And, as you are addressing contrast issues you may as well not pussy foot around with AA, go straight for AAA!

Addressing issues

On the good side, technically fixing contrast issues is easy work. Usually it's just a few simple changes to your CSS. The more difficult task is getting approval to make the changes in the first place! If your colour scheme is based on approved corporate colours and/or the designs have been "signed off", it's often a slow process to get approval make global changes to the colour scheme. So with the EU Accessibility Directive coming into force next year it's well worth getting the ball rolling in order to get your necessary updates live in time!

In my experience it's a good idea to offer some "ready-to-go" alternatives. As the site's product owner might not have time to fully digest the implications and impacts of contrast failures and come up with a solution, they will probably have time to look at three options and point at their favourite.

The first step is to explore some alternatives that meet the required contrast levels. Depending on what elements are failing, you'll likely find three or four viable options to consider.

Darken

If you have an issue with say a blue which is too light you can usually darken it, whilst still keeping the overall colour pallet. This won't work with colours like green, orange or gold as they don't darken nicely.
There are a number of theming tools like Theming Designer or Paletton.com
which you can use to extend your current pallet to include some WCAG compliant colour variations.

Complementary

You can expand the site's colour palette by finding some complementary colours which have higher contrast.
Look for colour wheel generators like Figma color-wheel or a matching colour generator like mycolor to get ideas.

Invert

You can try inverting the colours, or rather swapping white and black. For example if your issue is buttons that are a light colour with white text you can swap that round so the button is black with the light colour as the text.

Remove

The nuclear option. Remove the colour palette from the offending elements altogether. Falling back to generic grey scale. This might sound extreme, but, you can select greys that sit nicely within any colour pallet and easily meet the contrast requirements.

In the meantime

In the short term remove any CSS that is actively causing issues, for example check your CSS doesn't actively suppress the focus indicator (this was quite a common practise, so if you have inherited a code base, please check!).

/* remove anything that looks similar to these */
*:focus {
  outline-width: 0 !important;
}
*:focus {
  outline: 0 none !important;
}

Developers used to routinely remove the system outline so code similar to the above is still quite common. Read WCAG SC 2.4.13 Focus Appearance to get up to speed with requirements around the focus indicator.

It's worth checking when the user has requested High Contrast that your CSS is not overriding any important rules. Always a good idea to check this by enabling High Contrast on your machine to see what happens!

Implementing something is better than nothing. I recommend you pick your personal favourite solution and implement it within the CSS prefers-contrast: more media query.

button {
  /* can't change this until the theme update is approved */ 
  background-color: gold;
  color: white;
}
@media (prefers-contrast: more) {
  /* random example; */
  button {
    background-color: black;
    color: white;
  }
  button:hover {
    background-color: white;
    color: black;
  }
  button:focus-visible {
    outline: 2px solid black;
    outline-offset: 2px;
  }
}
/* or if you are using css variables */
:root {
  --accent-color-1: gold;
}
@media (prefers-contrast: more) { 
  :root {
    --accent-color-1: black;
  }
}

At least users who have specifically asked for high contrast will get it. And it shows you are making an effort to address the site's issues.

In conclusion

Ensuring good contrast in web design is crucial for accessibility and usability. It affects everyone who visually accesses a website, whether they have permanent, temporary, or situational vision impairments. Adhering to the WCAG success criteria related to contrast not only enhances user experience but also helps meet the upcoming European Accessibility Act requirements. While technically simple to fix, these changes often require approval due to established colour schemes and designs. Therefore, it's important to start early, prioritize common elements, and aim for AAA compliance. Remember, there are various strategies to address contrast issues, from darkening colours and finding complementary ones to inverting or even removing the colour palette. In the meantime, avoid suppressing focus indicators and consider implementing high-contrast options for users who prefer them. Ultimately, improving contrast is about making your digital content more accessible and enjoyable for all users.

(Thank you to jan huber for the cover image)

CSS wordwrap: Because Sometimes One Line Just Isn't Enough!

patrick clancey — Fri, 28 Jun 2024 10:48:07 +0000

Controlling how text wraps with CSS can be a headache. CSS offers a number of text wrapping options to keep your content readable and responsive. So your text doesn't break the page layout or look like it lost a fight with a blender.

Introduction

Text wrapping is vital in web design for content readability and visual appeal across different devices and screen sizes. CSS provides properties like overflow-wrap, word-break, text-wrap and hyphens that allow developers to control text behavior at the edge of its container. This post explores the practical use of these properties to manage long strings, prevent overflow, and enhance user experience. These CSS rules are essential when dealing with unbreakable URLs, optimizing text readability and maintaining responsive designs.

Wrapping vs Truncation

For the purposes of this post I'm only going to focus on text that needs to be visible to the user, hence it needs to wrap and ignore the truncation option entirely. Although, there is some overlap in the use-cases, text truncation has a more specific use-case and is specifically for hiding content over a specific length. So I'm just going to skip over it here!

Text wrapping style options

Let's jump straight in and take a look at some styles we can use to prevent strings form overflowing their container.

TLDR

Ok, I'm going to skip the boring bits and go straight to the summary. (For reference, the rather dry detail about each style follows further down the page.)

/* use for headings */
.my-h1 {
  hyphens: auto;
  overflow-wrap: break-word;
  text-wrap: balance;
}
/* use for general static copy */
.my-text-container {
  hyphens: auto;
  overflow-wrap: break-word;
}
/* 
  use specifically for breaking long strings or
  on large/dynamic content containers which 
  may contain long strings
 */
.my-url-container,
.my-very-big-text-container,
.my-dynamic-text-container {
  overflow-wrap: break-word;
}

As with most things CSS, there is more than one way to solve the problem. But which is the best? Let's look at three use-cases. Headings where long words might overflow on small devices, static content containers which could contain long strings like URLs, and containers that could either contain a lot of content or are repeatedly updated dynamically. Let's take these three in revers order. For contains that contain a lot of content, or are dynamically updated we can use overflow-wrap: break-word this will keep the content within the containers' boundaries. For short or static content (see below for detail about hyphens and performance) we can add hyphens: auto this will improve readability, but we still keep overflow-wrap: break-word which will ensure that long strings still wrap if the content is in a language that the browser doesn't know how to hyphenate or the long strings aren't words. And lastly for headings (e.g. H1) we'll keep hyphens and overflow-wrap and we'll also add text-wrap: balance this adds visual balance to the mix, so the header wraps nicely.

The boring bit

Let's look at the styles in more detail

hyphens: auto;

Using hyphens: auto in CSS allows for automatic, language-aware hyphenation of text, which can significantly enhance the readability and aesthetic of text blocks, particularly in responsive designs and narrow layouts.

hyphens, on the downside

This does more than just breaking long strings that don't fit in the container. You might still get text overflowing the container, for example a very long number won't be hyphenated so will still remain on one line. hyphens: auto has a performance overhead due to the processing required to determine hyphenation points, especially in dynamic or large text content. To mitigate the impact of this, particularly for containers with extensive or frequently changing text, I recommend only using hyphens: auto on specific elements that would benefit from it, don't just randomly add it here, there and everywhere!

overflow-wrap: break-word;

This style ensures that long words or unbreakable strings (such as URLs) break and wrap onto the next line instead of overflowing their container.

overflow-wrap, on the downside

Arbitrary word breaks at any point, which can lead to awkward or hard-to-read text breaks, disrupting the natural flow of reading. A small performance overhead (although less than that of hyphens).

word-wrap: break-word;

This is an alias for overflow-wrap: break-word, which is the standardized property name. Use overflow-wrap: break-word instead.

word-wrap: break-all;

I have nothing good to say about word-wrap: break-all. I can't think of any use-case for it. Only consider using this if you have a specific issue that isn't fixed by any of the other options!

break-all, on the downside

It breaks words excessively at any character, leading to awkward and very hard-to-read text at all widths.

Balancing text-wrapping

The style text-wrap: balance does NOT break strings. This is shorthand property which controls how text inside an element is wrapped, it's not standard (yet) but has solid support in all major browser vendors. I use this on main header elements (e.g. h1) to visually balance the content and make it more aesthetically pleasing. This is part of the css-text-4 text-wrapping proposal

text-wrap balance on the downside

I haven't seen any detailed performance metrics so I might be making too much of the potential performance impact. But nonetheless, I would only use this on specific static elements like headers. I wouldn't use this on large content blocks or anything that's repeatedly updated dynamically.

Forem: patrick clancey

Unlocking Hidden Content: An Introduction to hidden='until-found'

Interactive Components

The Problem

Implementation Example

Developer notes

Further Reading

WCAG: Empty Links

Introduction

Why empty links matter

Who is impacted by missing link text?

Related WCAG guidelines

Other related issue

Alt text doesn't describe the link target

Duplicate adjacent links

Links out of context

Conclusion

Tip

WCAG: Alternative Text for Images

Introduction

Why alt text matters

Who is impacted by missing or poor alt text?

WCAG alt text guidelines

The alt attribute is non-negotiable for accessibility

Identifying Decorative Images: When to use an empty alt attribute

How to write effective alt text

Testing alt text for accessibility

Alt text for complex images

Video content: Accessibility considerations

Conclusion

WCAG: The Unseen Impact of Missing Labels

Introduction

Missing Labels on HTML Forms: A Recipe for Confusion and Exclusion

Who is Impacted by Missing Form Labels?

The Importance of Labels: More Than Just Words

WCAG Guidelines for Form Labels

Identifying and Fixing Missing Labels

Best Practices for Effective Form Labels

Writing Clear and Concise Form Labels

Using Descriptive Language for Form Labels

Properly Associating Labels with Input Fields

Ensure all CTAs have labels

Visually distinct and placed appropriately

Conclusion: Labels are Non-Negotiable

WCAG: Good contrast, good vibes!

Introduction

Low Contrast - Who Does It Impact?

WCAG Contrast related Success Criterion

Testing for compliance

Addressing issues

Darken

Complementary

Invert

Remove

In the meantime

In conclusion

CSS wordwrap: Because Sometimes One Line Just Isn't Enough!

Introduction

Wrapping vs Truncation

Text wrapping style options

TLDR

The boring bit

hyphens: auto;

hyphens, on the downside

overflow-wrap: break-word;

overflow-wrap, on the downside

word-wrap: break-word;

word-wrap: break-all;

break-all, on the downside

Balancing text-wrapping

text-wrap balance on the downside

Further reading