Communications and Marketing

Anibal House
630 Pioneer Drive
Rochester, MI 48309-4482
(location map)
(248) 370-3184
fax: (248) 370-3182

two students using assistive technology to consume web content

Accessibility

Accessibility

Ready to get accessible? The UCM Web team is responsible for ensuring OU web content and online documents are accessible to people with disabilities.  Specifically, we strive to conform with the Web Content Accessibility Guidelines (WCAG) 2.1 AA.

Getting accessible allows us to realize the following goals:

  • Reach a wider audience:  Accessible content will attract more potential students, and retain more current students.
  • Lower our legal risk:  Proactively pursuing accessibility makes us more prepared to respond to demand letters or claims and to avoid potentially costly litigation.
  • Improve our reputation:  Becoming a university known for accessibility excellence will set us apart from other higher education institutions.
  • Improve our search optimization:  Providing transcripts for videos, for example, increases search engine "findability."
  • Improve our overall user experience:  Improved accessibility contributes to improved effectiveness for the community we serve, and better usability for people without disabilities as well.
ADA
Compliance

Policy:  Under Title III of the Americans with Disabilities Act (ADA), Oakland University can be considered “a place of public accommodation” that must provide “equal access” and “reasonable accommodations” to people with disabilities.  Further, courts have ruled that the ADA applies to web content and online documents, despite not expressly providing a set of standards specific to web accessibility. 

In lieu of ADA standards specific to web and document accessibility, OU strives for WCAG 2.1 AA conformance for the following three reasons:

  • Likelihood of future updates to the ADA that will include a specific WCAG recommendation.
  • Recent refresh of Section 508 to be in alignment with WCAG for government sites.
  • Worldwide recognition and adoption of WCAG as the standard for web accessibility.

Of course we want to avoid lawsuits and the reputation damage they can bring, but more importantly, we want all of our web content and online documents to be accessible because it's the right thing to do.

Process:  Our process can be summarized in four simple steps:

  • Issue IdentificationDetermine what needs to be fixed.  OU has partnered with Siteimprove for detection of accessibility issues via an automated accessibility testing software suite that integrates with our content management system Percussion.
  • PrioritizationDecide which issues to resolve in which order.  Content in the areas of recruitment, student success, and the office of the President are given higher priority.  Current issues in newer content will generally take priority over older content that is slated for near-future archival.  Frequently-visited pages will generally take priority over those receiving less traffic.
  • RemediationFix the issues.  Resolving issues identified by automated accessibility testing.  Remediation of both websites and documents performed within the University Communications and Marketing department's Web team.  Identification of common issues that will inform prevention measures.  Evaluation of the size, scope and complexity of accessibility error remediation projects may sometimes result in a decision that our current resources are not able to meet the demand, in which case we will recommend you work with vendors who specialize in this type of work.
  • PreventionReduce the influx of more issues.  The UCM Web team continually works to build in more accessibility features into our content management system, but that does not prevent new accessibility errors being introduced by new content being authored.  As automated testing uncovers accessibility errors in common areas, application of remediation via improvement of widgets, style sheets, and global templates is an ongoing practice.  Similarly, identification and remediation of accessibility errors published by content authors can inform the need for improvements to instructional and training materials herein.  See the Getting Help tab for more information about training opportunities.
Web
Accessibility

Responsibility:  The UCM Web team is responsible for ensuring existing and new web content is accessible.  We've partnered with Siteimprove for automatic detection of accessibility issues and are regularly working to resolve them.  Although we attempt to prevent as many errors as possible in our templates and content management system, this cannot stop new content from introducing new accessibility errors.

Getting started:  As a Content Contributor, a great way to help ensure content you author on web pages is accessible is to use free automated accessibility browser extension tools. They allow you to learn as you use them.  As you identify problems and how to resolve them with these tools, you avoid making the same mistakes again.  It’s a great first step in self-educating about web accessibility.

Free tools:  Some popular, reputable, and free web accessibility checkers available that can be installed as web browser add-ons, extensions or plugins include:

