Don't See What You're Looking For?

Help Us Improve

Browse by Collection

Skip to end of metadata
Go to start of metadata

A Level Errors

1.1.1 - All img elements have an alt attribute.

Why it's a problem

Screen reader users cannot perceive the image, and therefore are getting a less-than-equivalent experience from your website.

How to solve it

Provide appropriate alt text for the image. Writing good alt text is challenging. A good guideline is to try to write something as brief as possible, attempting to keep it under 100 characters of text, including spacees.

See: Alt Text Tips and Tricks

Bad:

<img src="exciting-photograph.jpg">

Good:

<img src="exciting-photograph.jpg" alt="a man walks on a tightrope between two skyscrapers">

1.1.1 - "Alt text for all img elements is the empty string ("") if the image is decorative."

Why it's a problem

Alt text is one of the most important things to understand about web accessibility. If you have determined that the image is decorative and doesn't need alt text, make sure you don't omit the alt attribute. If you do, the browser will read the image URL as alt text, which is not a very good time.

see also: Decorative

How to solve it

For decorative images, assign the alt attribute an empty string - " " as alt text.

Bad:

<img src="https://images.com/swoosh.png"/>

Good:

<img src="https://images.com/swoosh.png" alt=""/>

or

<img src="https://images.com/swoosh.png" alt=" "/>

1.1.1 - Alt text for all img elements that are not used as source anchors conveys the same information as the image.

Why it's a problem

One principle of web accessibility is that content should be equal amongst all users. If there's useful information contained in an image, and it's not present as alt text, screen reader users will never see it.

The "source anchors" part just means images that are not links.

How to solve it

Make sure to provide equivalent meaning in the alt text. Generally, this means that if you have an image that contains text, make sure the text is in the alt attribute.

There are different methods for larger, more complex images, such as charts and tables.

see: Complex Images

Bad:

<img src="http://www.images.com/branding-tagline.png" alt="tagline">

Good:

<img src="http://www.images.com/branding-tagline.png" alt="UMBC: An Honors University">

1.1.1 - A long description is used for each img element that does not have Alt text conveying the same information as the image.

Why it's a problem

Some images, such as charts and tables, are too complex to provide equivalent meaning in an alt tag, which should generally be short. Frequently, the alt text is set to "chart explaining X over time" which summarizes the chart, but doesn't provide the same experience to non-sighted users.

How to solve it

Provide a link to another webpage providing a detailed description of the information in the chart. This can be done in a number of ways that depend on the needs of the content. See: Complex Images

Bad:

<img src="chart.gif" alt="chart"/>

Good:

<img src="chart.gif" alt="A Complex Chart Described under the heading Care and Feeding of your Complex Chart />

<h4>Care and Feeding of your Complex Chart</h4>

1.1.1. - Alt text for all img elements used as source anchors is not empty when there is no other text in the anchor.

Why it's a problem

Screen reader users need alt text to understand images. When an image is inside a link, the only way a screen reader user can meaningly follow the link is if there is alt text applied to the image.

How to solve it

Ensure that the alt text is meaningful inside of a link. Generally this means that the link text describes where the user will go once the link is followed.

Bad:

<a href="https://www.umbc.edu">
    <img src="https://www.umbc.edu/images/x0pgh23-large.png">
</a>

In this case, the screen reader, with no alt text, will read the filename, which isn't particularly useful.

or

<a href="https://www.umbc.edu/sign-up-for-online-classes/">
    <img src="sign-up.png" alt="read more">
</a>

In this case, the screen reader will see a link that says "read more", which is better, but it doesn't say what they are going to read more about, so it's not very useful.

Good:

<a href="https://www.umbc.edu">
    <img src="https://www.umbc.edu/images/x0pgh23-large.png" alt="University of Maryland, Baltimore County">
</a>
or

<a href="https://www.umbc.edu/sign-up-for-online-classes/"> <img src="sign-up.png" alt="Sign up for online classes"> </a>

1.1.1 - Image Alt text is short.

Why it's a problem

Alt text needs to be descriptive, but not too long, or else it's difficult or tedious to interact with.

Monsido flags any alt text that's longer than 100 characters as too long. Additionally, some screen readers truncate alt text at 125 characters.

How to solve it

Rewrite the alt text to be shorter.

Also, don't be tempted to stuff extra words in the alt text thinking that it will boost your SEO - this practice is generally frowned upon by search engine ranking companies.

Bad:

<img src="retriever.jpg" alt="A Chesapeake Bay Retriever catching a frisbee flying disc in its teeth as it flys through the air. Chesapeake Bay Retrievers are the best dogs in the world, and this one is no exception.">

