The current laws related to accessibility are, to put it nicely, messy. The Americans with Disabilities Act, which is the law that requires most organizations in the United States to provide public accommodations for disabled people, was passed before HTML was even invented and thus has no specific rules for websites.

However, most legal experts still consider websites a “public space” that falls under the law’s requirements. Recently, the laws and government rules have featured different requirements depending on the state you operate in and your type of organization. To work around this patchwork, the best single source for guidance on website accessibility is the Web Content Accessibility Guidelines (WCAG). More specifically, WCAG 2.1 Level AA is considered the gold standard, cited more frequently in laws, rules, and litigation than any other source.

This framework has four major flaws when it comes to practical application for the average website owner.

  1. It’s written for developers. Reading it´s like reading Latin to most people.
  2. It only includes a few examples for each guideline. How the guidelines are practically applied is often subject to interpretation.
  3. The guidelines themselves update every few years, usually becoming more rigid. This leads to even further disagreement about proper application.
  4. There are mountains of existing content on the web that weren´t made with accessibility in mind. Only in recent years have regulators started to enforce web accessibility, and lawsuits related to it have started to rise. Combine that with the additional cost, and most website owners never even considered it or didn’t feel it necessary.

This ever-changing landscape can feel impossible for the average person to understand or keep up with. Below, I’ve outlined specific cases where the laws and guidelines fall short and how you can practically adapt without being a professional developer or accessibility expert.

When is alternative text needed on an image?

For the sake of this topic, “images” are defined as any photo, graphic, illustration, screenshot, or icon. The general rule is that decorative images don´t need alt text, while functional or informational images do. Technically, it´s not necessary to add alt text to every image. In fact, this can be contradictory to its purpose if the alt text is overly detailed or repeats information that is elsewhere in the content.

First, what is considered decorative?
Whether an image conveys information that would otherwise be absent for users with disabilities like limited vision is a judgment call that must be made in every situation. Each person evaluating your website may have a different opinion.

Second, what is an acceptable alternative version of that information?
If your image contains a lot of information, it´s open to interpretation at what line the information gets too complex to add as alt text, and should instead be displayed on the page the image shows on.

Third, how detailed should alt text be?
The general rule is that alternative text should convey a brief description of the subject or action of the image. It doesn’t need to describe every color or every object. But importantly, exactly how much detail is needed depends on the specific situation and is open to interpretation.

Any image related to the page’s content that adds information not covered elsewhere in the page’s text should include alternative text. Generally, this would include images of the locations, events, or people directly related to the content. Examples:

  • Banner photo that visually captures the subject of the article. Think of the photo that shows above a headline in a newspaper. Usually, it tells a story visually. For this type of image, briefly describe what’s happening.
  • Portrait of a person next to their biography. For this type of image, include their name and a brief description of what they look like in the alt text.
  • Logo of an organization that links to their website. Just the organization’s name is adequate alt text in most cases, but it can be helpful to briefly describe the logo’s icon or style.
  • A gallery of photos. Usually, this conveys a lot of information that isn´t directly in the page’s text. For each image, briefly describe the subject or what is happening.
  • Product photos on an e-commerce page. The alt text should include the product name and a brief description of its appearance.
  • An illustration of a workflow that isn´t described elsewhere in the text. Add the workflow steps as alternative text. If this is a complex workflow, consider adding text to the page with more detail rather than using alt text.

Any images that are purely decorative or that don´t provide any additional information don´t need alternative text.

  • Screenshots of applications. Generally, the screenshot should provide a visual representation of the text on the page, so no further alt text is needed.
  • Screenshots of flyers/documents. Any screenshot with a lot of text should display that information on the page or link to an accessible PDF.
  • Stock photos used for mood. Often, stock photos and featured images are just visual ways to reinforce the subject, so users can more quickly scan archives and feeds. They aren´t adding information, such as locations or visual cues, to the substance of the article.
  • Icons in the content. Usually, icons within the content work similarly to stock photos, providing a visual cue for scanning a page more quickly, but don´t need to be described because they are followed by a title or text that conveys the same information.
  • User interface icons. Usually, these will be set up by your web developer. It´s best practice to include screen reader text for these elements, so it’s not visible on the page but is readable with assistive technology. So long as that screen reader text is present, no alt text is needed.
  • Graphical flourishes. Shapes, swoops, background colors, etc., are irrelevant to the information conveyed on the page in most cases and thus don´t need alt text.

Do PDFs and Documents need to be accessible?

