Skip to Main Content


Headings are a useful visual aid, allowing readers to quickly skim a page to identify the content they are looking for. What you may not realize is that headings provide the same function to screen reader users, assuming they have been implemented correctly. As a matter of fact, almost 70% of screen reader uses say navigating through the headings if the first thing they do when looking for information on a lengthy web page (WebAIM survey - Finding Information).

The main points to remember about headings are as follows:

  1. Format all headings as "real" headings. That is, formatting text to look like a heading is not sufficient.
  2. Do not use headings to apply formatting to text that is not a heading. (The most common offender is a page subtitle.)
  3. Maintain an appropriate heading hierarchy. Do not skip heading levels.

Formatting Headings

For the web, headings come in six levels - h1 through h6. The HTML code for a heading level two looks like: <h2>This is a Level Two Heading</h2>. Other text editors (e.g. Google Docs, Microsoft Word) and content management systems (e.g. Canvas, WordPress) allow users to add meaningful headings, as well. It is absolutely essential to make sure that all headings are actually coded as headings, or screen reader users will not be able to identify them. Do not use manual formatting (e.g. font size, bold) to make text look like a heading.

Because headings apply formatting, sometimes it can be tempting to use a heading to format some other section of text. Do not do this, as the text will then be coded as a heading, and will be listed when screen reader users skim through the page's headings.

Heading Hierarchy

In general, every page should have a level one heading (h1) with the title of the page. Except for special situations (typically involving embedded pages and iframes), that should be the only level one heading (h1) on the entire page. After that, increasing heading levels provide further specificity to page content. It may be helpful to plan out your heading structure before writing the page. This will help you both to ensure that the heading hierarchy is correct and to organize your thoughts.

  1. Do not skip heading levels to be more specific (for example, do not skip from h2 to h5). It is perfectly acceptable, however, to skip headings in the other direction (for example, from h5 to h2).
  2. Do not select heading levels based on their appearance. Select the appropriate heading rank in your hierarchy.


Like headings, lists are semantic elements. They both provide visual formatting and provide behind-the-scenes structure that screen reader users can access.

  1. Format all lists as "real" lists. Rich text editors will provide buttons to create both numbered lists and unordered lists.
  2. Consider using ordered lists with different numbering systems for each level when creating nested lists, as screen readers do not usually distinguish levels of indentation. Penn State University provides a useful example of a nested list.


An accessible link is usable, has good link text, and does not cause any unexpected behavior.

  1. Links must have a non-empty href attribute. A link with href="#" that uses javascript to define its behavior is not considered accessible.

Link Text

Screen reader users may navigate from link to link. Their screen reader may even provide a list of links in alphabetical, rather than page, order. Thus, links should make sense out of context and out of order. Avoid using "click here" or "read more" as these are meaningless without context.

While links do need to make sense out of context, they should not be overly wordy. Keep link text short and to the point.

Some other points to remember:

  1. Do not use the URL as link text. Not all URLs provide clear information about where they lead. Even in cases where the URL is clear, it is still harder to read for both sighted users and screen reader users.
  2. Put identifying information about a link at the beginning. For example, if a link opens in a new window, indicate that after the normal link text. This makes it easier for screen reader users to distinguish between links and saves them time and frustration.
  3. Do not write "link" or "link to" in the link text or in the alt text of an image link. Screen readers will announce that it is a link, and the formatting should already make it clear visually that it is a link.

Link Examples

Expected Behavior

Links should never do anything unexpected. What may be merely irritating for sighted users may cause a lot of difficulty for screen reader users. The main issues are links that open in new tabs and links that automatically download files.

  1. Always indicate when a link opens in a new tab. If you cannot provide this indication, make sure the link will open in the same tab, instead.
  2. Always indicate when a link opens a PDF or downloads content. Your sighted users will also thank you.

There are several strategies for providing this kind of indication. Web developers may use a span only presented to screen readers with text indicating that the link will open in a new tab. When this is included along with the external link icon, the link behavior will be clear to all users. If content creators do not have this option, they may include text indicating the link behavior directly within the link itself. This strategy is much easier when it comes to automatic downloads. For example, for a link that downloads a word (docx) document called Being Awesome, you could provide "Download Being Awesome (docx)" as the link text.

Links and Images

Sometimes an image may be used as a link, or an image may be included as part of a link. These require some special considerations.

  1. If a link involves only an image, make sure the alt text provides the needed link text, so that screen reader users still know what to expect.
  2. If a a link involves both link text and an image, make sure these are bundled together as one link, rather than as two separate links to the same location.
  3. Link text/alt text for these kind of links can be tricky. The Alternative Text section will have more detailed advice for how to deal with this.

Other Link Considerations

  1. Avoid and remove empty or broken links.
  2. Make sure links are underlined and a different color than the rest of the text, to make them clear to sighted users.
  3. Do not use buttons as links. It is fine to format a link to look like a button, as long as it is still coded to look like a link.
  4. Do not use links as buttons. If the link provides a special function instead of opening a new page, it should be coded as a button.
  5. Pay extra attention to pagination or alphabetized links. You will need to ensure that the link text provided to screen reader users conveys the necessary information about where the link goes.
  6. Do not include extra information in a title attribute. The title attribute is not accessible for all users. (If you are not writing HTML/do not know what this means, you should be fine.)