The principles:  You may have heard of the POUR acronym.  The following brief list gives you a quick idea of what each involves.

  • Perceivable:  Making web content accessible to the senses of hearing, sight, and touch (for example:  providing image alt text, audio/video captions, optimizing reading order, including form field purpose, validating adequate color contrast, text spacing).
  • Operable:  Making web content such as forms, controls, and navigation accessible (for example:  keyboard navigability, timing controls, no flashing, providing skip methods, optimizing focus order, specifying link purpose, using sequential headings, allowing non-keyboard input).
  • Understandable: Making web information and user interface functionality understandable (for example:  specifying language, defining abbreviations, optimizing reading level, focus indication, errors and help).
  • Robust:  Making web content accessible to a wide variety of devices, platforms and assistive technologies (for example:  hardware compatibility, future-proofing, parsing, programmatic names, roles, values & status messages).

Quick tips by content type (w/ links to detailed advice):  Take into consideration the following short notes about how different types of content can be made accessible via HTML.  This general advise is meant to show you how to avoid the most common accessibility errors for each content type, with links that tell you where to go for more detailed, comprehensive information.  Click to expand by the desired content type:

Images

Specify alternate text via alt, aria-label or arialabelledby attributes:  An image file displayed on a web page can be made accessible with HTML, and although multiple accessibility rules may apply depending on context, the most important thing to remember is to convey the intent, content, meaning and purpose of the image via alternative text attribute values, even when intended for use as a button.  It should be short and descriptive, or else left blank if purely decorative.

Avoid words like “chart,” “image,” “diagram”; and do not use the file name. Charts, graphs, tables, and maps are examples of complex images that require both information about the display and added context.  In the case of buttons or images used as buttons, provide an accessible name for the button, and ensure they have discernible text that clearly describes the destination, purpose, function, or action for screen reader users.  If uploading to the Percussion content management system as an asset yourself, ensure the Alt text: field is populated with this information.

Ensure there is sufficient color contrast:  All text elements must have sufficient color contrast between the text in the foreground and background color behind it.  The ratio needs to be at least 4.5:1 for small text or 3:1 for large text (defined as 18pt or 14pt if bold), even if the text is part of an image.

Related WCAG guidelines: 

Related resources and tools:

Videos

Add a captions track and transcript:  Videos containing audio on web pages need to have closed captions that are synchronized with the audio, and text transcripts of the audio.  Videos without audio need to have descriptions of the video content. If not embedding videos from YouTube that contain captions generated automatically from scripts, video elements must convey captions via the track element, and should convey dialogue, musical cues, narration, dialogue, sound effects, and speaker identification.

Consider minimizing the general use of multimedia and limiting use to those situations where multimedia adds value to the information and content. UTS and Communications and Marketing are ready to assist with decisions and can coordinate external services for the creation of captions or transcripts. Such services are funded by the department requesting multimedia use.

Communications and Marketing suggests review of the following list of best practices as a starting point:

  • Captions are available and accessible for all viewers and audiences.
  • One to three lines of text appear on screen all at once, stay there for three to seven seconds, and are then replaced by another caption.
  • Do not cover graphics or other essential visual elements of the picture.
  • Require the use of upper and lower case letters.
  • Use a font similar to Helvetica medium.
  • Have good resolution.
  • Limit characters to 32 characters per line.
  • Captions are synchronized and appear at approximately the same time as audio.
  • Words are verbatim when time allows or as close as possible in other situations.
  • All words are captioned, regardless of language or dialect.
  • Use of slang and accent are preserved and identified.
  • Add music or other descriptions inside square brackets such as [music] or [laughter].
  • Use italics when a new word is being defined or a word is heavily emphasized in speech.
  • Speakers should be identified when more than one person is onscreen or when the speaker is not visible.
  • Punctuation is used to clarify meaning.
  • Spelling is correct throughout the production.
  • Write out sound effects when they add to understanding.

Related WCAG guidelines:

Related reference and tools:

Audio

Add a caption track:  Audio-only files accessed via embedded media player widgets need to have caption tracks that include a text description of all important background noises and other sounds, in addition to the text of all dialog and narration.

Related WCAG guidelines:

Lists

