Website ADA compliance

There is no substitution for developing a site with accessibility in mind. At best, an accessibility overlay is a Band-Aid. More impactful, tools like accessiBe and UserWay can make it so that the disabled user’s preferred way of using a web site does not work as they expect. Read our article for more information on accessibility overlays.

All images must have an ALT tag. If the image is decorative, if it provides no additional information, a “blank” alt can be used: alt=””. If the image is a link, has text, or provides further information not already on the page, the ALT attribute should repeat the important text and/or describe the meaning of the image; do not describe the image, describe the meaning of the image.

If the image can be removed from the page and all the important information remains on the page, the image is decorative. Stock photography is almost always decorative. Icons are decorative when they include a text aspect.

An aria-label is similar to alt text in that it provides supplemental text, especially for screen reader users. Whereas alt text provides a text alternative for images, an aria-label provides additional or alternative text for visible text. Like alt text, an aria-label is not visible. Imagine that you have a promotional card about Mobile Banking with a headline, image, and then a CTA that says, “Learn More”. The visual user can clearly see that they will learn more about mobile banking, but if a screen reader user is moving link to link, they will only hear “Learn More” and have no idea what they are learning more about. In this situation, we want the screen reader to say, “Learn More about Mobile Banking” so we would use the following aria-label to replace the visible text for the screen reader: aria-label=” Learn More about Mobile Banking”. Now, the visual user sees the concise “Learn More” which has good context, and the screen reader user hears “Learn More about Mobile Banking”.

When using an aria-label, it is necessary to start the label with the exact visible text. This is because the aria-label replaces the visible component, it does not supplement it. If a user is using voice-recognition software and they see a link called “Learn More”, but the aria-label is “Learn about Mobile Banking,” they cannot successfully select the link. Therefore, the aria-label must start with the exact visible text, in this case, “Learn More about Mobile Banking”. 

It’s better to avoid PDFs when possible and add content to the site with established templates that have been provided with base accessibility. If, however, there is a need for a PDF on a site, yes, it must be conformant. The rules about conformant content are not limited to HTML but rather any content on a site, including PDFs. 

Tables by default are “Tabular tables”. This means that assistive technology will automatically assume that the columns and rows in the table have a meaning and provide feedback to the user about what row or column the data is in. Properly marked up tabular tables can even provide a column or row header. “Presentation tables”, when a table has role=”presentation” in its HTML, tells assistive technology that the table is only to make the page look a particular way, and that the table structure should be ignored.

A table should have row headers specified when the information in the table isn’t useful without the row header’s context. For example, when using a comparison table, if the row lists a specific product, the columns list different features of the product, and the table cell says something like “Yes/ No” or “Included”, that information needs more context and the table should have row headers.

You can follow the tips provided by WC3 in the tables tutorial for the type of table you have.

In most cases, any interactive PDF reader you may add to your site will be inaccessible. Not only can it prevent assistive technology users from accessing the content, but the applet may also be more difficult for all users than a standard HTML page.

Videos are required to have both captions for visual readers, as well as a transcript of the video. This covers all users who can consume the video with or without sound and provides a static text version of the video to provide an accessible alternative to the video for users who cannot access it. For more information, check out our best practices for accessible video and audio content.

Any aspect of a website or application that uses code that is not able to be modified by the site owner or developer is third-party. Every effort should be made to ensure that the vendor being used provides accessible content and functions – if the vendor does not or cannot provide accessible material, pick a different vendor that does. But there are cases, like with Google Maps, where automated accessibility tools find issues that we cannot change and there is no other reasonable replacement so that tool is used.

Yes, companies are still being sued for a lack of accessibility. Per Seyfarth Shaw LLP, there were more than 2,450  lawsuits filed in 2024 in federal courts; this number does not include cases in state courts, nor does it account for demand letters and settlements.

Yes! Mobile device applications are structured in a remarkably comparable way to websites. Icons and buttons as well as user input boxes need to have proper labels and other tagging added to them to ensure that the device based “screen readers” can access every part of the application with enough context so that one can use all features of the application.