MTSU Course Accessibility

Students with disabilities comprise around 11% of typical university enrollment. (NCES study)

Though students with a hearing or vision impairment do not represent the majority of students with a disability, many of the accessibility practices that provide access for these students (captioning, renderable text, keyboard navigation) aid the wider population of students with disabilities while providing enhanced media that are more useable by everyone.

Course accessibility can be boiled down to access. Creating or using materials that a subset of students cannot access in an equitable manner is a thing of the past. We are pressing forward into the age of digital accessibility so that all students have equal access to a university education.

Universal Design for Learning (UDL) is a philosophy that recognizes the diversity of students. Because all people learn and experience life differently, flexibility in the means of presentation, engagement and expression help educators meet the needs of a spectrum of learners.

Faculty members are charged with creating new materials in a way that includes students of all abilities. There is not an expectation that all your course materials from over the years would be made fully accessible overnight, but we can work together to retrofit accessibility where needed.

If you have a student with a disability enroll in your course, you should expect to receive an accommodation letter from the Disability & Access Center that lists all approved accommodations to be made in your class. At that point, you will need to make sure that all materials given to the entire class are put into a format that the student with a disability can access.

These accessibility pages are designed with university classes in mind, but these principles can be used in the creation of any informational materials across campus. By creating accessible digital materials, you are building resources that can be used in traditional, flipped and online classes.

Building accessibility into your course is much quicker than having to adapt inaccessible materials when a student with a disability enrolls in your course.

Accessible course materials are useful to all students. A PDF that has been made readable to assistive software is then searchable by all students. Descriptive text for complicated images can help all students understand pertinent information.

Federal and state laws dictate that all instructional materials presented electronically be accessible to people with disabilities. 

(WCAG 1.1.1)

Problem: Images meant to convey information (charts, comics, email invitations, equations*) cannot be read by assistive technology. The software will simply say "graphic" or "image" without telling the user the content of the image.

Fix: Either use alternate text tags for images or type the alt text outside of the image. Alt text should present the content and function, not necessarily a description, of an image.

Note: Alt text tags should be kept under 125 characters. If the description needs to be longer, you can add the description into the body of the document or website. As mentioned above, this may help all students to understand the image better.

*See the Math Content element further down this list for a better solution than adding alt-text tags to equations

• View a demonstration of adding alternate text tags or this step-by-step website for alt text
• What information should you include or exclude from alternative text descriptions? See the DIAGRAM Center's alt text resource.
• View a step-by-step website explaining long descriptions

(WCAG 1.2.1)

Problem: Students that cannot hear a podcast, recorded class lecture, or other audio clip that is part of the class experience are excluded from essential content.

Fix: Include a text transcript in the simplest file format (Notepad in Windows; TextEdit in macOS) with all the information from the audio recording. Post the transcript file next to the audio clip, if embedding the clip on a website.

Note: Transcripts can help all students by making the text from audio-only clips searchable.

(WCAG 1.2.2)

Problem: Students with hearing loss or deafness cannot get information from videos, pencasts, etc. without captions

