Web Services Blog

Defining Acrobat PDF Accessibility

Posted on by Carol J Usher

Before discussing the accessibility of PDF files, it is important to distinguish between Adobe, Acrobat and PDF. These terms are often used interchangeably, but they are not the same.

  • Adobe is a company; they are the creators of Acrobat.
  • Acrobat is a tool for creating, editing and viewing PDF files.
  • PDF is a format or type of document. It stands for Portable Document Format. The PDF format was created by Adobe.

The terms Adobe, Acrobat, and PDF are related in the same way as Microsoft, Word, and doc.

PDF Tags

When people talk about “accessible” PDF files, they usually are referring to “tagged” PDF files, even though there is more to an accessible PDF than tags. PDF tags provide a hidden structured, textual representation of the PDF content that is presented to screen readers. They exist for accessibility purposes only and have no visible effect on the PDF file.

HTML tags and PDF tags often use similar tag names (e.g., both have tags named h1) and organization structures, but they really are quite different. If you are comfortable with HTML, you will probably have an easier time creating and editing tagged PDF files.

Posted in Cascade ResourcesTagged

Tips and Tricks for Images

Posted on by Carol J Usher

Tips and Tricks

  • Choosing appropriate text alternatives:
    Imagine that you’re reading the web page aloud over the phone to someone who needs to understand the page. This should help you decide what (if any) information or function the images have. If they appear to have no informative value and aren’t links or buttons, it’s probably safe to treat them as decorative.Decorative images don’t add information to the content of a page. For example, the information provided by the image might already be given using adjacent text, or the image might be included to make the website more visually attractive.In these cases, a null (empty) alt text should be provided (alt="") so that they can be ignored by assistive technologies, such as screen readers. Text values for these types of images would add audible clutter to screen reader output or could distract users if the topic is different from that in adjacent text. Leaving out the alt attribute is also not an option because when it is not provided, some screen readers will announce the file name of the image instead.
  • Prioritize information in text alternative:
    Aim to put the most important information at the beginning. Include “Clemson University, Clemson South Carolina” in the alt tag for SEO purposes.
  • Length of the text alternative:
    The alt text should be the most concise description possible of the image’s purpose. If anything more than a short phrase or sentence is needed, it would be better to use one of the long description methods.Complex images contain substantial information using long description methods are typically:

    • graphs and charts, including flow charts and organizational charts;
    • diagrams and illustrations where the page text relies on the user being able to understand the image;
    • maps showing locations or other information such as weather systems.

    In these cases, a two-part text alternative is required. The first part is the short description to identify the image and, where appropriate, indicate the location of the long description. The second part is the long description – a textual representation of the essential information conveyed by the image. Remember that complex images can be difficult to understand by many people – in particular people with learning disabilities and people with low vision. Long descriptions benefit many people, and it is good practice to make them available to everyone, for example, as part of the main content. It may also be possible to reduce unnecessary complexity in your images and make them easier to understand for everyone.

    It is also good practice to refer to and summarize more complex images from the accompanying text. For example, a reference such as “The following graph shows that visitors were lost in the first quarter, but the numbers recovered in the second quarter” helps to point out the relevant information that the image is intended to present.

  • Punctuation within alt attributes:
    • As for any text, using punctuation in the text alternative makes the information easier to understand. In particular, remember to add space characters in the alt text when there’s no space character between the image and adjacent text, to avoid having words running together when they are read by a screen reader.
    • If you use a null (empty) text alternative (alt="") to hide decorative images, make sure that there is no space character in between the quotes. If a space character is present, the image may not be effectively hidden from assistive technologies. For instance, some screen readers will still announce the presence of an image if a space character is put between the quotes.
  • Superfluous information in the text alternative:
    Usually, there’s no need to include words like “image”, “icon”, or “picture” in the alt text. People who can see will know this already, and screen readers announce the presence of an image. In some situations, it may be important to distinguish between paintings, photographs, or illustrations, etc., but it’s best to avoid the more generic use of the terms.
  • SVG graphics:  Scalable Vector Graphics (SVG) is an XML-based vector image format for two-dimensional graphics with support for interactivity and animation. The SVG specification is an open standarddeveloped by the World Wide Web Consortium (W3C) since 1999.SVG images and their behaviors are defined in XML text files. This means that they can be searched, indexed, scripted, and compressed. As XML files, SVG images can be created and edited with any text editor, as well as with drawing software.All major modern web browsers—including Mozilla Firefox, Internet Explorer, Google Chrome, Opera, Safari, and Microsoft Edge—have SVG rendering support.
    • SVG graphics can be referenced in the src attribute of an <img> element like other image formats (PNG, JPEG, GIF).
    • As SVG images consist of tags like HTML, their code can also be used in HTML5 directly. In this case you can provide a text alternative in a <title> element within the SVG image. To improve accessibility support, that title should be referenced from an aria-labelledby attribute of the <svg> element, for example:<svg aria-labelledby="svgtitle1"> <title id="svgtitle1">Settings</title> [other svg code] </svg>
  • Logos:
    Logo images with text are exempt from some of the accessibility requirements. For instance, there is no minimum contrast requirement.