Good:

<img src="retriever.jpg" alt="A Chesapeake Bay Retriever catches a flying disc in its mouth.">

1.2.1 - Links to multimedia require a text transcript.

Why it's a problem

Deaf users require text to be able to have an equivalent experience.

How to solve it

When linking to a video or other multimedia, include a link to a transcript.

Bad:

<a href="video.mov">Commencement Address</a>

Good:

<a href="video.mov">Commencement Address (text description follows)</a>

<h1> Commencement Address</h1>
...(commencement address transcript)

1.3.1 - All data tables contain th elements.

Why it's a problem

Screen readers generally assist users by announcing the table headings as you navigate between rows and columns. A table without explicit headings is difficult to understand with a screen reader alone.

How to solve it

For the first cell in every row and column, use a <th> to markup the header instead of the standard <td>.

An added benefit is that often a <th> gets bold text styling.

Bad:

<table>
    <tbody>
        <tr>
            <td>University</td>
            <td>Mascot</td>
            <td>Founding Date</td>
        </tr>
        <tr>
            <td>UMBC</td>
            <td>Retrievers</td>
            <td>1966</td>
        </tr>
        <tr>
            <td>UC Santa Cruz</td>
            <td>Banana Slugs</td>
            <td>1965</td>
        </tr>
        <tr>
            <td>Syracuse University</td>
            <td>Orangemen</td>
            <td>1870</td>
        </tr>
    </tbody>
</table>

Good:

<table>
    <caption>University Sports Mascots</caption>
    <tbody>
        <tr>
            <th scope="col">University</th>
            <th scope="col">Mascot</th>
            <th scope="col">Founding Date</th>
        </tr>
        <tr>
            <th scope="row">UMBC</th>
            <td>Retrievers</td>
            <td>1966</td>
        </tr>
        <tr>
            <th scope="row">UC Santa Cruz</th>
            <td>Banana Slugs</td>
            <td>1965</td>
        </tr>
        <tr>
            <th scope="row">Syracuse University</th>
            <td>Orangemen</td>
            <td>1870</td>
        </tr>
    </tbody>
</table>

1.3.1 - All complex data tables have a summary.

Why it's a problem

Navigating tables using a screen reader is hard. Often, information that would be apparent to sighted users by scanning a table eludes screen reader users.

Note: for simple tables, a caption is not necessary.

How to solve it

Provide a summary for a complex table. It can be helpful to think of this as alt text for the table. Try to think of a quick way to summarize the overall message of what the table is trying to show.

A detailed summary is only necessary for complex tables.

Note: in HTML5, the summary attribute is deprecated. The <caption> tag can used in its place.

see: Caption and Summary

Bad:

<table>
    <tr>
        <td></td>
        <td>Jan</td>
        <td>Feb</td>
        ...
    </tr>
    <tr>
        <td>Sales</td>
        <td>$1002</td>
        <td>$2034</td>
        ...
    </tr>
</table>

Good:

<table>
    <caption>
        Sales Figures for 2020
    </caption>
    <thead>    
        <tr>
            <td></td>
            <td>Jan</td>
            <td>Feb</td>
            ...
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>Sales</td>
            <td>$1002</td>
            <td>$2034</td>
            ...
        </tr>
    </tbody>
</table>

1.3.1 - All data tables contain a caption unless the table is identified within the document.

Why it's a problem

Data tables without any kind of identifying information can be difficult to understand. What's this table trying to achieve?

How to solve it

The best solution is to include a <caption> element inside the table. Otherwise, identify the table with descriptive text immediately before the table in the source code.

Bad:

<table>
    <tr>
        <td></td>
        <td>Jan</td>
        <td>Feb</td>
        ...
    </tr>
    <tr>
        <td>Sales</td>
        <td>$1002</td>
        <td>$2034</td>
        ...
    </tr>
</table>

Good:

<table>
    <caption>
        Sales Figures for 2020
    </caption>
    <thead>    
        <tr>
            <td></td>
            <td>Jan</td>
            <td>Feb</td>
            ...
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>Sales</td>
            <td>$1002</td>
            <td>$2034</td>
            ...
        </tr>
    </tbody>
</table>

1.3.1 - Use colgroup and col elements to group columns.

Why it's a problem

When a table has headers that span multiple rows and/or columns, it is complex. Simple tables alone are often problematic, let alone complicated ones. A screen reader can have trouble navigating them.

How to solve it

Use <colgroup> and <col> to help screen readers understand the complex nature of your table.

