decorative image showing disability symbols

Considering the amount of effort put into each Extension publication, it makes sense to spend a couple of extra minutes making your document accessible to everyone. This page presents some basic accessibility guidelines for IPM faculty and staff.

The first part of the page contains a quick-reference guide for common accessibility features.  Below that are specific sections for PDFs, web pages (CMS), and other documents.  The contents section contains navigation links to each topic.

This page is still under development, and is not intended to be a comprehensive guide to accessibility.  Those looking for more information about accessibility can start with the Web Content Accessibility Guidelines (WCAG) Overview. The World Wide Web Consortium also provides a WCAG quick-reference.

 


Contents

  1. What's this all about?
  2. File Properties
  3. File Name
  4. Fonts
  5. Page Structure
  6. Images
  7. Tables
  8. Web Pages (CMS)
  9. PDF
  10. Email (coming soon)
  11. Other Document Types (coming soon)
  12. Further Information

What's This All About?

It's about making the work we do at MSU Extension IPM accessible to everyone.  To do so, there are some simple rules that need to be adhered to.  This section covers the what, who, and why of accessibility.

Which Documents Need to Be Accessible?

Accessibility must be addressed on all electronic communications.  Full stop.  If a file leaves your computer, it needs to be accessible. 

Says Who?

ADA compliance is required by federal law. Electronic documents that are available to the public must be compliant with Section 508 of the Rehabilitation Act.  Montana State is a NIFA Land-grant University, and we need to reach for the highest rung of WCAG 2.0 conformance, Level AAA.

Why?

Because it's the right thing to do.  Because 1 in 4 people live with a disability.  Because digital communications allow us the ability to share information with everyone.

 

Return to Contents


File Properties

File properties are often overlooked because they're only displayed in metadata, but they're an important part of making sure others are able to find a document.  Fill in the title, author, keywords, and summary of every file.

File properties can be accessed in most software by clicking File in the top menu and selecting Properties from the drop-down.  In the CMS, page properties (or parameters) can be accessed from the Page Edit menu.

Keywords

Title, author, and summary are self-explanatory; keywords are terms that one would use to find a document. Each keyword should be separated by a comma or semicolon.  Capitalization generally does not matter, but avoid using the following characters in keywords: ! = ? @ % ^ *; ~ `, (){} <> |

Keywords can be skipped on CMS web pages, but they don't hurt, and it's advised to use them on other file types.  Keywords on a document about noxious weeds might include "noxious weeds; invasive plants; ipm" along with a few other words that identify the subject and author.  Just 5 to 10 keywords are adequate in most cases.

 

Return to Contents


File Name

This section contains pointers for internet and archive friendly file names; note that we're not talking about the document title, but instead, the actual file name that is seen in the file's URL or folder.

Mirror the Document Title

Due to the other constraints mentioned in this section, it's not always possible to simply copy a document's title to its file name, but try to get as close as possible to the original title.  The title can be summarized, but it shouldn't be completely different.  When many related files will be stored together, it is a good idea to add a date code as a prefix to the name (details below).

Use Only Letters, Numbers, Hyphens, and Underscores

These characters are safe for use on the internet, because they can be displayed in all languages, and are generally not used for special functions.  Continue reading for information on which to use, and when.

Always avoid using reserved characters in file names, such as: ! = ? @ % ^ *; ~ `, []{} <> |

No_Spaces

Every netizen has seen nonsensical web addresses that are full of percentage signs, the reason for this due to a mechanism called percent-encoding, or URL encoding.  Spaces are encoded as "%20", commas are encoded as "%2C", along with a number of other reserved characters.  This is why it's best to stick to basic characters, as mentioned above.

Us humans have an easier time of making sense of a statement when the words are separated, therefore, underscores and dashes have become the standard replacement for spaces in file names.  The reasons to choose one or the other are complicated, but the skinny is that files with dashes are indexed by search engines, while those with underscores are not.  We want web pages to be indexed, but we don't want to index non-web content, like PDFs.

  • underscores_for_pdf, and anything not listed below (Word, Excel, PowerPoint, etc.).
    • Example: ipm_survey_results.pdf
  • dashes-for-web-page, also folders, audio, video, and images.
    • Example: ipm-survey-results.html

no capitalization

Modern computer systems don't have much of a problem with capital letters, but they have the potential to break links for some users.  Best practice is to outright avoid using capitalization in file names.

Date Formatting

The international standard for time and date formatting is to write in big-to-small increments (ISO 8601).  Not only does this allow for universal clarity, but it also assists in organizing large batches of files, because they can be easily grouped in chronological order based on name alone.