Posted in Cascade Resources, Tips and Tricks

Web Forms

Posted on by Carol J Usher

Web Forms

Forms are commonly used to provide user interaction on websites and in web applications. For example, login, requesting information, registering, commenting, and purchasing. The same concepts apply to all forms, whether they are processed client or server-side.

Aside from technical considerations, users usually prefer simple and short forms. Only ask users to enter what is required to complete the transaction or process; if irrelevant or excessive data is requested, users are more likely to abandon the form.

  • Labeling Controls:
     Use the <label> element, and, in specific cases, other mechanisms (e.g. WAI-ARIA, title attribute etc.), to identify each form control.

    <label for="firstname">First name:</label>
<input type="text" name="firstname" id="firstname"><br>

<input type="checkbox" name="subscribe" id="subscribe">
<label for="subscribe">Subscribe to newsletter</label>

    The title attribute can also be used to identify form controls. This approach is generally less reliable and not recommended because some screen readers and assistive technologies do not interpret the title attribute as a replacement for the label element, possibly because the title attribute is often used to provide non-essential information. The information of the title attribute is shown to visual users as a tool tip when hovering over the form field with the mouse.

  • Grouping Controls:
    Use the <fieldset> and <legend> elements to group and associate related form controls.Grouping related form controls makes forms more understandable for all users, as related controls are easier to identify. It also makes it easier for people to focus on smaller and more manageable groups rather than try to grasp the entire form at once.
    The <fieldset> element provides a container for related form controls, and the <legend> element acts as a heading to identify the group.The legend for a group of controls can also highlight common attributes of all controls, for example, to advise that all fields in the group are required.

    <fieldset>
<legend>Output format</legend>
  <div>
    <input type="radio" name="format" id="txt" value="txt" checked>
    <label for="txt">Text file</label>
  </div>
  <div>
    <input type="radio" name="format" id="csv" value="csv">
    <label for="csv">CSV file</label>
  </div>
  […]