See: Tables with irregular headers

Bad:

<table>
  <tr>
    <td rowspan="2"></td>
    <th colspan="2" scope="colgroup">Mars</th>
    <th colspan="2" scope="colgroup">Venus</th>
  </tr>
  <tr>
    <th scope="col">Produced</th>
    <th scope="col">Sold</th>
    <th scope="col">Produced</th>
    <th scope="col">Sold</th>
  </tr>
  <tr>
    <th scope="row">Teddy Bears</th>
    <td>50,000</td>
    <td>30,000</td>
    <td>100,000</td>
    <td>80,000</td>
  </tr>
  <tr>
    <th scope="row">Board Games</th>
    <td>10,000</td>
    <td>5,000</td>
    <td>12,000</td>
    <td>9,000</td>
  </tr>
</table>

Good:

<table>
  <col>
  <colgroup span="2"></colgroup>
  <colgroup span="2"></colgroup>
  <tr>
    <td rowspan="2"></td>
    <th colspan="2" scope="colgroup">Mars</th>
    <th colspan="2" scope="colgroup">Venus</th>
  </tr>
  <tr>
    <th scope="col">Produced</th>
    <th scope="col">Sold</th>
    <th scope="col">Produced</th>
    <th scope="col">Sold</th>
  </tr>
  <tr>
    <th scope="row">Teddy Bears</th>
    <td>50,000</td>
    <td>30,000</td>
    <td>100,000</td>
    <td>80,000</td>
  </tr>
  <tr>
    <th scope="row">Board Games</th>
    <td>10,000</td>
    <td>5,000</td>
    <td>12,000</td>
    <td>9,000</td>
  </tr>
</table>

1.3.1 - Data tables that contain both row and column headers use the scope attribute to identify cells.

Why it's a problem

Tables are difficult for screen reader users to navigate and understand. It can be difficult, without sight, to identify the row and column that the current cell corresponds to without being able to scan to the top or left side of the table.

How to solve it

Use <th> elements to mark up table headers for the first cell of your columns and rows. Additionally, you should use scope="row" scope="col" to make it explicit what the <th> is identifying.

Bad:

<table>
    <tr>
        <td></td>
        <td>Jan</td>
        <td>Feb</td>
        ...
    </tr>
    <tr>
        <td>Sales</td>
        <td>$1002</td>
        <td>$2034</td>
        ...
    </tr>
</table>

Good:

<table>
    <caption>
        Sales Figures for 2020
    </caption>
    <thead>    
        <tr>
            <td></td>
            <th scope="col">Jan</td>
            <th>Feb</td>
            ...
        </tr>
    </thead>
    <tbody>
        <tr>
            <th scope="row">Sales</th>
            <td>$1002</td>
            <td>$2034</td>
            ...
        </tr>
    </tbody>
</table>

1.3.1 - All p elements are not used as headers.

Why it's a problem

It's often easier for sighted users to create paragraphs (which is usually the default element in WYSIWYG editors) and bold them to create the appearance of headers. It's pretty easy to scan down a page visually and see these ersatz headers.

However, screen reader users often navigate pages by navigating headings. A screen reader can't tell the difference between a bolded paragraph and normal paragraph. This makes the document much harder for a screen reader user to "scan" or skim the page.

How to solve it

Instead of using bold paragraphs to split up your text, use the appropriate heading. A nice bonus is that headers are often already styled to be bold, so you save some bytes on markup.

See: Header order

Bad:

<p><strong>Summary</strong></p>

Good:

<h3>Summary</h3>

1.3.3 - All layout tables make sense when linearized.

Why it's a problem

Using tables for layout is generally a bad idea. However, it can sometimes be necessary. When a table is used for layout, the order that the text appears in the source HTML can sometimes be different from the way you would read it as a sighted person. Tables are read by screen readers left to right and top to bottom. If the text only makes sense out of that order, it will be read backwards to a screen reader user.

How to solve it

Make sure that the text from your table makes sense when read from left to right, top to bottom. See Creating Accessible Tables on Webaim.

Note: Monsido considers a table to be a layout table when it has no <TH> element.

Bad:

<table>
    <tr>
        <td>
          <img src="swoosh.png" alt=""/>
        </td>
        <td>An Honors University</td>
    </tr>
    <tr>
        <td colspan="2">UMBC</td>
    </tr>
</table>

Read as: "An Honors University: UMBC"

Good:

<table>
    <tr>
        <td colspan="2">
            <img src="swoosh.png" alt=""/>
        </td>
    </tr>
    <tr>
        <td>UMBC</td>
        <td>An Honors University</td>
    </tr>
