Here are some of the basic considerations to help you get started writing web content that is more accessible to people with disabilities. These tips are good practice to help you meet accessibility requirements.

Provide informative, unique page titles

For each web page, provide a short title that describes the page content and distinguishes it from other pages. The page title is often the same as the main heading of the page. Put the unique and most relevant information first; for example, put the name of the page before the name of the organization. For pages that are part of a multi-step process, include the current step in the page title.

Use headings to convey meaning and structure

Use short headings to group related paragraphs and clearly describe the sections. Good headings provide an outline of the content.

Make link text meaningful

Write link text so that it describes the content of the link target. Avoid using ambiguous link text, such as ‘click here’ or ‘read more.’ Indicate relevant information about the link target, such as document type and size, for example, ‘Proposal Documents (PDF, 20MB).’

Write meaningful text alternatives for images

For every image, write alternative text that provides the information or function of the image. For purely decorative images, there is no need to write alternative text. Alternative text is usually not visible. Include Clemson University, Clemson, SC in the text for SEO purposes.

Create transcripts and captions for multimedia

For audio-only content, such a podcast, provide a transcript. For audio and visual content, such as training videos, also provide captions. Include in the transcripts and captions the spoken information and sounds that are important for understanding the content, for example, ‘door creaks.’ For video transcripts, also include a description of the important visual content, for example ‘Athan leaves the room.’

Provide clear instructions

Ensure that instructions, guidance, and error messages are clear, easy to understand, and avoid unnecessarily technical language. Describe input requirements, such as date formats.

Keep content clear and concise

Use simple language and formatting, as appropriate for the context.

• Write in short, clear sentences and paragraphs.
• Avoid using unnecessarily complex words and phrases. Consider providing a glossary for terms readers may not know.
• Expand acronyms on first use. For example, Clemson Computing and Information Technology (CCIT).
• Consider providing a glossary for terms readers may not know.
• Use list formatting as appropriate.
• Consider using images, illustrations, video, audio, and symbols to help clarify meaning.

Although you can create accessible PDF files in several programs, Adobe Acrobat Professional is required to evaluate, repair, and enhance the accessibility of existing PDF files.

Tags Pane

The Tags pane allows you to view, reorder, rename, modify, delete, and create tags. Many of these actions can be completed more easily using the TouchUp Reading Order tool, but there are some actions that can only be accomplished in the Tags pane.

To view the Tags pane, select View > Show/Hide > Navigation Panes > Tags. This pane displays the all the tags within the PDF, organized in a tree structure. This tags tree can be navigated, expanded, and collapsed using a mouse or the arrow keys on the keyboard.

Many of the tags are similar, if not identical to HTML. The most notable exception is the tag, which is similar to the tag in HTML.

How To

Highlight Content

• When the Highlight Content option is selected in the Options menu, selecting a tag should highlight the corresponding text, image, or other element in the PDF file.

Find Tag from Selection

• Just as selecting a tag highlights the content in the body of the PDF file, there is a way to accomplish the opposite effect of highlighting the tag that corresponds to selected content. First, click on the  Select Tool. Next, select text, an image, or a table. Finally, select the Options menu at the top of the Tags pane and then select Find Tag from Selection. This will highlight the tag or tags that contain the content you previously selected.

Change Tags

• At times, you will encounter a PDF file that contains incorrect tags. You can modify these by right-clicking the tag you want to change, selecting Properties, then the Tag, and then selecting the appropriate new tag type from the dropdown list labeled Type.

Add tags to an Untagged Document

• To add tags to an untagged document, choose Tools from the right-hand menu, then select Accessibility > Add Tags to Document. This process can sometimes be time-consuming, and you will almost certainly have to edit some of the tags, but it is usually faster than doing all the work manually. This is especially true if the document contains tables.

PDF files are not typically created in Acrobat. They are usually created in another program and converted to PDF. There are dozens or probably hundreds of programs that can create PDF files, but very few of them produce tagged PDF files. If you are using Microsoft Word or PowerPoint, OpenOffice.org Writer, or Adobe tools such as InDesign, you can often create accessible, tagged PDF files without opening Acrobat. Of course, the accessibility of the PDF depends on the accessibility of the original document.

Microsoft Word

The majority of the PDF files on the web were probably created in Microsoft Word. The good news is that it is possible to create accessible PDF files in Office, as long as the following requirements are met:

1. The file must be accessible. That includes providing alternative text for images, proper headings, appropriate link text, etc. For more information, read the WebAIM tutorial on Microsoft Word.
2. Office 2000-2003 users must have Acrobat installed, as well as the add-in.
   Office 2007 users must have either Acrobat or the Microsoft PDF add-in installed.
   Office 2010 users can create tagged PDF files natively or with the Adobe add-in.
3. The file must be exported correctly. If a file is created by printing to PDF, it will not be correctly tagged.

Caption and Summary

Captions and summaries provide information that can help users find, navigate, and understand tables. While they are not required in every case to meet WCAG 2.0, captions and summaries are fairly straightforward ways to provide such information that is often needed.

