![](/wp-content/uploads/2024/07/unnamed.jpg)
« Insights
Post-launch Pitfalls to Avoid
We pride ourselves on building accessible and performant websites for our clients. But a site’s code is only part of the equation—the content itself is just as important. Below are some of the most common content issues we see after we’ve handed over the keys to content authors and website managers. Avoiding them will ensure your site stays as accessible and performant as the day it launched.
Images missing alternative text
Alternative text, better known as “alt text,” describes an image for assistive devices (e.g., screen readers) and search engines. You should always add it whenever you’re uploading a new image, but authors often skip this step, leaving people with vision impairments no way to understand the content of photographs, illustrations, charts, graphs, or other visual information.
Though it sounds simple, writing good alt text is harder than you may think. Don’t just check the box of accessibility by adding a few words without understanding best practices to make your visual content truly usable. Here are some of my favorite alt text guides:
- Write Alt Text Like You’re Talking To A Friend
- Alt-texts: The Ultimate Guide
- Alt vs Figcaption
- An alt Decision Tree
Heading levels out of order
Screen readers provide a list of all headings on a page, known as a heading outline. Users can select a heading to jump to that point on the page. This ability to navigate via headings is used by over 70% of screen-reader users (source). The heading outline also serves as a table of contents. This helps users decide if they want to read the entire page.
Problems arise when authors select headings based on appearance instead of semantic hierarchy. For example, changing an H2 to an H3 for aesthetic reasons creates a gap in the heading outline. This gap in the hierarchical relationship of content creates confusion for assistive-device users. Here are some resources to help you avoid heading accessibility issues:
- Heading off confusion: When do headings fail WCAG?
- Accessible heading structure
- Headings: Web Accessibility Initiative
Note: WordPress supports creating custom styles for headings via Block Style Variations. This lets authors toggle the heading style without changing the level.
Ambiguous link text
It’s common for assistive-device users to navigate from link to link without consuming all of the contextual information before and after the link. When a link is focused the text will be read aloud, but not the URL. Authors should keep this in mind and use text that describes the purpose of the link. For example, instead of the vague “learn more” use “learn more about our organization,” which provides far more useful information about what a user will encounter when they click the link. Here are some resources to help you write better links:
Large images
Most modern Content Management Systems will automatically optimize and resize images as needed. This avoids wasting users’ bandwidth downloading enormous images onto their phones, for example, and for similar reasons, improves load time. To take advantage of this feature, authors should choose the most appropriate file format for their images before uploading. Here are some general guidelines:
- Convert photos to JPG or WebP—never use PNG.
- Use SVG for company logos, icons, and badges whenever possible. SVGs are vector graphics that can be displayed at any size without affecting quality.
- Use WebP or PNG for images with transparent backgrounds.
- Avoid animated GIFs in favor of videos when possible. If you must use an animated GIF, make them short, use few colors, and convert them to WebP before uploading.
- Large files (i.e. >10 MB) take longer to upload and process, potentially causing errors in your CMS. They also require more server space, leading to increased hosting costs over time. We recommend resizing large images first before uploading.
Squoosh is a helpful web app for optimizing and converting images to other formats. For batch updates, check out ImageOptim (macOS) or Caesium (Windows, macOS).
3rd-party plugins
One of the benefits of using WordPress is having access to its enormous plugin ecosystem. Many of them have existed for over a decade and are installed on millions of sites. These plugins let us add functionality without any additional costs for our clients. Some of our favorites include:
These particular plugins only add functionality to the WordPress back-end. They have no negative impact on front-end accessibility or performance. Plugins that add functionality to the public-facing side are a different story. Even popular ones can introduce accessibility or performance issues. We recommend having a developer test plugins in a sandbox environment first before installing on a live site.