Creating Accessible Layout or Data Tables

Posted on by Carol J Usher

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:

Shelly’s Daughters
Name Age Birthday
Jackie 5 April 5
Beth 8 January 14

 

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.

Shelly’s Daughters
Name Age Birthday
Jackie 5 April 5
Beth 8 January 14

 

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.

Shelly’s Daughters
Name Age Birthday
by birth Jackie 5 April 5
Beth 8 January 14
by marriage Beth 8 January 14

 

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.

Posted in Cascade Resources, Cascade Server How-To...Tagged

Procrastination Solutions

Posted on by Carol J Usher

Strategies for Combating Procrastination

  • Take control of your environment – work in a place that is free from distractions as much as possible.
  • Make a “TO DO” list.
  • Establish a routine.
  • Self-bribery — give yourself rewards.
  • Divide and Conquer — break larger tasks into smaller units — thereby eliminating how daunting the task seems. As you complete each small unit, move on to the next one. Before you know it, you’ll be done
  • Use a planner for time management.
  • Use the 10-minute rule. When you have trouble getting started, select a specific task to work on for 10 minutes. At the end of 10 minutes, see how much you’ve done. Keep working in 10-minute blocks until you are satisfied with what you have done.
  • When you finish working on a task, do one more thing before you quit then you will be ahead when you sit down the next time.

List created by Annie Passarello, GTA, Academic Success Center

Posted in Cascade Resources

Accessible Color and Contrast

Posted on by Carol J Usher

People who are color blind, vision impaired  or who have an age-related impairment often struggle to read text when there isn’t enough contrast between the color of the text and its background. There are two levels of requirements for color contrast, depending on the level of conformance your website is aiming to achieve.

  • Ensure that information conveyed by color differences is also communicated in text or via other visual cues.
  • Check that the contrast between text (or images of text) and background color meets the color contrast requirements that are applicable to your website’s level of conformance (WCAG 2.0 Level AA or Level AAA). Logos, decorative text and incidental text are exempt.
  • Use a larger font size or higher contrast ratio for lightweight fonts or fancy fonts.

Minimum contrast requirements (Level AA):

  • For text (and images of text) that is less than 18 points or less than 14pt bold, check that the contrast ratio between text and its background is at least 4.5:1.
  • For text (and images of text) that is 18 points or 14pt bold or larger, check that the contrast ratio between text and its background is at least 3:1.

Enhanced contrast requirements (Level AAA):

  • For text (and images of text) that is less than 18 points or less than 14pt bold, check that the contrast ratio between text and its background is at least 7:1.
  • For text (and images of text) that is 18 points or 14pt bold or larger, check that the contrast ratio between text and its background is at least 4.5:1.

Check your color/contract here: Clemson’s Palette

Check your color/contrast here: Color Contrast Checker

For more information, see 272: Color Accessibility with Geri Coady

Posted in Cascade Resources, Clemson Web Style Guide

Using Accessible Headings

Posted on by Carol J Usher

It is important to use headings to structuring a page into sections and provide the user with an idea of what content will follow.

They are even more important for blind and vision impaired users as they allow content to be easily navigated – this means using heading levels rather than styling text with large or bold fonts. Headings are also good for search engine ranking.

  • Organise your content into sections.
  • Ensure that each section of content is identified by a heading.
  • Ensure that each heading describes and identifies its section of content.
  • Keep headings short and succinct.
  • Ensure headings are properly nested within each section of the document. For example, a Heading 2 must follow a Heading 1; a Heading 3 must following a Heading 2 and so on within each section.
  • Mark headings using HTML heading elements <h1> … <h6>. Increasing text size or using styles (e.g. emphasis or strong emphasis) is not the same as using heading elements.
  • Avoid use of abbreviations and jargon in headings.
Posted in Clemson Web Style Guide, How To..., Tips and Tricks

Accessible Links on Web Pages

Posted on by Carol J Usher

“Click here” and “read more” links should be updated immediately! Link text should be meaningful and make sense out of context. It should describe the purpose of a link and if linking to a download, also include the file type and file size, especially when it’s a large file that will require time to download.

  • The best approach is to write link text that describes the purpose of the link without the help of surrounding text wherever possible (level AAA requirement).  Otherwise, write link text that describes the purposes of the link with surrounding elements and including the information needed to clarify the link before the link.
  • Ensure link text is as short and concise as possible.
  • Avoid using “click here” or “read more” or any other phrases that are ambiguous or unclear. Also avoid using URLs for link text.
  • For links to email addresses, use the email address as the link text.
  • For links to documents and files, include the file type (e.g. PDF, Word) and the file size within the link text.
  • Meaningful links improves search engine ranking.
  • Ensure that links to the same location have are referred to consistently, or use the same link text.
  • Ensure that links to different locations do not use the same link text.
Posted in Cascade Resources, How To..., Tips and Tricks

Giving to Clemson

Posted on by Carol J Usher

Charitable Contributions to or on behalf of the CU Foundation or any other 501c3 organization whose mission is to support Clemson University, cannot be solicited, nor can they be accepted, unless approved in advance by the CU Foundation. For information on obtaining appropriate approval for such contributions, please contact Gift Receiving Office.

Posted in Clemson Web Style GuideTagged , , ,

Password protect Web pages

Posted on by Carol J Usher

Creating a text file called “htaccess.txt” (all lowercase and no quotes) is a simple way to password protect certain Web pages.

Create a new file in any text editor such as Notepad (Windows) or Text Edit (Mac) and name it htaccess.txt. Copy the following text in red into your htaccess.txt file.