Ensure list items are within list elements:  Lists present useful groups to organize materials, but lists require careful management to convey the context of groupings and organizations.  Whether ordered or unordered, list items must be contained within <ul> or <ol> elements, which themselves can only directly contain <li>, <script> or <template> elements.  If you don't mark up a list using proper semantic markup in a parent/child hierarchy, list items cannot inform the screen reader listener that they are listening to a list when no parent is indicating the presence of a list and the type of list.

Related WCAG guidelines and techniques:

Related resources:

Headings

Make sure heading tags are not empty, and that they only ever increase by 1:  In other words, heading tags must have content, and their levels need to nest hierarchically.  So, be careful not to jump from an <h2> to an <h4> just for font or formatting purposes.

Related WCAG guidelines and techniques:

Related resources and tools:

Links

Don’t use color only to distinguish link text, use meaningful link text:  Links must not only rely on color to differentiate them from any surrounding text (typically this is taken care of via underlining in CSS).  Additionally, link text must be “discernible” which means it should always visible inner link text with an accessible name, and there should not ever be duplicate link labels. Avoid Javascript events (like onmouseover, hover, etc.) because they can prevent keyboard-only users from being able to programmatically focus on the link.

Ensure the link purpose can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.

Related WCAG guidelines and techniques:

Related resources and tools:

Forms

Ensure iframes inserted on pages include title attributes:  By default, when you get the embed code for a Google Form, the snippet it provides for you to paste onto a web page in the content management system to make the form appear does not include a title attribute for the iframe element.

Manually test keyboard focus order and navigation:  It is important that keyboard-only users are able to navigate via tab and/or arrow keys through a form in the desired sequential order of fields.

Related WCAG guidelines and techniques:

Related resources and tools:

Document
Accessibility

The same principles that apply to Web accessibility also apply to document accessibility.  Documents must be Perceivable, Understandable, Operable, and Robust (POUR).  It is important to keep in mind that certain document formats allow greater control over accessibility than others.

Most accessible to least accessible:  Always consider if the content can live on the web first, keeping in mind the following in order of most accessible to least accessible formats:

  • HTML:  Consider the intended audience first when determining appropriateness (most accessible).  For more information, see the Web Accessibility tab.
    • Image:  A .png or .jpg graphic such as a chart or graph can be made accessible with alt text (and accompanying text) if it is destined for the web.
    • Video:  Can be made accessible via synchronized closed captions in YouTube, which can then be embedded on a web page (with accompanying transcript).
    • Audio:  Can be embedded on a web page with accessible media player widget (with accompanying transcript).
  • PDF:  Make accessible in the source format first (next most accessible if converted properly).
  • Office - Word, Excel, PowerPoint (can be made accessible using built-in checker).
  • Google Docs - Docs, Sheets, Slides (least accessible, but can be made as accessible as possible using an installed add-on).

High-level process:  A typical process for producing an accessible document involves the following three steps:

  1. Get the document as accessible as possible in source format first (for example, paste content into Word, use the built-in Accessibility checker on the Review ribbon to view/fix errors).
  2. Optimize the conversion settings to PDF for accessibility, then convert (for example, by exporting/converting to a tagged PDF using a cloud service optimized for accessibility).
  3. Fix any remaining errors in Adobe Acrobat Pro DC (for example, by using the Full Check in the Accessibility tool, then using error explanations to fix).

Quick tips by document type:  The following sections provide format-specific advice about document accessibility.  Click to expand according to the desired format:

PDF

If the content needs to be a document instead of an HTML page on a web site, choose PDF over Office, Google Docs, or other formats.