Do not use dashes when adding a date to file names, because dashes are meant as a substitute for spaces.  A string of numbers may look odd at first, but you'll quickly become accustomed to reading dates this way; you'll also start spotting dates in other places, like product serial numbers.

Examples of ISO 8601 Formatting

  • yyyymm
    • May 1996 becomes 199605
  • yyyymmdd
    • May 18, 1996 becomes 19960518
  • yyyymmddhhmmss
    • May 18, 1996, at 7 seconds past 3:36PM becomes 19960518153607

Considerations for File Organization

  • Date in front of the name for chronological listing (e.g. 199605_my_file_name.pdf).
  • Date behind the name for alphabetical listing (e.g. my_file_name_199605.pdf).
  • Time and date can be used to keep track of file versions.

 

Return to Contents


Fonts

Fonts, or typefaces, also have accessibility requirements. If a font is too small, it may be difficult to read; if a font has too many curves (serifs), it can be difficult to distinguish between letters. Color contrasts need to be strong enough that fonts standout from their background.  There are also guidelines for the use of italics, bold, and underlines.  Please read on for details about each attribute.

More information can be found on the WebAIM fonts page.

Serif

A serif is a decorative line, or taper, added to the beginning and/or end of a letter’s stem, which creates small horizontal and vertical planes within a word. Times New Roman is a common serif font.

As mentioned at the top of this section, serif fonts should be avoided because their extra strokes can make it difficult for people to distinguish between letters.  Choose a sans-serif font instead.

Sans-Serif

As the name implies, this font family lacks serifs, or extra strokes. Sans-serif fonts are easy to read and are therefore the best option for accessibility.

Popular sans-serif fonts include Arial and Helvetica.  The MSU Branding Guide suggests using ITC Franklin Gothic for publications.

Font Size

There's no way of knowing exactly how a font will look on every screen, so font size also needs to be taken into consideration.  There's no perfect font size for every situation, but it's best to avoid any font that is labeled as small, or that is below 9 point.

  • 12 point font is generally considered normal size.
  • 18 point (or 14 point bold) font is considered large.

Underlining

Do not underline numbers and text. Underlined characters can be difficult to read, because the bottom of fonts are often cropped by the underline.  Secondly, links (or shortcuts) are automatically underlined by most web browsers; it's something that readers are accustomed to, and adding extra underlines leads to confusion.  Note that the WYSIWYG toolbar, in the CMS, doesn't even have an option for underlining.

Italics

Similar to serifs, italicizing fonts can lead to reader confusion.  The use of italics should be limited to short phrases, such as scientific names.  Avoid using italics on links, because they are often underlined by web browsers, and the combination can weigh heavily on readability.

For more information, see the W3C page for Understanding Guideline 3.1.

Bold

Similar to italics, bold fonts can lead to reader confusion, and their use should be limited to short phrases.  Because assistive technologies often don't distinguish bolded font, do not rely bold alone to convey information.  Don't avoid using bold entirely; italics are ok, color is ok, and bold is ok, just keep in mind that not everyone will notice these attributes, and there are some basic guidelines for their use.

Font Color

Never rely on color alone to convey information.

Text-to-background color contrast needs to have a ratio of 7:1.  Large text (14 point or greater) can have a ratio of 4.5:1.  The WebAIM Contrast Checker can be helpful in determining text-to-background ratios.

Link text should have a contrast ratio of at least 3:1 with the surrounding text.  Use the WebAIM Link Contrast Checker to help determine link-to-text color ratios.

Lastly, we're all familiar with blue text links; best-practice is to avoid using blue for non-links, because mixing them together can confuse your readers.  Note that using blue on printed media is a good way to distinguish links.

For more information, see Use of Color, Understanding SC 1.4.1.

Ampersand (&)

Some assistive technologies announce ampersand as "ampersand".  This is rarely the author's desired effect, so ampersand is best avoided all-together.

Ampersand is also a reserved character and is therefore translated to "%26" when encoded as a URL.  If a filename is "Insects & Plants.pdf" the link would be encoded as "Insects%20%26%20Plants.pdf", which isn't readable.  Naming the file "insects_and_plants.pdf" solves the readability problem by not using any reserved characters, like spaces and ampersand.

Capitalization

Headings and Titles

The WCAG calls for headline-style title and heading capitalization, so that titles are distinct from other written content.  Scientific journal authors should note that Shift keys are located on the right and left sides of their keyboards.

ENTIRE WORDS