The short answer to this question is yes. By the basic language of the WCAG 2.1 AA, all documents that are stored on your website need to be accessible. However, there is a practical reality to documents: The vast majority of public documents in existence have never been reviewed for accessibility. Because of this, and because many organizations have hundreds or thousands of documents that need to be publicly available for their mission or to meet other regulatory requirements, many laws/rules/guidance provide provisions that impose undue burdens or other exemptions for older docs.

This is an area of website accessibility that we, as web professionals, cannot directly help with. We aren’t document experts, and we don’t have access to editable document files in most cases. Thus, as with video content, this is your responsibility as the website owner. For organizations with large volumes of documents, or those that could lose funding or face fines due to inaccessible documents, this can feel very intimidating.

  1. Most documents are inherently accessible. If a document is black text on a white page with no images or colors, it’s probably accessible. It should still be tested, but it should be pretty quick to verify for each.
  2. Tools exist to help. Most document software, including Microsoft Word, Google Docs, and Adobe Acrobat, has accessibility checkers. Even more have the tools needed to add requirements like alt tags, there are easy contrast checkers online, and plugins to help you replace existing documents on your website while maintaining the same URL.
  3. Exceptions for organizations that receive federal funding. The HHS rule for Section 504 of the Rehabilitation Act includes exceptions for preexisting conventional electronic documents.
  4. Exceptions for state and local government websites. The DoJ rule clarifying Title II of the ADA, which goes into effect in April 2027 (previously April 2026), permits exceptions to archival documents on state and local government websites. Individual states may have more strict requirements, however.
  1. For outdated or unnecessary PDFs, we recommend removing them entirely before any further review. Like your website’s pages, anything that is no longer relevant/useful is an unnecessary liability.
  2. The first batch of documents to review would be any that contain current, relevant, actionable information, such as a flyer for an upcoming event, a how-to sheet, or an intake form.
  3. Next would be any document with a lot of formatting, such as newsletters. These can be the slowest to update, and the key things to check are color contrast and alt tags on images (see alt tag guidance in this article).
  4. Finally, the lowest priority would be any archival documents, such as board meeting notes and records. This is the most likely document type to be exempt or given grace in audits, grants, and litigation, since the vast majority of organizations don´t have a fully accessible archive of documents. (No promises though!)

Does all content need to be inside primary landmarks?

It´s not strictly required by the WCAG to have all content fit into <header>, <nav>, <main>, or <footer>, but it´s considered best practice in most situations. If content is included outside these primary landmarks, it should be assigned a role in the code, such as role=”dialog” or role=”region”, to clarify its purpose for users navigating the site with a screen reader.

Should Icons use the 4.5:1 or 3:1 contrast rule?

The rule for color contrast to conform with WCAG 2.1 AA is a minimum of 4.5:1 for regular text and 3:1 for graphic elements or large text. In plain language, this rule states that icons (a type of graphic) only need to meet a 3:1 ratio, which is enough for most use cases where icons are decoration.

However, when an icon is used as text replacement, as it often is in user interfaces for things like menu toggles and social links, it should meet the 4.5:1 contrast ratio, since the icon is acting as a stand-in for text. While you will likely pass an audit with the lower standard, we recommend using the higher standard to meet the spirit of the guidelines, ensuring users with contrast disabilities can still use your website.

As an aside, we also recommend adding title attributes to any UI icon and screen reader text. This covers all situations:

  1. Users with average vision can see the icon.
  2. Users with low contrast can see the icon and can see a title when hovering over the element for clarity.
  3. Users who require screen readers have the icon replaced with text.

Do headings need to be in the right order?

This is a good example of a disagreement among professionals about whether it violates WCAG. Some argue that missing heading levels violate the “1.3.1 Info and Relationships” criteria, as they prevent understanding of the content when using screen readers. While we agree with this opinion, it´s unlikely to be the cause of failure in an audit at this time.

However, it´s considered “Best Practices” to keep headings consistent and orderly. This means including an H1 page title on every page, using H2 as the first topic title within the page content, and using H3 for subsequent subtopics, etc. This also means not skipping heading levels, such as jumping from H2 to H4 or choosing heading titles based on aesthetics, such as size or style, instead of their intended purpose to indicate informational hierarchy.

In the future, we anticipate this rule becoming more strictly enforced and a more common cause for litigation. To avoid the technical debt, it’s most prudent to follow the best practices now.


Further Reading

  1. Getting Started with Website Accessibility
  2. How to add accessible content to your website
  3. Accessibility Laws that Affect Your Organization