Quick answers to common questions:

  • When a document is preferred over a web page, which type is most accessible?  If the content is either not appropriate for a web page, or cannot be easily converted to HTML, the PDF format should always be the next best option.
  • If WCAG guidelines are for web content, is there an equivalent set of guidelines for PDF documents?  No, because the WCAG guidelines can be mapped to automated PDF rules.  For the complete list in a handy table, see WCAG to PDF Mapping - Adobe Review the document content to see what it contains, then refer to the Web Accessibility section for general advice.  The same techniques used to make images, video, audio, tables, headings, lists, links, etc. accessible in HTML are also generally used to make them accessible in tagged PDF documents.
  • Are all PDFs automatically accessible?  No.  Lots of tools allow you to save something in the .pdf format, but that does not automatically make it an accessible PDF.  Configuration settings related to converting or exporting to PDF within a source format application such as Word, combined with configuration settings within Adobe Acrobat Pro DC to create a PDF from a .doc for example, allow for optimization of accessibility when converting from a native source format to PDF.
  • What is PDF/UA?:  UA stands for Universal Accessibility.  PDF/UA is the informal name for ISO 14289, the International Standard and technical specification intended for developers implementing PDF writing and processing software.  It will likely take many years before there is no gap between what is considered an “accessible PDF” versus what is considered PDF/UA compliant. In other words, the capabilities of the software do not measure up to the standard yet.  Key Takeaway:  The goal should always be to arrive at an “accessible PDF” that can be verified through passing all of the rules in the Accessibility tool’s Full Check in Adobe Acrobat DC, some of which must be checked manually.

Request process:  Follow these general steps to arrive at accessible PDFs at OU:

  • Always fix the source document first if possible: Often PDFs are created via Save As or Export from another application program such as Word, Excel, PowerPoint, InDesign, Google Docs, Apple Pages, etc. If you have the source, it can often save a lot of remediation effort.  
  • Contact your Account Manager and request accessible documents as you normally would for web work:  Attach the source files to an email to your AM, and ask that the documents be remediated and turned into accessible PDFs, and if applicable, which web pages links to them should appear on.  The Web Team will then estimate the effort involved, make the determination of whether we will remediate them in-house or use a service for larger projects involving many, longer PDFs.

Remediation process:  If you want to take a stab at making accessible PDFs yourself, follow these general steps and guidelines:

  • Make Accessible In Source Document First (before converting to PDF):  It is often more effort to “fix” an existing PDF in Acrobat Pro than it is to fix the source document first, then “re-convert” it to PDF in the best way.  Get the document as accessible as possible in its native format first prior to converting to PDF. This can be done using free accessibility checkers. When you use them to check for accessibility errors, you get messages that tell you how to fix the errors.
  • Use Word Instead Of Google Docs:  If possible, use Word instead of Google Docs for the source document prior to converting to PDF.  If available as a Google Doc, either paste the content into Word, or download it as Word. Reason:  Word is a more mature product with finer-grained control over accessibility. Optimizing a Word doc for accessibility ensures the most accessible PDF after conversion.  A template optimized for conversion to an accessible, tagged PDF is available for download here:  OU Accessible Word Template.docx
  • Use The Microsoft Office Accessibility Checker:  Often PDFs are made from documents originating from Microsoft Office products.  Use the built-in accessibility checker on the Review ribbon (enabled by default in newer versions of Office).  If using an older version of office, install the free Word Accessibility checker from Microsoft (which adds a ribbon to your toolbar) and run it on your Word doc to identify and learn how to fix accessibility errors.  Note: For complete information about using the Word accessibility checker, see Improve Accessibility with the Accessibility Checker - Microsoft Support.

Conversion settings:

  • Optimize the export from office to PDF:  When you do a File > Save As in Word, then select the Export Format File Format PDF, ensure the option ‘Best for electronic distribution and accessibility (uses Microsoft online service)’ is checked, then click the Export button.

Final remediation:

  • Open in Acrobat Pro DC and use its Accessibility tool:  Open the resulting PDF file, add the Accessibility tool in Adobe Acrobat Pro, then run the Full Check with all of the checkboxes selected. 
  • Fix any remaining errors:  Use the guidance in the Inspection Results to fix errors and remediate the PDF.  Tip:  Remember you can always right-click on an error in the inspection results and then click Explain for the detailed “how-to fix” information for each specific error.
Microsoft Office

Using the Accessibility Checker:  Newer versions of MS Word, Excel and Powerpoint have robust built-in accessibility checkers (Accessibility button on the Review ribbon).  They automatically check the document for accessibility errors and give you “how to fix” advice below each error and warning message.