• A caption functions like a heading for a table. Most screen readers announce the content of captions. Captions help users to find a table and understand what it’s about and decide if they want to read it. If the user uses “Tables Mode”, captions are the primary mechanism to identify tables. The caption is provided by the <caption> element.
• A summary conveys information about the organization of the data in a table and helps users navigate it. For example, if a table has an unusual structure (as in the examples below), information about what content can be found in which row or column can be provided to the user. A summary is usually only needed for complex tables.

If both caption and summary are provided for one table, the summary should not duplicate information present in the caption.

If you’re not a screen reader user, let’s pretend that you are for just a moment. You’re going to a web site to find out where the biology 205 class is going to be held. You go to a web page that has this information, and this is what you hear:

Table with 10 columns and 7 rows. Department Code, Class Number, Section, Max Enrollment, Current Enrollment, Room Number, Days, Start Time, End Time, Instructor, BIO, 100, 1, 15, 13, 5, Mon,Wed,Fri, 10:00, 11:00, Magde, 100, 2, 15, 7, 5, Tue,Thu, 11:00, 12:30, Indge, 205, 1, 15, 9, 6, Tue,Thu, 09:00, 10:30, Magde, 315, 1, 12, 3, 6, Mon,Wed,Fri, 13:00, 14:00, Indge, BUS, 150, 1, 15, 15, 13, Mon,Wed,Fri, 09:00, 10:00, Roberts, 210, 1, 10, 9, 13, Mon,Wed,Fri, 08:00, 09:00, Rasid.

After listening to this information, do you have any idea where biology 205 is supposed to be held? Probably not. When you listen to tables straight through, without going into table reading mode in a screen reader, this type of information can be quite confusing. Even when you do go into table reading mode, it can still be confusing if the table is not marked up properly.

Layout Tables vs. Data Tables

There are two basic uses for tables on the web: data tables and layout tables. The original intended use of HTML tables was for tabular data. A table is a data table when row headers, column headers, or both are present. For example, here is a simple data table:

Tables are also commonly used for page layout. Layout tables do not have logical headers that can be mapped to information within the table cells. Layout tables were traditionally used to overcome limitations in visual presentation and layout using HTML. With CSS, however, there is much more flexibility in controlling page layout, so it is best to not use tables to do this. Using CSS results in cleaner and more simple HTML code, better end user adaptability, and few potential accessibility issues.

It is sometimes suggested, even by some accessibility advocates that layout tables are bad for accessibility. In reality, layout tables do not pose inherent accessibility issues. There are certainly many worse things that you could do in terms of accessibility. People with all kinds of disabilities can easily access layout tables, as long as the tables are designed with accessibility in mind – ensuring proper linearized reading order, content scaling, etc.

Layout Table Linearization

Content linearization refers to the order of the content when all formatting is removed. For both data and layout tables, the order in which content is presented can affect its meaning. Many web sites use tables for layout, and most of them use spanned rows and columns to achieve formatting effects. The end result is that the linearized reading order may not be the same as the visual reading order. This can lead to confusion on the part of people who access the linearized reading and navigation order, such as individuals who use screen readers or who navigate with keyboards.

Screen readers essentially ignore the fact that the content is inside of a table. The screen reader just reads the content in the literal order that it appears in the code. If the literal order of the content in the code is logical, then your linearized reading order is logical.

Screen readers treat layout tables and data tables very differently. For layout tables, they simple read the content of table based on the source code order. For data tables, however, they will identify the presence of the table including number of columns and row, provide table navigation functionality, read row and column headers, etc.

So how does a screen reader know if a table is a data table or a layout table?

They perform some analysis of the table markup and structure to ‘guess’. Because of this, it’s vital that data table markup, such as <caption>, <th>, etc. are NEVER used within layout tables, otherwise the screen reader may incorrectly present the table as a data table causing increased overhead and confusion.

Layout Table

When author’s use tables for layout, they are typically doing so to get more precise and (supposedly) flexible control over the positioning of elements within the page. When doing so, layout tables typically define pixel values to attempt to control exact positions. Because there is an immense range of end user browsers and devices, ranging from text-only mobile browsers to large-screen, high definition displays, defining pixel-based sizing is very limiting.

A primary concern of layout tables is their lack of flexibility for accommodating end-user content adjustments, primarily text sizing by users with low vision. If text within a pixel-sized table cell is enlarged by the end user, this can cause readability issues, especially if the text can no longer fit within the pixel dimensions defined. This may result in horizontal scrollbars, text bleeding out of the cell and overlapping other page components, etc. If using layout tables, ensure that the structure of the table allows end user customization and text scaling.

It is possible to create all kinds of nested tables and unnecessary rows and columns, using spanned rows and columns in every which way, until the table hardly looks like a table at all anymore. All of this may be invisible to sighted users if the table borders are set to zero, but blind users will “see” it all. Their screen readers may inform them of the number of rows and columns in the table. When they try to navigate from one area to the other within the table, they may become disoriented. The rule of thumb here is, the simpler the better.