</fieldset>

    Depending on the configuration, some screen readers read out the legend either with every form element, once, or, rarely, not at all. To accommodate this consider the following:

    • Make the legend as short as possible for situations in which it is read together with the label each time.
    • Make the individual labels sufficiently self-explanatory for situations in which legends are not read aloud, without repeating the legend in every label.
  • Form Instructions: Provide instructions to help users understand how to complete the form and individual form controls.
    Provide instructions to help users understand how to complete the form and use individual form controls. Indicate any required and optional input, data formats, and other relevant information.Important: Screen readers often switch to “Forms Mode” when they are processing content within a <form> element. In this mode they usually only read aloud form elements such as <input>, <select>, <textarea>, <legend>, and <label>. It is critical to include form instructions in ways that can be read aloud. This will be explained further below.

    In addition to overall instructions, it is also important to provide relevant instructions within the labels of the form controls. For example, to indicate required input fields and data formats in the text of the labels.

    <label for="expire">Expiration date (MM/YYYY): </label> <input type="text" name="expire" id="expire">
  • Placeholder Text: Provides instructions or an example of the required data format inside form fields that have not yet been edited by the user.Placeholder text is usually displayed with lower color contrast than text provided by users, and it disappears from form fields when users start entering text. If the placeholder text contains instructional information or examples that disappear, it makes it more difficult for users to check their responses before submitting the form.While placeholder text provides valuable guidance for many users, placeholder text is not a replacement for labels. Assistive technologies, such as screen readers, do not treat placeholder text as labels. Moreover, at the time of writing this tutorial, placeholder text is not broadly supported across assistive technologies and not displayed in older web browsers. 
    <div> 	<label for="search">Search:</label> <input type="text" name="search" id="search" placeholder="e.g. Apple Pie"> </div> <div> 	<label for="email">Email: </label> <input type="text" name="email" id="email" placeholder="joe@example.com"> </div>
  • Validating Input: Validate input provided by the user and provide options to undo changes and confirm data entry.In addition to providing instructions, validate user input to help users avoid mistakes. HTML5 defines a range of built-in functionality to validate common types of input, such as email addresses and dates. In some situations, such as validating custom controls or supporting legacy browsers, additional scripting may be necessary to validate user input.

    Forms frequently include required input that needs to be clearly identified using labels. Also, the requiredattribute can be added to form controls, to programmatically indicate that they are required. Most current web browsers support this attribute and will communicate missing required input to the user, using standard web browser dialog mechanisms. These dialogs are expected to respect the settings and preferences of the user in the web browser (and operating system), such as default font-size, colors, and language.

    <label for="name">Name (required): </label> <input type="text" name="name" id="name" required aria-required="true">

    The aria-required attribute informs assistive technologies about required controls so that they are appropriately announced to the users (as opposed to validating the input). Most current web browsers automatically set its value to true when the HTML5 required attribute is present. In this example, it is provided redundantly to support web browsers that don’t communicate the required attribute to assistive technology.

    Validation should aim to be as accommodating as possible of different forms of input for particular data types. For example, telephone numbers are written with different separators and digit groupings. Your form will be easier to use if it can interpret multiple notations. Also, it is helpful to be liberal with input. For example, postal codes aren’t confined to just numbers in some countries, so using an input of the type number can easily become a problem for many of your website users.

  • Multi-Page Forms: Divide long forms into multiple smaller forms that constitute a series of logical steps or stages and inform users about their progress.
    Where possible, divide long forms into multiple smaller forms that constitute a series of logical steps or stages. This helps make long forms less daunting and easier to understand, particularly for people who are less experienced using computers or who have various cognitive disabilities. The following basic principles should apply for multi-step forms:

    • Repeat overall instructions on every page.
    • Split the form up according to its logical groups of controls. For example, in an online shop, shipping and payment information are typically separated.
    • Make it easy to recognize and to skip optional stages. For example, highlight optional steps in the main heading of the web page and provide an option to skip.
    • If possible, the first step of a form should explain how many steps will follow. Each step should inform the user about the progress they are making.
Posted in Cascade Resources, Cascade Server How-To...

Tips and Tricks for Tables

Posted on by Carol J Usher

Tips and Tricks

  • Keep it simple: Complex tables are more work for content creators as well as being harder to interpret for users. It’s usually better to break up complex tables into simple individual tables, each containing the data for one sub-topic. Multiple simple tables can provide the same information as the mutli-level table but it makes the information easier to understand for everyone and easier to code. Also, simple tables are much better supported by tools to create web content, including WYSIWYG (“What you see is what you get”) editors.
  • Table separation: If several tables follow one another, don’t use a single table and put in an additional row of <th> cells. Screen readers may read aloud all <th> cells in a column, resulting in confusion. Start a new <table> when the topic changes.
  • Data separation:
    • Make sure that each separate piece of data has its cell. Don’t use headers in one column and all data in a second column, as this will make it almost impossible for screen readers to work out the relationships between data across columns.
    • Don’t use line breaks (<br> elements) to create table rows as the data in the pseudo-rows may no longer align correctly when text is resized.
  • Alignment: Align text to the left and numeric data to the right (in left-to-right languages), so that people using larger text sizes or smaller screens will be able to find it. This is especially useful if a cell spans more than one column. It’s helpful to give column headers the same alignment as the data in the cells below.
  • Styling header cells: <th> elements are used for header cells, using <td> elements with different styling will make tables less accessible if not inaccessible. It is also helpful to differentiate <th> and <td> cells visually.
  • Zebra tables: Styling even and odd rows in a different way can be helpful to people who have reading difficulties or who enlarge text. It acts as a visual guide. Highlighting the cell (and row/column) on mouseover and keyboard focus to support people to see where they are. Make sure that the contrast ratio between the text and background is good for both headers and data cells. The contrast between all text and its background is at least 4.5:1 for normal-size text.
  • Flexibility: Due to the layout model of tables, they sometimes don’t fit on small screens small or are too wide if the user is zooming in. In such circumstances, it’s important that the table isn’t cut off (for example by using overflow: hidden in CSS).
  • Tables for Layout: Tables should not be used for layout purposes. Use Cascading Style Sheets (CSS) for layout. If there are already layout tables present, don’t use structural elements (like <th> or <caption>), and do add role="presentation" to the <table> element.
Posted in Cascade Resources, Tips and Tricks

Table “Caption” and “Summary”

Posted on by Carol J Usher

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.

Posted in Cascade Resources, Cascade Server How-To..., Tips and TricksTagged

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