With the document open, on the top menu bar, select the Review ribbon, then click the Check Accessibility button.  Issues will appear in the Inspection Results section along the right sidebar.  Follow the instructions provided to fix the errors and save the changes.

Click Check Accessibility after each change to verify the issue no longer appears.

Optimization Prior To PDF Conversion Tip:  Often, when you ensure the accessibility of your document (when you get the Inspection Results message that reads ‘No accessibility issues found. People with disabilities should not have difficulty reading this document.’) as a Microsoft Office document, when you then export it as a PDF, the Adobe Acrobat Pro accessibility will not find any issues either!  See the PDF section above for more related info if you’d still like to convert it to PDF.

In this section:

Word

Save documents as .docx format to preserve accessibility features.

Develop reusable accessible design templates to reduce the level of effort to create accessible electronic content.  Here is a link to one you can download to start with:  OU Accessible Word Template.docx

Use the Accessibility checker on the Review ribbon to display information about accessibility errors and how to resolve them.

Add alt text to all non-text objects:  Right-click on the image and then select Edit Alt Text... from the right-click popup menu, then enter text to describe the meaning and purpose.  Ensure it does not contain image names or file extensions.

Specify a header row for all tables:  Select the table, then on the Table Design ribbon, ensure the Header Row box is checked.  Additionally, if using tables for layout purposes, ensure the layout order is structured logically for easy document content navigation.

Align images with text:  Select the image, then right-click on it, then select Wrap Text > In Line with Text from the right-click popup menu.

Adjust text & background colors for contrast:  Use the Font Color and Text Highlight Color tools on the Home ribbon, and/or the Color and Page Color tools on the Design ribbon accordingly to ensure there is sufficient contrast between the text and background.

Use heading styles for organization:  Place the cursor on the line of text you want to be formatted as a heading, then select a Heading paragraph style from the Styles Pane on the Home ribbon to add structural context for ease of navigation.  In longer documents, add a Table of Contents based on the headings from the References ribbon.

Give the document a title in the metadata:  With the document open, select File > Properties > Summary, and then populate the Title field.

Related resources and tools:

PowerPoint

Use the Accessibility checker on the Review ribbon to display information about accessibility errors and how to resolve them.

Keep in mind the following best practices to make your presentation accessible:

  • Start with an accessible theme.  Include 'accessible' in your theme search.
  • Ensure each slide has a descriptive title
  • Check the reading order.  On the Arrange > Selection pane, view the reading order of objects and reorder as necessary.  Important!:  The reading order displayed is from bottom to top.
  • Ensure all images have alt text.  Right-click > Edit alt text to specify purpose and meaning, or mark as decorative as appropriate.
  • Specify a header row in tables.  Select the table header row, then in Table Tools > Design Tab, ensure the Header Row checkbox is selected.
  • Ensure links have meaningful text.  Use the Edit Hyperlink feature to specify descriptive link text to make the destination and purpose clear, instead of just inserting a full URL.

Related resources:

Excel

Use the Accessibility checker on the Review ribbon to display information about accessibility errors and how to resolve them.

How to prevent common accessibility errors in Excel:

  • Images:  Add alt text to all visual content (images, charts, graphs, shapes, etc.) by right-clicking on the graphic, then selecting Edit alt text.  If a visual element is used only for decorative purposes, on the Alt Text pane, select the Mark as decorative check box. 
  • Links:  Add meaningful text to hyperlinks by right-clicking a cell containing a link, selecting Hyperlink, then entering it into the Text to display field.
  • Sheet names:  Ensure no sheets are blank and that each has an unique name.  Remove blank sheets by right-clicking a sheet tab and then clicking delete, and ensure each sheet has a name by right clicking a sheet tab and then selecting Rename.
  • Table headers:  Ensure the top row is specified as a Header row in each table.  Position the cursor anywhere in the table row you want to be the header, then on the Table tab, select the Header Row check box.

Excel-to-PDF Tips:  If converting to PDF, be sure to add a title in the metadata via File > Properties > Summary > Title;  and also to specify the language via File > Properties > Custom > File > Language and save changes prior to converting.  To optimize conversion to an accessible PDF, do a File > Save As, then select PDF as the File Format in the dialog box.  As a final step, open the PDF in Adobe Acrobat DC, add and use the Accessibility tool, and run a Full Check with all checkboxes selected.  In the Inspection Results, remember you can always right-click on an error and then click Explain to learn how to fix.