Do not capitalize entire words unless they're trade names, acronyms, or abbreviations.  The reason for this is because some assistive devices read capitalized words letter-by-letter, which can get confusing when dealing with an entire sentence or paragraph.  Capitalized words are also simply more difficult to read, because there is not much difference in the shape of each letter; they're all essentially square. Besides the above, most people on the internet consider it yelling, and you wouldn't want that, WOULD YOU?

 

Return to Contents


Page Structure

These are general guidelines for the use of headings and nesting. There are intricacies that vary between document type, but these two rules always stand:

  • If the font on a heading is too big or small, adjust the heading style, not the heading number.
  • Images should not be used as headings.

The first heading on a page needs to always be Heading 1, which is usually the document title. Everything related to the title should be "nested" beneath it. Heading 2 is typically going to be where you start breaking up the primary sections of the content.  Nested below Heading 2 would be sub-content headings, then sub-sub-content, and so-on.

Not only does proper page structure assist readers with navigating documents, it also helps authors address the flow of the information they're presenting.  It's a win-win situation.

More information can be found in the W3C Page Structure Tutorial.

Heading Example

The two lists below are matching examples of how headings can be used on a basic document. The second list shows the headings that should be used in the first list. The indentations are purely for illustration.

  • Document Title
    • Table of Contents
    • Part 1 Title
      • Part 1 Sub-title
        • Part 1 Sub-sub-title
      • Part 1 Sub-title
    • Part 2 Title
    • Part 3 Title
    • Index / Appendix / Footer
  • Heading 1
    • Heading 2
    • Heading 2
      • Heading 3
        • Heading 4
      • Heading 3
    • Heading 2
    • Heading 2
    • Heading 2

This example page contains the above heading structure in the CMS.

Why is Nesting Important?

Assistive technologies, such as screen readers, need to know what order to read content in.  Also, search engines use headings to index the structure and content of web pages. Lastly, it puts a proud little tear in the eye of your 5th grade English teacher.

 

Return to Contents


Images

Outdoor photo of plump white caterpillar with black spots on top of a wild flower

Owlet moth caterpillar (Cucullia speyeri) snacking on a Bighorn fleabane daisy (Erigeron allocotus).  Photo taken near Flathead Pass, by Brett GosselinFull size image (5.2MB).

Photos, graphs, and branding are important aspects of a document; care needs to be taken to ensure images are accessible to individuals with disabilities, as well as those who may be viewing the document on devices with small screens, such as mobile phones. Overall size should be considered when adding images to a web page; images affect page load time, which is not only frustrating for users, but slow page loads also lower search engine ranking.

Alt-Text

Add an alternate text (alt-text) description to every image, without exception. Aside from making images accessible, alt-text also adds search engine optimization (SEO) value to web pages.

  • Briefly describe the image in one or two sentences; be concise, but aim for less than 100 characters.
  • Do not copy the image caption; alt-text should provide new information that can only be found in the image itself (objects, colors, setting).
  • For more information on image alt-text see Understanding Guideline 1.1 and the W3C Images Concepts tutorial.

Optimization

In terms of page load time, images are typically the largest part of the equation, and therefore have the most impact on performance.  Remember that the internet isn't fast-and-cheap for everyone; embedded images should be optimized and compressed.  Most image editing software has an optimize or "Save for Web" function, use it for every image you post online.

  • Do not use a large photo for a small web page image.
    • Use image editing software to properly size images.
  • Do not fill a single page with dozens of images.

If a large image is required, link to it instead of adding it to the main page body. A popular method for this is to create a small version of the image and then add a link to the full-size image in its caption (example).

More information on image optimization.

Metadata

Be aware of image metadata. If you've taken photos in your top-secret camping spot, make sure your phone hasn't geo-tagged the images with GPS coordinates. Though it isn't required, image metadata for images should include author, description, and licensing and/or copyright information.

Images with Text

Do not overlay text on images.  WCAG 2.0 level AAA does not allow for images of text.  Instead, add descriptors to image captions.

Image Editing Software

  • GIMP (GNU Image Manipulation Program) is a free and open source, cross-platform, image editor available for GNU/Linux, OS X, Windows, and other operating systems.
  • Inkscape is a free and open source vector graphics editor for GNU/Linux, Windows, and MacOS X.
  • Pixlr is a free online photo editor that works in a web browser.
  • Canva is another free online photo editor.
  • Adobe Photoshop is available to MSU faculty and staff, on campus computers.

 

Return to Contents


Tables

Tables should only contain data, do not use tables for web page layouts.  Tables require markup that defines header cells, data cells, and their relationship to one another.  Making tables accessible can be a complex operation; there are links to software-specific tutorials below.  Considerations when making a table include:

  • Lists can often be used in place of tables.
  • Table rows and columns need to have headings.
  • Tables require a summary (explain how the table functions).