Although WCAG 2 does not prohibit the use of layout tables, CSS-based layouts are recommended in order to retain the defined meaning of the HTML table elements and to conform to the coding practice of separating presentation from content.

Data Tables

The purpose of data tables is to present tabular information in a grid, or matrix, and to have column or rows that show the meaning of the information in the grid. Sighted users can visually scan a table. They can quickly make visual associations between data in the table and their appropriate row and/or column headers. Someone that cannot see the table cannot make these visual associations, so proper markup must be used to make a programmatic association between elements within the table. When the proper HTML markup is in place, users of screen readers can navigate through data tables one cell at a time, and they will hear the column and row headers spoken to them.

Table Captions

Data tables very often have brief descriptive text before or after the table that indicates the content of that table. This text should be associated to its respective table using the <caption> element. The <caption> element must be the first thing after the opening <table> tag.

Identify Row and Column Headers

A critical step toward creating an accessible data table is to designate row and/or column headers. In the markup, the <td> element is used for table data cells and the <th> element is used for table header cells. Going back to our original data table example, the column headers for this table are Name, Age, and Birthday. The row headers are Jackie and Beth. Also note the associated caption.

Table headers should never be empty. This is particularly of concern for the top-left cell of some tables.

Associate the Data Cells with the Appropriate Headers

Now that we’ve created headers, we need to associate the data cells with the appropriate headers.

The scope attribute

The scope attribute identifies whether a table header is a column header or a row header. Here is the markup for the table, using the scope attribute:

<table>
<caption>Shelly's Daughters</caption><tr>
<th scope=”col”>Name</th>
<th scope=”col”>Age</th>
<th scope=”col”>Birthday</th>
</tr><tr>
<th scope=”row”>Jackie</th>
<td>5</td>
<td>April 5</td>
</tr><tr>
<th scope=”row”>Beth</th>
<td>8</td>
<td>January 14</td>
</tr>

</table>

The scope attribute tells the browser and screen reader that everything within a column that is associated to the header with scope="col" in that column, and that a cell with scope="row" is a header for all cells in that row.

All <th> elements should generally always have a scope attribute. While screen readers may correctly guess whether a header is a column header or a row header based on the table layout, assigning a scope makes this unambiguous.

Scope will apply even if the table is complex with multiple levels of headers (such as in spanned cells). The scope of a table header will apply to all cells over which that header spans.

In this example, the “by birth” row header has a scope of row, as do the headers with the names. The cell showing the age for Jackie will have 3 headers – one column header (“Age”) and two row headers (“by birth” and “Jackie”). A screen reader would identify all of them, including the data cell content (e.g., it might read “by birth. Jackie. Age. 5.”).

Despite being standard markup for tables for many years, some screen readers still do not fully support complex tables with spanned or multiple levels of row and/or column headers. When possible, try to ‘flatten’ the table and avoid spanned cells and multiple levels of header cells.

The headers and id attributes

Another way to associate data cells and headers is to use the headers and id attributes. This method is NOT generally recommended because scope is usually sufficient for most tables, even if if the table is complex with multiple levels of headers.

In extremely complex tables where scope may cause table headers to apply to (or have a scope for) cells that are not to be associated to that header, then headers and id may be used. In these cases, while headers and id might make the table technically accessible, if there are multiple levels of row and/or column headers being read, it will not likely be functionally accessible or understandable to a screen reader user.

With this approach, each <th> is assigned a unique id attribute value. Then, each and every <td> cell within the table is given a headers attribute with values that match each <th> idvalue the cell is associated to. The values are separated by spaces and should be listed in the order in which a screen reader should read them. If using headers/id in the example above, the cell for Jackie’s age might be marked up as <td headers="birth jackie age">5</td>).

Again, it should be emphasized that this method is more complex, uses much more markup (and potential to become broken), and is rarely necessary (use scope instead).

Use Proportional Sizing, Rather than Absolute Sizing

The rule that applies to layout tables also applies to data tables. 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. Defined cell heights should generally be avoided so the cell can expand downward to accommodate its content – something especially useful for users with low vision that may enlarge text content.

Other table markup

Summary

The summary attribute of the <table> tag may be used to provide a summary of a data table structure (not content). Support for summary varies, but in general, it is screen reader specific (it’s not accessible to anyone else) and is not well supported. Additionally, the summaryattribute is not part of the HTML5 specification. In general, if a table is so complex that it needs an explanation of how it is structured, it probably is not very accessible and should probably be simplified. For these reasons, we do not recommend the use of summary. If it is used, it must never be used for layout tables.

thead, tfoot, and tbody

The thead and tfoot elements define header and footer rows for tables. They provide no accessibility functionality and are generally only of use when a long table is printed – the head and/or foot rows will repeat at the top or bottom of each printed page. Similarly, the tbodyelement defines the body content of a data table (meaning anything that’s not a thead or tfood). Again, this element does not provide any additional accessibility benefit, but there is no harm in using it for table styling or other reasons.