Dynamically Generated Content and Accessibility: 3 Quick Tips

March 22, 2022

Dynamic website content is any content that changes over time to adapt to user behaviors, preferences, interests, or other data points. Put simply, if your website changes its presentation in order to provide users with a better experience, it uses dynamically generated content. 

When used appropriately, dynamic content is an excellent resource for keeping users engaged. Here are a few examples that you’ve probably encountered:

  • An eCommerce website might use dynamic content to showcase items related to a certain product. 
  • A travel website might offer special discounts to people in a certain geographic area. 
  • A streaming service might present users with a list of similar titles when a video ends. 

In 2022, dynamic content makes up much of the internet — but unfortunately, not all of that content is accessible for people with disabilities. If you’re adding complex features to your website, make sure you follow the best practices in Web Content Accessibility Guidelines (WCAG) to create dynamic content that works for everyone. Here are a few tips to help you get started.

1. Provide accessible status messages when content changes

WCAG requires content to be predictable. If someone accesses your eCommerce website and selects a product, the visual presentation may show them that they’ve successfully added the item to their cart — but remember, not all users can perceive content visually.

WCAG Success Criterion (SC) 4.1.3, “Status Messages,” reads: 

In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

In other words, status messages shouldn’t rely on visual information alone. For example, if a user adds an item to their cart, the content could change to include a message like “one item" near the shopping cart item. A screen reader would announce “shopping cart, one item,” fulfilling WCAG requirements. 

Status messages should be properly coded using WAI-ARIA (discussed below) or HTML so that assistive technologies recognize them as status messages. Otherwise, screen readers might change the user’s focus unnecessarily, preventing them from comfortably navigating your website.

Related: What You Need to Know About Visual Focus and Accessibility

2. Use WAI-ARIA when necessary

WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications), also referred to as ARIA, is a technical specification that enhances accessibility for people who use screen readers and other assistive technologies. The purpose of ARIA is to provide semantic information about on-page elements.

ARIA can greatly improve the user experience in a number of ways, including:

  • A website uses a progress bar. ARIA identifies the completion percentage of the progress bar, and screen reader users can receive this value at any time.
  • A website provides an alert message when errors occur. ARIA’s “alert" role identifies the alert to assistive technologies, which can provide the user with relevant information without disrupting their experience.
  • A website contains purely decorative elements. ARIA’s “hidden" role identifies these elements to the screen reader, which allows the screen reader to avoid reading out the decorative elements to the user.

Before adding markup to your website, remember the first rule of WAI-ARIA: Use native HTML elements or attributes instead of ARIA wherever possible. Semantic HTML is widely supported by every browser and assistive technology. WAI-ARIA can cause content to behave in unpredictable ways — particularly when developers don’t test their code. 

If your website uses ARIA, make sure you have a testing strategy to ensure WCAG conformance. Don’t rely on automated accessibility tools alone: To prevent serious accessibility barriers, content must be manually checked, ideally by professional testers with disabilities.

Related: 4 Questions to Ask Before Using ARIA

3. Think about keyboard-only users

Many people browse the web with a keyboard alone (no mouse). To conform with WCAG SC 3.2.1, “On Focus,” dynamic content shouldn’t change in context when a field receives keyboard focus unless the change is predictable. 

For example, let’s say that a website includes a dropdown menu for navigation. A user accesses the dropdown, but every time they try to move through the menu, the website loads the selected webpage. That’s not a great user experience — the feature might work perfectly for mouse users, but for keyboard-only users, the site might be completely unusable.

Additionally, many websites have color contrast issues that prevent users from determining which element has focus. If your users can’t figure out which element they’re interacting with, they can’t navigate your content.

Try accessing your website with a keyboard. Try to move through dynamic content using the Shift and Shift-Tab commands. Does everything work as expected? Can you easily determine which element has focus? 

Test dynamic content regularly for WCAG conformance

Dynamic content can create accessibility challenges, but it’s also capable of providing a much better experience for all users (including those with disabilities). The principles of WCAG can be extremely helpful when planning: Content should be perceivable, operable, understandable, and robust. 

When creating your website, keep those principles in mind and ask questions about how dynamic content affects the user experience. Here are a few quick tips to keep in mind:

  • Consider whether each feature will cause unexpected changes for users. 
  • Provide updates to inform users when content will change. 
  • Make sure update notifications have a suitable priority — don’t interrupt screen reader users unless the update is critical. 
  • Exercise caution when using WAI-ARIA and test your markup to avoid serious accessibility barriers.

To test your content, use both automated and manual audits. Ideally, manual tests should be performed by experienced screen reader users and other testers with disabilities. However, developers can also find some issues (and gain helpful perspective) by installing a screen reader like JAWS or NVDA

For more guidance, contact the Bureau of Internet Accessibility to speak with a web accessibility expert.

Receive an industry accessibility analysis of your website

Recent posts

Why Page Titles Are Important for Web Accessibility

November 23, 2022

Tips for WCAG Success Criterion 1.4.2: Audio Control

November 22, 2022

The Digital Curb Cut Effect: The Universal Benefits of Web Accessibility

November 21, 2022

Not sure where to start?

Start with a free analysis of your website's accessibility.

GET STARTED