Fix: Either send your videos out to a third-party service, such as Cielo24, and pay to have your video captioned OR caption videos yourself using Camtasia or YouTube (using YouTube to caption doesn't mean that your videos have to be posted publicly on YouTube).

Note: Captioning someone else's video violates copyright by changing their original content. Cielo24 has a dynamic transcript player that may be a solution in this situation. Their player also has the advantage of creating a searchable transcript.

• See YouTube's instructions on captioning with YouTube or view a video on captioning with YouTube
• See TechSmith's instructions on captioning with Camtasia or view a video on captioning with Camtasia

(WCAG 1.2.3)

Problem: Videos with unspoken content (slides, pictures, action without dialog) cannot be understood in an equitable manner by students who cannot see the video. This becomes paramount when instructors assign videos where students are expected to respond to what they've seen. 

Fix: Either send your videos out to a third-party service, such as AMAC description or 3Play Media, and pay to receive professional audio description OR describe videos yourself using Camtasia or other video editing software.

Note: It's possible that your video doesn't need audio description if all of the visual content is already being described, as in a traditional lecture. If you're not sure, you can check with FITC at 8189 or itdacad@mtsu.edu.

(WCAG 1.3.1)

Problem: Page formatting (lists, headings and links) is read aloud to screen reader users so that the content can be understood in context. If you have not marked lists with the unordered or ordered list button, screen reader users are not getting the full picture about the structure of the document.

Fix: Easy! If order is important in your list, make it a numbered list. If order is not important, a bulleted list is a better choice.

(WCAG 1.3.1)

Problem: PDFs are a common medium for fillable forms. It is possible for PDF forms to be fully accessible, but the process of making them so can be a long, frustrating journey. Website forms usually have less issues, but form fields need to be labeled appropriately so that a screen reader user knows what information to enter at each question.

Fix: Use your departmental website in OU to create forms with labels for each field OR use Dynamic Forms (contact Mary.Smith@mtsu.edu) to create a web form. 

Note: If you need to use a PDF form, FITC can help you test it for keyboard and screen reader accessibility. Contact at 8189 or itdacad@mtsu.edu. 

(WCAG 1.3.2)

Problem: Tables are very useful for presenting complicated information in a compact, easy to read way. However, when a screen reader user enters a table that has not been marked appropriately, it can quickly become a jungle of disjointed information. Here is an example from the WebAIM Table Accessibility website: 

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.

Fixes:

Tables on the Web: Use correct HTML markup to create tables that make sense to a screen reader user.

Microsoft Word: Use Bookmarks in the first cell of tables, as shown in this YouTube Table Bookmarking video. This video also mentions some things you should not do when creating a table in a Word document.

Adobe Acrobat Pro: Use the Touch Up Reading Order tool on scanned documents. This should not be necessary for files created with accessibility in Word. For those, accessibility should carry over table markup when exported to PDF.

(WCAG 1.3.1 and 1.3.2)

Problem: Documents and websites are difficult to navigate when a heading structure is not present. Even when paragraph topics are bolded and placed in a larger font, assistive technologies cannot see them as headings unless they are marked using the built-in tools of the document creation program.

Fix: Place the cursor on the line of the heading that you typed and then choose Heading 1, Heading 2, Heading 3, etc. from the Paragraph or Styles menu so that the program can tell assistive technology where the headings are located.

Note: Headings should be on their own line. When paragraph text continues on the same line as the heading, assistive software cannot see it as a heading. 

• View a video demonstration of adding a heading structure to Word documents or this step-by-step website for adding headings

(WCAG 1.4.1 and 1.4.3)

Problem: People with low vision and/or color blindness may not be able to differentiate between shades that are nearly the same. Eg. This would be much easier to read in a font color that has higher contrast to the background.

You also don't want to convey meaning through color alone. A good example is MTSU parking. Red parking is for residential students, and Green parking is for all other students. People with color blindness had great difficulty differentiating between the two colors posted on signs in MTSU parking lots, so Parking Services added a large R on the Red parking decals. 

Fix: Use the  WebAIM: Color Contrast Checker to ensure high contrast in your text and find alternate ways to present information, such as using the moniker "Important:" before text that you would have otherwise bolded, underlined, or marked in a bright color.

(WCAG 1.4.5)

Problem: Scanned pages are often put into PDF format. If these pages do not have text recognition performed on them, they will simply be images of scanned content. Assistive software is not able to access the text if it has not been recognized with optical character recognition (OCR).

Text inside JPEGs, PNGs, etc. is also not readable by assistive technology. See Alternate Text Tags

Fix: Use Adobe Acrobat Pro (ITD has a free site license) to recognize (OCR) text in scanned pages. Alternately, you can scan pages using the R. J. Young printers with OCR turned ON and Compact turned OFF.

Note: For books, you'll want to press down on the pages while scanning so that the Acrobat software has the best images possible and thus, the best chance of correctly recognizing the text. 

• View a video of what students experience when text is and is not renderable or this step-by-step website to remediate accessibility in scanned PDFs 

(WCAG 1.4.5)

Problem: Mathematics are difficult to understand through description alone, although this is a common approach to accommodating students with a visual impairment. Students with a learning disability can also need more than traditional approaches to mathematics teaching.

Fix: Use MathML to create fully accessible mathematics that can be navigated by the student using a braille display, screen reader, or accessible math viewer.

Note: D2L has a built-in MathML creator. Alternatively, you can create documents with Microsoft Word and the MathType plug-in. Unfortunately, Equation Editor in Microsoft Word does not create accessible equations. PDFs do not mean automatic math accessibility either.

In Pearson products, the publisher has recommended choosing questions that have an ear icon (this denotes the problem as accessible to a screen reader). 

(WCAG 2.1.1 and 2.4.3)

Problem: Students with a mobility impairment may rely solely on the keyboard for navigation. If websites do not show focus when tabbing from element to element, these students will not be able to get to class content. You should be able to press the Tab key repeatedly on a webpage to access all information and functions.

Issues can also arise for screen reader users when software and websites have "keyboard traps." This is usually due to underlying code that has not been tested for accessibility.

Fix: Be sure that your website uses visual focus indication by pressing the Tab key repeatedly to make sure that you can access all information and functions. See a video on testing for keyboard access.

Note: If you require your students to use third-party software and/or websites, you will want to test those for accessibility with screen reading software. Contact FITC at 8189 or itdacad@mtsu.edu.

(WCAG 2.3.1)

Problem: Websites, videos, etc. that include flashing lights can trigger seizures for students with a seizure disorder.

Fix: Remove any parts of your website or presentation that include flashing/flickering elements.  

(WCAG 2.4.4)

Problem: Links such as "click here" and "https://www.youtube.com/watch?v=oG5iVYE..." do not tell a screen reader user what the link is taking them to. This may not seem like a problem when the context of a webpage or document describes the destination of the link. Eg. For more information on poison dart frogs, go to https://goo.gl/Kyj6u9. However, screen reading software has the ability to pull out all links on a page and put them in a quick list. This loses the context from the page (see demonstration video below) and creates a long string of URL text that may or may not make sense to the user.

Fix: Use descriptive links in the body of your text. Eg. The MTSU School of Nursing offers both graduate and undergraduate degrees.

Note: When putting together documents that will be printed out, such as a syllabus, use descriptive links for the hyperlinked page AND insert the URL as plain text (remove the hyperlink after pasting the URL). Eg. The MTSU School of Nursing (www.mtsu.edu/nursing) offers both graduate and undergraduate degrees. 

• View a demonstration of adding descriptive links to a document or webpage.

(WCAG 3.1.1)

Problem: Web pages and documents (Word, PDF, etc.) have the ability to change the specified language of the text. I.e. You can mark a Spanish language Word document as containing spanish text. If you do not make this change in the program, screen reading software may try to pronounce Spanish text with an English language synthesizer. This sounds a lot like someone who doesn't speak Spanish trying to pronounce Spanish words. Yikes!

Fix: Web pages have a specific way of coding language of the page, and you can even mark individual parts of the web page as containing a specific language, if the page has more than one language present. Document language can be marked in the menu system of the program where it was created. 

(WCAG 4.1)

Problem: Technologies that are the standard today may be changed or replaced tomorrow.

Fix: Use tools in the way that they were designed. In the same way that Microsoft Word has built-in Styles to aid in document creation ease and quick navigation for those using a screen reader, many programs have tools that ensure future compatibility with accessibility technologies. The best thing you can do is to become familiar with the accessbility tools built into document and website creation software. Use the list on the right side of this screen for a guide on application-specific accessibility practices.