AuthType shibboleth
ShibRequireSession On

require valid-user

The example  above will allow access to anyone with a valid Clemson userid and password (more options below).

Save the file and upload it to the same folder as the page want to password protect. If you are using Cascade, you will need to publish it to the server to enable the protection. Please note that if you have already logged in recently you may need to restart your browser before it will ask you to re-login.

Note: every asset in the same folder as the htaccess.txt file will be password protected.

The level of security varies with the options outlined in the file.

If you want to limit access to specific userids, then you would replace the valid-user variable with the specific valid userids:

require userid1
require userid2
require userid3

This will allow only the users userid1, userid2 and userid3 to have access.

Maybe you want to restrict access to just employees?

require primary-affiliation employee

Or perhaps only users of a specific blackboard workgroup?

require edirgroup .workgrouptest.workgroups.sitesets.clemsonu

 

For more information, visit CCIT’s page on Htaccess Controls.

Posted in Webmaster Tools ResourcesTagged

Size images for branded pages

Posted on by Carol J Usher

You can float images by adding the class right or left. Optionally, pair this with the code data-size="" to specify an image’s size.

  • full – image will fill 100% of its container
  • medium – image will fill 60% of its container
  • small – image will fill 40% of its container
HTML
<img src="" alt="image alt text" data-size="full">
<img src="" alt="image alt text" data-size="medium" class="right">
<img src="" alt="image alt text" data-size="small" class="left">
Image Sizes for Responsive Templates:

Page with left navigation, full width top of page: 1001 pixels by 350 pixels
Spotlights: 400 pixels by 300 pixels

For more information, see: Style Guide/Images.

See sample layout pages here.

 

Posted in Cascade Server How-To...Tagged ,

Video Standards and Guidelines

Posted on by

Video Standards:
The standard file format for video is MPEG-4.

Sizes:
Format: Small (talking head)
size: ~240 x 180 3:4 16:9
Data Rate: 400
Frames: 10 fps
On2 VP 6

Format: Medium
size: ~360 x 240 3:4 16:9
Data Rate: 200
Frames: 10 fps
On2 VP 6

Formatting standards for special occasion files that do not fall under the “small” or “medium” formats may be available upon request.

Other Video Requirements:
Video will not pop-up as a standalone browser window.
Media player skin design will not be user configurable.
Media player will be embedded into template design.

We highly encourage you to use descriptive copy with your video.

Note: Captions are required on all video content placed on any Clemson University Web site. This is to ensure Section 508 Accessibility compliance as mandated by the state of South Carolina. This guide is being further developed by the Web Leadership Team and will soon update the information here.

Video Guidelines:
Videos for the Web should contain either closed captions or a link to a transcript. If these options are not available, the individual posting the video must make a transcript available upon demand. The contact information for the person responsible for providing the transcript must be included with the video.

Video for the Web must comply with all applicable state and federal laws for intellectual property rights, including copyright and trademarks.

If you are posting audio and/or video available to the public on the Clemson University domain, you must notify University Relations, Robbie Fitzwater at rfitzwa@clemson.edu. When non-compliant videos/pages are identified by OWS or the New Media Team, they will contact the responsible department or individual to resolve the issue.

Archiving: A copy of the video must be on tape, DVD or server as long as the video is on the Web for legal purposes and to replace any corrupted files. The owner of the video is responsible for contacting Clemson University Archive/Records Management to determine whether or not a copy needs to be in the University Archives as well.

Video on YouTube:
Clemson University’s YouTube channel has been reorganized to help give you access to all the latest Clemson-related videos. The channel is managed by the Clemson Marketing Services Department, with the goal of including all University, college, departmental and alumni-related videos. In order to continue to build an expansive library, we need your help in gathering all existing and future Clemson videos.

Only official and approved Clemson University, college, departmental and administrative unit videos, or select videos approved by the CNMT, will be posted to Clemson’s YouTube Channel.

The channel will serve as a key promotional tool for your college or department, receiving thousands of views every month. Additionally, once videos are uploaded, they can be embedded on Clemson Web sites and Facebook pages.

Learn more about Video on YouTube here.

Resources:

Approved by the Web Leadership Team, March 10, 2008
Under review by the Office of General Counsel, April 7, 2008

Posted in Clemson Web Style GuideTagged ,

Web page required content

Posted on by Carol J Usher

While content will vary from site to site, the presentation of the content should be consistent and support Clemson’s position as one of the top public universities in the country. Proper use of visual identity elements such as colors, logos and type fonts ensures that you are enhancing the Clemson brand. If you have questions about identity or branding and how it is to be implemented on the Web, please contact ows@g.clemson.edu.

Web pages created outside of Cascade are required to contain the following:

  1. Include the official masthead with a link to the Clemson University homepage and its other University-wide links (Map, Phonebook and hidden link Text Only) and optional A-Z Index, Calendar, University or Department Search.
  2. Include the official footer and its University-wide links (Website Information, Contact Clemson, University Index).
  3. Include contact information about who maintains the site, including name and email, department mailing information and phone number.
  4. Meet Section 508 accessibility compliance. For more information see the WebAIM Section 508 Checklist.
  5. Follow all copyright and intellectual property laws.
  6. If your site doesn’t meet these minimum requirements, a properly-branded landing page will be created for your www.clemson.edu/xxx URL. A link on this page will then point people to your site.
Posted in Clemson Web Style GuideTagged , 1 Comment on Web page required content