</table>

Read as: "UMBC: An Honors University"

1.4.1 - For all img elements, text does not refer to the image by color alone

Why it's a problem

When referring an image, don't use color to describe what's happening. This goes for alt text as well as any text that references the image.

This issue is more for people with cognitive issues or colorblindess.

How to solve it

Rewrite the text to avoid mentioning color.

Bad:

<img src="http://www.images.com/couple.jpg" alt="a man in a blue windbreaker and a woman in a yellow jumpsuit hold hands while walking"/>

Good:

<img src="http://www.images.com/couple.jpg" alt="a man and a woman hold hands while walking"/>

1.4.1 - The luminosity contrast ratio between text and background color in all images is at least 5:1

Why it's a problem

It's relatively easy to detect if plain text on a background is readable, but it's harder to tell through automated means if text in an image is of the correct contrast. Images with text need to be just as readable as text.

How to solve it

The best way would be to remove the text from the image and place it in the HTML instead. If that's not possible, ensure that the image has appropriate alt text, and that the contrast is at least 5:1 with the background

See Color Contrast Tools

Bad: find an image

Good: find an image

2.4.2 - title describes the document

Why it's a problem

Each webpage has a title, which is generally displayed in the tab. Sighted users can use visual cues like icons, without this it can be difficult to know how to find the tab you're looking for without a detailed title.

How to solve it

In Wordpress, the title is generally the first field at the top of the document in edit mode. Whatever you put here will be incorporated into the title. Make sure that the page you are working on makes sense, even if you have many tabs open from the same site.

It's ok to incorporate your organization or brand in the title, but if you can help it, put it at the end. Users are more interested in the specific page than your brand, generally. Screen reader users especially appreciate this, it can be tedious to hear the computer say "UMBC - UMBC - UMBC " over and over. In a similar vein, try not to repeat text in the title. Only plain text is allowed, but don't be tempted to use things like asterisks - a screen reader reads this as "star". Stick to hyphens - "dash" or the pipe character - | - "vertical line".

Sometimes this issue can be solved by changing the title in the page, and sometimes it's hard-coded into the CMS. If you can't change the title, contact DoIT or OIT or whoever is in charge of your website.

Bad:

"UMBC – UMBC"

or

" | UMBC" - the title was left blank.

or

"Welcome to UMBC * UMBC * About"

Good:

"Leadership – UMBC"

"Welcome | UMBC"

2.4.4 - Suspicious link text.

Why it's a problem

Screen readers can present users with a list of all the links in a document. When navigating a document in this fashion, it's difficult or impossible to understand what the links are if they have poor quality link text. The most frequent problem here is people using the text "Click Here" or "Read More". Outside of the context of the sentences surrounding it, these links lose meaning.

How to solve it

It's best to use the name of the document or content you are linking to.

Bad:

<a href="register.html">Click Here</a>

Good:

<a href="register.html">Register For Classes</a>

2.4.4 - Link text is meaningful when read out of context

Why it's a problem

It's difficult to understand what will happen when you click the link without any other information. Many screen reader users navigate documents by tabbing between links. It's difficult to know where you are in the document if the link text doesn't describe what it's linking to.

How to solve it

Try to ensure that link text makes sense if you take it out of the sentence that surrounds it. A good solution is to use the name of the page you're linking to.

Bad: "To see the UMBC Photo Gallery, Click Here"

Good: "UMBC Photo Gallery"

2.4.4 - Each source anchor contains text

Why it's a problem

Links need text to be useful to screen reader users. A link that is an image but with no text is effectively invisible. Similarly, icons are often presented with no alternative.

How to solve it

Provide appropriate alt text for the image. In the case of an icon, text should be present inside of the link in some way, usually through an aria-label attribute.

Bad:

<a href="https://www.umbc.edu">
    <img src="/images/logo.png"/>
</a>

or

<a href="https://www.umbc.edu">
    <span class="icon-info"></span>
</a>

Good:

<a href="https://www.umbc.edu">
    <img src="/images/logo.png" alt="UMBC"/>
</a>

or

<a href="https://www.umbc.edu">
    <span class="icon-info" aria-label="Info"></span>
</a>

4.1.1 - id attributes must be unique.

Why it's a problem

HTML elements can have IDs set, but if there is more than one element with the same ID, this can confuse screen readers that perform processing on the document.

Additionally, it's not valid HTML. See the WHATWG HTML Standard document.

It may cause problems with javascript as well.

How to solve it