Checking for Empty or Broken Links

WAVE (a very useful testing tool) can check for empty links, but it cannot check for broken ones. There are various tools that can be used to check for broken links, though many of these cost money. Some content management systems may also have tools built into them. Of course, you can always manually check by clicking on each link, but that can be a pain if you have a lot of links. W3C (the World Wide Web Consortium) offers a free link checking tool that may be worth trying out.

Block Quotes

Block quotes can be a bit complicated, especially since they often need to be combined with other HTML elements.

  1. The text in the <blockquote> element should include only the actual quote.
  2. The author/source of the quote can be included using the <figcaption> element if both the block quote and the caption are enclosed within a <figure> element.
  3. The <cite> element should only be used for the source, not the author.
  4. The <q> element should be used for inline quotations to improve the quality of semantic markup (and to handle automatic quotation marks).

Here is an example of a blockquote with the author and source both cited:

        <p>You can't believe everything you read on the internet.</p>
    <figcaption>- Abraham Lincoln, <cite>This Random Book I Made Up</cite></figcaption>

Unfortunately, if you are styling the <blockquote> element, this may not look the way you want it to. You may want to add class="quote" to the <figure> element and style the "quote" class instead.

Note that while <figure> and <figcaption> are shown here with <blockquote>, they can be used in other contexts, as well. For example, this is one way that alternative text can be associated with an image.


Tables are a useful way to structure data, both visually and semantically. Historically, tables have also sometimes been used for formatting content, before CSS provided better options. These tables are often referred to as layout tables or formatting tables. Penn State University has some useful tips for implementing formatting tables.

Simple tables have at most one header row and one header column, and they do not contain any merged cells. Simple tables are more accessible than complex tables.

  1. Define column and row headers. The HTML should use the <th> tag and the scope attribute for this. This helps the screen reader organize the data to be read in a logical order and identify data types.
  2. Do not leave any table header cells empty. The most common offender is the top left cell in tables with both a row and column header.
  3. Do not put multiple values in the same cell. Each separate piece of data should have its own cell.
  4. Use a title or caption to display a title for the table. Ideally, the <caption> tag containing the title should be above the table as the first thing after the opening <table> tag.
  5. If necessary, use the summary attribute to clarify the organization of the table or provide a quick summary of its content. The summary should not repeat information in the caption, but can be used to supplement that information. Unlike the caption, the summary will only be presented to screen readers.
  6. The <thead> and <tfoot> elements define header and footer rows for tables. Like the <tbody> tag, these do not provide additional accessibility, but they are not inaccessible, either. They may be useful for long tables, and they are certainly helpful for styling the table.

Table Styling

  1. Align text to the left and numeric data to the right (in left-to-right languages). This is especially helpful for people using larger text sizes or smaller screens. It is also a good idea to give column headers the same alignment as the data in the cells below.
  2. Styling even and odd rows in a different way can act as a helpful visual guide, especially for people who have reading difficulties or who enlarge text. Also consider highlighting the cell (and row/column) on mouseover (hover) and keyboard focus to help people see where they are. Make sure that the contrast ratio between the text and background is good for both headers and data cells.
  3. Tables may be too wide for people using higher zoom levels or smaller screens. Make sure text is not cut off. Horizontal scrolling is typically frowned upon, but using overflow: scroll (instead of overflow: hidden) is a reasonable way to ensure users will still be able to access the table.
  4. Let the browser window determine the width of the table whenever possible, to reduce the horizontal scrolling required of those with low vision. If cell widths need to be defined, use relative values, such a percentages, rather than pixel values. Avoid defining cell heights to allow cells to expand downward to accommodate their content.
  5. Do not use empty cells to visually format the table, such as to indicate a division in various sections of the table. One alternative in that situation would be to use multiple tables, instead.

Complex Tables

Ideally, complex tables should be avoided. If at all possible, consider replacing one complex table with a series of simple tables. If you must use a complex table, it is theoretically possible to make the table accessible, but this can be very time consuming to implement and may not end up being accessible in practice.

  1. Avoid merging cells.
  2. Use the id and headers attributes to associate data cells with header cells.


Miscellaneous Elements

HTML has a wide selection of meaningful elements. Many of these are not currently recognized by screen readers, which will typically treat them as ordinary text. Examples include <kbd>, <ins>, <del>, and <code>, among others. If these elements will be used to convey information, you may want to use CSS to add screen reader features. For example, the <ins> element is used for inserted text, while the <del> element indicates deleted text. Assuming they are used correctly, it is pretty important to know what text has been added or removed. Screen readers can be informed of these elements using the CSS before and after psuedo-elements.

del::before, del::after, ins::before, ins::after {
    /* insert code used for screen reader only class to hide content visually */
del::before {
    content: " [deletion start] ";
del::after {
    content: " [deletion end] ";
ins::before {
    content: " [insertion start] ";
ins::after {
    content: " [insertion end] ";