Software Platforms

 

 Return to Contents


Web Pages (CMS)

CMS is an abbreviation for Content Management System, which applies to software platforms that are designed to manage digital content.  MSU uses a CMS called Omni Update Campus, or simply OU Campus. Assistance with the operation of OU Campus is available via the MSU Web and Digital Help Center's Content Management Systems page.

The web pages we create in the CMS need to be accessible.  The CMS will alert to some accessibility errors, but each page also needs to be tested with the WAVE Web Accessibility Evaluation Tool and pass with no errors.  Web content should be regularly audited for accessibility.

The WAVE Tool will also flag files that are linked on your web page; if a file that is hosted by MSU is linked, it also needs to be accessible.  Files that are hosted elsewhere do not need to be accessible, but this does not mean you can simply upload your document so another website; it's still related to MSU, and is expected to follow WCAG 2.0 guidelines.

Due to their open source nature, web pages are more accessible than other document types.  Consider the last time you had an internet gadget that didn't contain a web browser, right out of the box.  Then, consider how often you've had to install special software to view a PDF or Word document.  This alone means that web pages are more accessible than other document types.

WYSIWYG Editor

The What You See Is What You Get editor (pronounced "wizzywig") is the interface we use to edit web pages in the CMS.  WYSIWYG is not unique to our CMS; proficiency with wizzywig is a handy skill-set that can be transferred between many web platforms.  The WYSIWYG editor contains many of the same basic functions as Microsoft Word and other text editors; it's meant to be familiar and writer-friendly, so don't shy away from creating web content.

Page Navigation

  • Add a "Back to Top" button to the very-bottom of every page.  There is a Snippet for this function in the WYSIWYG toolbar (puzzle piece icon).
  • Create a table of contents and anchors for large or complex documents.
  • Layouts should follow proper page structure.
    • Use the "Show Blocks" button (WYSIWYG toolbar) to check nesting.

Links

A few simple rules need to be followed when creating a link, or URL, on a web page.  The MSU Web and Digital Help Center has a Best Practices page for creating web links.  Here are some pointers for link accessibility:

  • Keep link text short but descriptive, try not to use action words like "click here" or "read more..."
  • Avoid typing out entire URLs, especially within a paragraph.  If spelling out URL can't be avoided, remove the "http://" and "www", and just write it as you'd say it (e.g. montana.edu, msuextension.org).
  • Do not add titles (alt-text) to text links; the page text itself should be descriptive enough explain their intention.
  • Do not repeat links; adjacent links should not go to the same URL. For a keyboard user, it is tedious to navigate through redundant links. For users of assistive technologies, it can be confusing to encounter successive identical links.
  • Do not set links to open in a new window or tab. Automatically launching new tabs can be disorienting to users, which breaks WCAG conformance.  In the rare case that a link needs open in a new window or tab, it should be labeled as such.  Example: msuinvasiveplants.org (link opens in a new tab).  More information on opening links in new tabs:

Images

For information on the use of images, see the general Images Section of this page.

Tables

For information on the use of tables, see the general Tables Section of this page. 

 

 Return to Contents


PDF

When it comes to accessibility, adjusting PDFs seems to go one of two ways; very simple or quite difficult.  As it stands, there are just too many variables to fully automate the process of making a PDF accessible; they almost always require human intervention.

Though there are other readers like Sumatra PDF, and editors like Bluebeam, the Adobe Acrobat Pro Accessibility Test is the standard for meeting PDF accessibility compliance.  MSU faculty and staff can access Adobe Acrobat Pro DC on university computers.

PDFs need to pass an Adobe Acrobat Pro Accessibility Test free of error.  PDFs that are posted online should have a matching website, because HTML provides more robust accessibility features.

Creating PDFs

MSU faculty and staff are provided access to Adobe InDesign.  InDesign is desktop publishing software that does particularly well with exporting PDFs, because it is able to maintain page elements, like lists, that are often lost when exporting from text editors like Microsoft Word.

A detailed overview for PDF accessibility can be found in W3C's PDF Techniques for WCAG 2.0.

 

Return to Contents


Further Information

For more information about the topics discussed on this page, please contact Extension IPM Communications Specialist, Brett Gosselin (brett.gosselin@montana.edu).

Those wanting to continue learning about digital accessibility should start with the WCAG Overview.  The World Wide Web Consortium also provides a WCAG quick-reference. The rules and regulations that govern accessibility standards in the United States are found in Section 508 of the Rehabilitation Act.

 

MSU Extension logo banner

Return to Top