Change the ID to something unique. Often, you can use a class to achieve the same effect if it's being used for CSS. Classes can be duplicated.

Bad:

<h2 id="heading">UMBC</h2>
<h3 id="heading">An Honors University</h3>

Good:

<h2 id="main-heading" class="main-heading">UMBC</h2>
<h3 id="sub-heading" class="main-heading">An Honors University</h3>

AA Level Errors

1.4.4 - b (bold) element is not used.

Why it's a problem

The <b> element has been deprecated, but it is still in use in some WYSIWYG editors, and it still works in web browsers, however, some screen readers will have trouble with it.

How to solve it

Use the <strong> element instead.

Bad:

<p>
    The OCA Mocha is <b>my favorite</b> drink.
</p>

Good:

<p>
    I like my OCA Mocha with <strong>oatmilk</strong>.
</p>

1.4.4 - i (italic) element is not used.

The <i> element has been deprecated, but it is still in use in some WYSIWYG editors, and it still works in web browsers, however, some screen readers will have trouble with it.

How to solve it

Use the <em> element (emphasis) instead.

Bad:

<p>
    I <i>cannot</i> function without coffee in the morning.
</p>

Good:

<p>
    I have cut back on caffiene lately and I feel <em>great</em>!
</p>

1.4.5 - Alt text for all img elements contains all text in the image unless the image text is decorative or appears elsewhere in the document.

Why it's a problem

If there is no alt text or if the alt text is poor quality, screen reader users are getting a worse experience than sighted users. This is especially true if the image contains text that is apparent to sighted users, but has no alt text.

How to solve it

Provide adequate alt text for the image. If the image has a graphic with text or banner with text, be sure to add it to the alt text.

Bad:

<img src="umbc-logo.png" alt="logo">

Good:

<img src="umbc-logo.png" alt="UMBC">

2.4.6 - All h1 elements are not used for formatting.

2.4.6 - All h2 elements are not used for formatting.

2.4.6 - All h3 elements are not used for formatting.

2.4.6 - All h4 elements are not used for formatting.

2.4.6 - All h5 elements are not used for formatting.

2.4.6 - All h6 elements are not used for formatting.

Why it's a problem

Screen reader users often navigate documents using headers. An important aspect of this is that headers and sub headers need to be structured properly. Content authors often use WYSIWYG editors to format text and will change the order of headers purely for visual reasons, which can cause problems with screen reader software and cause confusion with users.

How to solve it

First - change the header number so it is properly nested.

For example, in a document, the document's title is often an <h2>, with multiple <h3> sub headings beneath that. If there are more sub headings beneath that, they should be <h4>, and beneath that, <h5>, and so on.

  • h2
    • h3
    • h3
      • h4
      • h4
        • h5

It helps to think of the headings as entries in an outline of the entire document.

If there are no deeper sub headings, it's not necessary to use them. You only need to go as deep as necessary.

Do not skip heading levels.

You can generally achieve the desired visual effect while keeping the proper header structure. For example, if you choose the header because it is styled with a color you like, there is quite possibly a style with just the color that you can use instead.

Also, in Sites, there are header styles that correspond to the existing header styles, so if you really really need the styling for <h4> but an <h3> would be the correct header, you can apply the css class .h4 to the <h3> class and get the visual look of the <h4>.

Bad:

<h2>About UMBC</h2>
(... content )
<h4>UMBC Academics</h4>

Good:

<h2>About UMBC</h2>
(... content )
<h3 class="h4">UMBC Academics</h3>

2.4.6 - The header following an h1 is h1 or h2.

2.4.6 - The header following an h2 is h1, h2 or h3.

2.4.6 - The header following an h3 is h1, h2, h3 or h4.

2.4.6 - The header following an h4 is h1, h2, h3, h4 or h5.

2.4.6 - The header following an h5 is h1, h2, h3 or h4, h5 or h6.

2.4.6 - The header following an h6 is h1, h2, h3 or h4, h5 or h6.

Why it's a problem

Headings should increase in number as they progress down the document. If a heading is jumped, say from an <h3> to an <h5>, with no <h4> in between, screen reader software will have problems with this and users will have trouble navigating the document.

How to solve it

The next heading should either go back up to the top level, or drill down deeper. It's perfectly fine to have multiple <h2>s in a document, as well as <h6>, but they should progress properly in order.

Bad:

<h2>About UMBC</h2>
(... content )
<h4>UMBC Academics</h4>

Good:

<h2>About UMBC</h2>
(... content )
<h3>UMBC Academics</h3>
  • No labels