Related resources:

Google Docs

Are Google Docs automatically accessible?  No.  Google Docs is a newer, lightweight set of applications with great sharing/editing capabilities, yet because they are free, they have only a subset of the functionality you would find in fully-featured professional products.  This includes very few options for controlling and optimizing accessibility as compared with Microsoft Office, or even other free options like LibreOffice for that matter.

If required to deliver accessible Google Docs, Use Grackle:  If you must use Google Docs, use a free accessibility checker add-on such as Grackle Docs to check for and fix accessibility issues in your Google doc prior to converting to PDF.  Note: This is only free on a Trial basis. (See instructions below)

Install the Grackle Docs accessibility checker for Google Docs

  1. Open a google doc.
  2. In the top menu, select Add-ons > Get add-ons.
  3. On the G Suite Marketplace popup window, enter Grackle Docs in the Search field at top right and press Enter.
  4. In the search results, click on the Grackle Docs box.
  5. On the Grackle Docs page, click the blue INSTALL button.
  6. Follow the prompts to Continue, select your oakland.edu account, and Allow to complete the installation.

Run the accessibility checker for Google Docs

  1. Open a google doc.
  2. Select Add-ons > Grackle Docs > Launch.
  3. The Grackle Docs accessibility checker appears on the right of your doc.
  4. Sign in with your Google Account (oakland.edu email) at the top to allow and authorize the add-on app.
  5. Use the blue Check and Re-Check buttons in the Grackle Docs add-on to automatically display accessibility errors and warnings.
  6. Expand any red X (error) messages to learn how to fix.  Some errors will provide hotspot anchor links and buttons you can click to immediately be taken to the portion of the doc where the error occurs, and allow you to fix it very quickly.

Pass all of the checks, save your changes, and you’ve ensured the Google Doc is accessible as possible.

Related resources:  

Google Forms

The process to get the embed code from a Google Form in order to embed it on your web page does not by default specify the title of the form as an attribute for the iframe element.

Typically, to get the embed code for a Google Form you would follow these steps:

Click the SEND button, then on the ‘Send form’ popup, select the [< >] tab in the ‘Send via’ field, then  COPY the code displayed in the Embed HTML field.

It includes attributes such as width and height, but does not include a title (even though the Google Form itself has a title).

  • Rule:  Any iframe element must have a title attribute, and further, it must not be empty.
  • Fix:  Provide the frame with the attribute title=”” and add a description of the content in the title.
InDesign

Often documents originating in the native format of Adobe InDesign are authored there for the purpose of exporting to a different destination format for final delivery (such as PDF, XML or ePub).  Therefore, accessibility rules for the target format need apply. 

That said, there are many things you can do to ensure the source .ind file is as accessible as possible prior to converting to a different format to alleviate the hassle of remediating only in the target format.  Further, the conversion settings matter when configuring how the source gets saved as the destination format.

Top Tips:

  • Use export tagging to specify tags for character and paragraph styles such as heading levels.
  • Add alternative text to all visual elements, and even when they offer no information, specify they are decorative.

Related resources:

For complete details about how to ensure your InDesign document is as accessible as possilbe (whether intending to convert/export to another format like PDF or not), see InDesign Accessibility - Adobe.

Getting
Help

Contact information:  Follow the normal process of contacting your Account Manager with any requests pertaining to web or document accessibility.  They coordinate with the UCM Web team and Web Compliance Coordinator via a ticket system for an initial accessibility effort estimation.  If the size, scope and complexity is feasible, the Web team will complete the work, and if not, recommend other service providers with suggested next steps. 

Along with each completed request, your Account Manager will relay to you a summarized description of the work that was necessary to make your content accessible, so this can both help you learn a little about accessibility, and take preventative measures to reduce the effort involved should you have similar, future requests.

Primary reference resources:  Handy links to detailed, reputable and reliable online resources about web and document accessibility.

Web Accessibility:

Document Accessibility: