Accessibility Table of Contents

This section contains accessibility tutorials, references and links and the Accessibility Blog and Resources . We hope to add to this resource over time.

Accommodation Needs

This is a tutorial about accessibility audiences, policy and where to learn more about accessibility accommodations for different technologies.

Definition of Accessibility

What is accessible design?

Tutorial Page 1

An online document or tool is accessible when it can be easily understood by everyone, regardless of what browser or adaptive equipment he or she is using.

Another term for accessibility is universal design , and is the principle that any one document or tool can be accessed by any user regardless of the device (e.g. visual browser, screen reader, mobile device) he or she is using.

This tutorial was created to help Penn State Web developers and faculty develop or adapt Web-based course materials so that they are accessible, and to raise both faculty and staff's awareness of disability-related issues as they affect teaching and learning with technology.

 

Target Audiences

Who are the audiences for accessibility?

There are multiple audiences needing their own accessibility accommodation, depending on their needs. However, many "accommodations" actually serve more than just the intended core group...showing that accessibility can benefit everyone.

A. Severe Visual Impairment

Individuals with severe visual impairment may rely on a screen reader (software that reads content aloud) to access Web sites. Visual cues, such as images, section divisions or table headers, may be imperceivable to this audience unless additional information is added. Often required are text alternatives for images and other visual content, and the specification of key landmarks (e.g. headers, lists) within a document.

 

Tools Needed

Screen Readers

Screen readers are pieces of software that read all the text within a digital document aloud. Most screen readers also allow users to move from landmark to landmark within a page. Landmarks can include section headers, links, table headers and other items indicating important divisions of information.

The most commonly used screen reader is JAWS (Windows only), but other screen readers include NVDA (Windows), VoiceOver (Mac), and Emacspeak (Linux). Screenreaders are often used by and associated with visually impaired users, but some, particularly Kurzweil (Win/Mac) are also used by individuals with certain reading disabilities.

See a demo of JAWS reading a page from the PSU Schedule of Courses.

Other Tools

Other tools used by the visually impaired community include:

  • Braille Printers—Printers that print embossed (raised) Braille on a page.
  • Refreshable Braille Displays—Tool that raise pins to form Braille characters. Users place their fingers on the device to detect changes in characters. See a Braille display demo (with a smart phone).
  • Embossed Printers—Printers that print embossed images and graphs with the edges raised.
  • 3D Printers—Devices that convert images into three-dimensional objects.
  • OCR (Optical Character Recognition) Software—Software that recognizes text embedded in an image and converts it to a text file. This is particularly useful for PDF documents in which each page is actually an image.

Top of Page

Please scroll down.

Screen Reader Demo

The following two images show a screen capture of the header at http://tlt.its.psu.edu in both Firefox and in Lynx.

TLT Header in Firefox

Image shows Penn State logo, Teaching and Learning with Technology logo, search box and tabs for Home, News, Events, Videos, About, Contact, RSS feeds

TLT Header Viewed in Lynx

Lynx screen capture shows alt tags for logos and tabs as menu. This is page 1 of 10 for this page.

Top of Page

Accommodations Needed

The main accommodations needed by users with severe visual impairment are:

  • Alt text to describe images or animations on the Web, in Microsoft Word and PowerPoint, ANGEL, Flash, PDF files, and any other online document.
  • Web forms and Flash forms that identify the functions of their fields.
  • Section headers indicated by something other than a format change. In Microsoft Word, authors should use the <b>Heading</b> styles. In HTML, headers should be indicated with H1, H2, H3, etc. tags.
  • Properly labeled Table headers.
  • Frames labeled with meaningful titles.
  • Functions, including scripted elements or all elements of a Flash interface, that are accessible from a keyboard.
    NOTE: Elements that can cause issues include drag and drop interfaces, menus and image maps.
  • Software and online tools designed to read out menus and functions to screen reader user.

See the Table of Contents to learn more about how to implement specific accommodations for each technology

Top of Page

Hidden Audiences for Text-Based Browsers

Visually impaired users are not the only ones who use text-only browsers. Other segments of users, such as those on older PDAs or cell phones, or who have disabled image downloading because of a slow connection, may also benefit from the simpler interface. Text-only browsers are especially useful to users outside the United States, who may only have access to the Internet via a text-only browser or cell phone.

Testing and Demo Tools

Screen Reader Simulations

Screen Reader Simulation Plugins

Top of Page

Etiquette for interacting with the Blind or Visually Impaired

Note: Many of these accommodations also apply to low vision users who retain limited visual acuity.

  • Identify yourself when speaking to a person who is blind and alert them when you leave.
  • Feel free to warn individuals with visual disabilities of dangerous situations. If there is a person with a walking cane navigating around a car in the street or headed for a column, feel free to speak up and say, “Hold on you’re in the street,” or “Stop… there is a column there!” Construction areas are a particular area of concern.
  • Strategies for asking if a person who is blind or vision impaired needs help:
    • Do not grab arm or touch someone, this may startle him or her.
    • Offer detailed instructions before touching someone. Offering an arm or providing detailed instructions is commonplace for those who are blind or have vision impairment. Detailed instructions could be a description of how to get to an open door, such as, “ two small steps to your right and just about 10 steps ahead of you is the doorway or would you like my arm?”
    • Offer an arm or shoulder, when guiding someone. Never leave him or her in a free or open space. Leave them in contact with a wall or arm rail if you need to leave them for a moment. When offering a seat you may offer to guide their hand to the seat.
  • Do not make assumptions of capability. Respect any persons’ ability to do things. People find ways and use tools to achieve their goals. Esref Armagn is a Turkish painter who just happened to be blind. He taught himself to write and oil paint with full visual perspectives in the paintings.
  • Guide Dogs: Do NOT approach, try to pet, try to feed, or try to gain the attention of a guide dog.  The dog is there to do a job and specially trained for that job. The casual attention offered to this dog may disturb the training and cause problems for the owner. A good rule of thumb to remember is if the dog is wearing his uniform or harness, then he is on duty. Note: If the dog is doing something inappropriate, inform the owner and allow the owner to correct the behavior of their guide dog.

Language

Remember, “person-first language

  • It is fine to refer to vision and metaphors concerning vision in a conversation, such as, “Do you see what I mean?” or, “Look at this!”
  • Speaking and giving directions; refer to directions by giving an approximate distance or number of streets and or give landmarks (They may recognize sounds of an escalator). Just remember to clarify the details of the direction, just like you would with anyone.
  • Maintaining a conversation and use descriptive language with some who is blind seems like an odd tip. In a discussion between people there are visual cues many of us do not think about when starting and stopping a conversation. Imagine your cell phone going off and you answer the phone, while offering an apologetic look at a friend and mouthing silently sorry.  This is NOT achievable with a person who is blind. Also, in conversation the reference to colors, patterns, design and shapes should not be avoided. Each person has various experiences and all forms of description are valuable. A person, who is blind, could be told the wall is a bright yellow and associate the color with the feeling of a warm summer day because the sun has been described as yellow. Just because the person may have never seen the bright color of the sun, doesn’t mean there is no association to the sun.

In the Classroom

  • With furniture placement, remember people who are blind or vision impaired memorize the layout of a room, especially if the room is frequently visited.  Try to avoid situations in which the room layout changes. If you or someone else changes the room layout, you should warn those who are Blind/Visually impair when he or she enters the room. Desks in a circle, or media cart brought in for presentations are just some examples that alter the space temporarily.
  • Engaging in class activities should, also, be considered with a student who is blind. Moving desks for group activities, hands-on activities, or watching a skit or other students’ performances or presentations should be addressed and accommodated to allow a student who is blind to participate.
  • Also, be aware, vision impairment may be degenerative in nature. This means the needs may change over time. As a teacher or employer, remember to clarify the needs with those who have vision impairments. And as a person with a visual impairment you should always maintain an “open dialogue” with your teachers or employers about changes in concessions.

Top of Page

B. Low Vision

The term "low vision" refers to individuals who have enough sight to use a visual browser, but who may need to enlarge text or use special high-contrast font and color settings in order to access online information. To accommodate low vision users, it is important tools not inadvertently disable zooming or the ability to adjust color/font settings.

Tools Needed

Low vision users need a mechanism to zoom in on content on a computer screen, sometimes to a great extent. Zooming works well for vector-based text and graphics in .PNG format, but causes pixellation for bitmapped images such as those in .GIF and .JPEG formats

Many users with special visual needs may implement custom settings or style sheets to override the formatting specified on a Web page or document. The adjustments these tools make depend on the user's settings, and can include zooming or light text on a dark background.

Demo

Please scroll below.
 

Page on High Zoom

This image shows an example of the Wikipedia entry for King Henry IV of France zoomed to a level that a person with low vision might require.

Image shows portrait and 3-4 sentences

Reverse Contrast

This image shows an example of the Wikipedia entry for King Henry IV of France as intended for another low vision user. This page uses CSS to display light text on a dark background in order to reduce glare. Note that the links are yellow, not blue.

Portrait of Henry IV with gray background, white text, and links in yellow.

Top of Page

Accommodations Needed

Low vision users need technology that allows adjustments in visual formatting. Cascading Style Sheets, employed through HTML, are one way to enable this, since users can use their own styles. Flash, Word and PDF and most modern browsers also enable zooming.

Depending on their specific condition, a user may need:

  • Always dark text on a light background (some prefer cream backgrounds over white) OR  always light text on a dark background (like a terminal)
  • Always serif fonts OR always sans-serif fonts OR
  • Always zoomed to large sizes OR a unique combination of all of the above

Top of Page

Hidden Audiences for Low Vision Accommodations

  1. Users of mobile Web devices who face the challenges of reduced screen size.
  2. Users, particularly older users, who may wish to zoom in on the text of a particular Web site because of small font size. In addition, some color combinations (i.e. those with bright colors) and fonts are difficult for all users to read.
  3. People who are particularly sensitive to light (e.g. migraine sufferers) or work in poor lighting conditions may need to adjust their browser views and colors.
  4. People accessing the Web in poorly lit conditions
  5. People on monitors with varying display capacities.

Top of Page

C. Colorblindness/Color Deficiency

About Colorblindness/Color Deficiency

Although considered only a minor disability, slightly fewer than 10% of all men suffer some form of colorblindness (also called color deficiency), so this audience is very widespread. Colorblind users are unable to distinguish certain color cues, often red versus green.

Read the Color and Colorblindness page for more detailed explanation of these deficiencies and how to accommodate them.

Demo

The two images below show a color-coded menu; first as it appears to a user with normal vision, and then as it appears to a user with a visual color deficiency.

Color-Coded Menu

Color Coded Menu - red=math, green=science, orange=word games, purple=history

Viewed by Color Deficient User

Red, purple, green are all shades of brown

Top of Page

Accommodations Needed

For users with colorblindess or color deficiency, it is important that color-coded information be available with another visual cue such as changes in shape, line texture or a text-based code. For example, in the color-coded menu above, even though the red and orange colors are muted, the user can still read the text and know to which sections they refer.

Top of Page

Hidden Audiences for Colorblindness Accommodations

  1. Users with severe visual impairment, since screen readers cannot spell out color differences.
  2. People using a black and white printer.

Top of Page

Colorblindness Simulators

  1. Cal Henderson: Color Vision—Lets users test color schemes while simulating almost all forms of colorblindness.
  2. Visicheck Colorblindness Tester—Allows users to view images and live Web pages while simulating red-green and blue-yellow color deficiencies.

Top of Page

D. Deaf and Individuals with Hearing Loss

Tools Needed

A Deaf person or someone with hearing loss can see all the visual information in a Web site, but will not be able to hear any audio content.

Audio information should be presented in captions or an alternative text transcripts for some who is deaf or who has a hearing loss.

Captioned Video Demo

Please scroll down.

Accessible Video File with Text Transcript

The following interview with Prof. Nuria Sagarra is captioned. You can access captions by clicking the arrow button in the lower right corner of the screen.

Image of Nuria Sagarra with caption 'It's a no brainer really.'

Hidden Audience for Captions

  1. Some users may not be able to find one of several volume controls to enable audio or audio may be disrupted.
  2. All users may need captions if the original audio quality is poor.
  3. Non-native speakers of English often use captions to help understand content.
  4. Some users may not have access to headphones, and it is very common to mute audio in public computer labs or common work spaces such as the library.

Top of Page

Deaf Culture

It is particularly important among many in the Deaf community to distinguish the condition of not being able to hear from the culture created and shared by sign language users.

Deaf- Deaf with a capital “D” refers “to a particular group of deaf people who share a language - American Sign Language (ASL) - and a culture.  The members of this group have inherited their sign language, use it as a primary means of communication among themselves, and hold a set of beliefs about themselves and their connection to the larger society."  (National Association of the Deaf)

deaf - lowercase deaf refers to the audiological condition of not hearing (National Association of the Deaf)

hard of hearing - refers to partial hearing loss. This term is preferred by many with partial hearing.

hearing-impaired - This term should be avoided since many in the Deaf or hard of hearing community feel it emphasizes a lack of ability.

Many students who are deaf or hard of hearing may come from multiple cultural backgrounds.
Possible Deaf Culture differences:

  • Some learned to speak and read lips which means learning English
  • Some may have cochlear implants to enable partial hearing
  • Some may have various levels of hearing impairment or partial hearing
  • Others use American Sign Language (ASL), a language composed hand gestures and facial expressions, or other sign language.
  • Some may have varying combinations

Top of Page

Etiquette for interacting with the Deaf

What does this cultural difference mean to the concessions needed to support these individuals?
This means written English is a second language for some. So, one must be aware, many ASL signs do not always translate directly to the English language. Furthermore, an oral speaking culture is a second culture with which a Deaf person must acculturate to. Much like a person from China or Spain must acculturate to the habits and behavior of Americans. We should be considerate of this and offer concessions. This may require several courses of action. There are three areas of consideration addressed below:

Culture

  • An important thing to clarify is “Deaf” with a capital “D” is recognized as referring to the culture or the Deaf community. Speaking Sign Language is comes with colloquial signs and regional dialects. Much like accents, or British culture in comparison to American culture. There is actually an American Sign Language and British Sign Language to continue this example. So, remember to respect Deaf culture as you would respect all cultures and their diversity.
  • Do not grab an arm or touch someone, this may startle the person. If you would like to gain their attention, tap on a surface near them. Tapping on a shoulder is acceptable, also. A person who is deaf will feel the vibrations and look in the direction of the disturbance. Remember, a person who is deaf uses other senses to communicate and interact in the world.
  • Speak to the person, not the interpreter if one is present. How you acknowledge a person affects how they feel. The next time you have a conversation, think about how eye contact with a person or the lack of eye contact the other person maintains with you, feels to you. Maintaining eye contact in an American culture offers a sign of respect and notifies the other person of a subtle sign of attention, understanding, and other conversational cues. This is especially heightened for a person who is deaf. If you are making eye contact with the interpreter, the person who is deaf may feel excluded or ignored and not part of the conversation.
  • Use the words, “I” and “you” when an interpreter is present. Do not say, “Tell him or her” or “Does she get it?” You are not communicating to the interpreter.
  • Do not make assumptions of capability. Sean Forbs won the 2013 Outstanding Hip-Hop Artist/Group DMA award. This Modern day Deaf music artist has been deaf since he was one year old.

Language

  • Do NOT ask if a deaf person can read and write. If there seems to be issues with writing content, recommending a writing tutor as occurs with those who speak English as a Second Language (ESL) students who orally speak other languages is acceptable and encouraged. Remember, sign language is a visual and conceptual language, which does not always translate verbatim to written languages. This can become an issue with specialized subjects or technical writing.
  • Carefully confirming content language if an interpreter is present. This issue of confirming content language with an interpreter falls to both the student using the interpreter and to the teacher, mutually. This is very important when discussing content language that has NO translation to sign language. An example where this may become an issue is in specialty fields using higher complex math equation or specific technical engineering language.

In the Classroom

  • Allow a student who is deaf or hard of hearing to select a seat for the best view of someone speaking or view of the projector and speaker.
  • Allow for hands-on participation if there is time for this form of class activity.
  • Also, facing a student and limit pacing. Facing and speaking to the students instead of speaking while writing on a whiteboard/chalkboard with one’s back to the audience, is helpful for those trained to read lips or those with various hearing impairments. Maybe using a projector or a slide projector remote to allow you to project information and speak in the direction of the class can be arranged. Technology is there to help students learn and the teacher to teach more effectively.
  • Class resources or online resources should be accessible in various forms. Videos may be close captioned or audio described. Content with audio components can be provided with alternate scripts and description. Various assistive technology devices are available to help meet these accommodations. A list of assistive technologies available to help teach and learn at Penn State can be found at http://accessibility.psu.edu/assistivetech
  • Strategies for asking if a person who is deaf or hard of hearing needs help:
    • Using a piece of paper or writing to speak is perfectly fine if you are unable to use sign language.
    • Check if there is a need for a note taker or other options to be arranged.
    • Repeat questions and or statements in class. Furthermore, allow participation and verification of content. When asking the class if there are any questions, simply making eye contact for a visual cue may be sufficient.

Top of Page

Audism

Audism is a belief that the ability to hear and orally speak is superior to not hearing and using sign language. Audists are those who believe in Audism and these believers may be deaf or not deaf. Audism is comparable to racism and sexism in the Deaf community.
There are multiple types of Audism:

  • Physical audism- the prejudice that someone is physically incapable of performing a task based solely on his or her ability to hear.
  • Linguistic audism- banning or not recognizing sign language as a language
  • Cultural audism- a prejudice that affects the depiction or results in suppression or exclusion of Deaf culture.
  • Internalized/dysconscious audism- audism that occurs within the deaf community. This is a complex issue within Deaf culture. It reflects various opinions about those who are deaf and his or her choices to obtaining cochlear implants, learning both English and ASL, learning to speak or read lips, and other situations.

 

Top of Page

E. Impaired Mobility

Users with mobility impairments often rely less on a mouse to navigate computerized content, instead using the keyboard or another, more specialized input device(s), and therefore may require accommodations in order to access and comprehend a Web page's content.

Tools Needed

Mouse alternatives primarily include keyboards, as well as special trackballs, "sip and puff" systems, joysticks controlled by the teeth, eye tracking devices and speech recognition input.

Accommodations Needed

Generally speaking, it is easier for motion impaired users to input data using a keystroke rather than by clicking a mouse. Whenever possible, a mouse alternative should be available in the form of text links, text-based wizards or keyboard shortcuts (such as in Flash). Custom keyboard commands should be overtly indicated on a Web page or within a menu.

If mouse-click tools are implemented, the targets should be larger (e.g. a whole phrase), rather than smaller (e.g. a single word).

NOTE: You should not necessarily implement these accommodations through hidden KEYACCESS tags. Such a fix can disrupt the normal operation of assistive devices and screen readers. Keyboard accommodations should be overtly written out on the page or within a menu.

Example of Keyboard Alternative

Photoshop Image Size Tool

Photoshop lets you to enter numbers for image dimensions/resolution and to tab between fields to change image size.

Photoshop Image Size Window with fields for width, height, resolution

Top of Page

Hidden Audiences for Impaired Mobility Accommodations

Anyone having difficulty using a GUI input device can be considered to have some form of mobility impairment. This includes:

  1. Users with a screen reader, since the device may not be able to see an interface well enough to aim a mouse to a tool or button.
  2. Users with carpal tunnel syndrome, or with certain forms of arthritis that limit manual dexterity.
  3. Anyone with an injured arm, elbow, finger or wrist who will need to rely on mouse alternatives for the duration of his or her injury.
  4. Those with neurological disorders that cause loss of fine motor control, such as Parkinson's and essential tremor.
  5. Anyone learning to use a new mouse, trackball, joystick or other device (e.g. iPhone touch control).

Top of Page

F. Learning Disorders

Readers with learning disorders such as dyslexia or attention deficit disorders may have difficulty processing certain types of information. At Penn State, these users would primarily include those with learning disabilities, as this is the largest set of students registered with the Office of Disability Services.

Accommodations Needed

Experts generally recommend maintaining a consistent, simple interface so that users with cognitive impairments can process online information more easily. Specific recommendations include:

  1. Adjust writing style:
    1. Use shorter chunks of text grouped by headings. This style of writing assists screen reader users and also helps many users who skim information on the Web site fully comprehend the content.
    2. Use as little jargon as possible. If specialized terms and abbreviations are needed, be sure that definitions are included and easy to locate.
    3. Be aware that humor (including sarcasm and pop culture references) may not be understood by all audiences, including those whose first language is not English.
    4. Ensure that fonts are enhanced for legibility.
  2. Avoid automatic background audio, scrolling text, automatic slide shows and continuous animations, as these features can be distracting for many users.
  3. Place universal navigational schemes in a consistent location on all Web pages.
  4. Make sure a Home link is included on as many pages as possible. Do not rely on a clickable logo alone to act as a home link - many people do not know that convention. Some research indicates that most users expect the "Home" link to be in the upper left portion of a screen or menu.
  5. Links styling and buttons should be distinct from other elements on the page. This is also important for low vision users.
  6. Change CSS styles to add left and right margins, and to increase line spacing. Both of these provisions enhance readability.
  7. Ensure that your site works on a screen reader. Some users may use a visual screen reader such as the Kurzweil screen reader which highlights text as it is read aloud.

Balancing Needs

Ironically non-text media can benefit many users including those with some cognitive disbilities. The key is to ensure accessibility for those who need a text alternative.

  1. Images (including icons, charts, maps) may benefit many users, but alternative text also needs to be available for the visually impaired users..
  2. Some icons (e.g. arrows, trash cans) can be beneficial, but if an icon is too ambiguous, a supplemental text label may be needed.
  3. Presentations of information in a audio podcast or video can benefit some users, but a transcript should be included for hearing impaired users.

Top of Page

Hidden Audiences for Cognitive Impairment Accommodations

The needs of different cognitively impaired user groups are subtle and not always well understood, but consider that:

  1. Many usability recommendations facilitate cognitive processing in general.
  2. Speakers whose native language is not English.
  3. In terms of course design or instruction, a student generally has a simpler cognitive model than an expert does.

Top of Page

G. Other Neurological Impairment

Epilepsy

Rapidly flashing or blinking objects are discouraged for use on Web sites, as they can trigger seizures in some users. Generally speaking, you should avoid objects which flicker or blink more than 3 times per second.

For more details on flicker guidelines, see the WCAG 2.3 Guideline: Seizures.

Items with gentle pulses or subtle dimming/lighting effects are effective while still meeting accessibility guidelines.

Hidden Audience: Migraine Users

Some users, including those with certain types of epilepsy and migraines, may be susceptible to attacks or "episodes" when confronted with "loud" visual presentations. Particularly aggravating are:

  1. Rapidly blinking or animated objects, which can trigger an epileptic seizure in some users and headaches in others.
  2. Stripes, zig-zags and other types of geometric patterns, which can trigger migraines in some users.
  3. Strongly contrasting color schemes, which some users have reported cause headaches.

Top of Page

H. Accessibility Etiquette

Synopsis

Language Basics

  1. Person First Language is recommended when referring to a person with a disability. Example: Do say, “a person with a disability” and do NOT say, “a disabled person.”
  2. Euphemism or Patronizing language is overly politically correct or nice language and should be avoided. Example: Do NOT say, “differently abled” or “he/she is challenged.”
  3. Open dialogue is a discourse between two people and the first step to effectively communicating needs between those two people.
  4. Public dialogue is an informal or formal group dialogue with the goal of resolving issues, and developing empathy and understanding.
  5. Group Internal use of Stigmatized Terms refers to the idea of “reclaiming” terms with which were previously considered negative. (e.g. a support group for women with disabilities called Gimp Girl, founded by a woman with a disabilities). You should NOT use such language unless you are a member of that community or are invited to.

Assisting a person with a disability

  1. Questions to ask before helping someone with a disability? Consider the accessibility of an environment or helping someone without physical contact and accessible materials for those with various disabilities.
  2. Tips to helping some with a disability can be specific to the person with disability. Check out the tips below and put yourself in their shoes.

In the Classroom/Hybrid/Online

  1. Teachers communicating with students with disabilities can be difficult depending on the specific kind of disability. Starting an “open dialogue” and reviewing the tips below are a great start.
  2. Persons with disability communicating with their teachers should begin on the first day of class and contacting the Office of Disability Services will allow for class content to be universally design for all the students’ needs.  All students can benefit from this.

Top of Page

Language Basics

Person First language

In order to provide focus on the person versus his or her disability, it is recommended that “person-first” language be used to refer to someone who may have a particular disability. Thus, the expression “a person with a disability” is preferred to “disabled person.”  Similarly, the expression “person who uses a wheelchair” is generally preferred to “wheelchair bound”. The use of “person first” language has become a practice of etiquette and more importantly respect for people with disabilities.

NEVER use a disability as an adjective. Calling a person “disabled,” “handicapped,” or identifying them solely by their disability, such as “the deaf guy” or “a blind person” associates them with ONLY their disability and not as a person. Another example, wheelchair bound or confined to a wheelchair is a negative verbalization of a wheelchair. The wheelchair enables them to be mobile and gives a person access to the environment, so the person is a person that uses a wheelchair and not a wheelchair user.

Euphemism or Patronizing language

A euphemism is patronizing or overly politically correct language, such as saying, “He/she is challenged.” The use of the word “challenged” is the euphemism. This is sometimes referred to as “Nice” language. Other examples of this are saying someone is  “differently abled.” When using patronizing language, there is emphasis placed on the disability with a connotation of inferiority as person. Every person is capable of achieving a goal and uses various tools to do so. People with disabilities use tools to achieve those goals, such tools as wheel chairs, canes, various technologies and other assistive devices or technologies.

Open dialogue

Open dialogue is an open discourse between two people to meet a consensual and mutual understanding between each other. This discourse should allow for freedom to ask questions, bring forth requests freely, and be mutually receptive and non-judgmental about the topic of the dialogue.

Initiating “open dialogue” with students, friends, coworkers or anyone for that matter is the first step to building communication. This allows for needs and concessions to be arranged for everyone to follow.

Students should approach teachers and clarify if the teacher understands any needs or concessions. A student should understand the perspective of the teacher. The teacher has a large number of students to attend to. So, the student needs to make a teacher aware of their needs.

Also, teachers should take the initiative and check with their students, especially if a student is identified with a disabilities. Each student has a differing set of abilities and differing concessions are necessary based on those abilities. Exploring these concessions should be done privately between the teacher and student and both should feel free to initiate discourse to achieve a mutual goal.

Public dialogue

Initiating “open dialogue” and engaging in “public dialogue” are very different. Public dialogue usually takes place in a formal or informal setting discussing the topic in a group or social group. The goal here is to gain understanding and develop solutions to communicating and understanding each other’s needs. Understanding each other’s perspectives on the subject of disabilities can be hard for those with a disability and without. No one wants to be mean, make someone feel bad for not understanding how to respect each other’s feelings and needs. So, those persons with a disability and those interacting with persons with disabilities should be careful not to have judgmental behavior. A “public dialogue” can be an opportunity to learn from each other and gain empathy for each other’s feelings and perspectives and develop solutions to help everyone feel comfortable.

Group Internal Use of Stigmatized Terms

You may find people with disabilities using or “reclaiming” terms which were previously considered negative. For example, there is a support group for women with disabilities called Gimp Girl (http://www.gimpgirl.com/). Another example is the use of Deaf with a capital D to describe the community of sign language speakers.

In many cases though, a person NOT belonging to that community may want to be cautious about using the term until advised to by a member that community.

Top of Page

Assisting a person with a disability

Questions you should ask yourself before helping those with disabilities:

  • Is the environment accessible? Assessing the surroundings from a perspective of the person with the disability is difficult. You are not he or she and may never understand their perspective completely. But, there are tips to help offer some foresight to the situation.
  • Are you able to give help without physically touching the person or entering their space or comfort zone?
  • Are classroom materials accessible for the students’ needs?
Assessing the needs is done both by the person with the disability and the faculty or staff providing the concessions. This leads to being sensitive about the environment, physical contact or how content is provided.

Here are some tips:

  • Do not pat someone on the head or touch a cane, wheelchair or other tools that they use. As in the previous example, having a table in the classroom available for the student and not desks with attached chairs maybe an issue.
  • If you are going to offer assistance, ask them how they would like that assistance to be given.
  • Also, be mindful about moving furniture and providing a pathway. Keep in mind clearance and consistency of furniture placement. This allows access for those with who need mobility access due to the use of a wheelchair or a person with vision impairment.
  • Think before speaking and use “Person-First” language as explained in the Language Basics.
  • Do not grab someone’s arm or touch someone’s physical persons, this may startle them. Is this normally done to you? If you would like to gain someone’s attention, tap on a surface near them or make your presence know verbally and without touching their persons. Remember, for those who are vision impaired/blind verbally identifying yourself is the best practice.
  • Offer and only push a wheelchair when requested. If possible, try to sit at eye level with a person in a wheelchair. This removes any perception of speaking down to a person in a wheelchair and this action reduces the kink in the neck of a person who uses a wheelchair.

Top of Page

In the Classroom/Hybrid/Online

Teachers communicating with students with disabilities

  • Behave naturally as if you would with any other person
  • Always talk to a person directly even if an assistant or interpreter is present.
  • Speaking at their physical level, if in a wheel chair sit and hold a conversation at eye level.
  • Avoid making assumptions to students’ needs or abilities. This goes for all students. There are students with hidden disabilities.
  • Respond to the requests when made in a reasonable amount of time.
For further information, please visit the Office of Disability Services web site: http://equity.psu.edu/ods/dcl
  • In the classroom the environment and the class activities play a big role. For example, the user of a wheelchair may need the classroom arranged to sit and participate with other students. This may be an issue if the classroom is full of desks with tables attached to the chairs. A student who is blind/vision impaired/deaf may need to sit near the front or be guided to a seat. Furthermore, breaking out into a group project and shifting chairs may cause unforeseen issues for some. If there are any doubts initiate an “open dialogue” with your student.

Persons with disability communicating with teachers

Students with disabilities should start an “open dialogue” with teachers at the beginning of the course. Not to seek special attention, but to allow the teacher to make the curriculum universally accessible for all students and allow teachers to actively engage in best practices for online, hybrid or in class teaching. These alternative resources may benefit the other students in the class, also.

Students are also advised to contact the Office of Disablity Services at their local campus. The Office of Disability Services has been established to help students who need accommodations, particularly extended times for assignments or exams, receive them in the most efficient and timely manner possible.

Communicating in the Workplace

For detailed information and inquiries may be found at:
http://www.psu.edu/dept/aaoffice/access_accom.htm
or
http://accessibility.psu.edu/links

Final Note

Remember to approach disability language as a language of “Empowerment”!
http://sudcc.syr.edu/LanguageGuide/index.html

Top of Page

Assistive Technology At Penn State

Tutorial Page 3

These are a few locations at University Park where students with disabilities can access specialized computer terminals and other assistive technology.

Penn State Policy and Accessibility Guidelines

Tutorial Page 4

Penn State Policy AD-69 and WCAG 2.0

Penn State Policy AD-69 "Accessibility of Penn State Web Pages" was created in August 2011 to specify the required accessibility accommodations for Penn State Web sites.

AD-69 Policy and Accessibility

To quote from policy AD-69:

"All Web pages published or hosted by the University must be in compliance with the World Wide Web Consortium's standard: Web Content Accessibility Guidelines (WCAG) Version 2.0, AA conformance level.
"...This policy applies to all University Web pages used to conduct core University business or academic activities."

Policy AD-25: Video Captioning and Accessibility

In addition to Policy AD-69, Policy AD-25 "Video Productions" specifies that promotional videos should also comply with accessibility guidelines.

Faculty Senate Policy 43-00: Syllabus Statement

As of Fall 2012, Faculty Senate Policy 43-00 specifies that all course syllabi must include "information on procedures related to academic adjustments identified by the Office of Disability Services". See Accessibility Syllabus Language for recommended language.

Top of Page

Accessibility vs. Usability vs. W3C Web "Standards"

Accessibility Versus Usability Versus "Standards"

Different Standards for Different Purposes

Tutorial Page 5

Although accessibility is related to the issues of usability and coding standards, it is possible for a site to be considered usable and standards compliant but NOT accessible (and vice-versa). Below are some definitions, and situations where distinctions may arise.

Usability

Usability refers to the ability of average users with the "standard" range of equipment or abilities to navigate and use a Web site. In most cases, accessibility standards will also add usability to a Web site, but accessibility consists of more than just general usability.

Web Standards

Web standards refer to an initiative from the W3C and other Internet standards bodies to develop open Web standards that can be used by any software developer. The goals of such standards are to ensure cross-platform compatibility and more compact file sizes.

The focus of these standards has been to separate "content" from "formatting" by implementing CSS. Although CSS can definitely facilitate accessibility, it is possible to design inaccessible styles. Similarly, a non-CSS solution could be as equally accessible as a CSS solution.

A standards-compliant site does not guarantee an accessible site.

Potential Mismatches

Although many accessibility guidelines are straightforward, in some cases guidelines may conflict with usability or standards. For these cases, extra care must be taken to ensure that all audiences are able to access and use a Web site.

When Usability, Standards and Accessibility Collide
Issue Good Usability/Standards Bad Accessibility Solution
Color Coding Color is a key visual signaling device for humans. About 10% of men are partially color blind and cannot distinguish certain colors (especially red/green). Supplement color-coding with text/icon coding.
Acronyms & Compounds Style conventions may require abbreviations like HTML, PDF, NaCl, Sitemap, etc. to be listed without periods or spaces. Screen readers often mispronounce these items. Include the ACRONYM tag to assist in pronunciation.
Multimedia Using images, sound and animations can often be more comprehensible than large blocks of text. Some people even recommend icons for users with cognitive impairments. Screen readers cannot interpret multimedia elements without textual assistance Always implement ALT text, extended text descriptions and/or captioning or transcripts
Repetitive Navigation Having navigation buttons repeated on top and bottom is good for consistency and for those with some motion disorders. It is tedious for screen reader users to hear the navigation on every page. Implement a "skip navigation" strategy.
Multiple Columns Multiple columns are one way to reduce text width, which is conducive to legibility, and allows more material to fit in one screen. Multiple columns are difficult for some screen readers to interpret. Use style sheets to reduce a column width within a single-column layout.

Use appropriate table tags for data tables, and make sure layout tables make sense when read left to right, top to bottom.
Unicode for Foreign Languages Unicode makes data exchange between operating systems and foreign languages easier. Some screen readers cannot recognize Unicode input. Consult with users for best solutions. Symbols or audio files may be needed for some items.
PDF Files PDF files may be the only way to present information in complicated layouts or with unusual symbols online for all browsers. Screen readers may not be able to interpret all the information. PDF files need to be made accessible, just as Web pages are.

Top of Page

Myths of Web Accessibility

Some Accessibility Gotchas

Tutorial Page 6

In the years of discussion about accessibility in Web design, some implementation myths have emerged. Below are some of the most common misconceptions.

1. There's only a small audience for accessibility.

Myth—Accessibility compliance only benefits users registered with the Office of Disability Services.

Reality—At some point almost all of us will be in a situation where an image link is broken, colors are not distinguishable, text is too small, audio is not working, we cannot see the whole screen or we cannot move the mouse properly.

Top of Page

2. Only accessibility experts can implement accessibility fixes.

Myth—Accessibility issues are so arcane only an expert can really fix them.

Reality—Most accessibility fixes are simple to understand and implement once the content creator is aware of the tools and techniques. For instance, techniques in Word involve applying tools such as Heading styles, the table of contents generator and appropriate selection of fonts. The most specialized tool , ALT tagging images, can be quickly accessed by right-clicking the image and selecting the Format Picture option. The same is true for PowerPoint, ANGEL and many other common tools.

Top of Page

3. Waiting for problems is just as easy as doing it now.

Myth—You don't need to worry about implementing accessibility until a user requests accommodation.

Reality—If "an ounce of prevention is worth a pound of cure," then one minute of implementing an extra tag or adding more descriptions is worth one hour of finding each problem and figuring out how to fix it. Retrofitting a site for accessibility is far more time consuming than implementing accessibility measures from the beginning.

Top of Page

4. Accessibility = captioning

Myth—If I caption all of my video and audio recordings, my content is accessible.

Reality—Accessibility also includes accommodations for users with visual, mobility, or other, slighter impairments, and for those with lower-quality technology options.

NOTE: In the past, accessibility was equated to just implementing image ALT tags. The rise of podcasting and video brought awareness of captioning needs to the surface.

Top of Page

5. If it's audio, then a screen reader can access it.

Myth—If my content is delivered by audio, then by default a visually impaired user can access it.

Reality—The navigation to the audio (including the login process) may not be accessible.

Top of Page

6. CSS styling will guarantee accessibility.

Myth—If I use CSS, I can guarantee that my site will be accessible.

Reality—Although CSS can improve accessibility, you can also create additional accessibility issues if you use the markup incorrectly. Similarly, you can create sites that are standards-compliant, but still inaccessible. WCAG 2.0 does not require that CSS be used, but it does recommend that sites be usable without CSS.

The same statement applies to other standards such as XHTML, XML, MathML, Unicode, etc. These standards facilitate data exchange, and are easier for assistive technologies to work with, but do not guarantee accessibility.

Top of Page

7. Accessibility means no more tables, JavaScript, Flash, image maps or frames.

Myth—All HTML tables, JavaScript, image maps, multimedia and frames must be removed to be standards-compliant.

RealityNone of these eliminations are required by WCAG 2.0. What is required is that that these tools be implemented with sufficient information for a screen reader to use. In most cases, this only requires the addition of a few specific attributes. Even JavaScript programmers have developed techniques to create accessible code, especially in terms of the recently developed ARIA standard

Top of Page

8. Accessible design is plain.

Myth—An accessible Web site is a plain Web site.

Reality—More complex designs can be implemented while remaining accessible. The key is to incorporate elements that do not interfere with legibility, screen reader access or keyboard access, and are easy to use for the motion impaired. See the following accessibility Web sites for examples: WebAIM, Jim Thatcher Accessibility Tutorials, and Accessify.com.

Top of Page

9. Text-only is a good accessibility option.

Myth—Creating a parallel, text-only site or service while maintaining an inaccessible site is the best solution for accessibility.

Reality—Most users prefer that accessibility options be incorporated into a single Web site, saving text-only transcripts for multimedia content and plug-ins. The reasons include:

  1. Many people with disabilities feel that text-only sites are exclusionary. A single site with appropriate accessibility is perceived as more inclusive to the entire Internet community.
  2. It's much more difficult to maintain a second site. Once it's out of date, you are out of compliance, because equivalent information is not available to everyone.
  3. Newer screen readers can actually process accessible HTML better than they can a text-only site.
  4. Text-only sites may address some accessibility issues specific to screen readers, but not all accessibility issues.
  5. Accessibility goes beyond "text-only," so the original site must be reviewed in any case.

NOTE: Using CSS to present alternate views of content may be a useful strategy in some situations.

Top of Page

10. Accessibility requires EM and STRONG tags.

Myth—You must replace the B (bold face) and I (italics) tags with STRONG and EM tags to be compliant.

Reality—Although this is recommended in the Web Standards community for a variety of reasons, it makes little practical impact in visual browsers or screen readers.

Top of Page

11. Minimum WCAG 2.0 compliance fixes all problems.

Myth—If you meet the minimum requirements for WCAG 2.0 compliance, you will never have to worry about accessibility issues again.

Reality—Not all user needs can be accounted for in any guideline. A user may require further assistance because of a particular combination of needs. In addition, advances in Internet options will inevitably create additional accessibility issues. This page and this site are continually updated to ensure compliance with accessibility guidelines. The goal of WCAG 2.0 is to address common barriers to usability in order to reduce future accessibility issues.

Top of Page

Conclusion: Accessibility for Everyone

Seminar Page 8

Here are some tips for effectively understanding and implementing accessibility strategies.

1. Experience a Screen Reader, a Film with no Audio and so forth

There is no wake up call like viewing a Web page you have developed on a screen reader to understand the issues that visually impaired users might face. This is also true for using the Internet with a grayscale monitor, a small screen, no audio, slow bandwidth connection or other less than ideal conditions.

2. Use a Multi-Pronged Testing Strategy

A testing strategy should include a standards verification report, checking to see how the site appears with images and CSS disabled, a color contrast check and an audit of content with

In addition any plugins, applications and web apps should be checked to ensure that they work with a screen reader (including login and navigation). Even if the plugin itself cannot be used, it may be possible to present the content or function within an alternate tool/format.

3. Remember the Context

There are very few accessibility requirements which can be blindly applied without considering the context of the Web page. For a screen reader audience in particular, a balance between too little information and too much redundancy should be maintained.

4. Make Sure Accessibility Tags or Tools are Supported

Some of the newer accessibility tags and standards have been proposed, but do not have full support yet in screen readers or broswers. Before spending great time and effort implementing new tags, make sure that modern browsers and screen readers such as Jaws have implemented them recently. Otherwise, it may be more efficient to use some other accessibility strategy.

For instance screen readers may not support all the tags for complex tables. In that case, a series of simple tables may be more accessible to more users.

5. Be Patient with Developers

Some tags and recommendations are time consuming to implement, especially if a Web site needs to be retro-fitted for accessibility. However, having developers experience screen readers may give them a different perspective.

6. Be Patient with Accessibility Experts

Accessibility is, unfortunately, a complex issue which does not always lend itself to simple answers. You may hear conflicting advice on how to best implement accessibility. Understanding the audience issues and your goals will hopefully provide you with sensible alternatives.

7. Be Patient with Users

Evan after implementing all the recommended tags and strategies, some users may still encounter problems you were not aware of, either because of unique conditions or outdated browsers or equipment. These users still need accommodation.

8. Keep up with Accessibility Developments

Screen readers and browsers are continuously evolving. Old problems may be solved and new ones created. Evolving technologies will create new accessibility issues.

BUT, if you incorporate accessibility now, you will be better prepared for new developments in the future and less likely to need to make major changes.

End of Seminar

Video: Importance of Web Accessibility (Penn State Only)

In this recorded presentation, Bill Welsh from the Office of Disability Services gives an overview of the issues accessibility policy, accessibility audiences and accommodations needed, particularly for students taking courses.

Note: Penn State login is required.
 

What to Fix

Downloads

Below are some slides which explain accessibility issues and blockers.

Specific Pages

These are issues which should be addressed in terms of accessibility.

Image ALT Tag Tips

About ALT Tags

ALT Tags are invisible descriptions of images which are read aloud to blind users on a screen reader. Adding ALT text allows authors to include images, but still provide the content in an alternative text based format. If no ALT tags are provided, then a screen reader would only be able to say "IMAGE" or perhaps provide a file name.

WCAG 2.0 Guideline 1.1.1—"All non-text content that is presented to the user has a text alternative that serves the equivalent purpose."

This page provides general guidelines on what kinds of text to use in an ALT tag. For specific steps within a specific tool, please select a link within the "Related Links" section.

Top of Page

Accurate, Concise Description

It's important to not only provide an ALT tag, but also provide one that is useful in the context of the document. You may not need to include every artistic detail, and you may be able to skip over purely decorative images, but those that contain critical information need to have it to spelled out in the ALT text.

A good rule of thumb to consider is to include what you might relay over the phone.

Infographic Example

Consider an graphic at an e-commerce which includes two credit card company logos. If you need to know which credit cards are accepted, which would be the better ALT text?

Select Preferred ALT Text for Credit Card Logo

  1. ALT="Credit Card Logos" (which ones?)
  2. ALT="Vidi-Visi and Magic Card accepted." (conveys specific cards)

Vidi-Visa (Fake Visa) and Magic Card (fake Master Card)

Top of Page

 

Artistic Example

Consider this example of a photograph of the dome of the U.S. Capitol (Picture from Architect of the Capitol Office).

Capitol Dome

When thinking of an ALT tag, the task would be to consider WHY the image is included. Is it within a political science course? A news story connecting Penn State to an event in Washington? An architecture course? Depending on the context, multiple ALT tags can be used.

Possible ALT Tags for Capital Dome Photograph

  1. ALT = "Capitol Building" (most Political Science/News)
  2. ALT = "Capital Dome in neo Classical style. Dome is white, circular with narrow windows on many levels and pillars on the lowest level. See additional details in text." (Architecture course)

Hint on long descriptions: If a description is very technical it may be worth including it in the main text so that all readers can benefit.

Top of Page

Decorative Image ALT Tags

A decorative image is one used to enhance the mood of a document, but not to convey actual information. Decorative images can include tool bars, clip art, photographs to add "color" and repetitions of a logo.

Decorative Images do need an ALT Tag, but the ALT tag can be empty (ALT="", best for Web) or a blank space (ALT=" " best for Microsoft Office). Both are valid but produce slightly different results across environments.

Long Description

ALT tags are generally recommended to be concise (about 150 characters). However, some images are so complex that more information may be needed. Today, most experts recommend including an ALT tag which refers blind users to a text based description elsewhere which is visible to everyone.

See the Complex Images section for different examples.

Top of Page

 

Links on ALT Tags

Top of Page

Complex Images

A course or document may need to use an image which would need a fairly long description to properly describe the content. In this case the recommendation is to include a short summary in the ALT tag which points to or links blind users to a long text description which fully explains the image.

The pages below describe some typical types of examples.

Long Description

Long Description

A course or document may need to use an image which would need a fairly long description to properly describe the content. In this case the recommendation is to include a short summary in the ALT tag which points to or links blind users to a long text description which fully explains the image.

In most cases, the long description should be available to all users. This long description will not only assist blind users but also sighted users who may not understand a complex image.

The examples below will provide examples of long description and how to place them to benefit the most users.

Example Technical Illustration

Below is a diagram of fluid laminar flow in a circular pipe. The velocity profile is parabolic indicating that flow velocity at the walls is slower than in the center.

Velocity profile of laminar flow in a pipe

ALT = "Velocity profile of laminar flow in a pipe."

Long Description Used

This diagram shows fluid flowing through a pipe along the x-axis in parallel layers with minimal disruption. Velocity arrows are shorter on the edges, representing a slower velocity vx and longer in the center, representing a faster. The edges of the arrow form a parabola and represent the "velocity profile."

Note: Only those visual details needed for understanding the concept are included in the long description.

3D or Tactile Images

If it is not possible to extract text information from an imagefor a blind user, then it is possible to provide a relief version of an image.

Contact the Office of Disability Services for more information if a student needs accommodation.

Top of Page

Charts & Accessibility

Charts, graphs and maps use visuals to convey complex images to users. But since they are images, these media provide serious accessibility issues to colorblind users and users of screen readers. See the examples on this page for details on how to make charts more accessible.

Synopsis

  1. If the data in a chart, graph or map is crucial to the content of a Web page, then you must provide a text description of the image. In some cases, a numeric table replicating the chart data could provide additional accessibility.

    WCAG 2.0 Guideline 1.1.1—"All non-text content that is presented to the user has a text alternative that serves the equivalent purpose..."

  2. Supplement color-coding of charts with texture, differences in line style, text in graphs or different shades of color to improve accessibility for colorblind users. Charts should be readable in black and white.
    NOTE: The default settings of the Chart Wizard in Excel are not color accessible. Use the formatting tools to change line styles and colors.

    WCAG 2.0 Guideline 1.4.1—"Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element."

  3. Don't convert tables of data into images—use an actual data table instead.

Top of Page

Text Descriptions for Charts

Strategies

Generally speaking an ALT tag cannot do justice to a complex chart. One way to describe a chart is to provide both a text summary and a properly coded data table near the chart.

This serves multiple audiences because a chart can show trends, but a table can provide exact data for those who are interested.

Example: Final /r/ Deletion in Detroit's African American Speakers

Trudgill (1995) presents the following data about the loss of word-final /r/ in Detroit African American speakers with speakers divided into categories for social class and gender. Numbers are in percentages with higher numbers representing higher numbers of standard forms.

Bar Chart for Data Comparing Men vs. Women across Classes. See table below for data
ALT= Bar Chart for Data Comparing Men vs. Women across Classes. See table below for data

Data from: Turdgill, P.(1995) Sociolinguistics: An Introduction to Language and Society, 3rd Edition. Harmondsworth, U.K.: Penguin Books.

Sample Text Description for Detroit Chart

Below is a description of the trends.

Summary of Trends

The numbers show that /r/ dropping becomes more common in lower classes (lower percentages of final /r/), but that women consistently preserve more /r/'s then men across social classes.

That is, women are more likely then men to approach standard English across social classes.

Repeat Data in Chart

This is the chart showing the specific numeric data. Please note that the data table features captions and header rows.

Percentage of Final /r/ in Detroit African American Speakers Across Gender and Class
Gender Upper Middle Class Lower Middle Upper Middle Lower Working
Female 90% 70% 44.2% 31.7%
Male 66.7% 52.5% 20% 25%

Top Of Page

Charts With Color

Sample Data

These charts will document the number of computers by platform.

Preferred Computer Platform  in Linguistics Seminar
Platform Number of Students
Windows 16
Linux 3
Macintosh 1

 

Bar Charts

Below are some examples of charts with inaccessible and accessible color choices and formats.

Inaccessible Bar Chart

Below is an image of an inaccessible bar chart for distribution of platforms in 2003. Solid sections of red and green are used, both of similar brightness, and therefore may not be distinguishable for colorblind users.

In addition, the only key to the chart refers to the colors, thus information is only conveyed by color.

chart with inaccessible color

In Grayscale

chart in grayscale, the gray bars

 

Accessible Version of Bar Chart

The data from the first table has been redone as a bar chart, but the colors have been changed to shades of blue. Colorblind users can use the different levels of darkness to tell the platforms apart. In addition, labels for each platform have been added to the bottom of the chart, so that viewers do not even have to refer to the key.

bar chart with accessible colors

 

Line Charts

For line charts, changing the style of the graph lines and adding labels increases usability.

Inaccessible Line Chart

This is an inaccessible line chart based on the data in the table comparing percentage of Mac and Windows users in 1990 and 2003.

Inaccessible line chart. Data shows Mac use declining and Windows and Linux use increasing

As with the previous inaccessible chart, this chart uses three colors of lines, all of similar brightness, with a key that only refers to color. In grayscale, these colors are virtually identical.

 

Accessible Version of Line Chart

This chart replaces three solid lines with one solid line and two dotted lines, with labels for each.

Accessible Line Chart. Same Data as previous image.

Top of Page

Documentation Screencaptures

For software documentation, it is often desirable to incorporate screen captures of particular windows or menus, and images could include lots of interface elements.

The key to accessibility is to ensure that the relevant information in the screencapture is included in the text instructions. Note that text plus images can provide an accessible alternative to a video screencast.

See examples below

Avoid Incomplete Information

Below is an example of what to avoid.

Create Accessible Data Table in Dreamweaver

Use the settings below to create an accessible table.

Dreamweaver Tables Properties Window. See next section for more details

ALT Tag

ALT = "Dreamweaver Tables Properties window"

 

Include Relevant Information in Text

Here is the Dreamweaver information with more details in the text which provide a detailed explanation for all developers.

Create Accessible Data Table in Dreamweaver

  1. In Dreamweaver, go to the Insert menu then Table. A pop-up window opens.
  2. Fill in desired settings for rows, columns, width, border thickness, cell padding and cell spacing.
  3. For the Header options, select from Left, Top, Both
    Note: Top or Both is the most widely supported in screenreaders.
  4. Enter in text for Caption and Summary as needed.
    Note: Caption is visible by default to all users, while Summary is used to provide extra information for those on screenreaders.
  5. Click OK to create the table

    Dreamweaver Tables Properties Window

ALT Tag

ALT = "Dreamweaver Tables Properties window. See information above"

Note that it is short because the additional information is included in the instructions above the image.

Top of Page

Equations: Images vs. MathML

There are several ways to handle equations from images with ALT tags to MathML. Having access to an equation editor such as MathType or MathMagic can streamline processing and converting equations considerably. These tools are similar to equation editors found in the ANGEL HTML Editor and Microsoft Office.

Image with ALT tag

A safe option to create an image of an equation (or export it from an equation editor) and then insert the image into a document with an ALT tag.

Note: ALT tags can be written in Nemeth MathSpeak for students who have learned that system.

An example in HTML is given below.

Equation Image

m equals begin fraction m sub 0 over begin square root 1 minus begin fraction v sup 2 over c sup 2 end fraction end square root end fraction

View the ALT Tag

ALT= "m equals begin fraction m sub 0 over begin square root 1 minus begin fraction v sup 2 over c sup 2 end fraction end square root end fraction"

Top of Page

MathML

Math ML is a text-based XML markup language designed for math equations. Browsers which support MathML are able to translate the XML into a formatted equation.

Browser support is increasing and equation editors can export MathML, but developers should consider the following:

  • For the JAWS screenreader, the optimal browser is Internet Explorer 9+ with the MathPlayer 3 plugin.
    Note: VoiceOver does not currently support
  • In most systems, the MathML used should include a link to the namespace in the first line in order for it to be displayed in Internet Explorer:
    <math xmlns='http://www.w3.org/1998/Math/MathML'>
  • The MathML should be embedded in an HTML 5 document for maximal support.

All of this means that MathML support is not available in all content management systems

Browser Support

This MathML Test page from Joe Java will give a good indication at how well a browser supports MathML. Browsers supporting MathML in HTML 5 include

  • Firefox 4+
  • Internet Explorer 9+ with the MathPlayer 3 plugin
  • Safari 5.1+ (limited)

Google Chrome does not support MathML as of October 2012.

CMS Support

Some sytems which support MathML include:

Top of Page

LaTeX

LaTeX is a math markup language familiar to many in the science and math community, but unfortunately is not currently supported by screenreader technlogy.

Fortunately, it is fairly simple to convert LaTeX to an image or MathML in most equation editors. In MathMagic and MathType, to import LaTeX.

  1. Copy a piece of LaTeX code such as
    m &= \frac{m_0}{\sqrt{1-\frac{v^2}{c^2}}}
    into an equation editor's main editing window.
  2. The equation should appear fully formated. Make minor adjustments as needed.

Technical Symbols in Unicode

In some cases, an instructor may wish to use Unicode text to insert a symbol into text as in the examples below:

P ⊃ P ∨ Q (P implies P or Q)

In this case it is important to ensure that screen readers are configured to output these symbols.
NOTE: VoiceOver for the Mac includes support for many symbols. JAWS typically needs to have its Symbol (.sbl) file adjusted.

Caveats to Text Equations

Even if the text of an equation is properly encoded as Unicode text, it may not be well-interpreted on screen reader because of layout elements such as superscript and subscript.

This is one reason why MathML is theoretically a better option if it can be implemented.

Top of Page

Equations: MathMLTest (Planck's Law)

Related Links

  1. Equations

The equation below is a MathML representation with MathJax implementation of one version of Planck's Law. As of October 2012 supported browsers include Firefox 4+, Safari 5+ or Internet Explorer 9 with MathPlayer 3.

E λ b = 2 π ℎc 2 λ 5 e ℎc λ k b T 1

MathML & MathJax Code

Below is the code used on this site. Some adjustments may be needed depending on your browser and access to your system templates.

Link to MathJax

<script type="text/javascript"
src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
</script>

Ideally this link to the script should be in the HEAD of an HTML document. However, you can also use an inline link elsewhere if your system allows it. ANGEL and some installations of Drupal allow this, but Sites at Penn State does not.

If page is password protected (e.g. ANGEL), then you should use the following URL in your SCRIPT link. https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML in You can read more at MathJax.org.

Flowcharts and Concept Maps

A common type of technical diagram is a flowchart, concept map showing relationships between different concepts. In many cases, the long description could be a list-based outline describing different parts of the process.

See examples below.

Concept Map

The following image is a concept map showing one way to organize pages of an online teaching portfolio. Below that is a text based outline which replicates the architecture within the image.

Concept Map Image

Concept map diagram - See outline after image

ALT ="Concept map diagram - See outline after image"

Outline of Concept Map

  1. Teaching Philosophy
  2. Courses Taught (can include course descriptions and syllabi)
  3. Teaching Awards and Publications
  4. Teaching with Technology Samples
    1. Teaching Philosophy in relation to technology
    2. Links to discipline or course-related links.
    3. List of technologies used
    4. Samples
      1. Course in which it was used
      2. Teaching goal of the sample
      3. Screen captures or actual document (graphics, audio, video, Powerpoint)
      4. Reflections on how technologies worked

Top of Page

Flowchart

A flow chart, process or cycle can also be described in terms of an outline, so long as the outline indicates the progression of steps either forwards, backwards or looping. See the example below of describing a flowcart of a captioning workflow.

Caption Worflow Image

Flow Chart image I Need a Caption - see outline after image

ALT="Flow Chart image I Need a Caption - see outline after image"

Outline Description

Title: "I Need a Caption"

Top of chart begins Q: "Did you shoot this video?"

    1. If "No" to shooting video, then Q: "Is it licensed?"
      1. If "Yes", then Q: "Can you buy a transcript?"
        1. If "Yes", then "Buy Transcript," then "Transcript Complete"
    2. If "Yes to shooting video, then Q: "Do you have a script?"
      1. If "Yes" to script, then "Use Shooting Script," then "Transcript Complete"
      2. If "Not" to script, then "Make a Transcript (3 Options)"
        1. "Pay A Vendor" then "Transcript Complete"
        2. "Hire a Typist" then "Transcript Complete"
        3. "Speech Recognition?" then "Transcript Complete"

 

Top of Page

Maps

Maps can present a number of accessibility, but focusing on information needed can help developers provide accessible information

Maps for Directions (with Google Maps)

If a map is being used to provide directions to a location, then make sure text based directions are also included. Note that text-based instructions benefits those who may have problems processing a particular map.

Here are some links to good examples of maps plus text-based instructions.

Note: ALT tags should be included for static images (e.g. ALT="Map to Old Main"). Embedded maps (e.g. Google Maps) should include some sort of label.

Leveraging Google Maps

An embedded Google Map alone is not screen reader accessible, but the Google Map tool is for providing driving and walking instructions. To maximize the effectiveness of Google Maps:

  1. Include a street address and zip code to enable Google Map search.
  2. Include basic text-based directions.
  3. A Google Map is typically embedded within an iFrame. Make sure the iFrame includes a TITLE attribute. See example below.

View HTML for Accessible iFrame

<iframe title="Map to X" src="https://maps.google.com/..." width="320" height="240" frameborder="0" marginheight="0" marginwidth="0">Loading... </iframe>

Top of Page

Maps for Displaying Multiple Locations

Some maps are used to display location (e.g. Campus locations or clickable states), and many also use Google Maps to make the locations clickable. To make these screen reader accessible.

  1. Provide a text list of locations or location links in a text-based list. OR
  2. Convert a Google Map to an accessible image map.

Google Map with Text List

See the screen capture of the Media Commons Location page for an example of a Google Map showing each location, but listing links for each campus below (in the area outlined by the red box).

Media Commons Google Map with list of campus location links beneath

Top of Page

Historical Map Example

Beyond the uses above are the use of maps to display different types of geographical data. In some cases, it may be possible to describe the most important information in a text-based long description. Again this would benefit all viewers.

Below is an example map showing the location of the New Sweden (or Nya Sverige) and New Netherlands (or Nieuw-Nederland) colonies in Pennsylvania, Delaware, New York and New Jersey.
Note: Image courtesy of Wikipedia.

Map of New Sweden and New Netherlands

Long Description

Colonial New Netherland (Nieuw-Nederland) stretched from New York City (New Amsterdam) up the Hudson River Valley to north of  Ft. Orange (modern Albany). Colonial New Sweden IO Nya Sverigewas centered on the Delaware river and stretched from the head of the bay to a little south of Trenton.

Note: The description includes informatin not the image.

Top of Page

Color Coding

If a map includes color coded regions, make sure that:

  1. There is sufficient contrast between the text and the background.
  2. That color coding is usable for those with color deficient vision. A good test is to see if the map is still usable in black and white.

3D or Tactile Maps

If it is not possible to extract text information from a map for a blind user, then a relief map or some other mechanism can be used.

Contact the Office of Disability Services for more information if a student needs accommodation.

Top of Page

Page or Document Title

All online pages should have unique topics that describe the content of the page or document. This allows screen readers to distinguish pages from each other and also enhances other functions such as tab titles (Web pages) and table of contents (PowerPoint).

Depending on the type of document, this can be accomplished in a number of ways.

HTML Web Page

Web pages should include a TITLE tag within the HEAD area, and the title should be unique to each page on the Web site. The TITLE can be repeated as the H1 of the page. SeeTitles for Web Pages for more information.

Frames and iFrames

Web pages using Frames can be made accessible, but a key element is to ensure that each frame is given a unique and meaningful title (e.g. "main_menu"). See the Frames and iFrames page for more details.

PowerPoint

Individual slides each should each have a title so that screen readers are can navigate to individual slides.

Word

Word files should also include a title styled as Heading 1 at the beginning of the document.

Web Page Tools

In systems such as ANGEL, Blogs at Penn State and Wikispaces, the information in the Title field also becomes the document title.

Top of Page

Headings and Subheadings

Many tags in HTML were developed not to assist with formatting, but to provide information on the structural hierarchy of a document. In order to facilitate accessibility and Web standards, it is best to use the tags for the intended purpose in the information hierarchy, rather than for pure formatting purposes. In many cases, doing so will also make your document easier to edit.

Purpose of Headings

For documents longer than 3-4 paragraphs, headings and subheadings are important usability and accessibility strategy to help readers both determine the overall outline of the document and to navigate to specific information that may need more of the reader's attention.

Level of Headings

Headings are classified into levels starting at Level 1 and working through Level 2, Level and so forth. By general convention, the highest level is "Level 1" and often corresponds to the title of the page or major document section. Level 2 is the next set of subheaders with a Level 1 section, and Level 3 are sub-subheaders within a Level 2 section. The lower the number, the smaller and more detailed a section.

Top of Page

Headings: Semantic vs. Formatted

Visual readers are able to identify headers by scanning pages for text of a larger size or a different color/font face. Blind users on a screen reader are not able to see these visual changes, so increasing the font size is not a sufficient cue.

Instead, the headings must be semantically "tagged" so that a screen reader can both identify headings and provide a list as a page or document table of contents (see image below).

This makes adding headings one of the most important tools for a screen reader user so that he or she can learn what is on the page. Note that tagging usually triggers a formatting change visually which can be adjusted in many documents.

Voice Over rotor window showing list of headings for Accessibility Home page

List of headings and heading levels for http://accessibility.psu.edu as shown in the VoiceOver screen reader.

See the list below for an example of how different tools add semantic headers to a document.

Examples of Heading Tags

  • Microsoft Word uses "Heading 1, Heading 2, Heading 3..." styles to add semantic headers. Formats for each can be adjusted in the Styles menu in Word.
  • HTML (Web pages) uses the H1, H2, H3...H6 tags as headers. Formats can be adjusted with CSS styles.
  • Web based editing tools (e.g. ANGEL's HTML Editor or Wikispaces) often include H1...H6 as options in a format or style menu.

To learn how to add headers in a specific document, please see the list of links in Related Links. In any case, what is most important is to avoid increasing font size or changing colors to indicate a section break.

Top of Page

WCAG 2.0 Guidelines

The following WCAG guidelines can be addressed with headers.

  • WCAG 2.0 Guideline 2.4.6—"Headings and labels describe topic or purpose."

Top of Page

Link Text

Helping users understand the desitnation of links is an important step towards increasing the usability and accessibility of a document.

Guidelines for In-Text Links

These guidelines apply to links embedded within the text of a document or a Web page.

  1. Write links that make sense out of context. Use descriptive link text detailing the destination; not just "click here," or other similar phrases. Link text should be made up of phrases rather than single words, so that users with limited motor control will not have difficulty hitting links.

    Unclear Link Text Examples

    Usable Link Text

    NOTE: Some search engines, such as Google, give higher rankings to sites that use "context-rich" text links.

  2. Maintain the standard that text links are underlined and are a different color value (lighter or darker) than the main text. This provision will help colorblind users find links more easily, and is good usability practice.

  3. If you use an image or image map to create links, make sure the destination is included as an ALT tag. See the Image Maps and Image pages for more details on creating accessible links with images.

For Web Pages

  1. You can insert "Top of Page" links after each section in longer documents to reduce the need to scroll up (which can be difficult for motion impaired users). These links should be formatted differently from other links so users know they are page-internal.

  2. Avoid links opening in a new window unless absolutely necessary. New windows are disorienting users of both screen readers and visual browsers (because the Back button becomes "disabled.") Also be aware that some users of visual browsers disable pop-up windows to avoid advertising.
    Note: If links do open in a new window, include a textual indication (e.g. Penn State Home Page (New Window)) so screen readers are aware of the new window.

  3. If you use JavaScript links, such as those to open pop-up windows, make sure they are coded to be accessible to screen readers. Many JavaScript links are unusable in screen readers.

Links on a Screenreader

Many screen readers including JAWS and VoiceOver give users the option to read just the links on the Webpage as demonstrated in the image below listing links from this page. As the list shows, link text which is meaningful out of context is more usable in a list.

List of links for this page

 

Top of Page

Table Headers and Captions

A table can be classified as a data table whenever you need to specify a row or column with header information about that row/column. If no informational header is needed, then it is a formatting table

Simple Tables vs. Complex Tables

A simple table here means means that there is a maximum of one header row and one header column where a header column specifies the type of information in the column. In addition, there are no merged cells within a simple table. Below are examples of simple and complex tables. Because screen readers present information linearly (i.e. table cell by table cell), it is generally easier to parse tables when are set up as simple tables.

Simple Table (More Accessible)

Top 2008 Presidential Candiates by Party
(num) = Primary Delegate Count
Democratic Republican
  1. Barak Obama (1828.5)
  2. Hilary Rodham Clinton (1726.5)
  3. John Edwards (4.5)
  1. John McCain (1575)
  2. Mike Huckabee (278)
  3. Mitt Romney (271)

 

Complex Table (Less Accessible)

Top Presidential Candiates 2008
Democratic Republican
Name Del Name Del Name Del Name Del Name Del Name Del
Barak Obama 1828.5 Hilary Rodham Clinton 1726.5 John Edwards 4.5 John McCain 1575 Mike Huckabee 278 Mitt Romney 271

Top of Page

Mark Table Headers

When sighted users focus on a table cell, they are able visually determine which row and column the cell is in and what the data means. On the other hand, a screen reader can only read aloud each cell one by one from left to right top to bottom.

One way to help blind users process the information is to read out what row and column header the cell refers too. In the table below, the headers are the top row (color names) and the left column (language names).

Because the headers are properly tagged, the cell for noir is read as "black, French noir". To learn the specifics of how to mark table headers in different softeare packages, please see the Related Links section.

Examples of Table Headers

Color Names in Multiple Languages
Color Spanish French Irish Welsh
Black negro noir dubh du
White blanco blanc bán gwyn
Red rojo rouge ruadh coch
Blue azul bleu gorm glas
Green verde vert glas gwyrdd
Yellow amarillo jaune buí melyn

Note: Gray cells with bold, centered text are headers.

In Screen Readers

Because this table contains TH tags with the proper SCOPE definitions, some screen readers will read the second row of the table as follows.

black, Spanish: negro
black, French: noir
black, Irish: dubh
black, Welsh: du

Top of Page

Don't Merge Cells

Even with headers properly marked, if cells are merged, a screen reader could find it difficult to determine which cell when cells become merged. Therefore it is recommended not to merge cells.

Titles (Captions) for Tables

It is also good practice to provide titles for tables, even for sighted users. This is sometimes also called a "caption."

Top of Page

Export Excel Data to HTML Tables

If you need to export Excel data to accessible HTML tables, then you may want to use the College of Agricultural Sciences Convert Excel tables to HTML. This tool allows you to cut and paste data from Excel, add captions and summary text then have it converted to HTML.

Even if you don't know much about HTML, you can cut and paste this code into the HTML view of any online blog, content manager or an HTML editor such as ANGEL.

Top of Page

WCAG 2.0 Guidelines

The following WCAG 2.0 Guidelines can addressed by using the techniques above.

WCAG 2.0 Guideline 2.4.6—"Headings and labels describe topic or purpose."

WCAG 2.0 Guideline 1.3.1 - "Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text."

Top of Page

Form Design Considerations

How to Implement

  1. Web Page Forms
  2. Flash (Generic)

Interactive can be a major barrier for users, especially those on a screen reader. Issues for navigating forms and interactive pages include:

  1. Users on a screen reader may not know what information to put into a particular field.
  2. Form controls and icons may not be fully identified on a screen reader
  3. Forms or interactive controls which only work with a mouse is a barrier for the motion impaired user as well as screen readers.
  4. If a user does not enter information correctly into a form, the error report form should clearly identify the location and type of error.

No matter what platform a form is created in, these guidelines should be implemented.

Contrast or Luminosity/Brightness

An important aspect of color for both low vision and colorblind users is sufficient contrast between the background and foreground (text or graphics). Color schemes can be changed in most documents, but it is most commonly a factor in PowerPoint, HTML Web pages and Flash.

Below are some general recommendations with some references to PowerPoint.

Contrast Just Right

The maximum contrast is black vs. white but other options are available such as navy/white, cream/dark brown, yellow/black and similar color schemes. Generally speaking, a color scheme is considered legible if it can be read in grayscale/black and white mode.

For a more specific information and tests, read the Contrast for the Web page.

Top of Page

Colors to Avoid

Orange

Orange should ONLY be used with large text and as a highlight. Because orange is neither very dark or very light, it is difficut to contrast it with another color.

Red vs. Green

This particular combination can be problematic because many color deficient viewers cannot distinguish these two colors. They are also both about the same level of darkness which is problematic for contrast.

Top of Page

Too Vivid

Large blocks of brightly colored text should be avoided. Adjacent areas of bright colors can cause issues with both visual vibration and, ironically, value contast.

Instead use colors like red, royal blue and emerald green for decorative blocks, large headlines, highlighting words or for links. See the Working with Bright Colors page for more details.

Top of Page

Too Much Texture

A slide or background with a texture (including a gradient) can also interfere with legibility. The more subtle the background, the more likely it is that the text will be legible. See the Color and Background Texture page for some examples of good and bad textures.

Top of Page

Too Subtle

The examples above are generally cases of a color scheme being "too garish," but it is also possible to be "too tasteful." Some modern color schemes feature such subtle contrasts, it can actually be insufficient for some readers.

Examples include contrasting light grey versus middle grey, middle pastels versus darks, or white versus light cyan (blue-green). If you plan to use a subtle color palette, again make sure that a black and white printout can be read.

Overly Subtle Color Schemes
Color Scheme Too Little Contrast Sufficient Contrast

gray/white

gray on white

gray on white

dark gray/light gray

light gray on dark gray

light gray on dark gray

teal/white

teal on white

teal on white

sea green/green

sea green on green

sea green on green

orange/white

orange on white

red-orange on white

WCAG 2.0 Guidelines

A detailed discussion of exact luminosity ratios required and how to test on Web pages can be found on Contrast for Web Pages.

Beware Color Coding

Using color coding alone to convey information can also be problematic for blind and color deficient users (particularly those who cannot distinguish red vs. green). Color coding should always be supplemented with some other mechanism such as a shape or symbol. See the Color Coding page for suggestions.

Top of Page

Color Issues

These pages deal with different topics related to color and colorblindness.

Color Synopsis

In terms of color blindness, the most problems seem to occur with spot colors especially when many colors are combined. Photographs tend have enough color and shade changes to be interpretable to color blind users.

For low vision users, a key issue is ensuring there is sufficient contrast in lights/darks between the background and text or objects in the foreground. Sufficient contrast is also important in design for color blind users.

  1. Do not rely on color codes alone to provide information. Always include additional changes in shape or text.

    WCAG 2.0 Guideline 1.4.1–"Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element."

  2. If you are using colored text or colored backgrounds, test that text and background have a sufficient contrast in light/dark or "luminosity." Juicy Studios hosts an online color contrast tester in which you enter the the color codes for the text (foreground) and background to receive a contrast value. You want a contrast ratio of at least 4.5 to 1.
    Note: In some other tools, you may want a number greater than 125.

  3. Avoid contrasts of red and black, since some color blind users do not perceive reds (i.e. red is the same as "no color" or black).

  4. In terms of color deficiency (color blindness), the safest colors are black, white and gray followed by blue and yellow. Contrasting red versus green is the most problematic, but can be usable so long as supplemental information is provided.

  5. To ensure that color contrasts are visible to the most viewers, use a color blind simulator. Having enough contrasts in darkness is important for low vision and color blind users.
    Note: There are some color combinations, such as some shades of teal and yellow which are acceptable in grayscale, but still problematic for color blind users.

  6. Adjacent areas of brightly colored hues also cause difficulties for normal-vision because of "color vibration."

  7. Avoid long blocks of light text on dark backgrounds; they are generally more difficult to read.

  8. Strongly textured backgrounds should be avoided since they make text harder to read. Subtly textured backgrounds or colored/textured toolbars can add interest without compromising legibility.

  9. Subtle variations of colors may be lost in different monitor settings. For instance, flat panel screens are brighter than older monitors; Mac colors may be lighter than Windows colors. Finally, some low vision users set their monitors to high color contrast, reducing the mid-value range. If possible, test your colors on different monitors or different gamma settings.

Color Blindness/Color Deficient Vision

The human eye contains rods which detects levels of light (dark versus bright) and three kinds of cones which distinguish among the different colors. If none of the cones are functioning (very rare), then a person has grayscale vision. If the cones are semi-functional (also rare), then the person sees colors, but they are muted.

More commonly, a person with color blindness (or "color deficiency") has a difference in only one of the cones, and it is usually either the red cone or the green cone. The result is that some colors appear to be more similar or are muted. The different type of deficiencies are simulated below.

Why Red/Black Can Be Bad

Some color blind users are lacking the capability to detect the lower color wave frequencies associated with red. For these users, red color waves read as "no signal", or "black". These users confuse red and black, so this contrast should be avoided whenever possible. Red and white is legible, but indistinguisable from black and white.

Sample Warning Signs

Note that the black text on red sign becomes black on black for some color blind users.

Warning sign test
Normal Vision Warning Warning
Red Vision Missing Warning Warning

 

Why Red/Green Can be Bad

If one or two sets of cones do not function correctly, then a person will have trouble telling certain colors apart. Almost 10% of men are red/green color blind; another group are blue/yellow color blind. Despite the fact that red-green contrasts are very distinct for about 95% of humanity, there are about 5% of people for whom this is non-functional. This is exacerbated by the fact that red and green are nearly identical on a gray scale monitor. See examples below.

NOTE: Red-Green color blind people are better able to find camouflaged objects in natural settings. See Visicheck Article for more details.

Merry Christmas in Different Color Vision Modes

Merry Christmas, Green on Red

The paragraph above is "Merry Christmas" in green text on a red background which a color blind person may not be able to read. This is also problematic because it causes a visual vibration for users with normal color vision.

In Grayscale

merry christmas grayscale, gray bar

In grayscale, there is only a slight contrast because red and green are of nearly equal brightness.

In Deuterope Mode (Red/Green Color Blindness)

Appears as dark olive on medium olive in normal color vision. Simulation courtesy of Visicheck.

Merry Christmas, Red/Green Colorblind Mode

In Tritanope Mode (Blue/Yellow Color Blindness)

Actually appears as teal and magenta. Simulation courtesy of Visicheck.

Merry Christmas, blue/yellow color blindness

 

More Accessible "Merry Christmas" Banner with Yellow Background

Merry Christmas, Yellow Background

The yellow Background separates the areas of red and green and provides a contrast in brightness, making the sign more legible. See the grayscale example below.

In Grayscale

grayscale, visible Merry Christmas

Tests for Simulating Color Blindness

Although it is difficult to determine exactly how a color-blind person sees the world, it is usually the case that if something is legible in grayscale, then a color-blind person can also view the information, although it may not be particularly appealing to that person. This is because, in most cases, the rods are functional and are still able to distinguish levels of light and dark.

Note: There are some color combinations, such as some combinations of teal and yellow which are O.K. in grayscale, but still problematic for color blind users.

Some Color Blindness Simulators

  1. Color Vision (Cal Henderson) - Test color schemes with almost all forms of color blindness

  2. Visicheck Color Blindness Tester - Allows you to test images and live Web pages for red-green and blue-yellow. color deficiencies.

Top of Page

Supplementing Color Coding

Color coding is possible as long as the color information is supplemented with differences in shape or text. Here are some accessible and inaccessible examples.

Inaccessible Red/Green Encoding

Accessibility Color Do's & Don'ts
Red Box = Don't Green Box = Do
Issue Description
Green Box Do Check site with color checkers or grayscale minor
Red Box Don't Use color coding alone
Green Box Do Use blue/green or black/white/gray
Red Box Don't Use red/green colors

A color blind user could have trouble distinguishing a green box from a red box. Furthermore, a colored cell would be inaccessible to screen readers unless invisible text were included.

 

Accessible Color Coding with Shape

Accessibility Color Do's & Don'ts
Red x = Don't Green + = Do
Issue Description
+ Check site with color checkers or grayscale monitor settings
x Use color coding alone
+ Use blue/green or black/white/gray
x Use red/green colors

Color deficient users can rely on cues of shape in the "+" and "x" symbols to distinguish "do's" and "dont's". Using text symbols with a key is also more accessible to screen readers.

 

Accessible Color Coding with Text

Accessibility Color Do's & Don'ts (colored text)
Issue Description
Do Check site with color checkers or grayscale minor
Don't Use color coding alone
Do Use blue/green or black/white/gray
Don't Use red/green colors

Color coded, but text labels makes it accessible to color blind users and screen readers.

 

Top of Page

Textured Backgrounds

Although changing a background on a Web page to a bright color or distinctive background can add excitement, these backgrounds can also make it difficult to read Web pages. In general, it is best to use dark text on light colors and subtly textured backgrounds. Here are some examples below.

Problematic Light Text on Dark

Skip TextAlthough changing a background on a Web page to a bright color can add excitement, these backgrounds can also make it difficult to read Web pages. In general, it is best to use dark text on light colors for long passages.

This light green text on dark green would cause eyestrain if an entire article were formatted this way.

More Acceptable Dark Text on Light

Skip TextAlthough changing a background on a Web page to a bright color can add excitement, these backgrounds can also make it difficult to read Web pages. In general, it is best to use dark text on light colors for long passages.

However, even this dark green text on lighter green should be used only for short paragraphs. An entire page of this could be difficult to read.

Problematic Strong Texture

Skip Text This is a not-so-good Celtic background texture - Although changing a background on a Web page to a bright color or distinctive background can add excitement, these backgrounds can also make it difficult to read Web pages. In general, it is best to use dark text on light colors for long passages and subtly textured backgrounds only.

In a visual browser, this text is almost illegible because of the strong contrast and rapidly changing colors in the background image.

A Subtler Texture

Skip TextThis is a much more subtle Celtic background texture - Although changing a background on a Web page to a bright color or distinctive background can add excitement, these backgrounds can also make it difficult to read Web pages. In general, it is best to use dark text on light colors for long passages and subtly textured backgrounds only. Here are some examples below.

The background image is more subtle, almost invisible, and is lightly colored. In small passages, legibility would be acceptable.

Top of Page

Vibrating Color Combinations

In addition to the issues of color blindness mentioned above, placing areas of brightly colored hues together can be hard for users with color vision to read. Bright colors cause an afterimage effect. With only one bright color, the after image is usually not bothersome, but with two bright colors together, the afterimages interfere with one another, causing a "visual vibration." This can be reduced by placing a neutral color between the two areas of bright colors or by making one of the colors a pastel or dark shade.

Some Vibrating Color Combinations (Avoid)

Below are some color combinations that can cause afterimage effects.

 

Some Vibrating Color Combinations
red/green

red on green

green on red

blue/orange

blue on orange

orange on blue

green/magenta

green on magenta

magenta on green

yellow/cyan

yellow on cyan

cyan on yellow

blue/magenta

magenta on blue

blue on magenta

orange/yellow

yellow on orange

orange on yellow (not so bad)

blue/green

green on blue

blue on green

 

Top of Page

Fonts and Text Layout

The links below contain information on font selection and text layout.

See also—Bold/Italics and Color and Colorblindness.

Font Size

The main concern related to font size is that text can easily be made too small for many users to read.

General Guidelines

12 Point for Body Text

For most documents, body text should be around 12 points. Fonts at smaller sizes may be illegible for some audiences.

Nine Point Minimum for Footnotes

If a document contains footnotes or endnotes, the minimum size should be about 9 points.

PowerPoint Guidelines

If a PowerPoint file is meant to be projected before a live audience (e.g. during a class lecture), the minimum font size should be about 24 points. At smaller sizes, the text becomes illegible on a screen.

Headers and subheaders can be much larger, between 40-60 points depending on the slide layout.

Top of Page

Font Face

General Recommendations

For online reading, sans-serif fonts (e.g. Arial, Verdana) are generally considered more legible than serif fonts (Times New Roman), narrow fonts or decorative fonts. Decorative and narrow fonts in particular should be reserved for headlines and decorative texts only.

Note: If a document is meant primarily to be printed, other font options can be used.

List of Recommended Fonts

Below is a list of recommended fonts with notes on the legibility of each. Fonts are available on both PC and Mac unless otherwise specified.

Note: For detailed notes on what enhances legibility, see the Fonts for the Web page.

Highly Recommended Fonts
Fonts Notes
Verdana Designed for monitors by Microsoft. Many sites on accessibility use Verdana.
Lucida Sans (PC)/
Lucida Grande (Mac)
Relatively new font. Used as a Mac system font.
Tahoma Available from Microsoft
Georgia Serif. Designed for monitors by Microsoft.
Palatino (Mac)/
Palatino Linotype (PC)/
Book Antiqua (PC)
Serif. Traditional print font. Weight can be light.

 

Additional Fonts of Reasonable Legibility
Fonts Notes
Helvetica Traditional print font. Available on Mac, Unix and newer versions of Windows. Some letterforms can be confused.
Arial A Windows analogue to Helvetica. Some typographers prefer Helvetica, but the two are generally similar.
Calibri Released by Windows for Office 2007/Windows Vista. Good distinctions among most characters, but x-height is not especially large.
Trebuchet MS Available from Microsoft. Good x-height, but some letterforms (e.g. "g" and &") considered too unusual for some readers, especially if literacy is an issue.
Century Gothic Sans-serif, somewhat Art Deco. Good x-height, but some letters can be confused. Weight is light.
Bookman Old Style Available from Microsoft. Traditional serif font designed for legibility. Good x-height, but may not be on all computers.
Cambria Released by Windows for Office 2007/Windows Vista. Good distinctions among most characters, and large x-height. Width slghtly narrower than some fonts.
Garamond Available from Microsoft. Traditional font, but x-height relatively small and weight is light.
Times New Roman Serif. Relatively small x-height, but succeeds with regard to legibility.
Comic Sans Considered legible by some, but also criticized as being "childlike." May be appropriate for sites with younger audiences.

 

Decorative: Use for Large Text Only
Fonts Notes
Arial Black Available from Microsoft. Very heavy.
Arial Narrow A narrow font that is probably too compressed for body text.
Haettenschweiler, Impact Available from Microsoft. Very narrow and heavy.
Harrington Available from Microsoft. letterforms are very ornate, which can slow down reading speeds.
Monotype Corsiva A cursive-style font. Italic-type slant can slow down reading.

 

Top of Page

Text Block Formatting

With the exeption of headlines or decorative text, it is best to avoid large blocks of italic text, colored text, underlined text, decorative fonts and capitalized letters. These formatting choices can make text difficult to read.

Below are the examples to avoid.

Note: Blocks in CSS refers larger units of text such as a paragraph, quotation or headline.

 

Don't format Text Blocks Like this

All Italics - An entire block of italic can be hard to read because computer monitors may not render diagonal lines clearly.

All Underlined - Not only is underlined text harder to read, but underlines should only be used to designate a link.

All Colored - Subtle, dark colors can work, but not long passages of brighlty colored text. Too much color can cause eyestrain and may induce migraines.

Light Text on Dark Background

On the Web, most readers prefer to read dark fonts on a lighter background

All Decorative Font - Reading times for unusual fonts are much slower, and display technologies may affect visibility.

All Caps - TESTS SHOW THAT READERS RELY ON CUES FROM LOWERCASE ASCENDERS & DESCENDERS....PLUS, CAPITALIZATION IS EQUATED TO "SHOUTING" ON THE WEB.

Justified Text - Justified text (alignment on both the left and right margins) is currently not recommended because the justification algorithm could cause large space gaps.

See image below for an example badly justified text.

Shows text 'margin-right is formatted' with 2  inches between each word

Top of Page

Text Reading Order

Whenever a document is organized so that information is in multiple columns or multiple text areas (e.g. text captions, unusual placement of icons/text), then it is important to verify that the screen reader reads the information in a logical or coherent order.

Reading Order Example

Consider the PowerPoint slide below which contains three images of and three captions. By visual scan, one would expect that the reading order would be the top-left image followed by the caption beneath, the second image, the caption beneath it then the lowest image with the caption below that.

However, within PowerPoint, the items were ordered so that the images were presented first then the captions. This occurred because the images were inserted on the slide before the captions. Fortunately, PowerPoint includes tools to allow authors to adjust the reading order of slide objects.

Slide shows PA in Hebrew, Cherokee and Devanagari. Images are read first then captions. Captions say that Hebrew is left to right with consonants only, Cherokee symbols represent syllables and Devanagari is consonants with vowel marks.

Learn More

The following documents can present reeading order issues.

  1. PowerPoint - Verify that items are in a logical order in the PowerPoint Reorder panel.
  2. PDF - Use the Acrobat repair tools to verify that blocks of text are in a logical order. Acrobat may make "guesses" different from what the author intended, especially when textboxes and columns are used.
  3. InDesign CS5 - Reading order of items can be set before the file is converted to PDF.
  4. HTML Web Pages - Text is read in HTML code order. However CSS and other techniques may present a visial order different from the original code order.
  5. Flash - The reading order of each object needs to be determined and verified manually. See the Flash External Links for more details

Top of Page

Foreign Languages and Accessibility

Synopsis

Foreign language support is still relatively incomplete for screen readers, but here are some things that can be done. Screen readers programmed in a non-English language may be able to switch to English easier than a screen reader designed for a U.S. audience can switch to non-English.

  1. Use language tagging to mark content as English or non-English. This ensures both accurate pronunciation in screen readers and enables foreign language spell checking.

  2. Save documents with Unicode encoding whenever possible. This will ensure that text is transferrable between systems including mobile platforms.

  3. Users on a screen reader may need to purchase foreign language extensions or install additional files.

Unicode Support for Foreign Language

Whenever possible, non-English text (including special characters such as ©, †) should be inserted as is into a document encoded in Unicode.

Unicode is an encoding standard which assigns a numeric code to all characters across multiple scripts including Greek, Cyrillic, Asian scripts, Middle Eastern scripts, ancient scripts and technical symbols.

This standard allows computers around the world to exchange data across multiple languages consistently and without need for custom fonts.

Top of Page

Screen Reader Support

Western European Languages

The comments below date from Aug 15, 2014.

Many screen readers including JAWS, NVDA and Apple VoiceOver include pronunciation engines for common Western European languages such as Spanish, French, German, Portand the Scandinavian languages.

VoiceOver currently includes voice options for 22 languages including major Asian and Middle Eastern languages.

JAWS Beyond Western Europe

In addition to Western European language support which comes with the U.S. English version of JAWS, various international distributors have programmed non-English versions of JAWS for languages such as Russian.

JAWS Symbol File

If JAWS is unable to recognize a particular symbol in a document, you can append a Symbol File (.sbl) file which assigns plain text values to a Unicode character.

VoiceOver Adjust or Add Symbol Pronunciation

VoiceOver supports pronunciations for a wide range of technical symbols. However, you can add a symbol or adjust its pronunciation in the VoiceOver Utility in the Accessbility section of the System Preferences.

  1. Open the System Preferences. Click the Accessibility icon, then VoiceOver in the left menu.
  2. Click the Open VoiceOver Utility button, then the Pronunciation tab. This will open a set of adjusted pronunciations for symbols and phrases.
  3. Click the plus button to add a new row. Fill in the symbol in the Text column and its pronunciation in the Substitution file. Adjust other columns as needed.
  4. Enable and test in VoiceOver as needed.

NVDA

NVDA appears to support switching pronunciation with LANG tag. However, it's technical symbol repertoire is limited and it is not clear that there is a mechanism to expand it significantly.

Top of Page

VoiceOver and Multiple Languages

A user can download voices for languages besides English in the VoiceOver Utility (Speech: Voices, Click Customize). Unfortunately, VoiceOver (at least in OS Xversion 10.8) does not appear to recognize the LANG tag signalling a new language at this time. A user can manually switch voices for longer non-English passages.

Top of Page

Language Tagging

See either the Language Tagging or Language Tagging in HTML to learn about tagging documents for different languages.

Top of Page

Language Tagging

How to Implement

  1. Microsoft Office (This Page)
  2. PDF (This Page)
  3. HTML (New Page)
  4. Common Language Tags

About Language Tagging

Tagging the language of a content is important for controlling the pronunciation engine of a screen reader. For instance, tagging a Spanish phrase such as ¿Cómo se llama Usted? as Spanish would trigger the word llama being pronounced with an initial /y/ instead of an initial /l/.

Other benefits to language tagging include activating language-specific spell-checking/proofing tools and optimized search across multilingual documents.

Microsoft Office

Microsoft Office includes utilities to mark and spell check text in major world languages such as Spanish, French, German, Chinese, Japanese, Dutch, Finnish, Hindi, Hungarian, and many others. To access the spell checkers, you have to mark your text in a specific language.

Office 2007+ for Windows

As of Office 2007, you can mark text as non-English in the Review tab. To mark your text, do the following:

  1. Highlight the non-English text.
  2. Click the Review tab on the Word toolbar,
  3. In the Proofing section on the left, select the globe icon (Set Language). A pop-window will open where you can select an appropriate language.
  4. Perform the spell check. The non-English text will be checked against the non-English dictionary.
    Globe icon in Review tools

Note: If no list appears or the spell-check does not work properly, check to see if the appropriate dictionaries have been installed. They are available on installation CD's for Microsoft Office

Macintosh Office

The following instructions apply to Macintosh and to earlier versions of Office for Windows.

  1. Highlight the non-English text.
  2. Go to the Tools then Language then Set Language. A pop-window will open where you can select an appropriate language.

NOTE: If no list appears or the spell-check does not work properly, check to see if the appropriate dictionaries have been installed. They are available on installation CD's for Microsoft Office.

Top of Page

 

PDF

Language tagging can also be accomplished in a tagged PDF within the full version Adobe Acrobat following the instructions below.

Note: For best results, use a tagged file created Microsoft Office for Windows, Open Office for Mac or InDesign.

Set Language for a Document

  1. In Adobe Acrobat, go to the File menu, then select Properties.
  2. In the Properties window, click the Advanced tab.
  3. Set the Language menu to English or some other appropriate language.
    Note: If the language is not present, then you can manually enter an ISO-639 language code.

Set Language for a Portion of the Document

  1. In Adobe Connect, open the Tags window
    1. Go to the View menu, then Show/Hide, then Navigation Panes.
    2. Check the option for Tags. The Tags icon (green price tag) will appear in the far left.
    3. Click the Tags icon to open the list of tags.
  2. Click the arrow next to the initial tag to reveal lower layers of tag structure.
  3. Find the tag corresponding the non-English word or phrase.
  4. Right click the tag and select Properties.
  5. Select the appropriate Language from the menu.
    Note: If the language is not present, then you can manually enter an ISO-639 language code.

HTML

See Language Tagging for the Web for information on how to insert the LANG tag.

Top of Page

Math, Science and Technical Content

Because much of the content in math and science fields is presented via complex visuals (e.g. equations, charts, diagrams and maps), making the content accessible on a screen reader may seem daunting, if not impossible.

However, these steps below can help instructors and other present content which is accessible and still retains the original visual characteristics.

Guidelines

  1. Ensure that headings are used to divide text into sections or on all PowerPoint slides.

  2. Ensure that critical videos are captioned and include appropriate visual descriptions for the blind.

  3. Ensure that equations are either images with an ALT tag or in MathML.

  4. Ensure that technical symbols are supported on a student's screen reader.

  5. Ensure that all images include an ALT tag.

  6. Ensure that all complex images include a text-based long description.

  7. Ensure that all charts can interpreted without color and include a properly tagged data table.

  8. Ensure that data tables include headers in the top row and a caption or summary. Simple tables are strongly recommended.

  9. Ensure that diagrams or charts supplement color coding.

 

PDF Files

This section links to all resources about repairing PDFs. See the "Issues and Recommendations" page for information on general issues and recommendations.

Note many experts recommend to avoid or minimize using PDF files as a sole source of online information because of the difficulty and cost of making PDF files accessible.

If wish to see how an explanation of how to make a PDF file accessibile we recommend this Lynda.com tutorial or using a PDF repair service such as CommonLook.

PDF Issues, Recommendations and Links

Potential Drawbacks

For over a decade, PDF files have been a convenient way to deliver print documents online, but they remain a challenge to make accessible.

For these reasons, many experts recommend to avoid or mimize using PDF files as a sole source of online information.

Potential drawbacks include:

  1. Developers require the full version of Adobe Acrobat to inspect and insert image alt text and other accessibility accommodations into a PDF file.

  2. The process of repairing PDF files is currently both time consuming and buggy. More training and plugins are required to make PDF forms accessible than to make HTML forms accessible.

  3. PDF documents are usually formatted to printed vertically, but computer monitors are generally horizontal. This mismatch causes users to scroll more often than on a Web site, which can be difficult for users with mobility impairments.

  4. Very large files can be slower to download than an HTML page.

  5. PDFs consiting of scanned pages are really a series of images, and therefore inaccessible to screen readers. Only an OCR (optical character reader) scanner can save a scanned document as a text file.

  6. The interface between a browser and a PDF file is not consistent across platforms and browsers.

  7. The transition between a PDF document and an external Web site is not as seamless as between two HTML documents.

Top of Page

Possible Uses

However, there are instances when a PDF can deliver material efficiently.

  1. To post material that uses technical fonts and/or specialized characters, such as in fields like music, foreign languages and mathematics.
    NOTE: Alternative technologies, such as Unicode and MathML, should also be considered for specialized purposes.

  2. To post print manuals and print forms online. These would include blank forms, how-to instructions designed for print, contracts, long articles or long user manuals.
    NOTE: Alternative file formats, such as Word files or Web pages, should also be considered in addition to PDF.

Top of Page

Recommendations

In order to make PDF files more accessible, consider these recommendations:

  1. If a PDF is used to create a graphically intense poster or flyer, ensure that the information is also available outside the poster or flyer.

  2. If a PDF is used to post a report, consider posting the report in a format such as Microsoft word.
    NOTE: A PDF alternative can be posted alongside if needed.

  3. If a PDF report is used to post a presentation, consider posting the report in a format such as PowerPoint.

  4. If a PDF is mandaded, generate a "tagged" PDF from a document source whenever possible. The specific method of doing so will vary on the original file format and the operating system. See some options below:

    1. Windows Microsoft Office (Word/PowerPoint/Access/Excel, etc.)
    2. Macintosh Microsoft Office via Open Office
    3. Adobe InDesign

    NOTE: Any tagged file should be inspected in Adobe Acrobat to verify that the tagging structure is sound.

  5. If a PDF is mandated, use the repair tools in Adobe Acrobat to ensure accessibility. See the External Links section for links to in-depth tutotials.

  6. Note when a link goes to a PDF file (e.g. "User's Manual (PDF)"). Doing so gives notice to all users that a link will be opening a PDF file, not going to another Web page.

  7. If you are scanning in material that is mostly text, scan the material in with an OCR (optical character recognition) scanner. This type of scanner converts a scanned image of text to an actual text file. If files are scanned with a regular scanner, the PDF file will consist of a series of inaccessible images.

    NOTE: Scanning text with an OCR scanner will also make the transition to HTML easier.

  8. Avoid converting text with multiple columns into a PDF file. A screen reader may unexpectedly read text across columns. It will also result in additional scrolling as each column is read, making it harder to process for people with motion impairments and some cognitive disabilites.

  9. Be aware that some security measures on PDF files may disable screen reader access. Be prepared to provide alternative access to visually impaired users.

Top of Page

Convert PDF Files to Other Formats

Due to reasons listed on the PDF information page we recommend avoiding or mimizing the use of PDF files as a sole source of online information.

However, if your only source of information is a PDF file, you may be able to export it to another format.

Conversion Options in Adobe Acrobat

If you need to extract information from a PDF file, but don't have access to the original document (e.g. Word, Excel or InDesign), you may be able to convert the content to another format in Adobe Acrobat.

Note: Additional tools may also be able to convert a PDF document to another format.

  1. Open a PDF in the full version of Adobe Acrobat.
  2. In the Save As menu, you can choose from these options:
    1. Microsoft Word
    2. Spreadsheet
    3. Image
    4. Other Options (includes RTF, HTML, text, XML)
  3. Once the information has been extracted, you can use approriate.
    Note: Different export options may be needed for different document types. You may want to experiment with them to see which results are optimal.

Convert to "HTML"

In some cases, PDF information can be converted to a Web page.

In many cases though, that could simply involving moving the information to a page within a content management system such as WordPress, Drupal or some other system. Many content management systems include WYSIWYG tools to facilitate creation of an accessible page.

Copyright Considerations

Exporting and manipulating PDF content should only be done for files that are owned by you or your organization. If you need to remediate an external PDF, be sure you have permission to extract the contents (or be sure that it can be done under a provision such as Fair Use).

Top of Page

OCR with OmniPage

Synopsis

OminPage version 18 is an optical character recognition (ORC) tool for the Windows platform and is available in the CLC Student Computing Labs.   This software identifies print characters in images using a scanner and computer software. This allows you to scan printed documents or scan a digital document/images such as a PDF, JPG, and PNG files. This is important because this allows us to make documents easily formatted for accessibility to screen readers for the visually impaired.

Basics to using OmniPage to OCR a document

Here are the basic steps to ORC a document in OmniPage version 18 found on the CLC PC computer labs here at Penn State.

  1. Selecting your document. OmniPage gives you two options to OCR a document: directly from the scanner and from a digital copy stored on your computer.
  2. Start OCR.
  3. Process the document.
  4. Proofread document.
  5. Name and Save.
  6. Formatting the document after OCR completed. We recommend Rich Text Document (RTF) for compatibility. Saving the document as an RTF allows you to import the document with a simple cut and paste to other programs such as MSWord or a WYSWYG, such as Dreamweaver. This allows you to easily format the document for accessibility.

Selecting your document

  1. Selecting Open File button from the Start page to take an existing digital file to OCR. Alternatively, select Scan Document button to import a hard copy document from a scanner you have connected.
    OmniPage Start page sample screen shot

  2. Top of Page

    Start OCR

  3. Select Process from the menu bar

  4. Select Perform OCR and Start to begin the process for the imported document. Be sure that Automatic is selected.
    Process option to start OCR screen shot
  5. Top of Page

    Process the document

  6. Alternatively, select the Workflow button to begin the OCR process. Using the options arrow to the right side of the Workflow button is another way to allow you to import documents to begin a new scan.
    WorkFlow Button screen shot
  7. Top of Page

    Proofread document

  8. Next, the OCR Proofreader Pane will open. Here, unidentified characters are highlighted and as the scanner to identify them. The Proofreader will give you selected options, allow you to ignore and leave the character unidentified or you can manually type the new characters in the highlighted area for the OCR to recognize.

  9. When you have completed proofing the unidentified characters Select Document Ready.
    OCR Proofreader pane screen shot
  10. The Start Automatic Processing Pane will open.

  11. Select Finish processing existing pages without adding new ones radio button if there are no other pages to OCR.

  12. Select Start.

  13. The document will be OCR.
    Start Automatic processing pane screen shot
  14. Top of Page

    Name, Save and Format

  15. The Save to File pane will open.

  16. Next, title the document under File name and save to the desired location.
    Save file Pane to title File Name Screen shot
  17. Under File Type drop down menu be sure to select RTF. We recommend Rich Text Document (RTF) for compatibility. Saving the document as an RTF allows you to import the document with a simple cut and paste to other programs such as MSWord or a WYSWYG, such as Dreamweaver. This allows you to easily format the document for accessibility.
    File Type: RTF drop down menu screen shot

Note: There is an HTML option in the Text Format drop down menu. However, the HTML file created requires the HTML code to be extensively edited for accessibility.

Top of Page

OCR with ReadIRIS (Mac)

Synopsis

ReadIRIS 11.5.6 is an optical character recognition (OCR) tool for the Macintosh platform and is available in CLC Student Computing Labs.  This software identifies print characters in images using a scanner and computer software. This allows you to scan printed documents or scan a digital document/images such as a PDF, JPG, and PNG files. This is important because this allows us to make documents easily formatted for accessibility to screen readers for the visually impaired. 

Basics to using ReadIRIS to OCR a document

Here are the basic steps to ORC a document in ReadIris version 11.5.6 found on the CLC Mac computer labs at Penn State.

  1. Selecting your document. ReadIris gives you two options to OCR a document: directly from the scanner and from a digital copy stored on your computer.
  2. Minor Editing. Who has not scanned a document upside down or side ways.
  3. Adding Unidentified Text. ReadIris may miss a line of text or a paragraph. This option shows you how to identify the missing text.
  4. Select a language
  5. Saving and Formatting the document after OCR completed. We recommend Rich Text Document (RTF) for compatibility. Saving the document as an RTF allows you to import the document with a simple cut and paste to other programs such as MSWord or a WYSWYG, such as Dreamweaver. This allows you to easily format the document for accessibility.

Selecting a document

  1. The Open File button has options to the side.

  2. Right clicking on the File button will give you the choice of opening and searching for a file or selecting a scanner that is attached to your computer. Selecting the Open icon will open your Finder pane.
    File options
  3. Selecting the scanner will change the File button to the option to acquire from a scanner. The button will now appear as an Acquire button. Position your document in the scanner and select the Acquire button.
    Acquire button screen shot

Top of Page

Minor Editing of the Document

  1. If the document is upside down or appears sideways. There is a Rotate icon that gives you options to fix this issue in the top menu bar.
     Rotate button screen shot
  2. After the scanning is completed, the document will automatically populate with text zones.
    Sample of Scanned document with text highlighted for OCR screen shot

Top of Page

Adding Unidentified Text

  1. If there is any text not recognized, you can draw in a text zone. Select the Zones icon and then select Draw Text Zones.

  2. Then just highlight the text or paragraph that is not recognized and have the unidentified text with in the hightlighted box.

Top of Page

Selecting a Language

  1. Next, select the language, located next to the Recognize icon. You may not need to do this if the language appears as the one you need.

  2. Selecting the Language icon will open the Choose a language pane, where you can scroll down a list to select your language of choice.

  3. Select the language.

  4. Select the OK.
    Language button with sample dropdown menu screen shot

Top of Page

Format and Save

  1. Next, select and export the document in a particular Format.
    Format Button set to RTF screen shot
  2. The Text Format pane will open up.

  3. Under Format select RTF. We recommend Rich Text Document (RTF) for compatibility. Saving the document as an RTF allows you to import the document with a simple cut and paste to other programs such as MSWord or a WYSWYG, such as Dreamweaver. This allows you to easily format the document for accessibility.

  4. Select Recreate Source documents.

  5. Select Merge Lines and include paragraphs.

  6. Select OK.

  7. Text format pane with settings screen shot
  1. Then select the Recognize icon.

  2. Recognize button highlighted in screen shot
  3. Be sure to rename your file and select OK.
    Save As pane to name document screen shot
  4. The document now can be opened with any publishing document.

For instruction on formatting for accessibility in MSWord go to http://accessibility.psu.edu/microsoftword

Note: There is an HTML option in the Text Format drop down menu. However, the HTML file created requires the HTML code to be extensively edited for accessibility.
Sample of Format dropdown menu to HTML screen shot

Top of Page

Course Accessibility

Where do I start?

In general, accessibility accommodations depends on the type of content

  • If you use videos, they may need to be captioned
  • If you use ANGEL, you can use the tools in the HTML editor to create accessible content
  • If you use PowerPoint, they can be optimized with a few simple techniques

Use the links on this page to learn more about how to provide accessibility for different content types and audiences

Is there a syllabus statement on accessibility?

Yes. The text is available on the Syllabus Statement page of this site.

Do I need to worry about accessibility if none of my students need accommodations?

There are a few reasons why accessibility experts recommend thinking about accessibility issues ahead of time.

  1. It's typically less stressful to accessify content over a period of time rather than everything at the last minute. Many fixes are quickly implemented once the skills are learned.

  2. Most accommodations benefit multiple audiences and enhance online content usability. For instance, clarifying the destination of a link benefits all students.

Who can I contact for more information?

For more information you can contact these sources

 

 

Course Accessibility Guidelines

Go to Courses and Accessibility

Goal

The goal of this checklist is to help instructors identify common accessibility blockers in their courses and provide them with techniques that will make the content more accessible to a diverse audience.

Rationale

Using these relatively low cost, low effort techniques will facilitate compliance with Penn State Policy A.D. 69 "Accessibility of Penn State Web Pages" and will reduce course preparation time should an instructor receive an Academic Adjustment Letter from the Office for Disability Services.

Audience

The primary audience for this document is instructors who may only have minimal access to accessibility support resources. This document can also be used by instructional design and support staff.

Checklist of Blockers

This checklist identifies the most prominent accessibility blockers along with methods to ensure accessible content. Techniques are identified as either Fix/Add, meaning you (the instructor) should begin to address that issue proactively, or With Letter, meaning that you should be aware that the blocker must be addressed when an Academic Adjustment Letter is received
from the Office for Disability Services.

Note:  A student enrolled in any course presenting a Letter of Academic Adjustment from the Office for Disability Services must receive the specified accommodations regardless of whether the technique is listed in this checklist.

List of Blockers and Recommend Solutions
Item Description Benefits/Notes

Accessibility Statement
Fix/Add

  1. Mandatory: All course syllabi must include the syllabus statement on accommodating disabilities.
  2. This is required Senate Policy 43-00

BENEFITS: All students become aware of the Office for Disability Services and the process for requesting accommodations.

Audio/Video from Penn State
Fix/Add

  1. Audio files should be transcribed.
  2. Videos should be transcribed and captioned.
    Note: See the videos page for information on storyboarding, speech recognition or captioning services.
  3. Visual demonstrations need a text or audio description.
  4. Make sure media files don't play automatically when a user enters the site.

BENEFITS: Captions also benefit non-native speakers or students experiencing audio glitches.

 

Audio/Video from Outside Penn State
With Letter

Transcripts or captioned videos must be provided to students requiring an accommodation. However, the distribution of the content may be restricted because of copyright.

  1. Find captions/transcripts if you can.
    Note: See the videos page for tips in finding a pre-existing transcription text.

 

Color Contrast for Legibility
Fix/Add

  1. Ensure good color contrast for text/graphics/charts and backgrounds. Content should be legible in black and white.

BENEFITS:  This fix improves legibility for all students.

Document Types
Fix/Add

The following formats are recommended and are supported through http://accessibility.psu.edu

  1. Web files (e.g. ANGEL HTML Editor, Sites @ Penn State, other HTML documents) can be the most accessible file type.
  2. Word and PowerPoint files can be made accessible as well.
  3. If you create a PDF, provide the same information in some other accessible format unless the PDF document is verified as usable by a screen reader test.
    Note: Making a PDF document accessible is possible, but very laborous and requires access to Acrobat Professional.
  4. Tools which allow you to insert Flash content typically result in inaccessible content.
    Note: Making a Flash document accessible is possible, but very laborous and requires access to developer access to Flash.

BENEFITS: PDF and Flash are not easily readable on mobile devices, so avoiding them will enhance mobile usability.

External Documents
With Letter

The content of any non-Penn State resource such as a Web site, PDF article from a journal, slides from external sources or other non-Penn State informational resource must be provided in an accessible format to students requiring an accommodation. In some cases, it permissible to copy and reformat content just for students with a documented need.

For additional information on addressing different scenarios see http://accessibility.psu.edu or links elsewhere in this document.

 

Image ALT Text
Fix/Add

  1. Use ALT text for all content images. ALT text should describe the meaning conveyed by the image in the context of the course material, and it should be up to 150 characters.
  2. Give the image file itself a descriptive file name.
  3. Include a descriptive reference to the image within the surrounding text.

BENEFITS: This allows any student unable to view the image to understand its content.

Image Long Description
With Letter

  1. A complex image requires ALT text significantly longer than 150 characters.
  2. For complex images, consider including a description in the text or a link to the description to the text in another location.

BENEFITS: Not all sighted students process visual information in the same way. If this can be addressed, then all students could have different options to process data.

Link Text
Fix/Add

  1. Avoid vague or repetitive link text such as "click here" or "read more".

BENEFITS: Improved link text is often more visible and increases student confidence in finding content.

Math Equations
Fix/Add

  1. Equations should be created with a technology such as LaTeX or an equation editor (e.g. MathType) which allows rapid conversion to MathML. See http://accessibility.psu.edu/math for details.

BENEFITS: This will facilitate conversion of equations to MathML should an accommodation request be received.

Section Headings
Fix/Add

  1. Documents with section headings should include semantically tagged headings.
  2. Use descriptive heading text to enhance page navigation and readability.

BENEFITS: Headings also enhance legibility and ability for all students to scan online content.

Table Captions and Column Headings
Fix/Add

  1. Do not use tables for layout and design purposes. Restrict tables to presentation of data.
  2. Use the simplest table possible, preferably without merging cells. It is better to use several simple tables rather than a complex table with merged cells.
  3. Use table headers to identify row and columns.
  4. Use a caption to display the table title.
  5. Consider alternatives to tables such as lists for complex tables.

BENEFITS: Accessible table design includes additional information for all students to use.

Technologies
Fix/Add

  1. Use Penn State technology options (e.g. ANGEL, Sites at Penn State) for course work whenever possible.
    Note: See http://accessibility.psu.edu/courses or http://sites.psu.edu/ETA for information on specific Penn State tools.
  2. Investigate the accessibility of all non-Penn State technologies or materials and make a decision about continued use based on your findings.

BENEFITS: There is more support for accessibility accommodations within Penn State supported tools and materials.

Top of Page

No Online "Distraction"

For this page, the term "distraction" refers to a number of Web page conventions which can interfere with a screen reader operation, keyboard operation or cause significant reading issues for people with multiple cognitive or neurological disorders.

Distractions include the following

General Issues

Some of the reasons these are issues are:

  • Background audio and video can interfere with screen reader audio
  • Text that changes too quickly may cause issues for someone not able to read it quickly enough
  • Moving objects are distracting for most users, but particularly for anyone with attention-related disorders
  • Blinking/flashes can induce seizures

WCAG Guidelines

WCAG 2.0 Guideline 2.2—"Provide users enough time to read and use content."

WCAG 2.0 Guideline 2.2.2 (Partial)—For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential.

WCAG 2.0 Guideline 2.3—"Do not design content in a way that is known to cause seizures."

Accessibility Resources (Links)

The following links have information about accessibility:

Penn State

Non-Penn State Tutorials and Guides

Faculty & Staff Software Tools

Information on accessibility in common Penn State tools such as ANGEL, Blogs, Adobe Connect and Microsoft Office (Word/PowerPoint/Excel)

ANGEL Course Management System

Because the ANGEL Course Management System is a Web tool, you may not have all the ability to manipulate accessibility features that you would in a stand-alone Web site. However, there are some steps you can take to make your ANGEL content more accessible.

See the ANGEL Help Page "Ensure ANGEL Course Content is Accessible" for the most up-to-date information.

Display Options

  1. Screen reader users, or those with severe low vision, may want to switch their display option to Accessible View, PDA Mode or 508 Mode. Any of these modes puts ANGEL into a frames-free, text-only mode and enlarges the text. See the ANGEL Help Page "Ensure ANGEL Course Content is Accessible" for more details.

  2. Depending on their needs, users with low vision or color deficient vision may wish to change their viewing profile, use a more accessible theme or link to a custom CSS.

  3. If students find the text too small in ANGEL even with zooming, you can suggest switching to a newer browser, such as Firefox or Internet Explorer 7+. These browsers tend to better support text zooming.

  4. If you use complex image maps, multimedia or scripts, you may want to develop them on an external Web site and link to them from within ANGEL.

ANGEL HTML Editor

The ANGEL HTML editor can be used to add formatting to HTML pages. Some tools that will assist users with different accessibility issues are:

  1. Page titles should be formatted with the Heading 1 (H1) option in the Select Format menu. This formatting helps users with screen readers quickly identify the page title.

  2. Main section headings should be formatted with the Heading 2 (H2) option in the Select Format menu. This formatting helps users with screen readers quickly scan and identify major sections of the page. Use the Heading 3 (H3) option for subsection headings.

  3. When inserting images, remember to fill in the Alternate Text field in the upload screen. This is the text that will be read aloud by a screen reader. See the HTML Editor: Insert an Image help topic for more details.

  4. Avoid using serif fonts like Times New Roman. The default sans-serif fonts are generally more legible.

  5. Make sure color schemes have enough contrasts between light and dark. See the Color and Colorblindness page for more details on color schemes.

  6. When inserting a table,
    1. Add a Caption as a title for the table
    2. Avoid merging cells, as it can make it difficult for screen readers to process
    3. Use the first row to indicate the type of data in each column
    4. Add a Summary to provide additional information to visually impaired audiences

  7. Avoid ambiguous link text such as "Here" or "Read More." Links should describe the destination. For instance, "Visit the NASA Home Page" is better than "For the NASA Home Page, go here."
    NOTE: Not only does this provision assist in screen reader navigation, but it also makes links and destinations ("information scent") more visible for all students.

  8. If you copy formatted text from Microsoft Word, use the Clean HTML Content tool (eraser icon) to clean the Word HTML code, then reformat the page.

  9. You can switch to View Source if you wish to hand-edit HTML code for accessibility.

Top of Page

Uploaded Files

All files uploaded into ANGEL should be made accessible. Accessibility accommodations include:

  1. Extended text descriptions for images critical to course content. Remember that you cannot edit an ALT tag in ANGEL; so the description must be available in the text.

  2. Text transcripts for any audio used. Videos should be captioned or include a text transcript.

  3. Uploaded Word files, PowerPoint files (especially with images) or PDF files should have accessibility-related measures incorporated.

Quizzes

  1. When writing multiple choice questions in ANGEL, select the format of "Multiple Choice" (choices listed with radio buttons) instead of the "Matching Option" (drop-down menu). Drop-down menus present more accessibility issues for users with mobility impairment, screen readers or certain cognitive disabilities.

    Multiple-Choice Versus Matching in ANGEL

    Matching Format - Answers in Drop-Down Menu

    screen capture-dropdown

    Multiple Choice Format - Answers Listed with Radio Buttons

    screen capture-radio buttons

    Both examples ask how Spanish /ñ/ differs from English /n/ in articulation, and provide a list of anatomical terms. The answer is that the tongue body makes contact with the alveolar ridge for English /n/, but with the palate for Spanish /ñ/.

     

  2. Add text descriptions for all uploaded images. For instance, if you upload an image for a quiz, include a brief description within the text for the quiz question. For example:

    Sample ANGEL Quiz Question
    With Description of Image

    Q: Identify the saturated fat below. The fat chain has 18 carbon atoms in it.

    saturated fat molecule

         

    NOTE: This description is also useful for students who cannot see an image attachment or image file online for technical reasons.

  3. Students with learning or physical disabilities may not be able to complete timed quizzes within the given time frame. If these students are registered with the Penn State Office of Disability Services, they are permitted to request accommodation for timed quizzes and assignments.

Alternative Quizzes and Assignments

In some cases, instructors may be asked to provide alternative assessments (quizzes) or assignments (e.g. an online test with a longer duration). This can be implemented in ANGEL by creating a hidden assignment available to only the student who needs it.

See the ANGEL Knowledge Base: Override Assessment Settings for Specific Students for detailed instructions.

Top of Page

Blogs at Penn State (Movable Type)

The Blogs at Penn State system includes some accessibility features, but the following guidelines can help to further enhance accessibility.

Synopsis

  1. Blogs with just text are normally accessible. Any issues that a user encounters can be reported to blogs@psu.edu.

  2. If you upload an image into the blog, make sure you give it a descriptive Name in the image upload window. This will become the ALT tag used by screen readers, and that is displayed when an image fails to load.

  3. Other files that are uploaded to the Blogs, such as PDFs, podcasts or PowerPoint files, should be made as accessible as possible if they are used in a course.

Add Image ALT Tag

Just as with other websites, images in blogs need to include the alt tag in order so that screen readers can read the text as a replacement for the images.

During Upload

To add an ALT tag when uploading image.

  1. While creating or editing a blog entry, click the Insert Image button in the formatting toolbar.
  2. Select an image to upload.
  3. After uploading the image, enter a short description in the Name field; this will become the image's ALT tag.
  4. Configure any additional attributes of the image such as alignment and thumbnail size, then click Finish.

After the Image is Uploaded

This procedure allows you to add an ALT tag to an image after a blog entry has been posted without editing the HTML code.

  1. Log in to the blog you need edit.
  2. Select the Manage menu then Assets. A list of images and files uploaded into your blog appears.
  3. Click the image you wish to add an ALT tag to.
  4. Change the LABEL field from the file name to an appropriate ALT tag then click Save Changes.
    Note:
    This new ALT tag only applies to new blog entries. Images on older blog entries would need to have their ALT tags manually adjusted.

Adjust ALT tag in Blog Entry

  1. Select the Manage menu then Entries. A list of blog entries you have posted appears in reverse chronological order.
  2. Click the link for the entry with an image.
  3. If you have adjusted the ALT tag using the Manage Assests procedure described above, you can re-upload the image. The new ALT tag will be inserted.
  4. Save the blog entry to republish.

Adjust ALT tag in Blog Entry (HTML method)

This method requires access to the HTML code, but allows the most control.

  1. Select the Manage menu then Entries. A list of blog entries you have posted appears in reverse chronological order.
  2. Click the link for the entry with an image.
  3. Click the HTML Mode (<A>) button in the editor to view the HTML code.
  4. Search for any text beginning with "<img alt=". This IMG tag represents the beginning of the embedded image code and the content in quotes after alt= is the ALT text.
  5. Change content after alt=" from the file name to an appropriate description.
    Note: If you do not see an ALT tag, you can insert alt="" and put the ALT text between the quotes.
  6. Save your blog entry to republish.

Top of Page

Student Blogs Entries

Depending on their situation, some users may not be able to fully interact with the system to create and write blog entries.

If your course requires posting entries to a blog and a student reports a problem, consider alternates such as:

  • Asking students to post comments instead of an actual blog entry
  • Allow students to forward entries as e-mail for instructors to post
  • Allow students to write blog entries in an alternative enviroment

Top of Page

Working with HTML Source and CSS Templates

Although the output of the Blogs at Penn State is generally accessible, there are always improvements that can be made. If you are comfortable using the HTML source view and CSS, consider these options:

  1. Paragraph breaks are coded <br /> when entered in the WYSIWYG editor, but should be replaced with true P tags in the source view, so that screen reader users can jump between paragraphs.
  2. Use the H2 tag on entry titles, and the H3 tag on section headers within a long blog entry. Specifying headers allows screen reader users to jump through the sections of a page. The easiest way is to do this in the HTML source view.
  3. If needed, you can modify the default style sheet to make H3 more distinct by default. See http://blogger.psu.edu/node/368 for details.

See support documentation at the Blogs at Penn State for information on how to access style sheets or templates.

Top of Page

Accessible Blogs Quickstart Guide

Download the "Creating Accessible Blogs" Quickstart Guide (.docx).

Top of Page

Chat & E-Mail

Synopsis

  1. If a participant in your correspondence is using a screen reader, make sure you use a chat client that is compatible with a screen reader. The screen reader should identify the sender of a given message, read text from incoming messages and inform the chatter where to input messages.
    Hint: If you are working with a blind user, ask that person what he or she would recommend. Some clients which are reported to be compatible with JAWS or screen zoomers include Skype, MSN Messenger and AIM (some limitations may exist).

  2. When using online communication technology such as an online chat, a blog or a threaded discussion message board, or e-mail, be sure to describe any ASCII art, attachments, or audio/visual files that are referenced.

Accessible CMC Passage

Sample Message Board Assignment

Tracking the Lion Logo - Realistic Lion

Assignment: By Friday, send me your thoughts on the lion image above for the "Tracking the Lion" logo. This image is a realistic male African lion in profile. Should the mascot be changed? Why or why not?

NOTE: This description is also useful for students who cannot see an image attachment or image file online for technical reasons.

A Note about ASCII Art in E-Mail Signatures

Many e-mail programs allow users to add a custom signature line, and many people like to incorporate ASCII art (the use of punctuation symbols and letters to simulate an image), such as the ASCII Nittany Lion below.

Inaccessible ASCII Art Image

ascii nittany lion

This image is a .GIF file, but if it were true ASCII art, a screen reader would say:

"Left parenthesis, quote, acute accent, dash, quote, backslash, quote, right parenthesis..."

If your signature line includes ASCII art, then make sure it is placed below all the essential contact information so users of screen readers can stop reading the content once they come to the ASCII art.

Top of Page

Clickers Accessibility

Clickers are a device used in various courses to allow students to submit answers to multiple choice questions during a lecture or other presentation. The current device is from iClicker and includes various mechanisms to enhance clicker accessibility clicker accessibility for different students.

Visually Impaired Students

The following options are available for visually impaired students. They include:

  • Clickers feature large raised letters. Braille stickers are also available free upon request. Contact clickers@psu.edu to request a clicker with Braille stickers.
  • Submission buttons are approximately the size of a finger pad.
  • The online registration form is tagged to include form labels.
  • Clickers which vibrate to indicate a student's vote being received are available upon request. Contact clickers@psu.edu to request a vibrating clicker with Braille stickers.

Color Impaired Vision

Blinking vs. non-blinking lights indicate whether a vote has been received or not. Specifically:

  • A steady green light signals that the vote was received.
  • A blinking red light signals that the vote was NOT received.
Complete accessibility information from iClicker is available from http://www.iclicker.com/products/accessibility/. Questions or concerns about the Clickers can be sent to clickers@psu.edu

Connect (Adobe)

Synopsis

  1. Adobe Connect 8 includes screen reader accessibility options. If a user still experiences problems after implementing these recommendations, consider using a telephone for audio. Other options include an accessible text chat, or a voice chat client such as Skype, which has JAWS scripts available.

  2. Users with hearing disabilities will have problems with audio (unless the chat is captioned), but may be able to use text chat and images to participate. See Adobe's Connect Closed Captioning Pod page for information on arranging live captions, or contact meeting@psu.edu.

  3. Videos recorded in Adobe Connect can be downloaded as Flash (FLV) files and captioned. Files typically need to be posted outside of Adobe Connect after an event.

  4. If you are screen sharing a document, such as a Word file or a Web site, consider enlarging the text to enhance legibility. You can also instruct users to click the Full Screen button beneath the shared document (in the "Share Pod").

  5. If your presentation includes a PowerPoint file with images, then include alternative text or text descriptions for images. Transitions like flying bullet points should be minimized, since the animation for each bullet point is assigned its own slide.

Top of Page

Download Adobe Connect Recording

The following instructions allow Adobe Connect meeting hosts download a recorded meeting by "replaying" it onto their computer. Thus, the recording process takes as long as the original meeting to complete.

Note: For long Adobe Connect recordings, it may be best to schedule the download during a time you will be away from your computer.

  1. Log in to http://meeting.psu.edu.
  2. Click the Meetings link the top row of tabs to see meetings you have Host privileges for.
    Note: The lower MyMeetings tabs shows all meetings you have access to.
  3. Click the name of meeting to open the Meeting Information window.
  4. Click the Recordings link to see a list of recordings.
  5. Click the link for the specific recording you need to download.
  6. Click the Make Offline button to start the download process. Install the Adobe Connect Add-in if prompted.
  7. Read the Recording Notes button to ensure you have the correct screen resolution and have followed other guidelines such as disabling your screen saver,
  8. Click the Proceed with Offline Recording button when you are ready to begin.

The recording will play and save itself to your local computer as an .flv Flash video file.

Top of Page

Caption Template

The following instructions allow you to download the Adobe Connect recordings, caption Adobe Connect recordings in MovieCaptioner, then re-upload the files.

  • Download the template files to receive necessary video player files.
  • Instructions on using the template files are included in the zipped file.
  • You will need to have admin rights to the Adobe Connect recordings that you wish to download and caption.
  • You will need Web space to upload the captioned files so you can link to them.

Top of Page

Excel Tips

Synopsis

Microsoft Excel files are generally accessible, but accessibility can be enhanced by the following

  1. Avoid using blank cells for formatting purposes. It is generally better to use other formatting tools such as adjusting column width or height

  2. Make sure headers for columns and rows are labeled as in a data table.

  3. If you are using the Chart Wizard
    1. Use the formatting options in line charts to create different types of dotted lines to facilitate legibility for color blind users.
    2. Avoid using the yellow and bright teal lines; use formatting options to change it to a darker color.
    3. Ensure that charts are legible are grayscale (black and white).
    Add a text key for bar charts or change the default colors to a color safe palette.

Adding Image ALT Tags

Modern versions of Microsoft Office allow you to add ALT text to inserted images. If these files are converted to HTML, the alt text is generally preserved. Please visit the Adding image ALT Tags page to see the complete list of steps detailing how to add ALT tags to images for different versions of Microsoft Office

Export Excel Data to HTML Tables

If you need to export Excel data to accessible HTML tables, then you may want to use the College of Agricultural Sciences Convert Excel tables to HTML. This tool allows you to cut and paste data from Excel, add captions and summary text then have it converted to HTML.

Even if you don't know much about HTML, you can cut and paste this code into the HTML view of any online blog, content manager or an HTML editor such as ANGEL.

Google Docs and Google Drive

Synopsis

This page contains some general guidelines for making your Google Drive documents more accessible, with a link to more detailed information at the end.

The University of Michigan also maintains a set of notes about Accessibility and Google Apps.

NOTE: Because Google Drive documents are missing some key accessibility functions, its use is not recommended for sharing documents with images and/or tables.

  1. Users on a screen reader must activate screen reader support.
  2. Google Drive also provides keyboard commands for editing documents.
  3. For long documents, use the Heading styles (Heading 1 through Heading 6) to break passages of text into multiple sections.
  4. All images, except those used for purely decorative purposes, should be accompanied by a caption or be described in the main text.
    Note: There is a mechanism for adding ALT text, but it may not work in all screen readers.
  5. Use one of the list tools to create lists, instead of inserting list items manually.
  6. Make sure that any hyperlink text clearly describes its target page.
  7. Sans-serif fonts are preferable to serif fonts with regard to on-screen legibility. If any text is given a colored "highlight," ensure that there is sufficient contrast between the highlight color and the text itself.
  8. A table of contents can help users navigate your document quickly, in addition to providing a preview of its content, both of which enhance its general usability.

Screen Reader Support

Because Google Drive is an application, the typical functions for navigating Web pages may not work. Specifically, Google Docs requires the activation of screen reader support by a user.

To learn how to activate screen reader support for individual Google Drive applications see Accessibility for Docs editors. See also Google Drive Use a screenreader

Note: If a user cannot read a Google Doc file, it is possible for an editor to download the file as an accessible Microsoft Office file.

Keyboard Support

A list of keyboard shortcuts for Google Docs editing commands is available from Google.

Top of Page

Headings

Headings provide context for your document, and allow screen reader users to quickly recognize its major sections. A screen reader will not recognize bold text or a large font size as indicating a heading.

Specifying heading styles such as Heading 1, Heading 2, or Heading 3 will allow a screen reader user to easily navigate your page. The document title should be in Heading 1, major subsections in Heading 2, further subsections in Heading 3, and so forth.

Designate headings in Google Docs by using the drop-down Styles menu.

Google Docs drop-down Styles menu

Top of Page

Images

It is now possible to add ALT text to an image embedded in a Google Doc file with the following procedure:

  1. Upload and embed the image file.
  2. Click and highlight the image file.
  3. Go the main Format menu and select the Alt text.. option.
    Note: The ALT text tool is not available if you right click the image.
  4. In the next window, enter the ALT Text into the Description fiield.
    Note: Do not enter the ALT text into the Title field.

Format menu with Alt text circled

Top of Page

Lists

Use one of the list tools to create either bulleted or numbered lists, instead of manually inserting bullets, numbers, asterisks or other symbols. As with headers, this tool enables screen readers to process list items more efficiently.

Numbered lists with multiple levels should use a different numbering scheme on each level. For instance, if the topmost level uses "1, 2, 3," the next level should use "a, b, c."

Create a list in Google Docs by using one of the Insert List icons in the formatting toolbar.

Google Docs List tool

Top of Page

Hyperlinks

Screen reader users often scan a document for hyperlinks, so it is important to make sure your links make sense without their surrounding content. For example, a link should say "Readings for the week of February 14" rather than "Readings for the week of February 14. Click here."

Click the Insert Hyperlink icon to create a hyperlink in Google Docs.

Google Docs Hyperlink tool

Top of Page

Ensuring Legibility

Sans-serif fonts are generally more legible than serif fonts, particularly on a monitor.

Color schemes (text color vs. background color) should have enough contrast between light and dark. If too little contrast is provided, colorblind or low vision users may have difficulty reading the content. Certain color combinations (often those with bright colors) can even cause headaches for some users.

Top of Page

Creating a Table of Contents

Adding a table of contents can help screen reader users navigate your document quickly and easily, in addition to making the file more generally usable by providing a preview of upcoming content.

You must designate headings to generate a table of contents, as these are what is used to specify the sections of the document.

Select Table of Contents from the drop-down Insert menu to create a table of contents in Google Docs.

Selecting Table of Contents from the drop-down Insert menu

Top of Page

Image ALT text in Microsoft Office

Modern versions of Microsoft Office allow you add ALT text to inserted images. If these files are converted to HTML, the alt text is generally preserved.

Adding Image ALT Text

Listed below are the steps to add ALT text to images for different versions of Microsoft office

Microsoft Office 2013

NOTE: In Microsoft Office 2007, the ALT Text tool is under the Picture Size options. In Office 2003, it is under the Format Picture options. Microsoft Office 2010 is discussed below.

  1. Open any Microsoft Office software and select an image so that the square anchors are visible.
  2. Right-click the mouse and select Format Picture.
  3. In the Format Picture window, select the Size & Properties tab on the right and select ALT TEXT

    Format picture window to select ALT TEXT option in office 2013

  4. Then insert the ALT Text into the Description field, NOT the Title field. Click the Close icon to finalize the ALT text.
  5. NOTE: If the ALT Text tab is not available, make sure you have not selected the Format Picture.

    Format Picture window on ALT Tag option to enter Description in office 2013

Top of Page

Microsoft Office 2010

Note: In Microsoft Office 2007, the ALT Text tool is under the Picture Size options.

  1. Open any Microsoft Office software and select an image so that the square anchors are visible.
  2. Right-click the mouse and select Format Picture.
  3. In the Format Picture window, select the ALT Text tab on the right, then insert the alt text into the Description field. Click the Close icon to finalize the alt text.
    NOTE: If the ALT Text tab is not available, make sure you have not selected the Format Picture.

    Word 2010 Format Picture window on ALT Tag option

Top of Page

Microsoft Office 2011 (Mac)

NOTE: This tool is not available in Office 2004 or Office 2008 for Mac.

  1. Open any Microsoft Office software and select an image so that square anchors are visible.
  2. Right click the mouse and select Format Picture.
  3. In the Format Picture window, select the ALT Text tab.
  4. Insert the alt text into the Description field as needed.
  5. Click OK to close.

Screen capture of Office 2011 Alt Text tool in Word

Top of Page

InDesign Accessibility

InDesign is a widely used tool to design and publish documents. Here are some quick steps to address key elements in making a short InDesign documents accessible. InDesign can export a document to accessible HTML document for the Web and for accessibility access. And when exporting to a PDF file these steps make it easier to make the document accessible in a PDF format. Remember these accessibility features are only available in recent InDesign versions 5.5 and 6.

Summary

  1. Take note of accessibility factors for font selections and the use of color contrast and color deficient issues when designing the document.

  2. Images Using the Object Tool to add image ALT Tags and Anchor Images to the Content for reading order.

  3. Threading text in text boxes as continuous flow helps maintain hierarchical structure.

  4. Use the Styles tool to tag headings and subheadings as H1-H6, paragraphs as P, and artifacts. These can be exported as tags to PDF.

  5. Use the Indesign reading order tools to verify and establish reading order. This ensures that a screen reader is reading the content in sequence.

  6. Adding Metadata will allow screenreaders to read the data without even opening the documument on the desktop. This allows ease of navigation and use.

  7. Exporting is the final step to converting to an accessible document as the document will not be read in InDesign. The document can be converted to a PDF or HTML. HTML is the recommended choice because of the simple process in making an accessibile document.

Top of Page

Add Image ALT Tags

Images need ALT tag descriptions for screen readers to read the content. This process guarantees information for screen reading if the metadata is not present. In InDesign there is an additional step in the in the Object Exportation Pane to allow for proper exportation of tags. These steps guarantee that images are given alternate text when exported to a PDF or as HTML code.

  1. First, to select your image, use the selection tool and click once on the image.

  2. In menu bar select Object then select Object Export Options.

    object export options screenshot

  3. In Object Export Options display select the ALT Text tab and change the Source to Custom.

  4. Add descriptive text in the ALT Text Source field. Do NOT click Done. Continue to next step.

    View o Object Export Options pane to customize Alt text

  5. Next go to the Tagged PDF tab in the same Pane.

  6. Set Apply Tag drop down menu to Based on Object.

  7. Set Actual Text Source to Custom.

    next step Tagged PDF tab and customize the Alt tag for Exportation screenshot

  8. Select Done.

Top of Page

Apply Anchors to Images

Use the Anchors to Images tool to allow screen readers to read images in flow of text. (For ID 5.5 and 6 only.) This feature allows a screen reader to read the ALT Tag description of the picture at the appropriate location in the associated content. Be sure to place this Anchor after or before a complete sentence.

Note: The Anchor icon will appear as a solid blue square near the top right corner of the picture.

Anchor icon circled to help Identify look and location, screenshot

  1. Click on the solid blue square, hold, and drag to the text content where you would like the picture to follow in the content. The solid blue icon will transform into an anchor symbol. The image will now be structured to follow the text without moving in the document.

    Example of Drag and dropping movement into text, in order to anchor a picture

Top of Page

Maintaining and Verifying Reading Order

Threading Text

  1. Threading means text is carried over from each text box as one continuous body of text. This allows for creative formatting.

  2. This will allow a screen reader to read the content in a continuous order. Furthermore, this will allow you to add or format content easily.

  3. The Threaded Text Marker will indicate that there is more text than will fit in the designated text box. The marker looks like a red cross in a red square found at the bottom right side of the text box.

    Example of Thread Text Marker, screen shot

  4. Clicking on the Thread Text Marker will cause it to transform and allow you to carry over flow content to a new text box and guarantee continuous flow, along with a hierarchical structure.

    Example of Thread Text Marker carrying over text to form a new box while continuing content, screenshot

  5. You can find more information on Threading at Lynda.com. Titled under Threading text Frames.

Top of Page

Reading Order Tools

Use the reading tools to verify reading order and establish the reading order.

  1. Go to the Menu bar above and select Windows, then select Article. This will open up the Articles Panel. Here you can see the order of document contents or place those contents in order with a simple drag and drop into the Articles Panel pane.

  2. To place content in order hold the shift button down, with the selection tool (black arrow), click the items (each individual content box) in the desired order, on a completed design in InDesign page.

  3. After selecting the last item hold the mouse button down and rag all the items to the Articles Panel. A list of the items will populate in the order you selected. Go to Adobe InDesign CS6 accessibility for an instructional video.


  4. Note: If you have anchored and image there is no need to select the image in order with the content.

Top of Page

Tag Headings and Paragraphs

Next, tag the content. Tagging the document will allow tags to be built when exporting to a PDF document. This will allow navigation options for a screen reader. InDesign headings and subheadings should be tagged as levels H1-H6; other readable items should be tagged as P for paragraph. Tagging allows the screen reader to identify items more efficiently. When exporting tags to Acrobat PDF, only H tags, P tags, Story, Table and Articles are recognized. You only need to Export H tags and P tags.

Notes:

  • Tagging for exportation is effective when Paragraph Styles have been assigned to the content. More information on how to assign Paragraph Styles can found at Lynda.com under Paragraph Styles and the subheading, creating and applying paragraph styles.

  • Decorative items, such as background color and design embellishments that do not apply to content, must be tagged as an artifact to be ignored by a screen reader.

  • InDesign does not tag Tables, Footnotes, or Hyperlinks. This is done accurately in the full version of Adobe Acrobat.

  1. From the InDesign menu, select Window then Styles and finally, Paragraph Styles. This will open the Paragraph Styles Panel.

    visual representation of pathway to reach paragraph styles pane

  2. Next right click over the style and select Edit “[style type]”. The Paragraph Styles Options Pane will open.

    Paragraph styles pane to be edited

  3. In the Paragraph Style Options Pane, select Export Tagging, and under PDF. Select the appropriate tag. Then click Okay.

    PDF tagging in the paragraph styles options pane

Note:
This will allow you to build a tagging style for one Style. A Style must be assigned to text to apply tags. For multiple styles you can read or watch a video at to Adobe InDesign CS6 accessibility.

Top of Page

Add Bookmarks

Bookmarks are strongly recommended for long documents, to allow navigation of a document in the exported PDF for screen readers and usability for all. Users can use a screen reader to navigate using headings and bookmarks. Heading allows one to search by topic and the bookmark allows one to skip to large sections. Short documents, three or less pages long may not need to be bookmarked.

First, Check whether the document has Bookmarks. In the menu bar, select Window then select Interactive and then Bookmarks. This will open the bookmarks pane. Visual pathway to reach Bookmarks, screenshot

  1. If there are no bookmarks, with the select tool, click on the content once to select the content and click on the Create New Bookmark icon. This will create a bookmark associated with content. Be sure to rename the bookmark.

    Bookmarks pain this new bookmark icon circled to highlight

Note:
Place bookmarks in logical places to navigate through large content topics, such as sections in a table of contents versus several on one page.

Top of Page

Add Metadata

Add document information in metadata. This allows screen readers to read the title of the document unopened on or in the desktop. Furthermore, the author, abstracts or document summary and security maybe added here.

  1. Add a title to export with the document. In the menu bar select File and then select File Info.

    pathway to add metadata under file information pane

  2. The File information display will open. Add the title in the Document Title field. This is the minimum for accessibility standards in this program.

    File Information, adding document title, screen shot

Top of Page

Export Options

The InDesign document may be exported into several types of document or files. The common document is Adobe PDF, but an HTML file is recommended. The HTML document and creation of a Web page is considered a more accessibility friendly document and can be printed as PDF document by the user. Exporting to a PDF document is not the first choice for an accessible document for online access, due to the complex procedure required to make the document accessible.

  1. To export your InDesign document: In the menu bar, select File and then Export.

    Visual File to Export pathway screen shot

Exporting to HTML

  1. In the Format drop menu, select HTML.

    Export pane, selecting HTML format screen shot

  2. The HTML Export Options menu will appear. Select and Verify that the Same as Articles Panel radio button is selected. Select and Verify Formatting Options. Bullets should be Map to Unordered Lists and Numbers should be Map to Ordered Lists.

    HTML Export Options pane screen shot

  3. Select OK.

  4. The HTML file can be modified before uploading to the web or attached to a Styles sheet before the exportation process under the Advanced menu. But this is not necessary to create an accessible document.

Top of Page

Exporting to a PDF

  1. In the Format drop down menu, select Export to Interactive PDF.

    Format drop down menu, selecting Adobe PDF (Interactive) screen shot

  2. The Export to Interactive PDF display will show.

  3. Be sure to select Include All radio button next to Forms and Media.

  4. Under Tagged PDF, check Create Tagged PDF and Use Structure for Tab Order.

    Export to Interactive PDF pane shown in screen shot with appropriate items selected

  5. Select OK to complete the process.

  6. Verify and complete additional accessibility options in Adobe Acrobat.

Top of Page

Microsoft Office: Excel, Word, PowerPoint

Microsoft Office: Excel, Word, PowerPoint

Some content on this site based on material from Michigan State Web Accessibility with their permission.

Adding Image ALT Tags

Modern versions of Microsoft Office allow you to add ALT text to inserted images. If these files are converted to HTML, the alt text is generally preserved. Please visit the Adding image ALT Tags page to see the complete list of steps detailing how to add ALT tags to images for different versions of Microsoft Office

Cautions on Converting Word and Excel to HTML

Although Microsoft products include a function to convert content to HTML, the implementation is not regarded as standards-compliant. Below is a sample of what codes are generated by the Save as Web file option in Microsoft Word.

If need convert to HTML, you can look for the Filtered Web option (available in Office 2007 for Windows only) or you can purchase a plug-in to audit the accessibility of the output file (Windows only).

Intended Result

This is unformatted text.

View the Code

<p>This is unformatted text</p>

 

Actual Result (Inaccessible)

(Font is fixed to 12 point, Times New Roman)

This is unformatted normal text.

View the code

<p class=MsoNormal>This is unformatted text</p>

p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-parent:"";
margin-top:0in;
margin-right:0in;
margin-bottom:5.0pt;
margin-left:0in;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:"Times New Roman";
mso-ascii-font-family:Palatino;
mso-fareast-font-family:Cambria;
mso-hansi-font-family:Palatino;
mso-bidi-font-family:"Times New Roman";}

 

Accessibility Issues of Word Generated HTML

  1. Styles use fixed font sizes, not relative font sizes. Fixed font sizes won't allow the text to be zoomed in Internet Explorer 6 or earlier.

  2. The font will probably be fixed to Times New Roman, which is designed for print, not for computer monitors.

  3. Style sheets are embedded and are time consuming to remove manually. In fact, all Word styles in your template are exported even if they are not used in the original document.

  4. Word HTML allows designers to specify unusual fonts and/or symbols, which may not be available on all computers.

  5. If Smart Quotes are turned on, then they will be converted to a Unicode numeric character or left intact. Older browsers may not be able to decipher these symbols.

NOTE: Some text editors, such as Global Writer, export HTML with less embedded formatting.

Top of Page

General Availability

Make sure your audience has ready access to Microsoft Office packages, and to the same version you are using. Although Word is readily available at Penn State, it may not be elsewhere. In some cases, a different option, like pure HTML or a PDF, may reach your audience better.

Top of Page

Microsoft Office to Accessible PDF for Windows

In Microsoft Office 2013/2010 (specifically Word, PowerPoint, Excel, and Access), it is possible to create a "tagged" PDF. Tagging sections of a PDF is a way to programmatically specify the order of the file's elements. This will allow visually impaired users to more easily navigate the document with assistive technology, and will reduce the amount of work needed to optimize the PDF for accessibility later on. This page gives instructions for creating a tagged PDF in Microsoft Office 2010 for Windows.

Office 2013 for Windows

  1. Create an accessified Word, PowerPoint or other Office 2013 file, following the recommendations for Word accessibility and PowerPoint accessibility.
  2. From the File menu, select Save As...
  3. Select the Computer option, then select My Documents, Desktop or Browse option to select your specified directory.

    Image of navigation to select directory in Word 2013

  4. Select the PDF format.
  5. Click the Options button to open a new window.

    Image of navigation to save a PDF in Word 2013

  6. Ensure that the "Document structure tags for accessibility" option is checked.
  7. Check the option for "Create bookmarks using:"
  8. Select the Headings option.

    Image of Options screen to place headings and bookmarks

  9. Click OK to close the window.

Office 2010 for Windows

  1. Create an accessified Word, PowerPoint or other Office 2010 file, following the recommendations for Word accessibility and PowerPoint accessibility.
  2. From the File menu, select Save As...
  3. Select the PDF format.

    Image of navigation to save a PDF in Word 2010

  4. Click the Options button to open a new window.
  5. Ensure that the "Document structure tags for accessibility" option is checked.
  6. Check the option for "Create bookmarks using:"
  7. Select the Headings option.

    Image of Options screen to place headings and bookmarks

  8. Click OK to close the window.

Check Accessibility in Adobe Acrobat

All PDFS should be inspected in Adobe Acrobat

  1. Open the PDF in Adobe Acrobat to verify reading order and tagging.
    NOTE: Adobe Acrobat XI is available from the Penn State Computer Store, and is installed in CLC Student Labs.
  2. In Adobe Acrobat, confirm that the reading order is set correctly.
    NOTE: This is important for documents with multiple columns, shapes and/or text boxes.
  3. Confirm that images are marked as "Figures" and include alt text.

Refer to the PDF Files for more information.

Macintosh

The instructions above only apply to Office 2010 for Windows.

A method of creating tagged PDFs in the Macintosh version of Office is also available, but involves using the open source word processor Open Office.

Top of Page

Microsoft Office to Accessible PDF for Mac

OpenOffice for Mac: How Convert Word/PowerPoint to Tagged PDFs for a Mac

“OpenOffice” is a tool to convert a correctly structured Word and PowerPoint to correctly tagged PDFs in Office for Mac. The accessibility Wizards are Windows only.

There is a cheap and simple accessibility tool for the Mac built within OpenOffice for the Mac (a shareware product). OpenOffice is an open source analogue of Microsoft Office, but sometimes it has some extra tricks not in Microsoft Office.

Note: OpenOffice is installed on CLC Student Lab Macs at PSU.

Create Tagged PDF in Open Office

First, have a well-structured Word file (using Heading 1,Heading 2 styles and ALT tags on images) or a well-structured PowerPoint file (Image ALT tags, titles on all the slides and using default list tools).

To create the accessible tagged PDF:

  1. Download and install at OpenOffice.org following instructions on the Web site, if not already installed.
  2. Create a second copy of your Word and PowerPoint files. For best results, save your original files as the older format .doc and .ppt files.
  3. Open Word or PowerPoint document in Open Office.

    Sample images of Word document and OpenOffice Document

  4. To add an ALT tag to images, right click or Control+click on image and select Description option. Fill in the Description Field and click "OK."

    Sample image of of alt tag field

  5. Ensure that all headings (Word) and titles (PowerPoint) are in place.
  6. In the File menu, select Export as PDF.

    Screenshot of PDF export in File Menu drop down list

  7. In the PDF Options window, check Tagged PDF.

    Screenshot of PDF Options window, tagging a PDF

  8. Click Export. A tagged PDF is exported.

    Sample image of exporing nd naming a tagged PDF

Top of Page

Microsoft Word Tips

Some content on this site based on material from Michigan State Web Accessibility with their permission.

Synopsis

  1. When inserting images or charts, be sure to add ALT tags or a description of the image for screenreaders.

  2. Ensure that all documents include a document title and that it is marked with a Heading 1 style.

  3. For long documents, use the Heading 1, Heading 2, Heading 3 styles to break up long text passages into multiple sections. These headers may be preserved and interpreted in screen readers when files are converted to PDF or other formats. The Format » Style menu allows users to adjust the appearance of these tags in a Word file.

    NOTE: In some HTML editors like Dreamweaver, Header styles are converted to H tags when the text from Word is copied and pasted into Dreamweaver.

  4. For long documents, insert or generate a table of contents based on Heading 1,Heading 2, Heading 3 styles. See details in the Quickstart Guides above.

  5. When inserting a data table, make sure the first row/column is marked as a header and includes a description of the type of data used in each row or column. For very complex tables, a table ALT Tag can be used to add extra information for screen readers (see Quickstart Guides above for details).

  6. For links, avoid using link text such as "Here" or "Click for more." Instead make sure link destinations are clear outside the context. For example a link saying "Readings for Feb 14" is clearer than "Click here" for the Feb 14 readings.

  7. Use the list tool instead of the bullet character plus text. Numbered lists with multiple levels should use different numbering schemes on each level.

  8. Accessibility does NOT equal plain and boring documents. There are tools in Word that help visually decorate and enhance a document, while still optimizing accessibility. In Word, Advanced Text Formatting may be used; some work and some do NOT.
    1. Text Effects will visually enhance a document without sacrificing screen reader compatibility. For visual effects, remember to address accessibility best practices for Color, Formatting, and Font Layout.
    2. Clear Formatting is one way to undo altered text.
    3. There are Formatting Tools to Avoid using, both on PC and Mac Word versions.

Top of Page

Adding Image ALT Tags

Modern versions of Microsoft Office allow you to add ALT text to inserted images. If these files are converted to HTML, the alt text is generally preserved. Please visit the Adding image ALT Tags page to see the complete list of steps detailing how to add ALT tags to images for different versions of Microsoft Office

Marking Table Headers

Microsoft Office allows you to mark the first row of a table as table headers. Please visit the Designating Table Headers page to see the complete list of steps.

Generate Table of Contents

  1. Go to the References Tab (Word 2010/2013 for Windows) or the Document Elements tab (Office 2011 for Mac) in the ribbon at the top of the page.
  2. Select Table of Contents. You can select one of the automatically generated formats or choose to enter the titles of the sections manually.

Word 2010/2013 for Windows Table of Contents Tool

Word 2010/2013 for Windows Table of Contents Tool

Word 2011 for Mac Table of Contents Tool

Screen capture for table of contents tool for Mac

Top of Page

Text Effects

  1. Highlight the content you wish to convert.
  2. Go to Home tab and Select the Text Effects button.

    Home tab to Text Effect button

  3. This will bring you a drop down menu of preselected colored letters and additional options, Shadow, Reflection, Glow and Outline.

    Option drop down menu for Text Effect button. Shadow, Relfection

Top of Page

Formatting Tools to Avoid

Text Box, Quick Parts, WordArt and Drop Caps are NOT accessible formatting tools in Mac or PC. Do NOT use a formatting tool that places a letter into a Text Box. A screen reader will not recognize this as part of a word to be read.

    Text Boxes and Word Art Buttons
    Text Box and Word Art button for word 2010 Text Box and Word Art button for word 2013 Drop Cap button in PC
    Text Box and Word Art button for word 2010 Text Box and Word Art button for word 2013 Drop Cap button in PC

Top of Page

Modifying and Customizing Heading Styles

Modifying "Styles" in a Word document is a wonderful tool to personalize and design your word documents, to easily create table of contents, and citations. Additionally, using the Styles to modify or format your text will provide accessibility in two ways.

  • Providing “tagging” for screen reader navigation in the word document and for export to a PDF document.
  • Next, customizing a template or various style templates to format a document for specific target audiences. Those with color or visual issues.

Modify Headings for your document

  1. Highlight the text and format using the Font tools in the ribbon. You may apply headings using Styles in the tool ribbon or using the Key commands : Ctrl+Alt+ #1

    image of right click formatting of highlighted text

  2. Open the Styles Pane. Key commands: Alt +H, F, Y F6.

    image of style pane opening

  3. Then right click on the desire Heading you wish that text to resemble and select "Update Heading to Match Selection."

    image of selecting the heading to match selection

    For a Mac do the same.

    Image of Mac Quick Styles Modification

  4. This will modify all the headings for this document.

PDF Issues

See the PDF page at http://accessibility.psu.edu/pdf for information about accessibility and PDF. This is also listed under the "What to Fix" tab.

PowerPoint Tips

Some content on this site is based on material from Michigan State Web Accessibility with their permission.

Synopsis

  1. Always add ALT tags or labels to images, and include extended text descriptions for graphics and charts as needed. Audio and video files should include captions or transcripts.

  2. Use a color scheme that provides enough contrast between the text and the background, yet is not too overpowering. See the color page for more information on suitable color schemes.

  3. Use sans-serif fonts that are designed for both projectors and online viewing. See the Font Face page for more information on picking a suitable font.

  4. Give a title to every slide. Make sure the title is entered into the designated area (usually at the top), as this will help generate a table of contents for screen reader users (in both PowerPoint and, if the file is converted, in the HTML file).

  5. If your slide includes multiple elements (e.g. images combined with textboxes), use the Arrange tool to order elements in a sequence that will be intelligible to a screen reader user.

  6. Avoid inserting text boxes as they are not recognized by screen readers. Use one of the slide master templates instead.

  7. If you use the Chart Wizard, make sure the chart formatting is accessible.

  8. If you use Adobe Presenter with a PowerPoint file to create a recorded presentation, make sure that images are tagged, and try to minimize transitions. Text transcriptions are also necessary for audio content. For more information, see Creating Accessible Content with Adobe Presenter (from the Adobe Users Community)

Top of Page

Adding Image ALT Text

Modern versions of Microsoft Office allow you to add ALT text to inserted images. If these files are converted to HTML, the alt text is generally preserved. Please visit the Image ALT text in Microsoft Office page to see the complete list of steps detailing how to add ALT tags to images for different versions of Microsoft Office

Designating Table Headers

Microsoft Office allows you to mark the first row of a table as table headers. Please visit the Designating Table Headers page to see the complete list of steps.

Using the Arrange Tool to Order Elements

Because screen readers cannot simply display all of a slide’s content at once, they must read every slide in a certain order. It is important to verify the order in which each slide is arranged to make sure the information is coherent when read aloud.

To verify the order of slide elements:

  1. Go to the Home tab.
  2. Select the Arrange icon to see a drop-down list of commands
  3. Choose Selection Pane (PowerPoint 2013 for Windows) or Reorder Objects (PowerPoint 2011 for Mac)
    • Reorder tool screen capture for Mac Office 2011 Selection pane for Office 2013
      Reorder tool screen capture for Mac Office 2011 Selection pane for Office 2013
  4. Use the tools to place items in correct reading order. See the Quickstart guides below for details.

Notes on Order

  • Windows: The bottom most item is in the Arrange panel read first.
  • Macintosh: Item #1 in the Rearrange panel is read last.

Top of Page

PowerPoint Slide Master

Summary

A Slide Master slide is a slide that is the master of all slides in look and feel. This look and feel may include a custom presentation of font, colors, contrast, effects, backgrounds, pictures or logos, placeholders, footers, titles, page numbers and more.

Adding custom slide layouts through the slide master is critical for screen reader accessibility because ONLY text fields added in a slide master are read out in a screen reader. Manually inserted text fields may be skipped by a screen reader. Slide masters also allow for consistent formatting between slides.

Detailed information on working with PowerPoint for Microsoft (PC) or PowerPoint for Mac can be found at Lynda.com (http://lynda.psu.edu).

 

Adding a Custom Layout to the Theme (Windows)

This procedure allows you to customize the layout and number of text fields on a slide such that each text field will be recognized by a screen reader.

  1. From the Master View screen, go to the side bar with all the sample slides. Scroll down and select in the empty space after the last slide. A blinking black line will appear below the last slide. This is where a new slide will appear.

    Description: View of the area where a new slide can be created in the theme.

  2. Next, in the top Menu bar, select the Slide Master tab.
  3. Select the Insert Layout to add to the existing set of slides. Be sure to select the new blank slide.

    Description: image of the Insert Layout button needed to add a slide to the theme.

  4. Select Insert Placeholder for a list of placeholders.
  5. Select and use the Content. A screen reader will read and understand all items place in this holder. The other Placeholder selections may not be accessible to some screen readers.

    Description: Screenshot of the Insert Place holder and drop down selections, highlighting the Content choice.

  6. Draw the Insert Placeholder in your power point slide.
  7. Repeat this step for the slide to arrange the content to your desired format.

    Note: The order with which you Content Placeholders, is the order with which the content will be read. Use the Arrange Tool to reorder elements to check and correct the reading order.

  8. When done, select the Close Master View button on the Slide Master tab.

    Description: Picture of the Close Master View button

Note: The slides you have created will be available from the Home tab, click the New Slide button and under the Office Theme gallery. Furthermore, every slide in the gallery has been formatted with the picture you inserted.  You are able to select the slide with the appropriate Layout or the layout with the content placeholders you placed.

 Description: Sample of the the New Slide button drop down menu, displaying the Theme slides that are available from a Normal view screen.

Top of Page

 

Placing a Picture in the Master Theme Slide (Windows)

This procedure allows you to add a background image to multiple slides without needing to add ALT text to each image.

  1. In PowerPoint, go to the Menu bar. Select View.
  2. Select Slide Master

    Description: visual aid highlighting the Slide Master Slide view.

  3. This brings you to the Master View screen.

    Description: Sample display of the Master View Screen.

  4. The first slide highlighted is the “Office Theme Slide Master”. Changes made to this slide will be repeated to all the other slides below. This is the time saver, when placing a picture or logo, repeated resource information or other custom alterations, such as fonts, background colors, etc. to your slides.

    Description: Sample view of the 'Office Theme Slide Master' slide.

  5. To Insert a picture or logo that repeats on every slide, go to the Insert tab in the menu bar and select Picture.

     Description: Steps to place picture using tab icons.

  6. Select the image file you desire (if your photo is stored on your hard drive). Locate the picture from you computer. The picture will appear in the center of the slide. In our example we use a logo, but any picture that you would like to appear on every slide may be selected and used.

     Description: Sample Picture of where a photo populates in a slide.

  7. It may need to be resized and moved. To adjust the size, press and hold Command + Shift and drag the corner in or out.
  8. Hover your cursor over the green point at the top of the picture. Description: Sample of the rotation fuction of a content placeholder frame. 
    A circle of arrows will appear and allow you to rotate the picture.

    Description: Sample picture of content being rotated.

  9. Proceed to place the picture in any position you would like.
  10. The picture will populate through all the slides below the Office Theme Master Slide. This is the creation of a Custom Theme.

    Description: Sample Picture Highlighting the the additional slides in a Theme, with the picture/logo populated throughout.

Note: This newly added picture in your Office Theme Master Slide would be read last, so be sure to add your Image Alt text when placing this content into your new theme.

Top of Page

 

 

 

Adding a Custom Layout to the Theme (MAC)

This procedure allows you to customize the layout and number of text fields on a slide such that each text field will be recognized by a screen reader.

  1. From the Master View screen, go to the side bar with all the sample slides. Scroll down and select in the empty space after the last slide. An orange line will appear below the last slide. This is where a new slide will appear.

    Description: View of the area where a new slide can be created in the theme.

  2. Next, in the top menu bar, select the Slide Master tab.
  3. Select the New Layout to add to the existing set of slides. Be sure this new blank slide is selected.
  4. Select Insert Placeholder for a list of placeholders.
  5. Select and use the Content placeholder. A screen reader will read and understand all items place in this holder. The other Placeholder selections may not be accessible to some screen readers.

    Description: Picture highlighting New Layout button, Insert Placeholder drop down menu and directing the use of the Content Placeholder.

  6. Draw the Content placeholder in your power point slide.
  7. Repeat this step for the slide to arrange the content to your desired format.
  8. Note: The order with which you Content Placeholders, is the order with which the content will be read. Use the Arrange Tool to reorder elements to check and correct the reading order.

  9. Lastly, select the Close Master View button.
  10. Description: Picture of the two choices of the Close Master View buttons.

    Note: The slides you have created will be available from the Home tab, click the New Slide button and under the Office Theme gallery. Furthermore, every slide in the gallery has been formatted with the picture you inserted. You are able to select the slide with the appropriate Layout or the layout with the content placeholders you placed.  

    Description: Sample of the the New Slide button drop down menu, displaying the Theme slides that are available from a Normal view screen.

Top of Page

 

Placing a Picture in the Master Theme Slide (MAC)

This procedure allows you to add a background image to multiple slides without needing to add ALT text to each image.

  1. In PowerPoint, go to the Menu bar. Select View.
  2. Select Master, then Slide Master

    Description: screen shot of entering the Slide Master Screen. Key Strokes are alt + command + 1.

  3. This brings you to the Master View screen.

    Description: Master Title Style screen.

  4. The first slide highlighted is the “Office Theme Slide Master”. Changes made to this slide will be repeated to all the other slides below. This is the time saver, when placing a picture or logo, repeated resource information or other custom alterations, such as fonts, background colors, etc. to your slides.

    Description: View of the Master title slide, which is the first slide in the slide bar to the left of the screen.

  5. To Insert a picture or logo that repeats on every slide, go to Insert in the menu bar and select Photo.
  6. Select Picture from File (if you photo is stored on your hard drive). In our example we use a logo, but any picture that you would like to appear on every slide may be selected and used.

    Description: picture highlighting the steps to opening a picture file.

  7. Locate the picture from you computer. The picture will appear in the center of the slide.

    Description: Sample slide of where the picture will populate on the Slide Master.

  8. It may need to be resized and moved. To adjust the size, press and hold Command + Shift and drag the corner in or out.

    Hover your cursor over the green point at the top of the picture. Description: Sample of the rotation fuction of a content placeholder frame. A circle with an arrow will appear and allow you to rotate the picture.

  9. Proceed to place the picture in any position you would like.
  10. The picture will populate through all the slides below the Office Theme Master Slide.

    Description: Sample Picture Highlighting the the additional slides in a Theme, with the picture/logo populated throughout.


    Note: This newly added picture to your Office Theme Master Slide would be read last, so be sure to add your Image Alt text when placing this content into your new theme.

Top of Page

Sites at Penn State (WordPress)

Sites at Penn State allow students, faculty and staff to design personal websites and blogs sites through a WordPress platform. Accessible design is achievable with simple considerations. These instructions will cover the Top Blockers and give you some of the best practices in regards to accessibility in regards to Sites at Penn State. The Twenty 12 template, a provided Theme in the WordPress platform, is recommended by Penn State’s Web Lion as one of the more accessible themes.

Summary

  1. Selecting Themes
  2. Page & Document Titles
  3. Headings & Subheadings
  4. Copy and Paste from Word
  5. Link Text
  6. Image ALT Tags
  7. Video & Audio
  8. Documents
  9. Tables
  10. Customizing

Selecting Themes

These instructions assume that you have selected the 2012 theme. Other themes are available, but because functionality can be different, options described below may or may not available in any particular theme.

Page Document Titles

Think about the title and take special consideration when making a new page. This title will appear as H1 in association to the primary content for a Screen Reader to read. This page title describes the topic of the page.

Headings & Subheadings

Organizing your documents content is important. Information about organizing accessible content can be found at Accessibility and Usability at Penn State for Headings and Subheadings.

Several choices for Sites at Penn State: If writing the content formatted or from unformatted content follow these steps:

Add Headings to Blog Entry or Page

  1. For content that you create on the page, you will need to go to the main menu of the Visual content tab, select the Show/Hide the kitchen sink icon. This will reveal more option in the content manager menu.Screen shot of menu bar, attention brought to the Show/Hide Kitchen sink icon and the Visual tab. Key strokes Alt + Shift + Z.
  2. Highlight the content/heading/subheading you wish to format, while or after you have typed up your content.
  3. Select the appropriate tag from the Format drop down menu.screen shot of format dropdown menu, showing the heading options 1-6
Note: Things to remember about placing content in the content manager; the headings in the main content should begin with H2 like the rest of the site and descend with the other subheadings. When you created the page, the page title is the H1.

Top of Page

Copy and Paste from Word

A Word document with properly formatted with headings will transfer headings and subheadings to Visual content window with a simple copy and paste. See the Microsoft Word page to learn tips to build an accessible Word document for this option.

  1. In a Word document, place the cursor in the content anywhere.
  2. Select Command + A, to select the entire Word document. This will select all the heading/subheading formatting in the Word Document.
  3. While the content is highlighted, select Command + C, to copy the content.
  4. Go to the Visual Tab and place the cursor in the dialogue box.
  5. Select Command + V, this will paste all content in the dialogue box. All the headings and subheadings will carry over.
Note: If the title or H1 heading was at the top of the page remove it and place it in the “Enter title here” text box. The H1 headings may need to be reformatted to H2 heading.

Top of Page

Link Text

Link text within a page or blog entry should clearly specify the destination of the link. Avoid vague such as, “here” or  “here, here and here”). See Link Text Accessibility for more information.

See information at Sites at Penn State Quick Start Guide for specific instructions on creating a link.

Media Option

A list of media that Sites at Penn State’s WordPress platform is able to use can be found at WordPress Support.

Information on uploading various media can be found at ITS Training Handouts.

Image Alt Tags

After uploading an image to the Media Library, the Image Alt Tag can be easily added. If the image is used for the Header, to customize your page the Alt Tag will NOT be associated.

  1. In the Left side menu panel, select the Media Library. This will show you the media you have uploaded to the site. Screen shot highlighting the location of the Media and Library buttons in the side menue bar and highlighting the list of media.
  2. Next, select the file you desire to use. Hovering over the file name will give you options.
  3. Select Edit.
  4. Screen shot of Hovering over a file and revealing option buttons to edit a picture in the wordpress platform.
  5. This will bring up the file and the alternative text can be place in the Alternative Text text box.Screen shot of Alternative Text box for editing an image in WordPress platform
  6. Lastly, select the Update button in the Save Pane, located at the top right of the Edit Media page.Screen shot of the Save Pane and Updat button

Top of Page

Video and Audio

If you link or embed a video or audio file, then to maximize accessibility, you need to:

  • Ensure that the video is captioned and that pages with audio files include a link to a transcript.
  • Depending on the video, users with visual impairments may need access to an  audio described video.
  • Videoplayers should be accessible on a screen reader. See the Multimedia page for information.
  • Top of Page

    Documents

    For conveying information via the web, the use of a correctly formatted HTML web page is optimal for most screen readers. As a best practice recommendation, cutting and pasting an accessible Word Document, to the Visual content pane will effectively transfer over the headings to an accessible web page. Hear are tips to make an Accessible Microsoft Word document.

    However, the WordPress platform used by Sites at Penn State allows for various document formats to be uploaded and to be placed on your website as a downloadable document. For long documents follow these tips and upload the document in the same manner at your discretion.

    Uploading a PDF file is to be avoided or minimized. Many experts recommend this, due to the complexity to building an accessible PDF document. You can find out more about issues with PDF files and options to Convert PDF files.

    Top of Page

    Tables

    Unfortunately, the WordPress template does NOT provide an easy way to make the table accessible. Accessibility PSU offers a detailed explanation of the HTML code format you will need to make an accessible table.

    Copying & Repairing Table Code

    A table can be cut and pasted from either Word or Dreamweaver and then be repaired in the Text (HTML code view).

    Copying from Word

    1. Follow steps #1-5 of the pasting from Word instructions above.
    2. Go to the right corner of the content pane and select the Text tab to display the HTML code. Repair the HTML code according to the specifications in the  accessible table page.
    3. Publish the entry or page when the edits are complete.

    Creating and Copying from Dreamweaver

    Note: A similar technique can be used for any HTML editor.

    1. Create an accessible table in Dreamweaver following the instructions on the Dreamweaver  pages.
    2. Copy the HTML code for the table.
    3. In WordPress, make sure the Text tab is checked in the page or entry editor (this displays HTML code).
    4. Paste the accessible code into the entry or page.
    5. Publish the entry or page when the edits are complete.

    Top of Page

    Customizing

    Header Image

    Currently, there is NO way to modify the image ALT tag of the header image. The ALT tag is “#” by default and cannot be changed.

    Background color

    When choosing a background color or image take into account Contrast & Luminosity. A distracting pattern or florescent color will detract from the content.

    Adding Widgets in Accessibility Mode

    The widget tool includes an option to Enable Accessibility mode. This allows authors to add widgets by clicking a link instead of by drag and drop. This option could also be useful to anyone building a site on a mobile device.

    Note: This option has nothing to do with making your final Web page more accessible to site visitors.

    To enable accessibility mode.
    1. Enter the Widget area of your site Dashboard.
    2. Click on Screen Options or navigate to Screen Options hit Enter in the upper right.
    3. Note: If you are on a screenreader, click Enable accessibility mode.
    4. Select the link for Enable accessibility mode. Each widget will be displayed with an Add or Edit option.Description: escription: Comparitive screenshot showing the how to enable the add buttons to add widgets to ones page versus the drag and drop method.

    Enabling Accessibility mode- Enables you to add widgets with an Add button, instead of drag and dropping with a mouse. However, accessibility mode here is referring to accessing the ability to place widgets in WordPress Platform without dragging and dropping. Dragging and dropping items cannot be done with a screen reader and keyboard.

    Top of Page

Table Headers in Microsoft Office

Microsoft Office allows you to mark the first row of a table as table headers.

Designating Table Headers

  1. Click anywhere in the table.
  2. Go to the Design tab (Office 2013/2010 for Windows) or the Table tab (Office 2011 for Mac) at the top of the page.
  3. NOTE: Office 2013 has 2 design tabs, click on the one the right under TABLE TOOLS. The other one is generic for the entire document.
    The two different DESIGN tabs for Office 2013
  4. Check the Header Row check box for the First Column and/or First Row.
  5. Type (or retype) your column headings.
  6. Press the Enter key.

Word 2013 for Windows Headers Tool

Word 2013 for Windows Headers Tool Screen capture

Word 2010 for Windows Headers Tool

Word 2010 for Windows Headers Tool Screen capture

Word 2011 for Mac Headers Tool

Screen capture

Top of Page

Turnitin

External Links

  1. Turnitin and JAWS

Turnitin is a is a Web-based plagiarism detection and prevention system licensed to Penn State instructors. Below is a summary of accessibility information

Blind Users on a Screen Reader

Turnitin includes accessibility accommodations for screen readers in its default interface. However, some screen reader testers have reported usability issues in some functions. Therefore, a blind student may still need additional support.

Alternative Submission Method

If a student reports a problem uploading an assingment, an instructor does have the option of uploading a file on behalf of the student.

Contact turnitin@psu.edu or the Office of Disability Services if a student reports a problem.

GradeMark and Originality Reports for Students

A PDF version of these reports is available with text based pages placed at the end. Students with severe vision impairments may only be able to access individual comments detached from the original text. We recommend instructors take care to write comments which include the original text and then the comment. That way a screen reader can understand the context without seeing where the comment is placed.

Peer Review Assignments

There is currently no way a student can use a keyboard to access papers they have been assigned to review. This affects blind students using a screenreader as well as students with certain motion impairments. For those students, it is recommended that papers they need to critique be sent to them via e-mail along with questions they may need to answer.

These students may also have problems accessing critiques from other students. If necessary, instructors can copy critiques and send them to the student.

Contact

Students or instructors who need to report an accessibility concern can send them to turnitn@psu.edu or accessibilityweb@psu.edu.

VoiceThread

VoiceThread is an online communication tool that allows students and instructors to contribute to a discussion thread using any mix of text, a microphone, a web cam, a telephone, or uploaded audio file. VoiceThread also includes a white board tool.

Depending on the needs of your students, different accommodation strategies may be needed.

Captions for Deaf and Hearing Impaired Students

Below are some options for courses with deaf and hearing impaired students.

  1. For purposes of captioning, a VoiceThread video can be captioned or or exported and captioned, allowing you to save a fixed copy of a VoiceThread which can captioned. This file plays as a movie, just like the VoiceThread would if you viewed it on the VoiceThread site.
  2. If the class includes Deaf or hearing impaired students, another option is to require that all students participating in a VoiceThread only use audio-free tools such as text commenting feature, image/file upload and the "doodle" whiteboard.
    Note: A variant could be that students using video/audio options should also create a transcript or script.

Add ALT Text to Uploaded Slides

Instructors should add ALT text to uploaded slides by adding a Title for each slide. See details at the page to support for VoiceThread Universal.

Screen Reader Options

The default version of VoiceThread is currently not screen-reader accessible and is therefore not fully usable by many blind students. VoiceThread does offer VoiceThread Universal, a "Universal" version of the the VoiceThread application designed specifically for use with a screen reader which supports accessible such as JAWS.

To access Voice Thread Universal, students can:

  1. Log in to the Voicethread service at http://voicethread.psu.edu with your Penn State Access Account userid and password.
  2. When log in is complete, go to the VoiceThread Universal at https://psu.voicethread.com/universal/

Note: Some screen reader testers have usability issues. Therefore, a blind student may still need additional support. Contact Penn State VoiceThread or the Office of Disability Services if a student reports a problem.

WikiSpaces (Confluence)

Note: These instructions are written for the Confluence 4.3.2 platform at the Penn State Wikispaces service.

Synopsis

WikiSpaces, also known as Confluence, is a valuable tool for sharing collaborative online material, and includes tools that enable users to create reasonably accessible documents.

This page contains some general guidelines for making your WikiSpaces content more accessible, with a link to more detailed information at the end.

  1. For long documents, use the Heading styles (Heading 1 through Heading 6) to break passages of text into multiple sections.
  2. Use one of the list tools to create lists, instead of inserting list items manually.
  3. Make sure that any hyperlink text clearly describes its target page.
  4. All images, except those used for purely decorative purposes, should be equipped with alt text.
  5. Data tables should have a header row, each cell of which should clearly describe the content in the corresponding row or column.
  6. If you change the text color, ensure that there is sufficient contrast between the text and the background.
  7. Ensure that all files attached to your WikiSpaces document are as accessible as possible.
  8. A table of contents can help users navigate your document quickly, in addition to providing a preview of its content, both of which enhance its general usability.

Headings

Specifying headings helps screen reader users quickly identify the sections of a page. Page titles should be formatted with the Heading 1 option found in the drop-down Styles menu. Likewise, main section headings should be formatted with the Heading 2 option, and subsection headings with Heading 3.

The WikiSpaces Styles menu

Top of Page

Lists

Use the list tool to create bulleted or numbered lists, instead of manually inserting bullets, numbers or asterisks. As with headings, this tool enables screen readers to process list items more efficiently.

Numbered lists with multiple levels should use a different numbering scheme on each level. For instance, if the topmost level uses "1, 2, 3," the next level should use "a, b, c."

WikiSpaces list tool

Alternatively, you may use keystrokes to add various lists to your Wiki page.
Press all the keys simultaneously and then type you content. Hitting RETURN once will continue the formatting list to the next item. Hitting RETURN twice will stop the list formatting of the list and your content will be formatted normally once, again.

Key Strokes

Bulleted List: Control, Shift, B
Numbered List: Control, shift, N
Check boxes: [ then ]

Top of Page

Hyperlinks

Screen reader users often scan a document for hyperlinks, so it is important to make sure your links make sense without their surrounding content. For example, a link should say "Readings for the week of February 14" rather than "Readings for the week of February 14. Click here." Use the Insert Hyperlink tool to create a hyperlink in WikiSpaces.

WikiSpaces Link tool

Top of Page

Images

Images, charts and graphs must have a description so that someone unable to see them will understand their purpose and content. This is what is known as alt text. Descriptions of images should be limited to approximately 20 words or 155 characters. Charts and graphs may require longer explanations.

Currently in Wiki Confluence 4, Alt Text can only be added in one manner, through the open source editor.

  1. Select the Open Source Editor tab.

    Open source button

  2. Look through the code and determine where in the content you would like to place the picture with alt text.
    Hint: use the search bar and find content prior to where you would like to place the picture.

    Source Editor Find field

  3. When you find the image code, you will add the alt text information directly to the code. Note: This does not match HTML code. The jpg file will appear between <ac:image> <ri:attachement ri:filename=” Place jpg file here “/> </ac:image> (Use code instead of image)
  4. You will add the alt image information after <ac:image
  5. The alt text will be typed as ac:alt=”ALT TEXT HERE” ac:title=” title of picture”>
  6. And be sure to place the ALT Text before the <ri:attachment ri:filename= “jpg file”/>. Use code instead of image.

Example of coded with Alt Text:
example of Wikispace with Alt Text code inserted
Note: Be sure to use Quotation marks to close off content the same way it is done in HTML. And, add the title of the picture.

Top of Page

Tables

It is helpful for screen reader users if tables are equipped with a header row (runs horizontally at the top of a table) and a header column (runs vertically along side the table) that describes the data in each column and allows for cross referencing data. This provision will help screen readers organize the table's content so that it can be read in a logical order.

When inserting a table, WikiSpaces 4 automatically creates a Header Row in the top row, running horizontally to identify items in the columns. To add a table without a header row you must hold SHIFT key down while create one without.

insert table button with heading instructions

Also, the “Scope Tag” is an added feature in WikiSpaces 4. This means your table can now have and identifying header running vertically, known as the Heading Column, to cross reference complex data.

To add Headers to table:

  • Place the cursor in the row or column of the table that you wish to highlight as a header.

     example of cursor placement to input headers into a table

  • To insert a heading row click on the tab in the table toolbar with highlight the top row.

    Row highlight button circled

  • To insert a heading column, use the tab in the table toolbar with the highlighted column.

    column highlight button circled

  • Done.

Note: To remove these tags, do the same steps to remove the highlighted areas.

Top of Page

Color Schemes

If you change text color, ensure that there enough contrast between the text and the background. If too little contrast is provided, colorblind or low vision users may have difficulty reading the content. Certain color combinations (often those with bright colors) can even cause headaches for some users. You can alter the color of the text in the tool bar with the More Colors button.

example of expanded more colors button for text

Top of Page

Attached Files

All files attached to WikiSpaces pages should be made accessible. See the Accessibility and Usability Guide's pages on Microsoft Word, PowerPoint, and PDFs for more information creating accessible documents.

Top of Page

Creating a Table of Contents

Adding a table of contents can help screen reader users navigate your document quickly and easily, in addition to making the page more generally usable by providing a preview of upcoming content. You must designate headings to generate a table of contents, as these are what is used to determine the sections of the document.

To create a Table of Contents in WikiSpaces, select Table of Contents from the drop-down Insert menu.

Selecting the Table of Contents option from the drop-down Insert menu

Top of Page

Yammer

Yammer is a communication tool in supports discussion and groups for discussion. Each group also supports file upload and notes.

Screen Reader Accessibility

The basic functions of Yammer are accessible to screen readers, but some screen reader testers have reported usability issues with certain advanced features.

Therefore, a blind student or staff member may still need additional support. Contact the Penn State Yammer service or the Office of Disability Services if a student reports a problem.

Yammer E-mail Feed

Yammer includes the ability to send messages to a user's e-mail. This can mitigate some issues, but note that not all content is sent directly to e-mail.

To activate feeds, users can visit their Notifications page at https://www.yammer.com/account/notifications. Note that login may be required.

Multimedia Tools (Audio/Video/Animation)

Below is information for accessifying audio, video (including captioning) and animation.

Video Captions and Audio Transcripts

Synopsis

  1. If you use audio files on your Web page, a text transcript or other text-based material should be provided.

    WCAG 2.0 Guideline 1.2.1—"An alternative for time-based media is provided that presents equivalent information for prerecorded audio-only content."

  2. If video files are used, captions or a synchronized text transcript should be provided.
    NOTE: Captions also benefit non-native speakers, users with audio disabled or viewers watching a video with poor quality audio.

    WCAG 2.0 Guideline 1.2.2—"Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such."

  3. Video files should be embedded or displayed in a player that can be accessed by a screen reader via keyboard commands. Accessible players include QuickTime, RealPlayer, iTunes, YouTube and properly configured JW Player.

    WCAG 2.0 Guideline 2.1—"Make all functionality available from a keyboard."

  4. Videos that include visual information critical to comprehension should include a description of events or images for visually impaired audiences. For example, a screencast of a software product should name the buttons and commands being used, not just say "click here".

    WCAG 2.0 Guideline 1.2.3—An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media, except when the media is a media alternative for text and is clearly labeled as such.

  5. A lengthy piece of audio or video should not be played by default when entering a page. Instead, the user should be able to click the play button to start the file. This provision prevents audio from interfering with screenreader audio.

NOTE: Transcripts are also beneficial to users who may not be able to access audio on their computers. This is a very frequent situation.

Top of Page

Accessible Audio/Video Examples

Audio Transcript Example

The following paragraph includes a link to a podcast and also to its transcript as a separate link.

Podcast on Knowledge Commons

Podcast Audio (MP3) | Text Transcript

Accessible Video File with Text Transcript

Instructor Interview

The following interview with Prof. Nuria Sagarra is captioned. You can access captions by clicking the arrow button in the lower right corner of the screen.

Image of Nuria Sagarra with caption 'It's a no brainer really.'

Additional Examples

Simply Speaking Computer Technology Videos

Top of Page

Captioning Tips and Tools

  • Download a free eBook: Get Started with Video Captioning, a beginner's guide to video captioning. Discusses why you should caption video, different caption formats, helpful software, and captioning style guidelines.
    - iBook Version
    - PDF Version

  • Many popular media players such as Quicktime Pro, Flash Video (including YouTube), Real Player and Windows Media include captioning options. In many cases, captions are stored in an external text file, which can be easily edited.
    NOTE: It is recommended that you do a Google search to determine the latest captioning options.

  • If you have a script for an audio or video production, it can be the basis for a text transcript. Otherwise you may need to manually transcribe the text.

  • Speech recognition software such as Dragon Naturally Speaking can automate some transcription, but should be reviewed for errors, especially when low-quality audio or unusual words is/are used.

  • Avoid having an audio or video file play automatically on a Web page. Such a feature is potentially distracting for some users, and could interfere with speech recognition software.

  • Visually impaired users may need additional information about images in a video.

  • Top of Page

    Captioning Software and Providers

    Captioning Software

    Penn State supports MovieCaptioner (Mac and Windows) from Synchrimedia. This tool supports many captioning formats and can create transcripts as well.

    A free license is available to Penn State faculty and staff by request. Students may use MovieCaptioner in the Mac labs on campus, but personal copies cannot be distributed due to the sheer volume of requests that could entail. Faculty and staff may contact the Penn State Synchrimedia Contact for more information.

    Captioning Providers

    These are some vendors who provide captions for a fee:

    There are also local providers near many campus locations.

    Top of Page

    Audio Descriptions for Blind Users

    For the visually impaired, the audio of many videos, particularly interviews, is sufficient for such a user to understand the content.

    In other cases, supplemental descriptions of visual content within the video may be needed for the audience to understand the context of the audio. Examples include descriptions of charts, graphs, software screenshots, or an action-filled video.

    See the Audio Description for the Blind page for more information.

    Top of Page

Audio Transcript Example (Knowledge Commons)

Back to Caption Information Page

Jamie Oberdick:

For Teaching and Learning with Technology at Penn State, this is Jamie Oberdick with the February edition of Conversations, the Senior Director Eye View of Education Technology at Penn State

For our conversation this month, I talked to Cole Camplese, senior director of Teaching and Learning with Technology, about how technology has changed libraries. Libraries are not dead because of technology, far from it, and proof of this can be found in the new Tombros and McWhirter Knowledge Commons in Pattee Library. The facility combines learning spaces and technology to create a cutting edge educational facility.
I talked to Cole about a class he is teaching in the Knowledge Commons with his colleague and Penn State faculty member Scott McDonald, the role of libraries in the modern world of education, and even how technology is making the library a much more active and yes, noisier place.

Jamie Oberdick:

Okay, I'm here with Cole Camplese. Cole, talk a little bit about how the class you are going to start teaching and where you will teach it, because that's also quite interesting.

Cole Camplese:

It is interesting. Okay, the class I am teaching, and I co-teach it with Scott McDonald, who's an associate professor of science education and curriculum instruction. He's also the director of the new Innovation Studio in the College of Education, which is a really interesting endeavor which in a future podcast maybe we can talk about.

So the class is - they changed the number on us this year, it's now CI598, it used to be CI597. It's called Disruptive Technologies for Teaching and Learning, and it's a graduate seminar. In the past we've had 24 students, last time we had 18. Interestingly enough we have eight students enrolled this time, so it's interesting because it's forced us to rethink our design. Because we've always done these big team things where you can have four or five different teams working on projects, but now we are only going to have two teams.

We were going to be teaching in Chambers, in the new Innovation Studio classroom, but there were some problems with the air handlers, so we won't be able to be in that classroom until Spring Break. Which sent us scrambling at the last minute because we have some unique technology needs. It's not like we need all the students to have computers in front of them all the time, because the class is really more about community identity and design and reading and discussing and things of that nature. But we do talk a lot about technology and we needed some things, but we couldn't find a classroom.

We ended up asking folks at the University Libraries if we could use the new classroom in the Knowledge Commons. Which is in the Pattee side of Pattee-Paterno Library. It's beautiful. If you've not been over there, you've got to go. I was there yesterday to get a tour of the classroom and everything. TLT has invested amazing time, energy, effort, and resources into it. I mean ITS in general. This has truly been an amazing partnership with the libraries.

We walked into the classroom yesterday and it's really wild. The classroom is designed very differently. The interesting thing is the class is also going to do an expose on and really expose the notion of physical learning spaces as it relates to the confluence of technology and its influence on community, identity, and design. And design specifically around teaching design.

So, what's crazy is you know we've been watching over the last 6-12 months the Occupy Wall Street movement. And Scott and I started to think; last semester there was an article right at the beginning of the semester from Onward State that listed the ten worst classrooms on campus. And so Scott and I started thinking about that and started thinking about the context of Occupy Wall Street. We started to think about how could we have our students switch from focusing exclusively on the connections between technology and disruptive technologies, emerging technologies and their relationship
to community and identity and design, over towards physical space. So virtual space is part of the teaching and learning environment, but traditionally and historically, physical space has been a bigger part of that.

And so, we've decided we have a big component of our class that starts in the fourth week called Occupy Learning. What we've done is we've identify what we thought were the 10 worst classrooms on campus, and the 10 largest classrooms on campus, and we're sending our students out to collect artifacts about those rooms. To do observations around what kind of teaching goes on in those rooms; talk to students and interview them, audio and video; talk to faculty via audio and video; take photos of them; and write little mini reports.

So all these rooms will have their own little mini report. And then they will be placed on a map, geo-tagged, all these little artifacts, like digital posters if you will. And then teams will have to talk about those, what they learned and about this space design, and how it influences what kind of learning and what kind of teaching goes on these environments. So we've taken our traditional course, which has always been very heavy on the research side and the readings and the conversations always have been very high level, then we mix technology in there. We are also going to add in there this idea of physical space design and how it influences teaching and learning. It's going to be a relatively ambitious but really engaging experience.

Jamie Oberdick:

Was this something that the University itself kind of looked at and maybe learned more about how we can redesign these spaces?

Cole Camplese:

So, as you know at TLT we have Classroom and Lab Computing, so we have heavy influence in what happens in our classroom and labs. And one of the things....I sit on UCIF, the University Committee on Instructional Facilities, and one of the things we are talking about doing is taking these final reports and inviting UCIF members to them. So they can see first hand graduate students dissecting these learning environments and talking to us about what kind of pedagogy do they support, what kind of activities they support, what kind of teaching practice they support, what they could be thinking about to challenge the traditional notion of the classroom.

So I think it's really going to be kind of interesting, it's a little risky for me as someone who is an administrator and I am actively promoting the critique of the environment that I myself design and oversee. But I think it's a critical step for thinking about what comes next. When I came into this position a year ago, I sat down with Kevin Morooney, our CTO and vice provost of information technology, and I asked him what are the 3-5 things I need to focus my energy on. Basically, what do I need to do to not lose my job.

The items on the list really surprised me. Course management system was one of them, keeping that active, engaging, and running. Printing - thinking about where printing goes. Printing is a huge cost for us. It's also becoming an outmoded approach. You talked to a student of ours, Zack, about the iPad and the way he used an iPad to overcome just an unbelievable amount of printing costs. So printing was one of them. What was interesting was Kevin wanted me to have a plan for 3-5 years - what does the computer lab look like? What does the classroom look like? Should we be continuing to put 200 Windows machines in a big room where everyone sits down to do work. We're not sure about those things.

So part of the idea of this class is to help inform my own practice. So, you hear a lot of people say my research is my teaching, but also in this case, the teaching becomes a component of the research and it informs practice. And it's really the reason why I continue to teach. I mean, I literally have no time to teach, but if I didn't do it, I would lose touch with what's really going on inside the classroom. So of course it informs. Every time I teach I learn something new about what it is I do here at the University well, and I learn probably 50 different things about what we do here at the University poorly, and we actively work to address those things.

I think there's no better way to that than firsthand. We do a lot of surveys here. But in my mind a survey never really contextualizes challenges and issues that you have the respondents reporting. You know what I mean? You have to live it. I can remember you going to visit different parts of campuses for different stories you're working on, and saying "that's incredible, I can't believe we do this at Penn State." But you don't get that unless you actually go out and talk to the people who designed the space. Or live in the space. And the same holds true for our teaching and learning environments.

Jamie Oberdick:

Now, one thing - speaking of environments, the class that Scott and you teach, is in a really interesting environment. Talk a little bit about that.

Cole Camplese:

Well, it's in the Knowledge Commons classroom. Interesting, we partnered with the Libraries on this space. Chris Millet, a member of Education Technology Services and a member of the design group that put it together, the room really supports different types of classroom activity. The room is organized in an X - there's no fixed podium in the room, so it's very very different from what we're accustomed to. It has a movable podium in the front, it's organized in an X - there's five screens in the room you can project to, so there's always a view.

So, if you think about an "X" and I'm the instructor and I am standing in the middle, in a traditional room there would only be projection in front. But now if I'm sitting in X and I'm looking to the middle there are screens behind each leg of the X as well as the middle so no matter where I'm sitting, I'm looking at both the instructor and the content that's being presented. Whiteboards all around the room, so the idea is to break people off quickly, talk about a topic, and say okay, let's move from passive mode to active mode. Turn your chair around, there's a wall of whiteboards there, I want you to organize that. Then there's a screen right next to you so you can hit a button and switch and show what you want to show over there. So you move students very quickly from sort of passive engagement to active engagement.

And so part of what we are trying to do, Scott and I, it's funny because we have librarians who are going to sit through the class to observe the kinds of practice we use in the room. To see how we actually take advantage of the design of the physical space. Because this space is designed pretty much around the concept that Steelcase has been talking about for many years, and that's this sort of active classroom engagement. I traveled to Steelcase with Scott last spring, and we sat through a demonstration of how you would actually take advantage of this space. It was really intriguing to watch this master teacher, who understands this environment, go from lecture to having his students engage in an action to bringing them back together to mixing up their teams, everything movable. The chairs are on wheels so you can move around quickly.

It's a radical departure from what we typically do. What we typically see is, Jamie, you're the instructor, you stand in front of the room at a podium in a position of power, you click your mouse button and you change those slides up there. Now we're going
in this whole different direction. The other thing the room has is a computer that can project but then there's an iPad in the room. And the iPad is really a giant remote control for the computer. So not only can you run your slide show from there, but if you try to imagine that my iPad has the same screen as the Mac on the podium does. And so, I can tap on Safari, and it doesn't launch iPad Safari, it launches Safari on the room machine. Then I can tap a toolbar and it comes down so I can choose different tools. So that I can annotate the Web if I want to.

I can play a Youtube video and I can say okay now what are the five biggest things that we took away from this. And right on the Safari screen I can write on the video and then record that, and play that back as a standalone movie if I wanted to. So I can embed that into a blog space or ANGEL or something like that. We don't quite yet know the full affordances of the classroom but that's going to be part of the fun. So we have this emphasis on space design and disruption and all these other kinds of things. And we're going to be in this room that no one's ever taught in before.

I mean, Scott and I were in the room and we stayed an hour after our meeting yesterday from 5 to 6 to do some design work on the course, and it was sort of kind of crazy because we were like, man, we're the first people to write on these whiteboards. So we are breaking this room in while at the same time retraining our own brains around the kinds of teaching practice that we are going to engage in at this space. We're looking forward to it. It's going to be a big challenge but it's going to be a lot of fun.

Jamie Oberdick:

That's really interesting to me that change in the room design is so radical that it's helpful to be in the classroom to do the planning. That's pretty unusual.

Cole Camplese:

That's a really interesting insight, you know, I never thought about that until you just said that. But Scott and I needed to be in that room to be able to chart how we are going to address some of the challenges. Just because there are screens everywhere doesn't necessarily mean you want to use them all. And so we were even talking about okay, where do we think we are going to position ourselves in this room. Because even in our previous semesters when we taught in 236 Chambers which is a departure from rows, but it's a U-shaped room. Scott and I always sat up at the front right of the classroom and didn't really stand up and present. We just sat and talked.

This room challenges that notion. Even being in that room we thought about how we are going to structure the physical location. Where did it make most sense for Scott to set up relative to me, relative to the eight students in the room, relative to how we have two librarians, Chris Millet and his GA are going to be there to watch how we are going to use the space. We have Ryan from the Media Commons who is going to be there watching and observing. So not only do we have the eight people in the class, we have at least another five people who are going to be like these somewhere between active and passive participants. What's funny is Chris Millet took this class when I taught it two years ago, so Chris has been through this class. So, I'm personally curious to see if he can control his urge to participate in the class. We invite people to participate. I'd love to have 20 people in the class, it's just that we have eight.

But we're going to be using online tools as well, we'll have a Twitter hashtag, we'll be Tweeting out different things and people can follow along.

Jamie Oberdick:

It's a great mashup of virtual and physical.

Cole Camplese:

That's the goal. We'll see.

Scott and I always have called this class the grand experiment. Every semester something blows our mind. And every semester we learn so much by going through this

Top of Page

Animations

Synopsis

  1. Animations needed to present content should also include a non-animated, text-based alternative that is accessible to screen readers. Text with still images can also be beneficial for users who have cognitive difficulties processing animations.

    WCAG 2.0 Guideline 1.1.1—"All non-text content that is presented to the user has a text alternative that serves the equivalent purpose."

  2. Avoid automatic or looped animations, blinking objects and scrolling. These items are distracting and, if incorrectly implemented, could trigger epileptic seizures or headaches for some users.

    WCAG 2.0 Guideline 2.1—"Provide users enough time to read and use content."

    WCAG 2.0 Guideline 2.3—"Do not design content in a way that is known to cause seizures."

  3. Animations with sound as a crucial component to the content should have synchronized captions or a text transcript.

    WCAG 2.0 Guideline 1.2.2—"Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such."

Top of Page

Audio Description for the Blind

Audio Description is either live or recorded information, provided by a trained describer that provides descriptions of visual components of an event to become accessible to those who are blind or of low vision. This information is not provided with the normal recording or live performance, yet is synchronized as not to interrupt the primary event.

Sample online Videos:

Documentary

Self-Driving Car Test: Steve Mahan  -Audio Described

Presentation with Audio Description

HTML5 video accessibility and the WebVTT file format - Audio Described
(Edited to input pauses time 33:25)

More examples from the American Council of the Blind can be found at
http://www.acb.org/adp/samples.html

Other Venues:

Audio description is used in various venues. Either live or recorded, audio description is a science and an art form. Live descriptions take place in theatres with live performances and essential information about the stage environment, look of the performers and movement, be it a clenched fist or a beautiful gesture of a dancer. With recorded audio description, media allows us to offer a rich alternative to just the visual images in video. A recorded presentation may be paused and slides explained in detail, describing an animation or documentary could benefit everyone universally.  

The rest of this page will focus on audio description for recorded video

Top of Page

When do you need it?

When to use audio description could be a subjective standard. When deciding to use A.D. consider the description from the listeners’ perspective and if the description could enhances the video production for everyone.
Here are some examples:

  • A newscaster who introduces themselves and the stations at the beginning of a video, delivers news of the day without any visual support during the cast is, plainly put, a talking head. In this situation, you need not describe a talking head, as it does not add to the content.
  • An animation of cells dividing in their various stages needs to have audio description. Depending on the narrator’s explanation, an audio describer may offer a more detailed and helpful description of what is visually occurring in the video.
  • Another example is a video explanation of a math equation.  In the math tutorial example, audio description of each step maybe needed depending on the detail of the instructor’s explanation.  Specifically, to supplement if instructor does not sufficiently describe written steps.
  • Now, recordings of presentations may need post-editing to offer detailed audio descriptions of slides.

Use your best judgment.

Top of Page

Techniques

Basics:

There are basic techniques to audio description.

  • Use of Natural pauses in existing soundtrack to insert descriptions of visual elements such as actions, settings, appearance of characters, body language, costumes, lighting, and on-screen text.
  • Offer good description when no audible indications are offered.
  • Describe what is seen and do not interpret and try to describe objectively.
  • Keep language consistent.
  • Do NOT censor the material.
  • Provide a separate script and record to a separate audio track.
  • If possible, allow the narrator’s voice to compliment the video. An appropriate tone should be used based on the levity of the topic. If possible, use a voice to compliment the topic being Audio Described.
  • A trained individual is recommended to narrate and/or write the descriptions.

You can find extensive and detailed written examples of audio description at:
http://www.audiodescriptioncoalition.org/index.html
Or download a PDF copy at: http://www.audiodescriptioncoalition.org/adc_standards_090615.pdf

Logo

Title: Audio description logo sample - Description: http://www.acb.org/adp/ad.html  Title: Audio description logo - Description: http://www.acb.org/adp/ad.html  Title: Audio Description logo - Description: http://www.acb.org/adp/ad.html

The three logos are samples of Audio Description logos offered for use by American Council of the Blind. These logos are free for you to download and use at http://www.acb.org/adp/ad.html.

Top of Page

Vendors

Selecting a vendor to record your Audio Descrprition is dependent on your venue. So, remember to select the right vendor for the right occation or based on their service specialty.

The WGBH Media Access Group provides information on Web Video captioning and video description service at:
http://main.wgbh.org/wgbh/pages/mag/pdfs/marketing_web.captioning.pdf

Furthermore, the ACB (American Council of the Blind) maintains a list of other services involved with Audio Description at http://www.acb.org/adp/services.html

NOTE: Pennsylvania State University does not endorse or recommend any of the vendors that provide Audio Description Services or Training. This list is only an example that audio descriptive services and training are available.

Top of Page

Caption Workflow

This page describes some tips for making the creation of a captioned video or podcast more efficient.

Before Shooting a Video

Script and Storyboard

The most time consuming step of creating a caption is recreating a transcript (i.e. transferring audio dialogue to text). If a video or audio project can be scripted ahead of time this script can become the basis of a transcript. The other advantage of developing a script is that the performers may read the words more smoothly.

This process will not work for interviews, but even knowing and writing down which questions to ask may make the transcription task easier in the long run.

Good Audio Quality

Ensuring good audio quality during recording is another way to make obtaining a transcript easier. Anyone listening to a video or audio after the fact will have a better chance of understanding the content, and this can speed up the transcription process. It can also facilitate a process using speech recognition.

Getting the Caption

When Does Speech Recognition Work?

In an ideal world, one could run a video through a speech recognition system like the YouTube "Automatic Caption" system or the Dragon product lines (many available through the Penn State Computer Store). Unfortunately this level of speech recognition does not yet exist, so the use of speech recognition needs to be considered carefully.

Speech recognition works best under these two conditions:

  1. When the system is familiar with one speaker's profile. This can be effective when:
    1. The same speaker (e.g. an instructor) makes a number of recordings.
    2. A videopgrapher repeats the words of a video into a speech recognition system
  2. The other scenario is when the system is working with a limited vocabulary. This is how speech recognition-based phone support is developed. As many users may be aware, these systems can be easily stymied when a speaker strays outside the vocabulary set, is upset or does not speak with a standard English accent.

When neither of these conditions are met, the general results of processing an audio track through speech recognition are typically too poor to be usable. Even correcting the files may be more time consuming than creating a transcription from scratch.

Top of Page

Manual Captions

If a pre-made transcript is not readily available, the following options are available.

Captioning Vendors

These are some vendors who provide captions for a fee. Although the fee is not inexpensive it is a good solution for departments who need reliable service, rapid turnaround or do not have personnel to provide manual captions.

Top of Page

Captioning Tools

Another method that always works to create a transcript is to listen to the audio and transcribe the words. The skills needed for this are essentially typing skills. Expect that a typist will take approximately 2-4 hours per one hour of video to produce a transcript based on typing speed, familiarity with the content and quality of the audio.

A captioning tool such as MovieCaptioner (Mac/Windows) can facilitate the process in a variety of ways.

  • MovieCaptioner requires minimal training
  • MovieCaptioner works on Mac or PC
  • Captions can be exported for multiple platforms
  • Scripts can be imported into MovieCaptioner for edits.

Top of Page

Live Caption

A third way to create captions is to hire a live captionist to transcribe events as they happen and are being recorded. Although the cost is similar to hiring a captioning vendor, the benefit of this option is that it allows Deaf participants to participate in an event as it occurs live.

This service will also result in a transcript which can be included an a recorded video as a caption.

Top of Page

Copyright for Someone Else's Video

If a course or Web site is interested in linking to or embedding a video made by someone else, then copyright can be a factor. If the video or audio content is crucial, then consider these following options.

  • Request permission to caption and provide the caption to the owner.
    Note: This can be very effective for many amateur YouTube videos. See Template Permission Letter (Courtesy of the Dutton e-Education Institute, College of Earth and Material Sciences)
  • Buy a transcript of the program. Many news and educational programs offer a transcript for sale.
  • Link to a transcript. Song lyrics and transcriptions of notable speeches, scenes or videos may have been created and posted on other Web sites.
  • If using a DVD, check for "English Subtitles". In some cases, it may be possible to a create a streamed video with the subtitles permanently on display as captions.
    Note: This option applies to videos licensed by the TEACH Act or to those to which permission to stream has been granted.

Top of Page

Flash Files

HTML Versus Flash

Flash is a well-respected tool able to deliver interactive components to multiple browsers and platforms, but can be problematic for screen readers and mobility impaired users. Although Macromedia is committed to providing tools to develop accessible Flash tools, ensuring Flash accessibility can be difficult.

Tip: HTML Shell, Flash Objects

Although many developers create entire modules in Flash, including navigation functions, it may be easier to maintain the navigation, text and images in HTML and use Flash only for key animations, interactive activities or multimedia elements (audio/video).

When navigation is in HTML, options for accessibility are generally easier to implement.

Synopsis

In order to make Flash files more accessible, consider these recommendations:

  1. Whenever possible, start animations and movies in pause mode, then allow the user to start and stop them as needed. Avoid endless loop animations, as they can be distracting for many users.

    WCAG 2.0 Guideline 2.2—"Provide users enough time to read and use content."

  2. Link to an XML caption file for Flash video whenever possible. See Flash documentation and tutorials for details.

  3. Avoid including a full-screen automated Flash movie on a homepage, since mobility impaired users may not be able to exit, and cognitively disabled users may become disoriented. These Flash files should be started by the user.

  4. Provide keyboard alternatives for common actions, and enable tabbing in forms. For example, you can both include a zoom button and program the "+" and "-" keys for zooming in and out. See Flash documentation and tutorials for details.

    WCAG 2.0 Guideline 2.1.1—"All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints."

  5. Add text labels to all controls, form fields, labels and components so they can be identified by a screen reader. See Flash documentations and tutorials for details.

    WCAG 2.0 Guideline 3.3.2—"Labels or instructions are provided when content requires user input."

    WCAG 2.0 Guideline 4.1.2—"For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined."

  6. Flash files should follow the same principles for font styling, color schemes, blinking objects, animations and audio and video accessibility that HTML pages do. One advantage of Flash files is that images and text are vector-based, and are therefore usually zoomable.

  7. Keep text together in one object whenever possible. Screen readers may jump from text object to text object in unexpected directions.
    NOTE: ActionScript can be used to control reading order in newer versions of Flash.

  8. Minimize navigation within a Flash interface. This will minimize the amount of accessibility features needed within Flash.

Top of Page

Flowplayer: Streaming Captioned Videos

About Flowplayer

Flowplayer is a streaming video player used to embed videos in a Web site. It is an open source technology, and can be used to embed a number of different types of video files, although those in Flash format are perhaps used most frequently. Flowplayer also offers the user a large degree of customization, with the video player's appearance, the appearance of the captions, and the availability of certain functions all being configurable.

NOTE: You will need knowledge of HTML, CSS, and/or JavaScript to take advantage of Flowplayer's customizability.

Software Used in This Guide

This guide requires the use of a number of programs, all of which are available either in Penn State CLC computer labs or for free download from their respective vendors. If you're unsure whether a given lab has the CLC software package, consult the "Lab Locations" page of the CLC Web site. The availability of each program has been noted below.

Flowplayer can stream FLV files, MP4 files, and any video compressed using the H.264 standard. For an explanation of these filetypes, see the "Supported Video Formats" section of Flowplayer's documentation.

Preparing Your Video and Captions

  1. Open MovieCaptioner. Load your video by clicking the Load Movie button in the top left corner of the screen.
    The Load Movie button in the MovieCaptioner interface
  2. Create your captions. For more information on captioning videos in MovieCaptioner, see the instructional materials on synchrimedia.com, or the "How to Use MovieCaptioner" PDF within the MovieCaptioner folder, which is in your computer's "Applications" directory.
  3. Click the Export menu and select SubRip SRT. Name your .SRT file and select a location in which to save it.
    Selecting Subrip SRT from MovieCaptioner's Export menu
    NOTE: This is the file that contains your captions.
  4. Place the video file and the .SRT file on your Web server. Its exact location doesn't matter, but it's generally easier if it isn't inside a number of sub-folders, since you'll need to type out its path later on.
  5. NOTE: If you're looking to stream the video on your personal Web space (e.g. personal.psu.edu/xyz123) and need more information on uploading files, see the ITS Knowledge Base article "PASS: How do I upload files to my personal web space?"

Embedding Your Video

Before you can stream your captioned video, you will need to include a few elements in the source code of your Web page. If you're using the Blogs at Penn State or another content management system, be sure that you've selected HTML markup as your method of input, rather than rich text or another format.

  1. If you haven't already, download the free version of Flowplayer from the Flowplayer download page.
  2. Find the .zip file that you downloaded and decompress it. In most cases, the proper program (e.g. WinZip, Archive Utility) will open by double-clicking on the .zip file, which will then be automatically decompressed.
  3. After decompressing, you should be left with a folder called "flowplayer." Open the folder, and then open the sub-folder called "example." Find the file flowplayer-3.2.6.min.js. This file contains the Flowplayer API, which gives your browser the various commands that Flowplayer will be executing.

    NOTE: The exact series of numbers in this filename and others may change as new versions of Flowplayer are released.
  4. Place flowplayer-3.2.6.min.js on your Web server in a location that's easy to remember. For this guide, all of the Flowplayer-related files have been placed in a folder called "flowplayer."
  5. Just as you did with the API file, find the files flowplayer-3.2.7.swf and flowplayer.controls-3.2.5.swf and put them on your Web server. These files contain the specifications for the video player itself.
  6. In your HTML document or content management system, put the location of the API file between the <head> tags. For example:
    <script src="flowplayer/flowplayer-3.2.6.min.js"></script>
    Remember that this guide is placing the Flowplayer files in a folder called "flowplayer," but that you need to specify the exact location that you decided on. Also note that the file path is not the complete URL of the file, it is just the location of the file relative to the location of the Web page in which you’re embedding it. If you need more information regarding file paths, see Flowplayer's installation guide.

    If you're using The Blogs at Penn State, you'll have to put the above code in the header.tmpl module, or use the alternate method described in the Movable Type article "Including Custom Javascript or CSS in the Header."
  7. Next, in the body of your document, you need to provide a link to the video you're streaming using <a> tags. This guide is using a video called "test.flv."
    <a href="flowplayer/test.flv" style="display:block; width:425px; height:300px;" id="player"> </a>
    Be sure to enter the exact location of your video in the href field. If you want your video be a certain size, specify the width and the height in the corresponding areas, but be sure to preserve the aspect ratio.
  8. Directly following the link discussed in the previous step, enter the code:
    <script language="JavaScript"> flowplayer("player", "flowplayer/flowplayer-3.2.7.swf"); </script>
    This points your browser to the location of the script that creates the video player itself. Again, be sure to enter the exact location you chose for the flowplayer-3.2.7.swf file.

Embedding Your Captions

  1. If you haven't already, download Flowplayer's Captions plugin and Content plugin. These plugins allow you to embed a standalone caption file for your video, and will control the way that the captions are displayed.
  2. Find the two .SWF files that you just downloaded. They should be named flowplayer.captions-3.2.3.swf and flowplayer.content-3.2.0.swf, respectively.
  3. Place the files on your Web server.
  4. Back in your HTML document or content management system, place the following code after the code you added in the previous set of instructions:
    <script language="JavaScript">
    $f("player", "flowplayer/flowplayer-3.2.7.swf", {
    clip: {
    url: "flowplayer/test.flv",
    captionUrl: "flowplayer/test.srt"
    },

    plugins: {
    captions: {
    url: "flowplayer/flowplayer.captions-3.2.3.swf",
    captionTarget: 'content'
    },

    content: {
    url:"flowplayer/flowplayer.content-3.2.0.swf",
    bottom: 5,
    height:40,
    backgroundColor: 'transparent',
    backgroundGradient: 'none',
    border: 0,
    textDecoration: 'outline',

    style: {
    body: {
    fontSize: 14,
    fontFamily: 'Arial',
    textAlign: 'center',
    color: '#ffffff'
    }
    }
    },
    }
    });
    </script>
    Each section of this code performs a different function—for example, the clip section specifies the locations of the video and its caption file, while the captions section specifies the location of the Captions plugin file and points to the content section for information on displaying the captions.

    There are multiple instances of file paths in the code above, so remember that you'll need to change each one to reflect the locations of the files on your Web server.
  5. View your video to ensure that it and its captions were embedded correctly. For additional support and troubleshooting tips, see Flowplayer's documentation.

Top of Page

ITS Streaming: Uploading Captioned Videos

About ITS Streaming

ITS Streaming is a service offered by Penn State that allows students and faculty to upload audio and video content for streaming online. It is a convenient way for those within the Penn State community to share such materials, whether the intended audience is a course's students, all Penn State users, or simply anyone with an internet connection.

Because the accessibility of Web materials is a constant concern here at Penn State, it is important that any videos uploaded with ITS Streaming be captioned if there is a possibility of the audience including users with hearing impairments, or for whom English is a second language (see the "Video Captions and Audio Transcripts" page for more information on accessifying video content). This guide outlines the steps necessary to upload captioned videos to ITS Streaming, and for setting the proper permissions for uploaded videos.

NOTE: This guide requires the use of MovieCaptioner and QuickTime Pro. Both programs are available on any CLC Macs in Penn State computer labs. If you're unsure whether a given lab has this software, consult the Lab Locations page on the CLC Web site. Keep in mind that other captioning solutions do exist, such as the many captioning services employing human transcriptionists, but that these methods will incur additional fees. Captioning services may be ideal, however, when a quick turnaround time is necessary.

NOTE 2: To purchase QuickTime Pro, first download QuickTime 7 then upgrade to the Pro version.

Saving a Captioned Video File

  1. First, create your captions in MovieCaptioner. For instructions on using MovieCaptioner, see MovieCaptioner's tutorial page or the "How to Use MovieCaptioner" PDF in the Applications folder on your computer.
  2. In MovieCaptioner, go to the Export menu and select Embedded Quicktime.
    Selecting the Embedded Quicktime option in MovieCaptioner's Export menu
  3. The video should open automatically in QuickTime. Once it does, go to the File menu and select Export.
    Selecting the Export option in MovieCaptioner's File menu
    NOTE: By re-exporting the video in QuickTime, you are essentially combining its video track and text (i.e. caption) track. These tracks need to be combined in order for the captions to be preserved in the streaming video.
  4. The Save exported file as... menu will open. Enter a new file name and/or location for the video (if you wish to change them from the defaults), and ensure that the Export drop-down menu has Movie to QuickTime Movie selected.
    Preparing to re-export a movie in QuickTime, with the Export option set to Movie to QuickTime Movie

  5. Click on the Options button next to the Export drop-down menu. In the Video section, select Settings.
    The Movie Settings menu, with which you can choose your movie's quality and its compression type
  6. Make sure that the Compression Type is set to H.264 and that the Quality slider (under the Compressor section) is set to High or Best. Likewise, make sure that the Encoding is set to Best quality (Multi-pass).
    NOTE: These settings will optimize the video for the combination of the video and text tracks.
  7. Click OK. Back in the Movie Settings menu, click OK again.
  8. You will be returned to the Save exported file as... menu. Click Save.

Uploading a Captioned Video

  1. Go to the ITS Streaming Web site and log in. You will be taken to the QuickTime Streaming Server Interface.
  2. Click on Upload Movie near the top of the page.
    The Upload Movie link in the QuickTime Streaming Server Interface
  3. Enter a title for your video in the Movie Title field, then find the video you just exported on your hard drive or server space by clicking the Browse button next to the Movie File field. If you wish, you can also enter a description for your video in the Movie Description field.
    Adding a title and description to the video
  4. Click Upload Movie. You will be given a message saying that the video was successfully uploaded, and that you’ll receive an email when the video is ready to view.
    NOTE: ITS Streaming will automatically create three versions of your video—one full size, one "blog" (i.e. medium) size, and one small size. Each version is particularly suited for certain purposes and/or audiences. For instance, the "blog" size is ideal for blogs, and the small size is ideal for viewers with slow internet connections.
  5. Assuming all of the steps were followed correctly, all three versions of the video should show up (with captions) in the Manage Movies section of the QuickTime Streaming Server Interface. View the videos to ensure that the captions were preserved in the uploading process.

Setting a Video's Permissions

By default, the videos you upload will only be viewable by you, but this can be changed to suit your specific purposes. To change a video's permissions:

  1. In the Manage Movies section of the QuickTime Streaming Server Interface, select the video for which you're altering the permissions with the Select Movie checkbox.
  2. In the drop-down menu at the bottom of the interface (which says With Selected Movies before you've made a selection) choose Change Permissions, then click Submit.
    Selecting the Change Permissions option
  3. You’ll be taken to the Change Movie Permissions page. In the drop-down menu labeled Make this movie available to, select the option that best suits your needs.
    Selecting to whom the movie should be available
    If you choose Selected Courses and User IDs, the interface will be expanded, and you can specify exactly who should be able to view the video.
    1. Instructors: You will need to choose the appropriate campus for your course(s), and will need to enter the Course Key and Section to specify which students should be able to view the video. Examples of each are provided on the Change Movie Permissions page. After entering the appropriate values in these fields, click Add Course. You can also use the Search for Courses option, which is positioned underneath the Add Course button. The sections you add should appear in the Pending Permissions field on the right side of the page.
    2. If you wish to allow specific users access to your video, enter their user ID(s) in the Additional User IDs field, then click Add User IDs. You can also use the Search for User IDs option, which is positioned underneath the Add User IDs button. The user IDs you add should appear in the Pending Permissions field on the right side of the page.
  4. When you're finished choosing your video's permissions, click the Apply Permissions button on the bottom of the page.

For more information and troubleshooting tips for the ITS Streaming service, see the ITS Streaming FAQ or support form.

MovieCaptioner: Adding Captions to Videos

MovieCaptioner is a captioning program for Mac OS X and Windows that streamlines the task of captioning video content by looping one short section of a video at a time.

In addition to simplifying the captioning process, MovieCaptioner also has the ability to export captioned videos as QuickTime movies, as well as standalone caption files in a variety of formats.

Getting MovieCaptioner

MovieCaptioner is available for free to all Penn State faculty and staff. Contact synchrimedia@gmail.com to inquire about obtaining a copy. Please use your PSU ID email and state whether you need the Mac or Windows version. Other users can purchase a license for MovieCaptioner – see Synchrimedia.com's "Buy MovieCaptioner" page.

MovieCaptioner is also available on all Macs in Penn State CLC Student Computing labs. It will be coming to Windows labs in the near future. If you're unsure whether a given lab has this software, consult the Lab Locations page on the CLC Web site.

Required Software and Additional Plugins

MovieCaptioner is a QuickTime-based program, and requires the use of Quicktime 7 Pro or later. Like MovieCaptioner, QuickTime 7 Pro is installed on all Macs in Penn State CLC Student Computing labs. The Windows version will not require QuickTime Pro, but it is still recommended. You may need other software to convert your Windows movies to QuickTime or MPEG-4 movies to use with MovieCaptioner.

Also, depending on the type of video file you're trying to caption, you may need to install some additional QuickTime plugins to ensure compatibility. Possible required plugins, all of which are available for free download for Mac OS X, include:

These plugins are not available for Windows at this time.

Creating a Caption File

If you are creating the captions for your video, you'll need to type them out in the MovieCaptioner interface. To create new captions for a video:

  1. Open MovieCaptioner from your computer's Applications folder.
  2. Click Load Movie in the top left corner of the screen.
    The Load Movie button in MovieCaptioner
  3. Find your video on your hard drive (for best results, do not use a mounted drive). Click Open.
  4. Enter a name for the MovieCaptioner project file and select a location in which to save it. Click Save.
  5. Click Start to begin adding captions. MovieCaptioner will begin looping a short segment of the video.
    The Start button in MovieCaptioner
  6. Type your first caption in the black box underneath the video player. When you're finished, hit the Enter key on your keyboard to record the caption and its timecode. MovieCaptioner will then move on to the next segment of the video.
    The area in which new captions are entered in MovieCaptioner
    Note: To force a line break in your captions, type a pipe ("|") character. Note that this only inserts a line break, and does not signify the end of a caption.
    Note 2: To change the length of the segment that MovieCaptioner loops, change the number of seconds in the field labeled Repeat Interval. However, the default 4 second loop works well in most cases.

  7. Repeat Step #6 until the entire video has been captioned.
  8. If necessary, edit your captions in the caption list in the right-hand area of the MovieCaptioner interface.
    The Caption List area of the MovieCaptioner interface

Moving Caption Text

The Editing tools provide a number of useful features, such as the Insert Caption, Split Caption, Remove Caption, and Merge Captions options.

When these tools are to move text between lines, MovieCaptioer is able to readjust time codes.

The Editing tools in the MovieCaptioner interface

Formatting Caption Text

You can also change the appearance of your captions by using the Text Properties tools underneath the video player.
Note: This only affects new captions . To change existing captions' text properties, set the options you wish to change, then click either the Change Selected Caption(s) or the Change All Captions buttons.

Text Properties windows with options for font face, size, color, and background color

Top of Page

Importing a Caption File

If you already have a transcript or existing caption file for your video, you can import it into MovieCaptioner for editing, embedding and/or exporting. To import captions:

  1. Open MovieCaptioner from your computer's Applications folder.
  2. Click Load Movie in the top left corner of the screen.
    The Load Movie button in MovieCaptioner
  3. Find your video on your hard drive (for best results, do not use a mounted drive). Click Open.
  4. Enter a name for the MovieCaptioner file and select a location in which to save it. Click Save.
  5. Click on the Import menu and select one of the file types.
    MovieCaptioner's Import menu. Includes text options, STL, Flash XML, SCC, SRT, Quicktime, YouTube Cart and others
  6. Make changes to your captions within MovieCaptioner as needed.

Top of Page

Adding Timecodes to a Transcript File

If you already have a transcript of your video but it has no time codes, you can import it to MovieCaptioner and assign each line a timecode to create captions.

Any imported text must be in a .txt file, as other types of text files (e.g. .doc, .rtf) may contain formatting information that will cause problems in MovieCaptioner. To import a transcript and assign timecodes:

  1. Click on Import and select Text in Paragraph Form or Text in Line Form.
    MovieCaptioner's Import menu
  2. Find the transcript file on your hard drive or server space and click Open.
  3. If you imported Text in Paragraph Form, MovieCaptioner will import the captions, separating them by sentence. However, if a sentence is over 90 characters, it will be broken into multiple captions. If you imported Text in Line Form, each line (again, up to 90 characters) will be a caption.
  4. After you import transcripts either in paragraph form or in line form, a Set Timecode button will appear at the top of the caption list. Click the Set Time Code button to play the movie.
    Set Time code button
  5. Click the Set Timecode button again at the end of each caption line to insert a time code.
  6. Repeat the previous step until the end of the movie is reached.

Top of Page

Exporting Caption Files

Once you've created or edited your video's captions, you can export a caption file into a separate text file, which can then be paired with the video in a desktop or streaming video player.

This option allows you to correct the text of a caption file if necessary or, in the case of YouTube, provide multiple captioning options for one video.

To export a file.

  1. Refer to your particular video system's documentation to determine which file format you need.
  2. After determining what type of caption file you need, choose the appropriate file format from MovieCaptioner's Export menu.
    Note: Among MovieCaptioner's export options are .srt files (for uploading to YouTube), SCC files for iTunes, Flash XML files, and many others. .
    MovieCaptioner's Export menu with options for QuickTime, SMIL, YouTube, SCC, SRT, SAMI, WMP, Flash XML plain text transcripts and many others.

 

Top of Page

Embedded or "Burned" Captions

Another method of exporting is to export a QuickTime movie with the captions embedded or "burned" in the video. This results in an "open caption" caption because captions are part of the image and cannot be hiddend.

This method is less flexible than exporting a separate caption text file because errors cannot be easily fixed, but is required in some services such as the ITS Streaming Server.

  1. Click on the Export menu and select Embedded QuickTime.
    Selecting Embedded QuickTime from MovieCaptioner's Export menu
  2. MovieCaptioner will automatically launch QuickTime, which will open a .mov file of your captioned video.
  3. Save the .mov file on your hard drive or server space.

Top of Page

Adobe Connect Caption Template

MovieCaptioner offers a template to allow users to caption recorded Adobe Connect files. See the Adobe Connect page for more information.

More Information

For more information on using MovieCaptioner, and walkthroughs for utilizing some types of captions, go to Help, then How to Use MovieCaptioner.

Synchrimedia also has tutorial videos, as well as a MovieCaptioner FAQ, which is helpful for troubleshooting specific issues. These resources are also linked under the Help menu in MovieCaptioner.

Top of Page

Podcasts in iTunes

Synopsis

  1. For audio-only podcasts, transcripts should be available. PDF files can be loaded into iTunes, but these files should also be made accessible. Another option is to provide a Word or text file outside of iTunes.

  2. Video-only podcasts should be captioned or provided with transcripts. See WGBH Creating Accessible iTunes U Content (PDF) for information on how to create captions.

  3. If a screen reader configuration does not support iTunes, then a link to an MP3 or video file outside of iTunes can be given.
    NOTE: Recent versions of JAWS and other screen readers can work with recent versions of iTunes, but some users may be on older versions of JAWS because of the expense of upgrading.

Adding SCC Captions to Video Podcasts

Video-only podcasts should be captioned or accompanied by transcripts, although iPods and iPhones only supports captions in SCC (Sonic Scenarist) format. SCC files do not use a human-interpretable language, and therefore need to be created with specialized software like MovieCaptioner.

To create an SCC caption file in MovieCaptioner:

  1. Add your captions by following the directions in the "How to Use MovieCaptioner" PDF in the MovieCaptioner folder within your computer’s Applications folder
  2. Under the Export menu, select Sonic Scenarist (SCC Embed in QT) or Sonic Scenarist (SCC File Only). The former option will embed the SCC captions directly into a QuickTime video. The latter will only create an .scc file, which can be opened with any text editor.
  3. If you used the Sonic Scenarist (SCC Embed in QT) option, QuickTime will launch automatically. View the video to ensure that the captions were added correctly. Even if you only intend to create a standalone .scc file, it's generally advisable to also export with SCC Embed in QT to test that your captions are working.
 

QuickTime: Adding Captions to Videos

There are several methods by which you can add captions to QuickTime videos, each with its own set of advantages and disadvantages. This page gives step-by-step instructions for implementing each method, as well as discussion of their appropriate use(s).

Recommended Software

Captioning QuickTime videos may require some specific applications, depending on the exact method of captioning you choose to use. Possible required programs, both of which are available on all CLC Macs on Penn State campuses, are:

Note: Other methods to generate time codes for QuickTime are available.

Creating a Separate Caption File

Creating a SMIL Caption File

One method of captioning a QuickTime video involves creating a completely separate SMIL (Synchronized Multimedia Integration Language) caption file, which can then be added as an additional "track" within the video. This allows typos or other errors to be corrected without editing and re-exporting the video.

You can create a SMIL file manually, but you can also use a program like MovieCaptioner to ease the process significantly.
Note: Alternative methods to create a SMIL file are described in detail on WebAIM (see Using SMIL to Add Captions to QuickTime Movies). Also, the W3C Synchronized Multimedia Home Page has an extensive list of SMIL tutorials and other resources.

To create a SMIL caption file in MovieCaptioner:

  1. Add your captions by following the directions on the page MovieCaptioner: Adding Captions to Videos.
  2. Under the Export menu, select QuickTime SMIL.
    Selecting QuickTime SMIL from MovieCaptioner's Export menu
  3. QuickTime will launch automatically. View the video to ensure that the captions were added correctly.

MovieCaptioner will create two new files: a .txt file, which contains the captions, and a file with the extension .qt.smi. The .qt.smi file combines the video and the captions, and is therefore what you should open when you want to view the captioned video. Likewise, if you're embedding the video in a Web page, all of your links should be to the .qt.smi file, although all three files (the .txt file, the .qt.smi file, and the original video) will need to be on your Web server.

Note: Mac OS X may attempt to treat .qt.smi files as though they were disk images. This is because the file extension .SMI is also used by an outdated type of disk image file, the "self-mounting image." If OS X attempts to mount the .qt.smi file like a disk image, right click on the file and select Open With » QuickTime 7.

Creating an SCC Caption File

If you want your captions to be suitable for broadcast, or for playing on an iPod or iPhone, you'll need to create captions in .scc format. See the page Podcasts in iTunes for information on creating .scc caption files.

Embedding a Text Track

One way to add captions to a QuickTime video is to give it a new "track" that will contain the captions' text. Using this method allows your captioned video to be completely contained in one file, which is simpler to distribute and maintain, but will make changing the captions difficult in the future.

About the Text Track

A text track is added to a QuickTime video by creating a .txt file containing the captions and some simple code, and then adding the .txt file to the video. The code tells QuickTime how to interpret the caption file, as well as when to display each individual caption. A QuickTime caption file will have the following format:

{QTtext}{font: Arial}{justify: center}{size: 12}{backcolor:0, 0, 0} {timescale: 30}{width: 320}{height: 60}

[00:00:00.00] Caption 1

[00:00:05.15] Caption 2

[00:00:09.08] Caption 3

The file is structured as follows:

  1. The first two lines contain formatting information for the cations such as font, alignment, size, and background color (in RGB format), as well as the width and height of the their background area.
  2. Underneath these display specifications are the actual captions, each one preceded by a timecode in square brackets. The timecode specifies the hour, minute, second, and division of a second at which that individual caption should display.
  3. Divisions of a second are represented by the number following the decimal point in the timecode, but you can adjust the exact size of these divisions by changing the timescale value at the beginning of the caption file. A timescale value of 30 means that each decimal unit in the timecode (i.e. .01) is equal to 1/30th of a second. A decimal value of .15 is therefore equal to half of a second.

For a full description of the QuickTime text track code, see the WebAIM tutorial "Captioning for QuickTime."

Creating and Adding the Text Track

To create a text track with MovieCaptioner:

  1. Add your captions by following the directions on the page "MovieCaptioner: Adding Captions to Videos."
  2. Under the Export menu, select Embedded QuickTime.
    Selecting Embedded QuickTime from MovieCaptioner's Export menu
  3. QuickTime will launch automatically. View the video (a .mov file) to ensure that the captions were added correctly.
  4. Save the .mov file on your hard drive or server space. This file is your video with the captions added.

"Burning In" the Text Track

In some cases, you may need to "burn" the text track of your video into the video track. This is usually necessary when you're uploading the video to a service that doesn't support QuickTime text tracks, such as Penn State's ITS Streaming server.

Note: The term "burning in" refers to the fact that caption text is incorporated directly into the video image.

See ITS Streaming: Uploading Captioned Videos for instructions on how to "burn" captions into a QuickTime video.

General Notes

Potential Issues

When adding captioning, it's possible that the additional content will alter the size of the video, adding a large amount of blank space. If this occurs, you will need to adjust the size of the caption track. To do so:

  1. In QuickTime, click on Window and select Show Movie Properties.
  2. Find the caption track in the list at the top of the Properties menu. Depending on the type of captions you added, the caption track may be listed as a Closed Caption Track, a Text Track, or a Video Track.
  3. Click on Visual Settings.
  4. Uncheck Preserve Aspect Ratio.
  5. Adjust the size of the caption track to match the size of the video, or so that any additional spacing is eliminated.

More Information

For more information on using QuickTime 7, see Apple's Self-help resources for QuickTime 7 and QuickTime 7 Pro.

For more information on using MovieCaptioner, see the "How to Use MovieCaptioner" PDF or the Tutorial Videos found in MovieCaptioner's Help menu. Also see the Accessibility and Usability Guide's page "MovieCaptioner: Adding Captions to Videos."

Top of page

YouTube: Uploading Captions

Adding Captions to a Video

  1. Log in to your YouTube account.
    NOTE: If you do not have an account, you can create one on the "Create a New Account" page.
  2. Under the My Account pulldown in the upper right, choose Videos.
    screenshot of account pulldown menu

  3. Find the video you want to add captions to and click Edit Info.
    screenshot of account Edit Info button

  4. Click the Captions and Subtitles tab.
    screenshot showing Captions and Subtitles tab

  5. Click Add New Captions or Transcript.
    screenshot of Add New Captions or Transcript button

  6. Use the Choose File button to locate the .SRT file on your hard drive, then click the Upload File button. Select a language for the video, and enter a title in the Name field if you wish.
    screenshot of choose file and upload buttons

  7. Click on the title of the video beneath the "Info and Settings" tab to go to its page.
    screenshot showing movie title lunchroom mannersat top iof video screen

  8. You should see the captions play in the video's normal size. screenshot caption Just before lunch one day

Top of Page

Embedding a Captioned Video

  1. Click the Share button below the video.
    screenshot of the Share button

  2. Click the Embed button.
    screenshot of the Embed button

  3. Select the options you wish to configure, then copy the iFrame code and paste it into your Web page.

    screenshot showing how to copy the embed code

YouTube and Screenreaders

The YouTube player has some screenreader accessibility built into its Flash player. To learn more visit the Google Support site at. http://support.google.com/youtube/bin/answer.py?hl=en&answer=189278

Top of Page

Testing Tools and Triage

This section contains information about developing a testing protocol and testing tools to use.

Triage for Accessifying Websites

Fixing Web Site Accessibility with Limited Resources

Triage is a process being developed by the TLT Web Accessibility Team (the ATeam) to bring a website to an acceptable, if not perfect, level of compliance with current standards (WCAG 2.0 comformance level AA) - quickly.

Audit

  1. Document all websites that you or your unit are responsible for maintaining
  2. Collect web analytics reports and data

Select

  1. Select the most popular sites based on volume (i.e., visits in the analytics report).
  2. For each site, select the 10 to 20 most popular pages based on volume.
  3. Include the home page.
  4. Include pages with known blockers (e.g., unlabeled form fields, videos without captions)

It is important to understand that triage is an iterative process; when the initial set of selected pages is complete, the criteria for selecting the next set of pages will change. For example, select next the next most-popular pages, or target an audience of color blind users and examine colors and contrast used in pages in that context.

Test

Test selected pages with these tools:

  1. Validators: machine test of standards-based accessibility. Note that validators can only test for standards compliance and limited machine-testable accessibility issues; they cannot guarantee accessibility.
  2. Screen readers: provide a more complete test for accessibility, including usability. It is strongly recommended that one or more web developers and designers, or content experts, learn to effectively use a screen reader for accessibility testing.
  3. Code review: some testers will find reviewing the code of pages with forms or tables to be more efficient.

Fix

Use these critical HTML markup guidelines

Navigating web pages and websites

  1. The page title is important to confirm at first glance that the page you're reading is interesting to you. There is one H1 heading tag per page containing the page title, e.g., <h1>Symposium Agenda</h1>. The H1 tag is at the top of the page and before any other heading tags.
  2. Page layout is identified by heading tags H2 through H6.
    1. Page sections (e.g., header, footer, primary and secondary navigation, content) are identified with H2 at the top of each section.
    2. The content area contains the article, story, or item that you want to read or interact with; it is also identified with H2 at the top of the section, and is structured with nested H3, H4, H5, and H6 heading tags.
  3. Link text explains purpose of the target page or location. The classic dilemma is a list of links (as routinely provided by screen readers), all with the same text, e.g., "click here" or "read more"

It is still common practice to place a "skip to content" link as one of the first links on the page, although this link is not as important as marking page layout with header tags. Ryan Jones, a trainer from Freedom Scientific said "providing heading tags in correct order is icing on the cake; just give me headings!"

Navigating Forms

Identify form fields with a meaningful label, e.g., "First name", "Year", "User name". Use the LABEL tag.

Navigating tables

  1. Data tables must have understandable and descriptive summary attributes and CAPTION tags.
  2. Data cells in data tables are related to headers either by scope attributes or id attributes.

Describe content images and media

  1. Content images, e.g., images with a story, have appropriate ALT text.
  2. Videos have captions, and viewers are accessible; music players are accessible.

Top of Page

Testing for Accessibility

Synopsis of Testing Protocol

This protocol will help you address major accessibility errors for a given Web page.

  1. Use the triage method to determine high priority pages for large Websites.

  2. Use testing tools like Compliance Sheriff to run checks on Web pages to find key content and template errors.

  3. Ensure that all videos are captioned and audio is transcribed.

  4. If you use style sheets, then disable stylesheets content is in a usable order with style sheets turned off. This is the order that will be presented to screen readers or to a low vision user using an alternate high-contrast stylesheet.

  5. Attempt to operate your website with just the keyboard (but not in a screenreader). This test shows how well a mobility impaired user can access your system.

  6. Use a color contrast checker to ensure there is adequate contrast between the background and foreground text for WCAG AA compliance.

  7. View your Website with a color deficient vision simulator or grayscale to ensure that content is not dependent on color.

  8. Make sure that all content is available in a screen reader. This is especially important for pages containing dynamic elements, Flash, Javascript elements or other content not easily tested in a reporting tool. See Screen Reader Testing

Top of Page

Streamline the Protocol

Triage Your Pages

Accessibility Site Triage is a process developed by the TLT Web Accessibility Team to quickly bring a website to an acceptable, if not perfect, level of compliance with current standards (WCAG 2.0 comformance level AA).

In addition to service sites, triage can be applied to a list of courses (i.e. accessify large enrollement courses first) or a suite of online services maintained by one unit.

Streamlining Tests

Although the protocol above involves multiple tests, not every test needs to be done on every page. For example, a check for video captions is only needed for a page with videos. This is especially true of pages using a common CSS file and common CMS template.

See the table below for recommended guidelines on how to apply tests.

Test Which Pages
Compliace Sheriff Most Pages
Screen Reader
  1. Page with Flash object, slideshow, dropdown menu or unusual plugins
  2. Web application pages
Captions/Transcription Pages with video or audio
Disable Stylesheet
  1. Home page
  2. Sample content page
  3. Unique page layout
Keyboard
  1. Home page
  2. Sample content page
  3. Page with Flash object, slideshow, dropdown menu or unusual plugins
  4. Web application pages
Contrast, Color
  1. Home page
  2. Sample content page
  3. Page with unique color scheme

 

Top of Page

Accessibility Reports

A variety of organizations and companies have developed tools to "scan" Web pages and see if they are accessible or not. Although these tools can catch some errors like missing ALT or TH tags, they cannot catch all errors. You must still use the manual checks above to determine that all accessibility requirements have been met.

Common Reporting Tools

Some common reports include:

Lists of Manual Checks

For errors that cannot be caught automatically, a list of manual checks, is generated. Therefore a completly compliant site could still generate a list of items to check depending on the reporting tool - this is perfectly normal.

Limits of Accessibility Reports

Below are some advantages and limits of accessibility reporting tools.
(Chart based on content from the University Libraries)

HTML Element Reports CAN Reports CANNOT
Images Check for Missing ALT tags Verify that ALT tags are accurate
Headings Determine if headings are properly nested and possibly detect large text NOT formatted as a heading Always check if text formatted as a heading IS a heading.
Color Suggest manual color check Simulate color blindnesss modes
Data Tables Identify most missing TH tags Check that tables are coherent when read left-to-right, top-to bottom
Flash Objects Suggest manual check Determine accessibility of Flash forms or interactive modules
Style Sheets Suggest manual check without CSS sheets Check stylesheets for accessibility
Links Identify large blocks of links Identify links which are vaguely worded or too close together
Forms Identify missing LEGEND, LABEL and ID tags Fix them for you automatically or ensure that they are accurate
Javascript Suggest manual NOSCRIPT check Automatically insert a NOSCRIPT alternative
HTML Code Validation Do nothing HTML and XHTML validation is completely different tool or report

Top of Page

Screen Reader Testing

Screen reader tests are particularly valuable for elements which cannot be checked in any other reporting tool. These include Flash objects, interactive elements and unique plugins and documents.
NOTE: It is also recommended to use screen readers on static sites to learn how they operate for users.

Multiple screen readers can also be tested to verify the behavior of new applications or unusual HTML (and HTML 5) tags or new CSS styles in each screen readers. Common screen reader tools include

Blind vs. Non-Blind Testers

Although it is ideal to have blind users test new sites and services to ensure that the interface is usable, a sighted user can also provide valuable testing data because they can see what is on the screen and listen to the screen reader at the same time.

Sighted users can spot items which are on the screen but NOT read by a screen reader.

Top of Page

Disable Stylesheets

Disabling stylesheets on Website can show the likely reading order of elements in a screen reader. Once stylesheets are disabled, items which have been placed by absolute positioning or floats will move to their actual location in the code.

This test not only shows the order on a screen reader but shows what may appear if a low vision user chooses to override the CSS with a custom stylesheet.

Tools to disable stylesheets are available in these Firefox plugins among others.

Top of Page

Keyboard Testing

Keyboard testing refers to the process of using a series of keystrokes (usually the Tab key to move forward, Shift+Tab to move backwards and Enter to click a button) to navigate a page and determine if links can be accessed and forms completed without using this mouse.

This tests the accessibility of a Web site to a motion impaired user unable to use a mouse.
Note: This is separate from a screen reader test because screen readers include additional keyboard commands not available in a visual browser.

The following sites include information on keyboard shortcuts for specific browsers and system setup.

Note: Many keyboard shortcuts have been standardized across the browsers

Contrast and Color Testing

These tests determine how legible a color scheme is to low vision and color deficient users. Learn more about these tests on the Contrast page and Color issues page.

Top of Page

JAWS HTML Commands

Access JAWS at Penn State

Penn State departments may request access to ITS licenses for the JAWS screen readers. Contact accessibilityweb@psu.edu to learn more or make a request for access.

Below are several lists of useful keyboard commands for JAWS, current since Version 14 (released February, 2012). For a complete lists of shortcuts for JAWS, see Freedom Scientific's JAWS Keystrokes page.

Keystrokes for Listing Elements

These commands will list all elements of a specified type on a Web page.

Element Lists
Function Keyboard Command
List Form Fields Insert + F5
List Headings Insert + F6
List Links Insert + F7
List Frames Insert + F9
List Tables Insert + Ctrl + T
List Buttons Insert + Ctrl + B
List Lists (ordered, unordered & definition) Insert + Ctrl + L
List Graphics Insert + Ctrl + G

Keystrokes for Reading Text

These commands control the way that JAWS reads content on a Web page, and also specify exactly what type of content should be read.

Reading Text
Function Keyboard Command
Pause Reading Ctrl
Resume Reading Insert + Down Arrow
Read Line Caps Lock + I
Read Paragraph Caps Lock + Ctrl + I
Read All (laptop layout) Caps Lock + A
Read All (desktop layout) Insert + Down Arrow
Skip Links (go to content) N

Keystrokes for General Navigation

These commands allow the user to jump to elements of a certain type within a Web page.

General Navigation
Function Keyboard Command
Go to Element (next/prior) Shift + Period/Shift + Comma
Go to Same Element (next/prior) S/Shift + S
Go to Different Element (next/prior) D/Shift + D
Go to Heading (next/prior) H/Shift + H
Go to Table (next/prior) T/Shift + T
Go to List (next/prior) L/Shift + L
Go to Link (next/prior) Tab/Shift + Tab
Go to Graphic (next/prior) G/Shift + G
Skip Links (go to content) N

Keystrokes for Headings

These commands allow the user to jump between headings on a Web page. For keystrokes containing "1–6" the command is valid with any number from 1 through 6, and will jump to headings of the corresponding level.

Headings
Function Keyboard Command
List Headings Insert + F6
Go to Heading (next/prior) H/Shift + H
First Heading Insert + Alt + Home
Last Heading Insert + Alt + End
Heading at Level (next/prior) 1–6/Shift + 1–6
First Heading at Level Insert + Alt + Ctrl + 1–6
Last Heading at Level Insert + Alt + Ctrl + Shift + 1–6

Keystrokes for Tables

These keystrokes help the user navigate and read content within tables. Note that these keystrokes will be necessary to navigate both layout and data tables.

Tables
Function Keyboard Command
List Tables Insert + Ctrl + T
Navigate Rows and Columns Windows Key + Alt + Arrow Keys
Navigate Cells Alt + Ctrl + Arrow Keys
Read Current Row Windows Key + Comma
Read Current Column Alt + Ctrl + Arrow Keys
Read Current Cell Alt + Shift + Comma

Keystrokes for Forms

These commands help the user navigate and manipulate HTML forms.

Forms
Function Keyboard Command
Enter Forms Mode Enter
Exit Forms Mode + (Num Pad)
First Form Field Insert + Ctrl + Home
Last Form Field Insert + Ctrl + End
Go to Form Field (next/prior) F/Shift + F
Go to Button (next/prior) B/Shift + B
Go to Edit Box (next/prior) E/Shift + E
Go to Radio Button (next/prior) R/Shift + R
Go to Check Box (next/prior) X/Shift + X
List Form Fields Insert + F5
List Buttons Insert + Ctrl + B
List Edit Boxes Insert + Ctrl + E
List Radio Buttons Insert + Ctrl + R
List Check Boxes Insert + Ctrl + X

Top of Page

JAWS Symbol File

If you are teaching a course with technical symbols such as /→,ə,ŋ, ∲,∑,⊃,¥,₹,₩,₪/ (arrows, phonetic symbols, math symbols and non-U.S. currency symbols), JAWS may skip over them completely unless the Symbol (.sbl) file is adjusted to recognize these symbols.

The instructions below will explain how to add a symbol based on its Unicode value.

Symbol Files

JAWS includes a set of symbol or .sbl files which match punctuation and symbol characters with a "word" (e.g, ? = "question mark"). The key is to add the character and reading to your working files.

As it happens there are some .sbl files collecting common symbol types available for download:

Note: The Greek and Hebrew files are meant for spelling isolated words. For a full page of content, a screen reader with a language pack for Greek or Hebrew is recommended.

Adjust Symbol File

This procedure assumes that JAWS is using the Eloquence speech engine, in which case the key file to change is eloq.sbl. You will also need to have an Admin account on your Windows machine to implement the changes.

Note: SBL files can be opened in any text editor such as Notepad.

  1. Open or download a .sbl file.
  2. Find the location of your eloq.sbl file. A sample path may be:
    JAWS 13 C:\Users\All Users\Freedom Scientific\Jaws\13.0\Settings\enu\eloq.sbl
    JAWS 14/15 C:\ProgramData\Freedom Scientific\JAWS\15.0\SETTINGS\enu
  3. Make a (second) copy of this file and rename as eloqOld.sbl. This is your backup in case something goes wrong.
  4. Make a third copy and rename it as eloqNew.sbl. This is a temporary file to edit since you may not be able to directly edit eloq.sbl.
  5. Open eloqNew.sbl in a text editor such as Notepad. This file contains pronunciation values for multiple languages. Scroll to the language you normally use (e.g. "[American English]"
  6. Scroll to the end of the symbol list for that language.
  7. Copy and paste the list of symbols from one of the other .sbl files immediately after the final line in the list. Each symbol will be in a single line and have the format U+0001=character name
    Note: Don't worry if the format does not match the rest of the symbol list.

  8. Repeat the last step for each language you want to support. You can translate character names as needed for each language. Save and close file.
  9. Exit JAWS if it is open.
  10. Delete eloq.sbl. You may be asked for an admin password at this point.
  11. Rename eloqNew.sbl as eloq.sbl.
  12. Restart JAWS and test on a page such as IPA Characters based on Letter A with Numeric Codes

Find Additional Codes

Below is one of the formats for a character entry in a Symbol file:

U+Codepoint=Character Name (no quotes)

For instance, if I wanted to expand the repertoire of currency symbols to include the new rupee symbol of India (₹), I would add the following to my .sbl file

U+20B9=Rupee symbol of India

A list of Unicode charts with code points is available at http://www.unicode.org/charts

Top of Page

NVDA Commands

NonVisual Desktop Access (NVDA) is a free and open source screen reader for the Microsoft Windows operating system developed by NV Access, with contributions from the community. It can be downloaded from NV Access. This page only lists a few of the most used keyboard short-cuts and commands, for a complete list See NVDA User Guide.

The NVDA Modifier Key

Most NVDA-specific keyboard commands consist of pressing a particular key called the NVDA modifier key (Numpad Insert or Extended Insert by default) in conjunction with one or more other keys. In the table below, this will be referred to as just NVDA. Notable exceptions to this are the text review commands for desktop keyboards which just use the Numpad keys by themselves, but there are some other exceptions as well.

NVDA can be configured so that either the Numpad Insert, Extended Insert, or Capslock key can be used as the NVDA modifier key.

If you wish to cause one of the NVDA modifier keys to act like its original key (for instance you wish to turn Capslock on when you have set Capslock to be an NVDA modifier key) you can press the key twice in quick succession.

Keystrokes for Basic NVDA Commands

These are the most basic commands used in NVDA.

Basic NVDA Commands
Function Keyboard Command
Stop speech Control
Pause Speech Shift
Browse mode elements list NVDA+F7
NVDA Menu NVDA+N
Toggle Speech Mode NVDA+S
Toggle Input Help Mode NVDA+1
Quit NVDA NVDA+Q
Pass next key through NVDA+F2
Toggle application sleep mode on and off NVDA+Shift+S
Keyboard help NVDA+1

Keystrokes for Reading Text

These commands control the way that NVDA reads content on a Web page, and also specify exactly what type of content should be read.

Note: Some shortcuts require the use of Numpad keys, for example Numpad 1. In such cases, using the Numeric keys, like 1, on the left hand side with the alphabet pad, will not work.

Reading Text
Function Keyboard Command
Say Prior Character ←(Left Arrow) or Numpad 1
Say Next Character →(Right Arrow) or Numpad 3
Say Current Character Numpad 2
Say Word Numpad 5
Spell Word Numpad 5 twice quickly
Say Next Word Ctrl+→(Right Arrow) or Numpad 6
Say Prior Word Ctrl+←(Left Arrow) or Numpad 4
Say Prior Line ↑(Up Arrow) or Numpad 7
Say Next Line ↓(Down Arrow) or Numpad 9
Say Current Line NVDA+↑(Up Arrow) or Numpad 8
Spell Current Line NVDA+↑(Down Arrow) twice quickly
Read all starting at current position NVDA +↓(Down Arrow) or Numpad +
Top line Shift+Numpad 7
Bottom Line Shift+Numpad 9
Start of Line Shift+Numpad 1
End of Line Shift+Numpad 3

Keystrokes for Links

These commands allow the user to navigate between the links within a Web page.

Links Navigation
Function Keyboard Command
Jump to next link/form element Tab
Next link K
Jump to previous link/form element Shift + Tab
Elements List - lists page links, headings, and landmarks NVDA+F7
Unvisited Link Quick Key U
Visited Link Quick Key V

Keystrokes for Headings and Lists

These commands allow the user to jump between headings and Lists on a Web page. For keystrokes containing "1–6" the command is valid with any number from 1 through 6, and will jump to headings of the corresponding level.

Headings and Lists
Function Keyboard Command
Headings Quick Key H
Headings level 1-6 1-6
List Quick Key L
List Item Quick Key I

Keystrokes for Tables

These keystrokes help the user navigate and read content within tables. Note that these keystrokes will be necessary to navigate both layout and data tables.

Tables
Function Keyboard Command
Table Quick Key T
Next Cell ↓ (Down Arrow)
Previous Cell ↑ (Up Arrow)

Keystrokes for Forms

These commands help the user navigate and manipulate HTML forms.

Forms
Function Keyboard Command
Form Quick Key F
Button Quick Key B
Enter Forms Mode Enter or NVDA+Space (in a form element)
Exit Forms Mode NVDA+Space
Navigate to Next form Control Tab
Navigate to Previous Form Control Shift+Tab
Select and Deselect Checkboxes Spacebar
Open Combo Box/Jump Menu/Auto-complete Menu Alt+↓(Down Arrow)
Select Radio Button ↑(Up Arrow) or ↓(Down Arrow)
Select Element in Combo Box ↑(Up Arrow) or ↓(Down Arrow) or the First letter
Checkbox X
Combo Box C
Radio Button R
Submit Form Enter (in forms mode)

Keystrokes for Voice Rate

These keystrokes help the control and adjust the voice rate

Voice Rate
Function Keyboard Command
Decrease Voice Rate Ctrl+NVDA+↓(Down Arrow)
Increase Voice Rate Ctrl+NVDA+↑(Up Arrow)
Change Voice Settings (Inflection, Pitch,etc.) Ctrl+NVDA+>/<

Keystrokes for Application Specific Commands

NVDA provides its own extra commands for some applications to make certain tasks easier or to provide access to functionality which is not otherwise accessible to screen reader users.

Application Specific Commands
Function Keyboard Command
Microsoft Excel: Set column headers NVDA+Shift+C
Microsoft Excel: Set row headers NVDA+Shift+R
Microsoft PowerPoint: Toggle speaker notes reading Control+Shift+S
Miranda IM: Report recent message NVDA+Control+1-4
Poedit: Report Comments Window Control+Shift+C
Poedit: Report notes for translators Control+Shift+A

Top of Page

VoiceOver Commands for Web Page Testing

Apple's screen reading utility VoiceOver.comes standard with Mac OS X 10.4 and later. The information below is meant to help users begin to use VoiceOver's functions.

For a comprehensive list of VoiceOver's keyboard commands, as well as guides on getting started with VoiceOver and its newest features, see Apple Accessibility.

Note: These commands are optimized for the Safari browser. Some commands may work in other browsers.

Activate VoiceOver

To activate VoiceOver you can:

  1. Press Command + F5 keys to toggle VoiceOver on and off.
  2. VoiceOver can be toggled on and off from the Systems Preferences panel in the Accessibility settings.

Basic Commands

Note: The sequence of Command + Option is called the VoiceOver or "VO" key in other documentation.

Begin/Pause Reading
Function Keyboard Command
Enter Web Page Control + Option + Down Arrow
Exit Page Control + Option + Up Arrow
Read All Control + Option + A
Pause VoiceOver Control
Go to Address Bar Command + L
Previous Page Command + Left Arrow
Next Page Command + Right Arrow
Brower Menu Command + Option + M
Access "Right Click" Menu options Shift + Command + Option + M
Enter/Exit VoiceOver Command + F5

Top of page

Rotor Window

The "rotor" is a menu window in VoiceOver which presents lists of Web elements such as headings, links, images and other Web elements. It can be configured to add or remove Web page elements as well.

Rotor window - see details after image

Rotor window showing "Headings" on Accessibility Home page. The first is "2: Quick Links" indicating the presence of an H2 for Quicklinks.

Open and Browse Rotor

Rotor Commands
Function Keyboard Command
Open Rotor Control + Option + U
Close Rotor Escape
Next Window Right Arrow
Previous Window Left Arrow
One List Item Down Down Arrow
One List Item Up Up Arrow
Jump to Item Command + Option + Spacebar
Read After Item Command + Option + A

Configure Rotor Options

The rotor can be configured to display or disable different Web page elements. This is done in the VoiceOver Utility settings in the System Preferences. To open the VoiceOver Utility

  1. Open VoiceOver (Command + F5).
  2. Open the VoiceOver Utility by pressing Command + Option + F8.
  3. Look for the rotor settings options under the Web tab.
    Note: The location varies depending on operating system version.
  4. Check or uncheck the Web page elements as desired elements.
  5. Use arrow key commands to reorder elements into an appropriate sequence order.

Top of page

Navigate to Page Elements

You can navigate different Web elements without using the rotor with the keyboard commands below.

Navigating to Different Elements
Function Keyboard Command
Read Next Heading Control + Option + Command + H
Next Link Control + Option + Command + L
Next Image Control + Option + Command + I
Next Form Control Control + Option + Command + J
Next Frame Control + Option + Command + M
Next List Control + Option + Command + X

 

Navigate to Previous

To navigate to previous heading, link, image and so forth, add the Shift key to the command for the "Next" option.

For instance, if Next Heading is Control + Option + Command + H, then Previous Heading is Shift + Control + Option + Command + H

Top of page

Reading Text in Detail

These commands allow the user to specify exactly what type of content VoiceOver should read.

Keystrokes for Reading Text
Function Keyboard Command
Read Paragraph Control + Option + P
Read Sentence Control + Option + S
Read Line Control + Option + L
Previous Line Control + Option + Up Arrow
Next Line Control + Option + Down Arrow
Read Word Control + Option + W
Previous Word Control + Option + Left Arrow
Next Word Control + Option + Right Arrow
Read Character Control + Option + C
Previous Character Control + Option + Shift + Left Arrow
Next Character Control + Option + Shift + Right Arrow
Read Row in Table Control + Option + R
Read Column in Table Control + Option + Shift + C
Read Visible Window Control + Option + Shift + W

Reading Tables

Function Keyboard Command
Keystrokes for Tables
Read Row in Table Control + Option + R
Read Column in Table Control + Option + Shift + C
One Cell Forward Command + Option + Right Arrow
One Cell Backwards Command + Option + Left Arrow
One Cell Down Command + Option + Down Arrow
One Cell Up Command + Option + Up Arrow

Top of page

iPhone/iPad

A version of VoiceOver is also available for iPhone, iPad and iTouch and is based on finger gestures.

More information about VoiceOver on the iPhone is available on at the following links.

Top of page

Compliance Sheriff

This documentation serves as an instructional resource for the Compliance Sheriff automated accessibility testing tool from HiSoftware.

Getting Started

Welcome to Compliance Sheriff!

So, you're ready to start your journey with Compliance Sheriff? Congratulations, your assistance in making sites at Penn State accessible is both a welcome and appreciated effort. Here are some resources to help you get started.

Accessing the Compliance Sheriff Server

The first thing you'll need is the URL to the CS Server

Request an account on Compliance Sheriff

If you have a Web Access or Friends of Penn State account, you'll notice that you can login, but can't yet see anything. You'll need to request an account on the CS server by contacting the listserv. Upon creating your account, the Administrator will place you in the appropriate User Group for your budget unit.

Request additional scans on Compliance Sheriff

If the website you're attempting to remediate isn't yet included in the list of scans, you can request a new scan be created for your site by contacting the listserv. Additionally, you are provided several custom user scans to make use of as you wish. If you need some more room in the sandbox, you may also request additional user scans in the same manner.

Additional support resources

Now that you're ready to dig in, there are plenty of documentation and support resources available to you. Be sure to follow Compliance Sheriff progress at Penn State on Yammer and join the discussion!

Blockers Training Materials

Below are materials for different elements of Compliance Sheriff training.

Blockers

Training Goals and Objectives

Let's begin by acknowledging some of the questions you may have.

Why am I attending this class?  What information is important to me?  How will the types of questions I ponder change over time?

Why am I here?

  • I want to know why Compliance Sheriff is scanning my site and why its important.

Who initiated this process?

  • I want background information on NFB compliance.

What is my score?

  • I want to know my score so that I can understand my site's degree of legal risk.
  • I want to know how my score compares to other units across Penn State so that I can understand the relative legal risk.
  • I want to know how my score is determined so that I can understand why it so low/high.

How do I read reports?

  • I want to learn the terms and concepts used in Compliance Sheriff so that I can understand the reports.
  • I want to learn how to understand the reports that have been generated for me so that I can take this back to my web developers.

When do I need to fix these issues by?

  • I want to know how my web developers can fix the errors so that I can comply and lower the legal risk.
  • I want to know how to scan additional sites so that I can improve the compliance of my overall web presence.
  • I want to know how to generate custom or mini-reports and have those emailed to me so that I can monitor progress.

Training Goals

This course contains two major components:

  • Learn to use Compliance Sheriff to scan a web site and determine accessibility problems
  • Learn about methods to remediate accessibility problems

Training Objectives

You will learn to:

  • Log into the system
  • Identify common terms
  • Identify a site's health score
  • Read required reports
  • Identify methods to remediate your site's accessibility problems

Background, Understanding, and Compliance

Background

Pursuant to the revised Web Accessibility Policy AD -69, the Accessible Information Technology Committee (AIT) has implemented the HiSoftware Compliance Sheriff tool as a service to provide a University-wide web evaluation and remediation.

The rollout of this service meets one of the critical deadline as specified in the agreement with the NFB:

The University shall complete an accessibility audit of its electronic and information technologies ("EITs") no later than February 15, 2012 that will examine the accessibility and usability of the EITs provided by the University to students, prospective students, staff and faculty who are blind.

For the users of the HiSoftware scanning tool, EITs refers to public-facing websites, login protected websites that are core to the missions of the University, and web applications. However, any site, including all login-protected sites, must be made accessible if a request to access information is made by a user.

Why be accessible?

The United Nations' Universal Declaration of Human Rights addresses the issue appropriately:

Everyone has the right freely to participate in the cultural life of the community, to enjoy the arts and to share in scientific advancement and its benefits.

Excluding segments of the audience is contradictory to the nature and intent of a free and open society.  However, increased access to information should be considered an altrustic endeavor inherent to all University principles.

Creating and maintaining accessible websites is good for institutional business and establishes opportunities to provide access to all individuals with or without disabilities at Penn State University.  A more accessible Web presence will raise Penn State’s profile on the Web and have a direct and positive impact on efforts such as student recruiting, donor giving, and access to materials on the Web for all constituents of Penn State, including those with disabilities.

A better understanding of assistive adaptive technologies will also empower your developers to think differently as they realize the challenges that exist in the accessibility space.  They will begin to reassess how they design, program, and write for the web and reconsider decisions on color usage, image placement, page formatting, and table layout.  With this heightened level of knowledge, your developers will more often be mindful of the overall usability of your site, which will in turn improve your overall web presence.

Usage

The purpose of this service is to assist Penn State Web sites in meeting compliance with current federal, state and local laws utilizing current standards: the Web Content Accessibility Guidelines, 2.0 recommendations.  Anyone with a Penn State Access ID who wants to use this tool to scan their site may do so by contacting the Systems Administrator.

Training

These training courses meet another critical deadline as specified in the agreement with the NFB:

No later than August 15, 2012, the University shall conduct training, instruction and support at all levels about the University's EIT Accessibility Policy and procedures and shall list the tools and techniques that are available for faculty and staff to comply with the Policy and procedures so that the University's Accessibility Policy and procedures are effectively and consistently implemented.

Successful Compliance

The AIT along with the Web Liaisons will review the reports, may provide individualized feedback to each University Budget Executive through the Web Liaison, provide guidance on accomplishing the set strategic plan goals, develop ongoing rubrics for completion of the 3 year strategic plan and will establish a continued framework for measuring the progress of the strategic plan and agreement with NFB.  These efforts will help the university meet the October 14, 2014 deadline for making all sites at Penn State accessible to blind users.

What is my Health and how is that score determined?

What is my Health score?

HiSoftware Compliance Sheriff produces two scores which can be tracked over time.

  • WCAG 2.0 score - Checks against all WCAG Level A and Level AA rules
  • NFB score - Checks against 29 WCAG 2.0 checkpoints that map to the 8 blockers identified in several communications with the NFB

These scores can be found by navigating to the Scans section and viewing the percentage in the Health column.

Screen shot example: table of ITS-accessibility-wcag2 and ITS-accessibility-nfb scans, websites, dates, and health scores

Screen shot example: Compliance Sheriff health ranges and percentages

How is Health score determined?

This percentage is determined by a HiSoftware algorithm that measures weighted results against the number of pages on your site.  This number is different than the ratio of passes to failures for all occurrences (which can be found by viewing your full report).

The priority level of a checkpoint, 1 2 or 3, is used to weight the value.  The higher the level of the checkpoint that failed, the lower the health value you will receive.

Compliance Sheriff health range percentages

How does my Health score compare to other units across Penn State?

A typical revelation after receiving your first HiSoftware Compliance Sheriff report is likely to go something like this...

    "Wow!  My score is really low.  How does my site rank with other sites at Penn State?"

Well, you're not alone.  After the initial set of scans were run in February 2012 on the top 100 sites at Penn State,

  • There were very few sites had higher than 50% Health score.
  • No site with a 50% score or higher had more than 16 pages in their scan.
  • The majority of scan results fell between 2%-39%

Compliance Sheriff Terms and Concepts

Scans

HiSoftware Compliance Sheriff "Scans" provide automated accessibility tests for the web in order to reduce the amount of human accessibility testing.  Websites and scan criteria submitted by the Web Liasons have been preserved for the purpose of auditing and reporting.  These scans are set to be re-run at regular intervals (ex. every 6 months) and cannot be edited or deleted.

Scanning additional sites: "User scans"

Additional scans can be performed by editing any of the four sample user-scans.  These scans come with several default options:

  • Display Name: The name is in the format UNIT-user-scan provided by default, such as TLT-user-scan-1.  Change user-scan to meet your needs, UNIT name should remain consistent, such as TLT-my-website.
  • Base URL:  http:// provided by default.  Fill in the URL of the new site you wish to scan here.
  • Checkpoint Groups: The following checkpoint groups are provided by default.  You may add/remove additional checkpoint groups to suit your needs.
    • WCAG 2.0 - Compliance Level A

    • WCAG 2.0 - Compliance Level AA
    • NFB blockers for screen reader users
  • Start Page: The default / character indicates that the scan will start at the root of the site.  You may also click ADD to include additional start pages.
  • Level: Level 2, for example, indicates the scan will descend two navigation levels within the site (ex. http://mysite.com/events/compliance-sheriff-training
  • Options: 250 Page Limit indicates the maximum number of pages the scan should cover.
  • Additional file formats: Include Microsoft Office documents and Include PDF and SWF files are checked by default.
  • Exclude URLs matching: This field is blank by default, but may be filled-in to specifically exclude pages from a scan.

The "New" Scan Button

If you click New on the Scans page, you will receive a notification stating "Permission denied - Please contact your administrator".  This is expected and you should only consider contacting the Site Administrator if you need more than the four provided user-scans or wish to permanently archive a user-scan which you have customized.

Scan Groups

Scan Groups are containers for Scans.  Scan Groups for the Web Liaisons have also been predefined and cannot be edited or deleted.  These groups are also persevered for the purpose of tracking the overall health of your Budget Unit over time.

  • WCAG-related scans are grouped together with the UNIT-wcag2 naming convention (ex. ITS-wcag2)
  • NFB-related scans are grouped together with the UNIT-nfb naming convention (ex. ITS-weblion-nfb)
  • User-related scans are grouped together with the UNIT-user-scan-group naming convention (ex. ITS-user-scan-group)

Viewing All Custom User Scans: "User Scan Groups"

The four sample user scans are included in the UNIT-user-scan-group container.  This Group will provide you a Report overview which contains all of the custom scans.  You cannot add/remove scans from this scan group.

The "New" Scan Groups Button

You cannot create new scans.  If you click New, you will receive a notification stating "Permission denied - Please contact your administrator".  This is expected and you should only consider contacting the Site Administrator if you need more scan groups provided.

Checkpoints

Checkpoints are instruction sets that will check that a web page conforms to predetermined rules or guidelines.  The predefined checkpoints link directly to the corresponding WCAG 2.0 rule page and contain detailed information on the issue.

Checkpoint Groups

Checkpoint Groups are collections of checkpoints.  The predefined checkpoint groups used in the existing scans are described as follows:

WCAG 2.0 Compliance Level A

The priority set of WCAG 2.0 criteria.  Generally these requirements are the most important and will have the widest impact on the accessibility of your site.

WCAG 2.0 Compliance Level AA

The next level of conformance to the WCAG 2.0 guidelines.  To declare AA conformance with WCAG 2.0 all criteria in Level A must also be met.

NFB blockers for screen reader users

In several communications with the NFB, a demonstration by Tony Olivero of NFB, and training provided by Ryan Jones of Freedom Scientific a list of consistent "blockers" to screen reader users emerged.  they include page structure with heading and sub-heading elements, labels for forms, relating table cell data to headings, ALT text for images, and usable link text.  Christian Vinten-Johansen added keyboard operability and video captioning as per PS Policy AD25.

Reports

Reports provide executive management visibility into how your organization is performing with respect to compliance goals, and allows you to compare compliance performance among individuals and groups (business departments, geographical units, and others).

Summary

To view a summary report of your website's health, click Health Percentage, which includes:

  • Scan Statistics:  A general summary of passes, failures, and warnings
  • Trend:  Changes to your website's health percentage overtime
  • Top 10 Checkpoints:  Top compliance failure occurrences
  • Top 10 Issues:  Top compliance failure issues

Full Details

To see a detailed list of all the failures and warnings in a printable Report, click Health Percentage, View Full Details.

  • To see a rendered view with the problematic area of the page highlighted, click the page where the error originates
  • To see the problematic source code, click the code where the error originates

Logging In to Compliance Sheriff

Log in

Log in at https://csa.win.psu.edu/compliancesheriff with your PSU Access ID and Password

What you will see

Here is what you will see when you first log in.

 

Initial view of Compliance Sheriff after login, the Dashboard tab, saying 'Your dashboard is not configured to show any views.'

What you will access

The global navigation links which are most important to users are the "Scans", "Notifications", "Views", and "Dashboard" tabs.  "Monitors" are less likely to be used, as site scans and full reports will be generated for you on a routine basis.  The "Checkpoints" tab is likely to never be used, as checkpoints have been pre-defined and cannot be edited.  The "Reports" tab does not work for any user in a restricted user group (or all non-systems-admin users of this service).

Requesting Group Access

You will not be able to see any scans or reports until you have been added to the appropriate user group for your department.  If you have not yet been added to a user group or wish to add more users at any future time, please contact the systems administrator.

How to Read Compliance Sheriff Detailed Reports

Reports can be read by clicking the Health Percentage number of a scan.  In this document, we'll use a real world example to walk you through the process.

Health Percentage

Screen shot example: 10%, ITS-accessibility-wcag2 Scan completed 2/20/2012

This number is generated based-on the number of pages in the site which pass all checkpoints.  It is meant to be an overview of your site's progress towards health, rather than an exhaustive proportion of passes and failures.

Scan Statistics

Here you will find a comprehensive listing of the statistical results from a scan.  This is useful for obtaining a total number of passes, warnings, and failures.

Screen shot example: Scan Information and Result Occurences

Trend

Trends are represented by a line graph showing changes to your website's health percentage overtime.

Screen shot example: Trend of 0% change today compared to last run 2/16/2012

Top 10 Checkpoints

This list includes the checkpoint failures that occur most frequently across your site.  This is a good place to start when you're looking for the top compliance issues your site faces.

Screen shot example: Top 10 Checkpoints, Failures, Number, Description, Occurrences

There are several click-able links within this table:

  • Number combinations will take you to the checkpoint itself.
  • Description or Occurrences will take you to an overview the checkpoint-related issues found within the code.

Top 10 Issues

This list includes the checkpoint failures that occur on the most pages within your site.  This is a good place to start if you're looking for the top compliance issues that are effecting your overall Health Percentage.

Screen shot example: Top 10 Issues, Result, Page Count

Clicking the description will take you to a cached rendered view of your site with the problematic area highlighted.  By navigating the links in the large horizontal bar at the top of the page, you can:

  • Previous/Next: Navigate to the next occurance
  • How to fix?: Read a full explanation of the WCAG 2.0 rule
  • Code source: Find the specific line in the code causing the failure

Top 10 Recent Checkpoints Changed via Results Revision

In general, you should not notice any changes listed in this column unless you are revising your results to exclude specific compliance issues.

Top 10 Pages

This is a list of the top 10 pages on your site which contain the most failures.

Screen shot example: Top 10 Pages, Failures, Description, Results

Full Details

To see a detailed list of all the failures and warnings in a printable Report: Click Health Percentage, View Full Details

Screen shot example: ITS-accessibility-wcag2 Report, Result metrics, Key: Failed, Warning, Visual Check

  • To see a rendered view with the problematic area of the page highlighted, click the page where the error originates
  • To see the problematic source code, click the code where the error originates

How to Scan Additional Sites

The "New Scan" Button

If you click New on the Scans page, you will receive a notification stating "Permission denied - Please contact your administrator".  This is expected and you should only consider contacting the Site Administrator if you need more than the four provided user-scans or wish to permanently archive a user-scan which you have customized.

User Scans

Additional scans can be performed by editing any of the four sample user-scans.  In this document, we'll use a familiar example to walk you through the process.

Sample Scan:

  • Site: accessibility.psu.edu
  • Unit: ITS
  • Checkpoint Groups: NFB blockers for screen reader users

Display Name

First, add your custom scan name...

Screen shot example: Display Name: ITS-user-scan1

  • Change ITS-user-scan1 to ITS-user-scan-accessibility-nfb

Base URL

Next, add your URL...

Screen shot example: Base URL: text box containing http://

  • Change http:// to http://accessibility.psu.edu

Checkpoint Groups

Since we only wish to check against NFB blockers for screen reader users...

Screen shot example: table of each checkpoint: WCAG 2.0 A, WCAG 2.0 AA, NFB blockers for screen reader users

  • Remove WCAG 2.0 - Compliance Level A
  • Remove WCAG 2.0 - Compliance Level AA

Start Page

We want to scan the root of the site, but let's say we want to add another site that redirects from /another-site...

Screen shot example: Start page, slash, Add button

  • Click Add and a new line will appear
  • Type /another-site on the new line's Start Page field

Level

We want to scan 3 levels down, so...

Screen shot example: Levels, drop down menu with selection of 'two'

  • Change Level 2 to Level 3

Options

Since there are only 50 pages on accessibility.psu.edu, we can adjust the Page Limit...

Screen shot example: Options, Hide button, Username:, Password:, Domain:, Page limit: 250

  • Click Edit under Options
  • Change Page Limit 250 to Page Limit 50

Additional file formats

We do not have any Microsoft Office documents, but we do have PDF files...

Screen shot example: Additional file formats: checkboxes for Include Microsoft Office documents, and Include PDF and SWF files

  • Uncheck Include Microsoft Office documents

Exclude URLs matching

This field is blank by default, but let's say there's an intranet that we don't need to scan at http://accessibility.psu.edu/intranet

Screen shot example: Exclude URLs matching: text box

  • Add intranet

If you wish to include multiple URLs, use a vertical bar

  • intranet|private

Shared-service Considerations

It is important to remember that this tool is being used University-wide and thus has many users and scans within the system. So, be kind to your neighbors! Here's are some helpful hints:

  • Running custom user scans - User scans can be re-run at any time, however the server can only handle a limited number of scans running simultaneously before the service slows. You may consider scheduling your scans to be run off-hours while fewer people will be accessing the service.
  • Larger page limits - Page limits have been set at 250 pages in order to help the triage process of remediating site errors. If you wish to scan more than 250 pages, you may, however we ask that you avoid scanning 5000 pages as this will tie up the server for quite some time.

Scans naming convention

Baseline scans

Baseline scans were created with a standard naming convention to better group and organize units across Penn State. This schema derives from the following standard:

  • Convention: UNIT ABREVIATION CODE - website - checkpoint group - scan type
  • Example: ITS-accessibility-nfb-BL

Baseline scans are read-only and can only be renamed by a site administrator.

Custom user scans: Default

Custom user scans were also created with a standard naming convention.

  • Convention: UNIT ABBREVIATION CODE - user-scan - number
  • Example: ITS-user-scan1

Custom user scans are read-write and can be renamed at any time.

Custom user scans: Edited

For site-wide maintainability purposes, we ask that you continue to abide by the following standard convention.

  • Convention: UNIT ABBREVIATION CODE - user-scan - website - checkpoint group
  • Example: ITS-user-scan-accessibility-nfb

Advanced Usage of Compliance Sheriff

Receiving Email Notifications

Notifications allow you to subscribe to scan results by email.  You can choose to send the information in various formats including Link, PDF, or Table Only.  Subscriptions can be delivered after any scans defined within the View is run, or at regularly scheduled intervals.

Views

View

A View is a presentation of data from the results database. A View may contain a graphical chart, a textual summary, and/or table of Checkpoint results.

Screenshot example: Trainee User View

Creating New Views

Creating additional views can assist you in displaying only the statistics which are most important to your unit such as custom chart types, rendered statistics, or modified table displays.  From the Views tab, click New, and then add Scans or Scan Groups to be displayed.  If you would like to generate a report similar to Full Details, choose the default options.

Scorecards

Scorecards are a modified visualization of Views.  A Scorecard is a table that gives you a visual sense of how well your organization is meeting its unique web compliance standards. By allowing you to make side-by-side comparisons of several sites or groups of sites across your network, a Scorecard allows you to see which areas of your site network are exceeding your goals, which areas need further attention, and which areas have improved or declined.

Screenshot example: Trainee User Scorecard

Creating New Scorecards

Creating additional scorecards can assist you in comparing only the scan results which are most important to you.  From the Views tab, click New, and then add Scans or Scan Groups to be displayed.  The two options which are the most important for historical comparison are the Health Line Chart types and the Scorecard Tables types.

Graphing Scan Results... Dashboard

Dashboards enable a one-stop location to list and compare Views.  Dashboards are directly driven by custom Views, and cannot be created without first creating a View.  Dashboards are specific to the user only and cannot be enabled group-wide.

Screenshot example: Weblion Dashboard

Revising Compliance Sheriff Scan Results

Identifying pages to exclude from scan results

The first step in deliberation is to consider whether or not these pages should be excluded from your scan results. Here are three common use cases for excluding pages from your scan.

  • The crawler has found internal URLs to other subsites which use the same baseline URL.
  • The crawler has found subfolders which are used for separate projects and not part of the main site
  • The crawler has identified intranet pages which should otherwise be considered private
If any of these issues apply to you, please send an email to the site administrators bjd18 at psu.edu or mlb354 at psu.edu and we can exclude these pages from your results.

Identifying false positives

Compliance Sheriff is a pretty handy service, but automated tools have their limits. You may notice errors which clearly make no sense. Let's take a look at an example.

Page contains substantial text but does not contain headings

Screen shot example: Page contains substantial text but does not contain headings Compliance sheriff has flagged this RSS page for not using headings. However RSS templates do not use headings.

Submitting these findings to the site administrators is quite helpful as false positives can often be effecting more than one unit. With helpful feedback on these issues, the administrators may have a chance to remedy the situation by adjusting Checkpoint rules.

Revising scan results

There may be occurrences in which results will show up in your scans which you may interpret differently than Compliance Sheriff. While in many circumstances, the easiest solution may be to simply fix the errors, there is a path to contest those results.

If you click on the health percentage score to look at your report, you will notice three buttons at the top of the page. Click on "Revise results".

Screenshot example: Revise scan results

This will take you to the default page of the results revision wizard.

Screenshot example: Results revision wizard default page

From here, you can group your errors in one of two ways: By page or By Checkpoint.

Screenshot example: By page or by checkpoint

You can also change what results show up in the revision wizard by selecting which criteria to include.

Screenshot example: Include failures, warnings, visual checks, passes, N/A

Once you've narrowed down the results, you can click "Next" and "Previous" to navigate to the error you wish to revise.

Screenshot example: Previous and Next buttons

Once you locate the error, you can then change its Error Type by clicking on the colored icons. This will allow you to move errors into other categories like failures, warnings, visual checks, passes. This will also allow you to flag false positives as as N/A or "not applicable".

Screenshot example: Revising results as not applicable

Finally, clicking "Close", "Next", or "Previous" will commit your change to the database.

Troubleshooting

Spinning scans

If you notice that a scan is "running" for an extended length of time and failing to complete, it is important to kill this process as it has the potential to max out CPU on the server. However, the web interface will not let you stop or delete the scan. The process we've found by which to stop these is to schedule the scan to be run a few minutes after the current time. When the scheduled scan kicks in, it kills the running process, allowing your scan to stop.

FAE Firefox Accessibility Evaluation Toolbar

The Accessibility Evaluation Toolbar (also referred to as the Firefox Accessibility Extension) is a Firefox add-on created by the Illinois Center for Information Technology and Web Accessibility (iCITA) that serves as a browser-based counterpart for the Functional Accessibility Evaluator (FAE).

It allows the user to quickly assess the accessibility of a given Web page, with functions for testing the accessibility of the page's individual elements, as well as for validating the page's source code.

The Accessibility Evaluation Toolbar is available for free download from Firefox add-ons site. To install, click the Add to Firefox button.

General Reporting

The Reports function will assess the accessibility of all the elements on a page, reporting any that are inaccessible or potentially problematic. The Toolbar uses the qualifiers Pass, Fail, Warning, and Check to describe the accessibility of each element. For an explanation of these categories' criteria, see iCITA's Rule Evaluation Definitions.

The Reports function can test a Web page's compatibility with two different sets of accessibility rules:

  1. The FAE Rule Set, which contains the standards prescribed by the Illinois Information Technology Accessibility Act (IITAA).
  2. The beta Rule Set, which contains proposed IITAA standards, as well as standards prescribed by WAI-ARIA for accessible Web applications.

The IITAA standards are comparable to those recommended by WCAG 2.0. See the IITAA Web site for a comparison of the IITAA and WCAG 2.0 standards, as well as for the comprehensive IITAA standards.

To check for accessibility issues on your Web page:

  1. Choose a rule set by clicking on the Reports button in the Accessibility Toolbar.

    Screen capture

    Alternatively, you can go to the Accessibility menu in the top menu bar and select Reports.
  2. In the same location, select Accessibility Issues.

    Screen capture

  3. The List of Accessibility Issues dialog box will open. This window will list the page's accessibility violations, the severity of the violation (i.e. Fail, Warning, or Check), and the number of violations of each type. Evaluate the violations in the List of Accessibility Issues and determine what needs to be fixed.

    Screen capture

For a comprehensive explanation of the information and options in the List of Accessibility Issues dialog box, see "Reports: Accessibility Issues" on the iCITA Web site.

Specific Reporting Functions

In addition to the Reports tool, the Accessibility Evaluation Toolbar contains a number of functions that allow you to assess the accessibility of specific types of content within a Web page. These functions, which group together several related reporting options, are as follows:

  • The Navigation functions, which allow you to access lists of all the elements of a given type on a Web page, with accessibility information for each.

    Screen capture

  • The Text Equivalents functions, which operate similarly to the Navigation functions, but evaluate content that usually requires text equivalents to be fully accessible, such as images and HTML objects.

    Screen capture

  • The Scripting functions, which also operate similarly to the Navigation functions, but evaluate the accessibility of dynamic content on a Web page.

    Screen capture

  • The Style functions, which evaluate the aspects of a page's content that are usually set via CSS, such as the color contrast between foreground and background.

    Screen capture

For a comprehensive explanation of the information and options provided by these functions, see the individual sections in the left sidebar of the extension documentation.

Validators

The Validators group of functions gives you quick access to several source code validators, both for HTML and CSS, as well as for more specific types of contents (such as the W3C Link Checker).

Screen capture

Although their individual purposes vary, validators in general check the correctness of your code against the language's prescribed standards.

For a comprehensive explanation of the Toolbar's various validation tools, see the "Validation" section of the extension documentation.

Tools

The Tools section of the Accessibility Evaluation Toolbar provides links to a number of other accessibility evaluation tools on the Web. Although these validators have some overlap in their functionality, they differ with regard to the accessibility information they provide, and to the amount of code they can assess (i.e. single Web pages vs. entire sites).

Screen capture

For a comprehensive explanation of the evaluation tools to which the Toolbar links, see the "Tools" section of the extension documentation.

Keyboard Options

The Keyboard options allow you to enable keyboard shortcuts for the Toolbar's reporting functions. When Enable Keyboard Enhancements is turned on, the Toolbar will map specified keys to certain types of elements within the page, such that pressing a certain key will put focus on an element of that kind.

Screen capture

You can also choose to enable keyboard shortcuts, which will bring up accessibility information for a certain type of element, the same information available via the Toolbar's reporting tools. For example, pressing Shift + T will bring up information on the current page's title, which is also available through the Toolbar's Navigation functions.

For a comprehensive explanation of the Accessibility Evaluation Toolbar's keyboard options, see the "Keyboard" section in the left sidebar of the extension documentation.

Top of page

WAVE Toolbar for Firefox

The WAVE Toolbar, available free at http://wave.webaim.org/toolbar, is a Firefox add-on created by WebAIM to allow the user to quickly assess the accessibility of a given Web page.

It is essentially identical to the online WAVE Webpage Accessibility Evaluator, but allows a user to test password protected pages, preview pages or unposted .html files.

Errors, Features, and Alerts

The primary evaluation function of the WAVE toolbar is the Errors, Features, and Alerts button.

Screen capture

This function displays your Web page with icons indicating accessibility features, errors, and alerts (elements that require human evaluation), as well as structural and semantic elements. By viewing your Web page with these icons embedded, you can easily determine any potential accessibility issues.

Example WAVE Output Icons

For example, in the screen capture below, the toolbar found a number of issues with an HTML form, including:

  • A form with several input fields missing the LABEL tag (indicated with a red no-label icon)
  • An empty <h2> tag (indicated with a blue H2 icon plus a red warning icon).
  • The blue table icon also indicates the form is enclosed in a layout table

Screen capture

The WAVE Web site contains a comprehensive list of the accessibility icons, complete with descriptions and explanations of each.

Note: WAVE is not tied to WCAG 2.0 guidelines. However, WAVE's criteria for an accessible Web page are generally accepted best practices.

Structure/Order

The Structure/Order function displays your Web page with graphics emphasizing its structure and reading order. This function allows you to quickly determine whether your page's reading order is logical, and therefore whether the page will make sense when read by a screen reader or viewed with style sheets disabled.

Screen capture

Text-Only

The Text-only function displays only the text-based elements of your Web page, including any text alternatives provided for graphical or other non-text content. This function can give you a general idea of the content that will be read by a screen reader.

Screen capture

Outline

The Outline function displays only the headings on your Web page, which can help you determine if the headings are properly nested, and if the structure of the page's content is logical.

Screen capture

Disable Styles

The Disable Styles function will turn off style sheets for the current Web page. Some users, including those with visual impairment, may view the Web with style sheets disabled, so this function is useful for testing a Web page's overall accessibility, including the semanticism of the markup.

Screen capture

More Information

For more information on the WAVE Toolbar, see WebAIM's WAVE Help and About WAVE, or click on the Tools button in the toolbar and select Toolbar Help or About.

Top of page

Accessibility Test Pages

This section links to some accessibility test pages.

Untitled On Purpose - An Inaccessible Page

This page includes basic accessibility errors and can be used to test reporting tools. It mirrors content from the Color Deficient Vision Detail Page

Color Design Gone Bad

The human eye contains rods which detects levels of light (dark versus bright) and three kinds of cones which distinguish among the different colors. If none of the cones are functioning (very rare), then a person has grayscale vision. If the cones are semi-functional (also rare), then the person sees colors, but they are muted.

More commonly, a person with color blindness (or "color deficiency") has a difference in only one of the rods, and it is usually either the red rod or the green rod. The result is that some colors appear to be more similar or are muted. The different type of deficiencies are simulated below. Read more about different type of color vision here and here.

Merry Christmas: Why Red Green is Problemetic

Almost 10% of men are red/green color blind. Despite the fact that red-green contrasts are very distinct for the vast majority of viewers, there are significant number of people for whom this is non-functional.

NOTE: Red-Green color blind people are better able to find camouflaged objects in natural settings. See This Article for more details.

Images Gone Bad: Merry Christmas in Different Color Vision Modes

The image below is "Merry Christmas" in green text on a red background which a color blind person may not be able to read. This is also problematic because it causes a visual vibration for users with normal color vision.

In Grayscale

full color (incorrect - it's grayscale)

In grayscale, there is only a slight contrast because red and green are of nearly equal brightness.

In Deuterope Mode (Red/Green Color Blindness)

Appears as dark olive on medium olive in normal color vision. Simulation courtesy of Visicheck.

Merry Christmas, Red/Green Colorblind Mode

Tables Gone Bad: Possible Contrasts

Here are some tables of good vs. not so good contrasts.
These contrast examples are by color scheme type.

Orange/White

Orange vs. Red-Orange

orange on white
#FF6600 on #FFFFFF

2.94:1 (fail)

red-orange on white
#DD3300 on #FFFFFF

4.61:1 (pass at AA)

Gray/White

Tests on Different Values of Gray on White
Grey Level WCAG Ratio
#000000 (Black) 21 : 1 (pass)
#333333 12.63 : 1 (pass)
#666666 5.74 : 1 (pass)
#777777
#777777 (large)


4.48 : 1 (fail)
OK for large text
#999999 2.85 :1 (fail)
#CCCCCC 1.61 : 1 (fail)

Forms Gone Bad: Comments

Your Name Your E-Mail Your Affiliation

 

What are your comments?

Try this Comment Form




 

List of Errors

  1. Page title?
  2. Vague link text
  3. Some images missing ALT tags. One has inaccurate ALT tags
  4. Some headings not H2, but just enlarged text
  5. Empty H2 tag (Dreamweaver artifact)
  6. Some text has low contrast and is small (typical of footer text on many sites)
  7. Some tables lack captions and proper headers
  8. Some forms have unlabeled fields

 

 

Top of Page

Inaccessible HTML Code from Word

Although Microsoft Word gives users the ability to generate XHTML files, the results generally contain an unnecessary amount of specifications that render them largely inaccessible.

Intended Result

Default font and size, enclosed in P tags

"This is a sample of unformatted, normal text."

<p>This is a sample of unformatted, normal text." (default font and size, enclosed in P tag)</p>

Actual Result

XHTML file with embedded styles that fixes text at Times New Roman, 12 point.

This is a sample of unformatted, normal text.

<p style="font-size:12pt; font-family:'Times New Roman'">This is a sample of
unformatted, normal text.</p>

Here's the Full Code

This code was generated in Word 2002. For an example of code generated in Word 2008, see the Microsoft Office Page. Even newer versions generate an extesive number of styles, many of which are usually unnecessary.

Problematic Code Generated by Word

<html xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:w="urn:schemas-microsoft-com:office:word"
xmlns="http://www.w3.org/TR/REC-html40" >
more code, return to top
<head >
<meta name=Title content="This is normal unformatted text" >
<meta name=Keywords content="" >
<meta http-equiv=Content-Type content="text/html; charset=utf-8" >
<meta name=ProgId content=Word.Document >
<meta name=Generator content="Microsoft Word 10" >
<meta name=Originator content="Microsoft Word 10" >
<link rel=File-List href="WordtoHTML_files/filelist.xml" >
<title >This is normal unformatted text </title >
<!--[if gte mso 9] > <xml >
<o:DocumentProperties >
<o:Author >Elizabeth Pyatt </o:Author >
<o:Template >Normal </o:Template >
<o:LastAuthor >Elizabeth Pyatt </o:LastAuthor >
<o:Revision >1 </o:Revision >
<o:TotalTime >1 </o:TotalTime >
<o:Created >2003-10-22T19:05:00Z </o:Created >
<o:LastSaved >2003-10-22T19:06:00Z </o:LastSaved >
<o:Pages >1 </o:Pages >
<o:Company >ETS </o:Company >
<o:Lines >1 </o:Lines >
<o:Paragraphs >1 </o:Paragraphs >
<o:Version >10.2418 </o:Version >
</o:DocumentProperties >
</xml > <![endif]-- > <!--[if gte mso 9] > <xml >
<w:WordDocument >
<w:DisplayHorizontalDrawingGridEvery >0 </w:DisplayHorizontalDrawingGridEvery >
<w:DisplayVerticalDrawingGridEvery >0 </w:DisplayVerticalDrawingGridEvery >
<w:UseMarginsForDrawingGridOrigin/ >
<w:Compatibility >
<w:SpaceForUL/ >
<w:BalanceSingleByteDoubleByteWidth/ >
<w:DoNotLeaveBackslashAlone/ >
<w:ULTrailSpace/ >
<w:DoNotExpandShiftReturn/ >
<w:AdjustLineHeightInTable/ >
</w:Compatibility >
</w:WordDocument >
</xml > <![endif]-- >
<style >
<!--
/* Font Definitions */
@font-face
    {font-family:"Times New Roman";
    panose-1:0 2 2 6 3 5 4 5 2 3;
    mso-font-charset:0;
    mso-generic-font-family:auto;
    mso-font-pitch:variable;
    mso-font-signature:50331648 0 0 0 1 0;}
@font-face
    {font-family:Arial;
    panose-1:0 2 11 6 4 2 2 2 2 2;
    mso-font-charset:0;
    mso-generic-font-family:auto;
    mso-font-pitch:variable;
    mso-font-signature:50331648 0 0 0 1 0;}
@font-face
    {font-family:Palatino;
    panose-1:0 2 0 5 0 0 0 0 0 0;
    mso-font-charset:0;
    mso-generic-font-family:auto;
    mso-font-pitch:variable;
    mso-font-signature:50331648 0 0 0 1 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
    {mso-style-parent:"";
    margin:0in;
    margin-bottom:.0001pt;
    mso-pagination:widow-orphan;
    font-size:12.0pt;
    font-family:Palatino;}
h3
    {mso-style-next:Normal;
    margin-top:12.0pt;
    margin-right:0in;
    margin-bottom:3.0pt;
    margin-left:0in;
    mso-pagination:widow-orphan;
    page-break-after:avoid;
    mso-outline-level:3;
    font-size:13.0pt;
    font-family:Helvetica;}
p.MsoBodyText, li.MsoBodyText, div.MsoBodyText
    {margin:0in;
    margin-bottom:.0001pt;
    mso-pagination:widow-orphan;
    font-size:12.0pt;
    font-family:Palatino;
    color:#993366;
    font-weight:bold;}
p.HeaderE, li.HeaderE, div.HeaderE
    {mso-style-name:HeaderE;
    margin:0in;
    margin-bottom:.0001pt;
    mso-pagination:widow-orphan;
    font-size:16.0pt;
    font-family:Palatino;
    font-weight:bold;}
p.SubHeadE, li.SubHeadE, div.SubHeadE
    {mso-style-name:SubHeadE;
    margin:0in;
    margin-bottom:.0001pt;
    text-align:center;
    mso-pagination:widow-orphan;
    font-size:12.0pt;
    font-family:Palatino;
    font-weight:bold;}
p.TitleE, li.TitleE, div.TitleE
    {mso-style-name:TitleE;
    margin:0in;
    margin-bottom:.0001pt;
    text-align:center;
    mso-pagination:widow-orphan;
    font-size:18.0pt;
    font-family:Palatino;
    font-variant:small-caps;}
p.FigureText, li.FigureText, div.FigureText
    {mso-style-name:"Figure Text";
    margin:0in;
    margin-bottom:.0001pt;
    mso-pagination:widow-orphan;
    font-size:10.0pt;
    font-family:Helvetica;
    font-weight:bold;}
p.RedBold, li.RedBold, div.RedBold
    {mso-style-name:RedBold;
    margin:0in;
    margin-bottom:.0001pt;
    mso-pagination:widow-orphan;
    font-size:12.0pt;
    font-family:"Times New Roman";
    color:red;
    font-weight:bold;}
p.Sub-SectionHeading, li.Sub-SectionHeading, div.Sub-SectionHeading
    {mso-style-name:"Sub-Section Heading";
    margin-top:0in;
    margin-right:0in;
    margin-bottom:6.0pt;
    margin-left:.25in;
    mso-pagination:widow-orphan;
    font-size:12.0pt;
    font-family:Arial;
    font-weight:bold;}
p.Sub-SectionParagraph, li.Sub-SectionParagraph, div.Sub-SectionParagraph
    {mso-style-name:"Sub-Section Paragraph";
    margin-top:0in;
    margin-right:0in;
    margin-bottom:6.0pt;
    margin-left:.5in;
    mso-pagination:widow-orphan;
    font-size:12.0pt;
    font-family:"Times New Roman";
    letter-spacing:-.5pt;}
p.MainSectionHeading, li.MainSectionHeading, div.MainSectionHeading
    {mso-style-name:"Main Section Heading";
    mso-style-parent:"Heading 3";
    margin-top:0in;
    margin-right:0in;
    margin-bottom:6.0pt;
    margin-left:0in;
    mso-pagination:widow-orphan;
    page-break-after:avoid;
    font-size:16.0pt;
    font-family:Arial;
    font-weight:bold;}
p.TitleHeading, li.TitleHeading, div.TitleHeading
    {mso-style-name:"Title Heading";
    margin:0in;
    margin-bottom:.0001pt;
    text-align:center;
    mso-pagination:widow-orphan;
    font-size:24.0pt;
    font-family:Arial;
    font-weight:bold;}
@page Section1
    {size:8.5in 11.0in;
    margin:1.0in 1.25in 1.0in 1.25in;
    mso-header-margin:.5in;
    mso-footer-margin:.5in;
    mso-paper-source:0;}
div.Section1
    {page:Section1;}
-- >
</style >
</head >

<body bgcolor=white lang=EN-US style='tab-interval:.25in' >


<div class=Section1 >

<p class=MsoNormal >This is a sample of unformatted normal text </p >

</div >

</body >

</html >

Top of Page

Website Accessibility

Accessibility options for different HTML tags and Web-based technologies. See options in the alphabetical list below.

HTML and Web Page Accessibility

Alphabetic List by Tag/Technology

This is a list of techniques of accessifying Web page for multiple HTML objects as well as additional Web page technologies.

Abbreviations in HTML

In general, screen readers do not recognize abbreviations and acronyms, and generally read them as if they were typical English words. For instance the phrase "ITS at PSU" would not be read by screen readers as the intended "I.T.S. at P.S.U.", but as "It's at Sue". Here are some workarounds to help deal with this issue.

Synopsis

  1. Using periods between letters (e.g. P.S.U. versus PSU) in an acronym may help screen readers parse the acronym.

  2. When writing ALT tags with acronyms, add spaces between characters (e.g. <alt="P S U" >).

  3. For unusual abbreviations and acronyms, supply a key with their meaning (e.g. "ITS (Information Technology Services"))

Note on ABBR and ACRONYM Tags

In the past the use of ABBR or ACRONYM tags has been recommended, but due to browser inconsistencies, it is difficult to use one tag consistently.

For example, HTML 5 is deprecating the ACRONYM tag, yet this tag has been more widely supported in older browsers, including Internet Explorer 6.

Top of Page

Auto Datestamps without Javascript

With JavaScript

Although JavaScript can be used to create accessible content, the code must be constructed with care. See the Scripts page for more information.

If you wish to include an automatic date generator without JavaScript, the following options are available. All these options add special tags as HTML comments that allow the date to be updated by the Web editor, content management system or the server.

"Insert Date" in Dreamweaver

Dreamweaver allows you to insert a date in a format that updates itself every time you save the file.

To Insert the Date:

  1. Go the the Insert menu and select Date (or choose the Calendar icon in the Common tab of the toolbar).
  2. In the pop-up window, select the desired format and check the Update automatically on save option.
  3. Save the document and the current date will be displayed. See the example below.

Dreamweaver Auto Date (in Military-Style Time)

This file was last saved on - December 14, 2011 12:56

View the Code (Date is not updated)

<!-- #BeginDate format:Am1m -- >December 14, 2011 12:56 <!-- #EndDate -- >

Top of Page

Server Side Includes (SSIs)

You can include a snippet of code that instructs the server to change the date everytime you upload the file. To do so:

  1. Write <!--#echo var="LAST_MODIFIED"-- > wherever you want a date to appear.

  2. Save your file with the .shtml extension to indicate that a server needs to parse a server side include.
    NOTE: Some servers support this extension even if the file type is .html. Test your page or check with your administrator for details. Also see the Penn State ITS Knowledge Base for setting up SSI support within .html files in your own directory.

Top of Page

Bold and Italic Formatting

Bold Instead of Italics

Italics in print are used for a number of reasons, including listing book and movie titles, foreign words and mathematical variables, and for emphasis. Unfortunately, italic text is often not as clear on the Web, so many editors use bold face, or a combination of bold and italics, where italics alone would be used in print. See the examples below.

Print Formatting

The book Le Petit Prince is considered to be poétique et philosophique in French literary culture (See French Wikipedia: Le Petit Prince).

Web Formatting 1 (Bold)

The book Le Petit Prince is considered to be poétique et philosophique in French literary culture (See French Wikipedia: Le Petit Prince).

Web Formatting 2 (Bold and Italics)

The book Le Petit Prince is considered to be poétique et philosophique in French literary culture (See French Wikipedia: Le Petit Prince).

Top of Page

B Versus STRONG

Many accessibility experts recommend using STRONG instead of B for bold face text, and EM instead of I for italic text. The reasons for this recommendation are:

  1. STRONG and EM are semantic tags, meaning that they indicate that the author wishes to provide emphasis, which is rendered as bold/italic on a visual browser or in different speaking styles on a screen reader.

  2. In theory, screen readers could pronounce STRONG and EM in a different voice or style. However this rarely happens in practice (the same is true for B and I tags).

It should be noted, however, that many authors specify bold or italics purely for visual reasons. In these cases, B or I may be better because having a screen reader switch voices without adding true emphasis may be distracting.

NOTE: No accessibility specifications require eliminating the use of the B and I tags, just that they be appropriately used.

Some possible semantic uses of bold & italics.

These items are examples of items that could be tagged as STRONG and EM.

  1. Warning labels
  2. Key concepts or key vocabulary items in a course.
    But using bold face to highlight every instance of emphatic intonation could be just a bit distracting within a long text but could be useful in visual browsers.

Some possible visual uses of bold & italics

  1. To make colored text or small text more distinct and legible.
  2. Academic conventions, including:
    • Book and movie titles (e.g. Gone with the Wind)
    • Foreign words in an English text (e.g. "The Spanish word for cat is el gato.")
    • Variables in math, science and computing texts (e.g. x = 2)
  3. To make menu items, titles or navigation tools more distinct.
  4. Helping users on a visual browser scan for key concepts that may be delimited in another way (e.g. special punctuation) within the text.
  5. For design-related purposes.

Top of Page

Using CSS

When bold face or italics is primarily visual and tied to a specific presentational use, it is often better to include a CSS specification for bold face or italics. For instance, if you want a CAPTION tag within a TABLE to always be bold or bold and italics, you can use a CSS declaration such as:

Examples of using CSS for bold and italics

caption {font-weight:bold}
caption {font-style: italic; font-weight:bold;}

However, there may still be times when using a B or I tag to indicate visual formatting is the most efficient solution. From a standards point of view, a style sheet solution such as <span class="bold">Bold Text</span> is just as semantically vacuous as <b>Bold Text</b> and consumes many more ASCII characters in the HTML file.

Top of Page

More Alternate Tags

There are some tags which are not commonly known that are designed to represent different semantic concepts normally indicated by italics or other formatting changes. These tags are supported by all browsers and can be restyled with CSS.

CITE Tag (Italics by Default)

The CITE tag is semantically designated for short citations such as book titles. The default formatting is italics, but CSS can be used to make this tag both bold and italic.

VAR Tag (Italics by Default)

The VAR tag is semantically designated to represent variables in computer code or mathematical equations.

DEL Tag (Strikethrough by Default)

The DEL tag is semantically designated to indicate text that should be removed, and should be used as a substitute for the STRIKE tag.

The INS tag is used to indicate recently inserted text or text that replaces deleted text. The text is underlined by default, but you can use CSS to change it to another format (perhaps a new color, or with a colored background).

CODE and KBD Tags (Monospace Font by Default)

The CODE tag is semantically designated to spell out code such as HTML tags (e.g. <br />) or CSS specifications (e.g. {font-weight:bold}).

The KBD tag is designated to specify keys to be typed by a users (e.g. RETURN) in technical documentation.

Top of Page

HTML 5

The new HTML 5 specification includes additional semantic tags that can also be used in conjunction with CSS to provide appropriate markup and formatting. Some examples include:

  • FIGCAPTION – Creates visible text that describes an image.
  • MARK – Creates marked or hilighted text

Top of Page

C.S.S. (Styles)

This page includes information about using CSS (Cascading Style Sheets) for accessibility. See the list of CSS tutorials under "External Links" if you are interested in learning more about style sheets. This site also includes a page on CSS rollovers.

Synopsis

  1. The use of style sheets to provide formatting has several accessibility advantages, including the following:

    1. You can use CSS to improve legibility by increasing line spacing, increasing left and right margins and specifying fonts designed for a monitor. See some code examples below
    2. You can replace less accessible image links and JavaScript rollovers with text links styled with CSS. Text links are more accessible because they do not "pixelate" when text is zoomed.
    3. Users with colorblindness or in low visibility conditions can implement custom style sheets to enhance contrast and legibility.
    4. In some cases, the use of style sheets to specify background colors and borders can improve the accessibility of layouts and decrease reliance on HTML tables for layouts.
    5. It is easier to re-design content for alternate media such as printing and mobile technology (e.g. smart phones and Palm pilots) via alternate style sheets.

     

  2. However, care must be taken that Web sites are still readable on visual browsers with style sheets turned off. See the section "When Styling is Inaccessible" for details on what to avoid.

    WCAG 2.0 Guideline 1.3.1—"Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text."

    NOTE: The iCita Firefox Accessibility Toolbar will allow you to display your Web page without CSS markup.

  3. CSS commands for specifying absolute font sizes should be avoided. Use relative font sizes instead.

  4. Remember that any tag can be styled. This includes accessibility tags such as TH, CAPTION, STRONG, FIELDSET, LABEL, OPTION and SELECT.

  5. Avoid using float:right, since it typically requires coders to place elements that will be displayed on the right BEFORE those on the left. Screen readers will read files in code order, not in layout order. A layout table may sometimes be more accessible than complicated CSS layouts.

  6. If you use absolute positioning, be sure that the positioned text is in logical order, so that it will be coherent with CSS disabled.

  7. Do not use "visibility: hidden" to hide text from visual browsers; it also hides it from screen readers. See the Skip Nav page for accessible methods for hiding text for details.

  8. Style sheet commands should be stored in a separate .css text file, not embedded in the HTML document itself. This allows users to completely override your style sheet.

Top of Page

Some Benefits of Style Sheets

Style sheets are designed to allow you to globally specify colors, fonts and backgrounds for an entire Web site. For instance, if you specify that all H1 tags should be centered, then you do not need to repeat the ALIGN="center" tag on every page.

Here are some examples of how style sheets can improve accessibility and reduce code maintenance.

Line Spacing and Margins

The generic specifications for margin and line spacing are not optimized for screen legibility. Compare the following two paragraphs - one with legibility-enhancing styles and one with no styling.

With CSS

Increased side margins, Verdana specified and line spacing increased slightly.

SAMPLE PARAGRAPH: Style sheets are designed to allow you to globally specify colors, fonts and backgrounds for an entire Web site. For instance, if you specify that all H1 tags should be centered, then you do not need to repeat the ALIGN="center" tag on every page.

View the Code

body: {margin-left: 25px; margin-right: 25px;
font-family: Verdana,Arial,Helvetica,sans-serif;
line-spacing: 120%}

Without CSS

Text goes to edge of screen, is single-spaced and in Times New Roman (not ideal for monitors).

SAMPLE PARAGRAPH: Style sheets are designed to allow you to globally specify colors, fonts and backgrounds for an entire Web site. For instance, if you specify that all H1 tags should be centered, then you do not need to repeat the ALIGN="center" tag on every page.

Coloring and Aligning H Tags

Sample H1 - Centered and colored blue

With CSS

h1 {color: #000066; text-align: center;}

...

<h1 > Sample H1 </h1>

Without CSS

<h1 align="center"> <font color="#336699> Sample H1 </font> </h1>

Creating Formatting DIVs Resembling Tables

This is a centered pink div with dotted black border. Actually it's a P with a style specification.

With CSS

.pinkdiv {border: 1px dotted black;
background-color: #FFAADD;
padding: 7px;
margin-left: 150px; margin-right: 150px;}

...

<p class="pinkdiv" > I want a centered pink div area </p >

Without CSS

Displaying colored or dotted borders is extremely difficult without CSS, and would probably require nested tables. See the code below for a pink table with a solid black border.

<table align="center" width="60%" cellpadding="7" border = "1">
<tr>
<td bgcolor="FFAADD"> I want a pink table </td>
</tr>
</table>

NOTE: Data tables are still the best option for presenting tabular data.

Top of Page

When Styling is Inaccessible

CSS can cause accessibility problems if not thoughtfully executed. Below are some examples.

Float: Right and Absolute Positionong

Some sites use different "floats" to position content without tables. However, some style attributes, such as float: right cause text to be placed in an order different from that of the HTML file. For instance, the following site uses float: right to position the gray box to the right of a list of links. See the page on CSS: Ensuring that Text Order is Logical for details.

Non-Contrastive Backgrounds

Whatever theme or color scheme is used, it should have sufficient contrast between text and background. In manymodern sites, the contrast is too muted to meet WCAG AA standards.

Mixing Styles with Old Formatting Tags

This Web site has a black linen background with a pale rose area in the center with dark text. The color contrast is sufficent.

Stitching site with blackbaground and pink text area

The designer used CSS for the pink area and an HTML tag to specify the black linen background as <body background="blacklinen.gif">.

website with CSS on

 

Styling Turned Off - Inaccessible

Because only the rose text was formatted with CSS, when the style sheet was turned off, the result was black text and blue links on a black textured background - clearly unreadable in a visual browser.

no css, black on black

 

Styling Turned Off - Accessible

Once the site was redesigned so that the background image was included in the CSS file and not in the HTML, the site without CSS was readable, although it appears with standard white background with black text.

without css, black on white

Notice that the use of H tags to provide content structure means that sections are easier to distinguish even with style sheets turned off.

Top of Page

C.S.S. Rollovers

Synopsis

  1. If you use rollovers to change text format, consider using CSS rollovers. They generally do not interfere with screen readers, are better for low vision users because they edges remain crisp when the page is zoomed and are usually easier to maintain on the fly. See below for examples of different types of CSS Rollovers.

  2. Rollover links should be distinct from other text even in the "Off" state. Otherwise many users, especially those with older browsers may not realize they are there.

  3. If you use an image rollover with Javascript, then make sure the ALT tag in the "Off" image is descriptive. For rollovers showing complex concepts, make sure a text description is included. See example below.

Top of Page

CSS Rollovers: Font Color Change

There are several specifications you can use to create a different type of rollover effects including changes in font color and style, changes in color background and additions of borders to create "buttons". This page will start with examples of font format changes.

Note: These techniques will work in Firefox, Mozilla, Internet Explorer, Safari or Opera, but not in earlier browsers such as Netscape 4.7. It is important to make sure that links are distinctive even in the "off" state.

For global specifications, you would need to create a . css file and write specifications for these classes:

a (all links)
a: hover (links with the mouse cursor over it)
a: focus (links tabbed to on a keyboard)
a: visited (visited links)

Here is some code for making all links navy blue (#000066) which change to bright green (#006633) when the mouse passes over it. I've also specified "font-weight: bold" in order to make the links more visible.

Links which turn Green

C.S.S. File Specification

a {color: #000066; font-weight: bold} /*Navy Blue*/
a:hover, a:focus {color: #006633; font-weight: bold} /*Green*/
a:visited {color: #9900FF; font-weight: bold} /* Purple */

HTML Code

<a href="#">Green Link </a>

Sample Link (No Effect in Netscape 4.7)

Green Link

 

The key to the rollover is in the specification in the a:hover (mouse effect) and b:focus (keyboard effect) classes. Because they have been specified as a different color than the a (anchor) tag, all links for a document linked to that style sheet will change to green when the mouse rolls over it or a person tabs to it on a keyboard. The style is coded once, but all links become rollovers automatically.

C.S.S. Rollovers: Changing the Background Color

With style sheets, you can also add specifications to change the background color of a link. In this case, this is done by doing nothing to a, but making the a:hover/a:focus tags change its color to white and it's background-color to gray (#333333). A left-padding and a right-padding of 3 pixels have been added to make the item more "button" like.

Links which change background colors

CSS File Specification

a {padding-left: 3px, padding-right: 3px}
/* You need to specify padding in order to keep the text in the same position as in a:hover */

a:hover, a:focus {color: #white; background-color: #333333
             padding-left: 3px, padding-right: 3px }

HTML Code

<a href="#">Background Changing Link </a>

Sample Link

Background Changing Links

Top of Page

C.S.S. Rollovers: Classes for Special Navigational Links

One advantage of stylesheets is that you can create specify different behaviors of the same tag depending on the context. For instance, many sites visually distinguish between two types of links - those embedded in the text and those used for general navigation (e.g. "Home" and "Sitemap"). Links embedded in the text are typically underlined, while those used for navigation may be made to look more "button" like with different background colors and no underlining.

In this first example, I will create a class of navigation links which are bigger, green (#006633) and not underlined. When a mouse rolls over them, an underline will appear and the color will change to black. Links like these might be placed within a colored table layout cell, toolbar or div.

The first step is to create a class of links called "mainnav". This is done by declaring "a.mainnav," then specifying the style classes as before. In this case I need to add a statement "text-decoration:none" in order to block the default underline of most links. To get the underline to appear at a mouseover, a parralel "a:hover.mainnav" and "a:focus.mainnav" classes are declared and specified as "text-decoration: underline." Finally, in order to block any color changes for visited links, a statement a:visited.mainnav is added and given the same values as a.button.

Within the HTML file, all links which are meant to be button like are specified as <a class="mainnav" href="" >. See the example below.

Green Plain Text Button Style Link

C.S.S. File Specification

/* .mainnav means the "mainnav" class*/

a.mainnav {font-weight:bold; font-size: 125%; color: #006633
             text-decoration: none }

a:visited.mainnav {font-weight:bold; font-size: 125%; color: #006633
             text-decoration: none }


/* You need to specify identical formats for a.button and a:visited.button in order to keep appearance the same*/

a:hover.mainnav, a:focus.mainnav {color: black; text-decoration:underline}

HTML Code

<a href="#" class="mainnav" >Main Navigation Link </a >

Sample Link

Main Navigation Link

Top of Page

C.S.S. Button Style Links: Simple

The trickiest type of link to encode are links which look like buttons. The simplest way to do it is to create a class of link which has one background color for the a and a:visited statements and another for a:hover. Here a class called "button1" has been created which starts out with black, non-underlined text with a pink background (#FFCCFF) and changes to white text on a purple background. As with the second case, a left and right padding of three pixels have been added. See the example below.

Simple Gray Button

C.S.S. File Specification

/* .button1 means the "button1" class*/

a.button1 {font-weight:bold; font-size: 125%; color: black;
             background-color: #FFCCFF; text-decoration: none;
             padding-left: 3px; padding-right: 3px}

a:visited.button1 {font-weight:bold; font-size: 125%; color: black;
             background-color: #FFCCFF; text-decoration: none;
             padding-left: 3px; padding-right: 3px}

/* You need to specify identical formats for a.button and a:visited.button in order to keep appearance the same */

a:hover.button1, a:focus.button1 { color: white;
             background-color: purple; text-decoration: none;
             padding-left: 3px; padding-right: 3px}

HTML Code

<a href="#" class="button1" >Simple Button Style Link </a >

Sample Link

Simple Button Style Link

Top of Page

C.S.S. Button Links with Borders

Changing the background color is still somewhat limited though. Ideally, one would also want to specify borders, and add additional padding at the top and bottom of a link.

Defining the Styles

For this example, I will create a class of links which have a gray background (#CCCCCC), a padding of five pixels and a black, three pixel solid border. When the mouse rolls over it, the link will become black with white text and a white border.

In order to access controls for borders and padding, you must specify that a specific class of links will be treated as a "block", like a P or H1, instead of as a "span". This is done by specifying a region such as a P, here called "navgation" within which a, a:visited and a:hover will behave as "blocks". To declare this, a statment p.navigation a is added and given its features. The browser will interpret these as meaning that any A tag found within a <p class="navigation" > statement will behave as a block. The p.navigation class itself contains specifications for font size, center alignment and a width of 50% of the page. These standardize the appearance of the "button" across the three type of a classes.

The statement for p.navigation a specifies no underlining, bold face and background-color as before. The property display:block will access the additional properties such as padding: 5px and border: 1px solid black. Similar statements for p.navigation a:visited and p.navigation a:hover are needed to complete the effect. See the example below.

Complex Rollover Button

C.S.S. File Specification

p.navigation {font-size: 125%; font-weight: bold; text-align: center;
                 width: 50% }
/*p.navigation is the holder unit for the block links. It also specifies larger bold text*/

p.navigation a {display:block; color: black;
             background-color: #CCCCCC; text-decoration: none;
             padding: 5px; border: 3px solid black}

p.navigation a:visited {display:block; color: black;
             background-color: #CCCCCC; text-decoration: none;
             padding: 5px; border: 3px solid black}

p.navigation a:hover, p.navigation a:focus {display:block; color: white;
             background-color: black; text-decoration: none;
             padding: 5px; border: 3px solid white}

HTML Code

<p class="navigation"> <a href="#">Complex Button Link </a> </p>

Sample Link

Top of Page

Image Rollovers

Since CSS can also be used to specify background images, almost all the visual effects found in a JavaScript rollover are available through CSS.

First, you will need to know the pixel dimension of your image. Note that if two images are used, the total dimensions should be the same, even if you add visual padding in one image.

Note: If the rollover is being used to compare two images, then a text description must be included in either hidden or visible text.

Defining the Styles

In this case, the links are embedded in a p.surprise class which is set to the height and the width of the image(s) - which is 250 pixels wide and 50 pixels high. As with the previous example, the A tags must be treated as a block so that the background can be formatted with CSS. Images are specified in the background-image: url() specification.

In this case, only the a:hover is specified with a background image. The a and a:visited just have a color code for their backgrounds.

Image Rollover in CSS Button

C.S.S. File Specification

p.surprise {font-size: 125%; font-weight: bold; text-align: center;
width: 250px; height: 50px}
/*p.surprise is the holder unit for the block links. Height and width match that of the image. It also specifies larger bold text*/

p.surprise a {display:block; color: black;
background-color: #CCCCCC; text-decoration: none;
padding: 5px; border: 1px solid black}

p.surprise a:hover, p.surprise.focus {display:block; color: black;
text-decoration: none; background-image:url(surpriseme.gif);
padding: 5px; border: 1px solid black}

p.surprise a:visited {display:block; color: white;
background-color: black; text-decoration: none;
padding: 5px; border: 1px solid white}

HTML Code

<p class="surprise">&nbsp; </p>

Sample Link

Surprise Me

This rollover should reveal a colorful spectrum background image.

Top of Page

Javascript Rollovers

There may a few cases in which it is desirable to create a rollover with Javascript, but there are some guidelines to follow.

  • The ALT tag describes the two images - in this case alt="Color Chart versus Grayscale Chart". If this were a link, the ALT tag would describe the location of the link.

  • Follow other guidelines for JavaScript and other scripting processes.

  • If the comparison of the two images were critical, then a link to a longer text description describing the change would be needed. For example:

  • This rollover shows a color bar chart with red, blue and green contrast with a grayscale version in which the contrast is almost muted. It is an example of how color coding alone can be inaccessible.

    Top of Page

    C.S.S.: Ensuring that Text Order is Logical

     

    Whenever a document is organized so that information is in multiple columns or multiple text areas (e.g. text captions, unusual placement of icons/text), then it is important to verify that the screen reader reads the information in a logical or coherent order.

    WCAG 2.0 Guideline 1.3.1—"Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text."

    For Web pages, an important principle to remember is that screen readers read pages in HTML code order. However, the improper use of CSS and table layout could cause the visual order to be different from code order.

    The information below will provide some potential roadblocks CSS stylesheets can present and suggestions for how to avoid them.

    Synopsis

    1. Avoid using float:right, since it typically requires coders to place elements that will be displayed on the right BEFORE those on the left. Screen readers will read files in code order, not in layout order. A layout table may sometimes be more accessible than complicated CSS layouts.

    2. If you use absolute positioning, be sure that the positioned text is in logical order within the HTML code, so that the text will be coherent with CSS disabled.

    3. Do not use "visibility: hidden" to hide text from visual browsers; it also hides it from screen readers. See the Skip Nav page for accessible methods for hiding text for details.

    Top of Page

    Dangers of Float:Right

    The float:right specification is used to place items to the right side of the page. However, the text floated to the right is often placed BEFORE other text to its left in the HTML. Thus the visual order may be left to right (with the floated item second) while the HTML item will read the floated item first.

    See the example below which compares the position of elements with CSS enabled, then disabled.

    Page with Float:Right Positioning

    Propososal submisison page with purple box listing possible projects to the right

    But in the code, the list of example projects in the right hand box actually comes first. When CSS is disabled, you can see the list above the section with the links. Fortuniately, the text can be read in either order.

    View the float:right Code

    CSS

    .projectbox { float:right; width:45%; background-color:#CCF; color: black; padding:7px; margin: 5px;}

    HTML

    <body> <div class="projectbox"> <h2>Projects can Include</h2> [ORDERED LIST] </div> <h2>View Sample Teaching Objects</h2> [TEXT] ...

    Page with CSS Disabled. "Right" is on Top

    Same page with no CSS and right text on top

    Use float:left

    A safer float to use is float:left because it moves content to the left (1st in visual order) while generally being in the correct position in the HTML. Note that even large content chunks (e.g. a 75% wide DIV) can be floated to the left.

    When float:right is OK

    The float:right attribute can be used so long as the text is still coherent in HTML order. An example is the positioning of a decorative image to the right or to the left.

    Top of Page

    Dangers of Absolute Positioning

    Absolute positioning is a technique used to place a section of content anywhere on the page regardless of it's location within the HTML. For example any item with position:absolute and position set to top:0px and left:0px will be displayed first visually, even if the div is the final text in the HTML code. Alternatively, an item may be listed first in the code, but actually be positioned to the bottom right side of the page visually.

    Note: position:fixed could present similar issues.

    An example of absolute positioning is the link to a "Surprise Web Developer Guide" which is actually positioned to the right top of page (visual users can scroll up)

    View the Code

    CSS Styles

     

    #abs { position:absolute; right:0; top:5%; z-index:10000;}

     

    strong.surprise{ padding-left: 3px; padding-right: 3px; background-color: #006; color: #FFF; margin-bottom: 7px}

     

    a strong.surprise{ color:#FFF; text-decoration:none;}

    HTML

    <p>An example of absolute positioning is the link to a &quot;Surprise Web Developer Guide&quot; which is actually positioned to the right top of page (visual users can scroll up)</p> <div id="abs"> <a href="http://www.psu.edu/dept/itscss/publish/webdev/visual.html"><strong class="surprise">Surprise Web Developer Guide</strong></a> </div>

    Lightbox Positioning

    Another way that absolute or fixed positioning is used is to display "lightboxes" or pieces of text superimposed on a grayed out Web site (such as in warnings or pop-ups). When the lightbox text is in an incorrectly placed DIV, a screenreader will skip over the lightbox and may read the text BENEATH the lightbox instead. An additional problem is that the close button on a lightbox could be inaccessible on a keybooard.

    If you wish to use a lightbox, but cannot place the lightbox text in context, consider a Javascript popup window instead. A correctly coded pop-up window can be recognized by modern screen readers and can be closed.

    When position:absolute is OK

    If this technique is needed, then the DIV should be inserted within the code where reading it within a screenreader will be logical. That is a DIV placed at the top via absolute positioning should have the code be near the beginning of the page.

    Top of Page

    CAPTCHAs

    Synopsis

    CAPTCHA forms with distorted text or audio can cause a number of issues related to accessibility. The purpose of CAPTCHA forms is to prevent automated servers and automated robotic web crawlers ("bots") from submitting forms, but in doing so, they also deny some human users access.

    Although there are workarounds available, the best approach may be to use a CAPTCHA that poses a logic question in plain text. Such questions are easy for humans to answer, but difficult for a machine to parse.

    Top of Page

    What are CAPTCHAs?

    Simply put, the CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) system is a type of form used on many Web sites. Users are asked to enter text displayed in an image, or text heard in an audio file.

    In both cases, the text is distorted (i.e. wavy in an image file or embedded in a set of whispers in an audio file). The theory is that human eyes can understand these images or recordings, but automated text readers or voice recognition systems cannot.

    Captcha text: word following on a curve with line through it

    Top of Page

    Issues With CAPTCHAs

    1. A CAPTCHA image cannot include ALT text for screen readers, because a bot would read it.

    2. Audio CAPTCHAs can interfere with screen readers unless a pause at the beginning is included.

    3. As spammers develop algorithms to break CAPTCHA systems, images and audio become more distorted, to the point where even many sighted users have difficulties identifying the text.

    Top of Page

    Captcha Alternatives

    Below are some options to the traditional image based captcha.

    Logic Question CAPTCHAs

    One method to avoid using inaccessible images or audio is to use a question rather than an image or audio. A sample CAPTCHA question might be "Which animal is larger—a mouse or a horse?"or "What state is Philadelphia located in?"

    Another class of challenge questions is math questions (e.g. "What is one plus three?").

    It should be noted that with question-based CAPTCHA systems, hackers can develop algorithms to predict questions and answers or hire users to answer CAPTCHA questions. Rotating questions is recommended for high volume sites.

    Moderators

    Another alternative for services with a relatively light traffic load is to manually approve access or postings. In many cases, when spammers realize that they cannot post automatically to a service, the rate of traffic typically drops over time.

    Spam Detection

    Some developers employ natural language filters to detect likely spam messages. Others may watch for activity coming from similar IP addresses and then present a challenge (e.g. ask for a cell phone number to which a confirmation message is sent).

    Example algorithms may also be online.

    Filters

    One developer reported that the rate of spam messages dropped significantly when he banned the string "http://" from being used in a discussion post (although web addresses without it were still allowed).

    WebAccess or Other Authentication

    Penn State services can often take advantage of WebAccess single sign-on if the target audience is the Penn State community. Penn State is also part of the InCommon Federation (aka Shibboleth), which is a technology that allows single sign-on between universities and select vendor services.

    Top of Page

    Drop-Down or Floating Menus

    Definition

    A floating menu is one that appears when you roll your mouse over a target area. Floating menus may be found on http://www.psu.edu and other Web sites.

    Potential Accessibility Issues

    Although innovative, floating menus present the following accessibility issues:

    1. Incorrectly coded menus may not work on screen readers.

    2. Users with mobility impairment may find it difficult to move the mouse and click on the correct option. The more options in the menu, the more significant the problem.

    3. If only part of the hierarchy is visible at any one time (as with scrolling menus), users with memory or cognitive disabilities may have difficulty locating a given menu.

    Top of Page

    Recommendations

    1. If your Web site includes a drop-down menu, ensure that menus can be accessed by tabbing on a keyboard and that users can also navigate through the menu with a keyboard.

      WCAG 2.0 Guideline 2.1– "Keyboard Accessible. Make all functionality available from a keyboard."

    2. According to a usability study by Jakob Nielsen, the most effective drop down menus show all options available.

    3. A text-based menu should also included in the Web site which can be accessed via a visible link.

      WCAG 2.0 Guideline 2.4.5– "More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process."

    Top of Page

    Dynamic Pages

    What's a Dynamic Page?

    Dynamic pages are created by pulling repetitive chunks of HTML code from different sources. For instance, this site uses a database engine to insert the same header and footer on each page of this Web site.

    Dynamic pages or content management systems can be a convenient way to make sure navigation blocks, skip navigation links, ALT tags in headers and so forth are consistently implemented on each page. However, almost all dynamic pages require access to special server set-ups, so require input from server administrators or programmers.

    Some Dynamic Page Types

    • AJAX
    • Server Side Includes (.shtml)
    • Active Server Pages (.asp)
    • Cold Fusion (.cfm)
    • PHP (.php)
    • Java Servlets and Java Server Pages (.jsp)
    • Perl CGI's
    • Dynamic page technology is used on content management systems such as blogs and wikis, ANGEL, Drupal and other systems

    Some Tips

    1. Implement recommendations from the WAI-ARIA working group whenever possible. ARIA support is available in Firefox 3, Opera 9.5 and is scheduled to be available in Internet Explorer 8 (in beta as of April 2008) as well as Safari 4 (in beta).

    2. Make sure all HTML code chunks include accessibility tags such as ALT tags, TH tags for data tables, LABEL tags for forms, and so forth.

    3. If your system uses Javascript links, make sure to include a link to a text-only alternative navigational system such as a Sitemap.

    4. Avoid using arbitrary database numbers for ALT tags, TITLE tags, FRAME tags and other text-alternative accessibility tags. Ideally, a content management system would allow users to enter an ALT tag text for an uploaded image.

      Inaccessible ALT Tag

      <img src="1103AB43.jpg" alt="Image_1103AB43.jpg" >

      A screen reader would say Image 1103AB43.

    5. If possible, use a script to convert dynamic page style links (e.g. www.mysite.psu/main.php?id=11) to more traditional type links (e.g. www.mysite.psu/page11.html) They are less likely to encounter compatibility issues with screen readers or older browsers.

    Links

    Some Server Side Include Tutorials

    If you wish to experiment with dynamic page creation, the simplest technology is probably Server Side Includes. The rest require either extensive programming, access to a database backend or both.

    Top of Page

    Font Face on the Web

    List of Recommended Fonts

    Below is a list of recommend fonts and fonts which should be used sparingly.

    Font Recommendations
    Highly Recommend Reasonably Accessible CAUTION: Headers Only

    These fonts are highly recommended for legibility:

    • Verdana
    • Georgia
    • Lucida Grande (Mac)/Lucida Sans (Win)

    These fonts are also legible in many dimensions:

    • Helvetica/Arial
    • Tahoma
    • Trebuchet
    • Century Gothic
    • Bookman Old Style
    • Palatino/Book Antiqua
    • Comic Sans

    These fonts should be sparingly used in headers and decorative text:

    • Arial Black
    • Arial Narrow
    • Impact/Haettenschweiler
    • Harrington
    • Monotype Corsiva
    • Any stylized font

     

    Top of Page

    Factors for Selecting Fonts

    Below are some factors that can be considered when selecting a legible font.

    Type of Fonts

    Fonts can be classified as follows

    • Serif: Strokes extend out from the top and/or bottom of the letterforms. Examples include Georgia, Times New Roman, and Palatino.
    • Sans serif font: Strokes do not extend out from the top or bottom of the letterform. Examples include Arial, Helvetica, Verdana, and Lucida Grande (Mac)/Lucida Sans Unicode (PC).
    • Monospace: Each letter has the same width. Monospace fonts can be serif (Courier New) or sans-serif (Andale Mono or Monaco [Mac]).

    Sans-serif fonts such as Verdana and Arial were originally recommended over serif fonts like Times New Roman, because monitors were not able to render fonts with serifs very accurately. A lot of detail useful in print was lost in the transition to computer monitors.

    However, advances in display technology can allow for more serif fonts to be used on the Web (if the audience is using recent operating systems and browsers).

    Font Availability

    The ideal font is one that is available to many members of the audience. Microsoft fonts are generally good choices, but some may be more recent than others, and therefore less common. Also, if your audience contains a lot of Unix users, be aware that their font selection can be different from that of Windows and Mac.

    If you specify a font in a CSS, you should include alternate backup fonts whenever possible.

    x-height

    The x-height of a font is the height of any lowercase letter without ascenders or descenders. Letters used to measure x-height include lowercase x, o, a, r, m, and s. Letters with ascenders include lowercase b, d, h, and k, and those with descenders include p, q, g, and j.

    Generally speaking the higher the x-height in relation to a capital letter, the more legible the font is likely to be.

    Distinguishing Ambiguous Characers

    Another factor in legibility is how well-distinguished similar characters are. Potentially problematic characters include capital I, number 1 and lowercase l (L), as well as 0 (zero) and capital O. Ideally, each letter or number form will be distinct.

    Weight

    Weight is a measure of a letterform's thickness in comparison to its height. Some fonts, such as Verdana, are designed with more weight than others, such as Palatino. Weight can assist with legibility because it darkens letters, but too much weight, such as in Arial Black, can make a font unsuitable for body text.

    Character Width

    Generally speaking, wider fonts are more legible than narrower fonts (within reason). One way to check width is to examine the letters x and o. You may also want to check narrow letters such as lowercase i and j to see how legible they are. A related concept is tracking, or the width between adjacent letters.

    Top of Page

    Font Samples

    Below is a list of fonts with notes on the legibility of each. Fonts are available on both PC and Mac unless otherwise specified.

    Highly Recommended Fonts
    Fonts Notes x-height I vs. 1 vs. l Zero vs. O Lower i,j
    Verdana Designed for monitors by Microsoft. Many sites on accessibility use Verdana. Xx Oo Aa Rr I vs. 1 vs. l 0 vs. O i,j
    Lucida Sans (PC)/
    Lucida Grande (Mac)
    Relatively new font. Used as a Mac system font. Xx Oo Aa Rr I vs. 1 vs. l 0 vs. O i,j
    Georgia Serif. Designed for monitors by Microsoft. Xx Oo Aa Rr I vs. 1 vs. l 0 vs. O i, j

     

    Additional Fonts of Reasonable Legibility
    Fonts Notes x-height I vs. 1 vs. l zero vs. O Lower i,j
    Helvetica Traditional print font. Available on Mac, Unix and newer versions of Windows. Some letterforms can be confused. Xx Oo Aa Rr I vs. 1 vs. l 0 vs. O i,j
    Arial A Windows analogue to Helvetica. Some typographers prefer Helvetica, but the two are generally similar. Xx Oo Aa Rr I vs. 1 vs. l 0 vs. O i,j
    Trebuchet MS Available from Microsoft. Good x-height, but some letterforms (e.g. "g" and &") considered too unusual for some readers, especially if literacy is an issue. Xx Oo Aa Rr I vs. 1 vs. l 0 vs. O i,j
    Tahoma Available from Microsoft Xx Oo Aa Rr I vs. 1 vs. l 0 vs. O i,j
    Century Gothic Sans-serif, somewhat Art Deco. Good x-height, but some letters can be confused. Weight is light. Xx Oo Aa Rr I vs. 1 vs. l 0 vs. O i,j
    Bookman Old Style Available from Microsoft. Traditional serif font designed for legibility. Good x-height, but may not be on all computers. Xx Oo Aa Rr I vs. 1 vs. l 0 vs. O i,j
    Palatino (Mac)/
    Palatino Linotype (PC)/
    Book Antiqua (PC)
    Serif. Traditional print font. Weight can be light. Xx Oo Aa Rr I vs. 1 vs. l 0 vs. O i,j
    Garamond Available from Microsoft. Traditional font, but x-height relatively small and weight is light. Xx Oo Aa Rr I vs. i vs. l 0 vs. O i,j
    Comic Sans Considered legible by some, but also criticized as being "childlike." May be appropriate for sites with younger audiences. Xx Oo Aa Rr I vs. i vs. l 0 vs. O i,j
    Times New Roman Serif. Relatively small x-height, but succeeds with regard to legibility. Xx Oo Aa Rr I vs. 1 vs. l 0 vs. O i, j

     

    Decorative: Use for Large Text Only
    Fonts Notes x-height I vs. 1 vs. l zero vs. O Lower i,j
    Arial Black Available from Microsoft. Very heavy. Xx Oo Aa Rr I vs. 1 vs. l 0 vs. O i,j
    Arial Narrow A narrow font that is probably too compressed for body text. Xx Oo Aa Rr I vs. 1 vs. l 0 vs. O i,j
    Haettenschweiler, Impact Available from Microsoft. Very narrow and heavy. Xx Oo Aa Rr I vs. 1 vs. l 0 vs. O i,j
    Harrington Available from Microsoft. letterforms are very ornate, which can slow down reading speeds. Xx Oo Aa Rr I vs. 1 vs. l 0 vs. O i,j
    Monotype Corsiva A cursive-style font. Italic-type slant can slow down reading. Xx Oo Aa Rr I vs. 1 vs. l 0 vs. O i, j

     

    Top of Page

    Font Size on the Web

    There are two main concerns here. One is ensuring that default font sizes are not too small. Another is ensuring that text can be expanded to 200% on Web sites.

    1. For traditional computer monitors, a size of 12-14 points/pixels for body is generally recommended for body text (depending on audience).
    2. Ensure that default fonts are no smaller than 9 points/pixels. Smaller sizes may be illegible beyond the Windows platform.
    3. The WCAG Guidelines recommend ensuring that text can be zoomed to 200%. Along with that goes a recommendation for liquid layouts which can accommodate 200% text.

      WCAG Guideline 1.4.4—Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

    4. When using CSS, most font sizes should be made in relative terms (e.g. %, em). This allows fonts to be displayed relative to a particular monitor setting or device.

    CSS: Relative Font Sizes

    A current accessibility recommendation is to use relative font sizes such as percentages or units of em instead of absolute sizes such as pixels or points. This allows text to be more easily resized appropriately across multiple devices and platforms.

    Top of Page

    Nine Point/Pixel Minimum

    If you are using a WYSIWYG editor that gives you the option to make text smaller, make sure the size doesn't go below 9 point or 9 pixels. Font sizes at 8 points or smaller can be illegible for many Mac users, as seen in the example below (see the section "Points Versus Pixels" below for an explanation of font sizing systems).

    The minimum font size only applies to footers, such as a copyright statement. For body text, you should leave the font size set at the default, which is usually set between 12 and 14 point).

    Eight Point Text on a Mac

    The image below shows how 8 point text can be rendered in some Mac browsers.

    8 point text in 2 fonts

    Top of Page

    Beware CSS Sizes X-Small and XX-Small

    If you're assigning styles with CSS, be cautious when using {font-size: x-small} and {font-size:xx-small} which can render text at very small font sizes. See demo below.

    Demo of Small Relative Font Sizes

    • Default Font Size
    • Small
    • X-Small
    • XX-Small

    Font/Text Layout for Web Pages

    1. Do not manually adjust text size for section headers and subheaders - use the proper heading tags instead.

    2. Avoid using fonts smaller than 9 points/9 pixels as they will become illegible on the Mac platform.

    3. Avoid specifying absolute font-sizes unless absolutely necessary; otherwise zooming may be disabled for low vision users

    4. Use font faces which more favorable for computer screens such as Verdana, Tahoma, Lucida Grande, Arial, or Georgia.

    5. Avoid underlined text except for links. Users unfamiliar with Web conventions may click on any underlined text.

    6. Avoid using italic text except for short passages or when academic convention calls for it. Italics is particularly difficult to read on a monitor; in some cases, bold face can be used in place italics.

    7. Generally use dark colored fonts on light backgrounds instead of the reverse since these are more readable.
      Note: PowerPoint presentations should be light text on dark when projected on a screen,

    8. Whenever possible, use external cascading style sheets instead of the FONT FACE tag or inline style specifications (i.e. avoid <p style="font-family: Verdana, sans-serif" >). This allows users with certain visual problems to replace your stylesheets with their own custom style sheets tailored for their needs.

    9. Avoid blinking text as it could trigger epileptic seizures in some users and is generally very distracting.

      WCAG Guideline 2.3.—Do not design content in a way that is known to cause seizures.

      WCAG Guideline 2.3.1—Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.

    10. Avoid entire text blocks of italic text, colored text, underlined text, decorative fonts and capitalized letters. These formatting choices can make text difficult to read.

    11. The use STRONG and EM tags for B and I is generally encouraged by the standards and accessibility community.

    Top of Page

    Foreign Language Web Pages and Unicode

    Synopsis

    Below are some considerations for

    1. Use Unicode encoding whenever possible. This will ensure that text is transferrable between systems including mobile platforms.

    2. Use language tagging to mark content as English or non-English. This ensures both accurate pronunciation in screen readers and enables foreign language spell checking.

    3. Users on a screenreader may need to either purchase foreign language extensions or install additional files.

    Unicode Support for Foreign Language

    Whenever possible, non-English text (including special characters such as ©, †) should be inserted as is into a document encoded in Unicode.

    Unicode is an encoding standard which assigns a numeric code to all characters across multiple scripts including Greek, Cyrillic, Asian scripts, Middle Eastern scripts, ancient scripts and technical symbols.

    This standard allows computers around the world to exchange data across multiple languages consistently and without need for custom fonts.

    The Penn State Computing with Accents and Symbols page has information about individual language, accent codes and math symbol codes.

    Unicode Meta Tag

    Note: A Web page encoded as Unicode often has a meta tag resembling the one below in the HEAD section.

    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    ...
    </head>

    Top of Page

    LANG Tag (Attribute)

    The LANG tag (i.e. the lang="" attribute) is designed to signal screen readers pronunciation engines to switch to another language. For this reason and other, tagging Web text as being in a particular language is required in WCAG 2.0.

     

    Top of Page

    Forms in HTML

    Input forms – from forms to select courses to search forms – are one of the greatest source of potential accessibility issues. As a result, there are many specific guidelines in WCAG 2.0 to help ensure that forms can be used by all.

    Synopsis

    Layout

    1. Use the LABEL tag to match a field with a label. Because some screen readers may not implement LABEL, be sure to use other strategies for logical form layout listed below.

      WCAG 2.0 Guideline 4.1.2— "For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined."

      WCAG 2.0 Guideline 3.3.2— "Labels or instructions are provided when content requires user input. "

    2. Labels should for text entry fieds be placed above or to the left or above of the corresponding element.

      WCAG 2.0 Guideline 1.1.1– "If non-text content is a control or accepts user input, then it has a name that describes its purpose."

    3. For many screen readers, the only text inside the FORM tag that is read is the LABEL and its field. Use the FIELDSET and LEGEND to add extra information.

    4. If you are using layout tables for a form, avoid placing a form field and its label in different table cells. You can use the BR tag between the label and the field if you need to place elements vertically.

    5. If more than one input field is on the same line, then the label and its element should be on the same line on the screen.

    6. If a series of checkboxes or radio buttons are used, then place each option on its own line so it is clear which option goes with each button.

    7. If there continue to be concerns about the function of a form field, you can use the default text option to provide information. For instance default text could be "Enter Penn State Access ID here".

    8. Tabbing should take users from field to field in a logical order. In some cases, the TABORDER tag should be used to modify tabbing order in complex layouts.

    9. If you include a SELECT drop-down menu with a long list of choices, uses the SIZE= attribute to add vertical height.

    10. The OPTIONGROUP can be used to divide a long list in a drop down menu into catagories.

    Required Field and Errors

    1. Required fields should be indicated with a symbol or text such as an "(R)" and not just a change in color. The best option is just "Required", but if a symbol is used, then include a key such as "(R) = Required Field" should also be included above the FORM tag.

      WCAG 2.0 Guideline 1.4.1—Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

    2. The Required Field indicator (e.g. "Required) should be included in the LABEL tag so it can be accessed by a screen reader.

    3. A form should include a separate SUBMIT or GO button to initiate a form submission. A submission upon option selection can interfere with screenreader function and also be difficult for users with motion impairment.

    4. Form error messages should identify fields with errors and the nature of the error.

      WCAG Guideline 3.3.1— "If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text."

    5. Error messages must be presented in a format detectable by a screen reader. Possible formats include a separate error page or a pop-up window. Lightboxes or updated pages should be avoided unless tested on a screenreader.

    Other

    1. If the Submit button is an image, then make sure the ALT tag says "Submit".

    2. Avoid "jump menus" which direct you to new page once you select an item. This may interfere with keyboards alternates and cause these users to only be able to go to the first item in the list. An option list with a "Submit" or "Go" button may be a better alternative.

    3. If necessary, provide an alternate way to submit the form such as phone, mail, or e-mail. It could be as simple as allowing users to print and mail a complete form or calling a contact to have that person fill out a form for them.

    4. Do not include the RESET button unless there is a legitimate demand for the need for a user to delete all the information in a form before it is submitted. It is very easy to accidentally press this button for users with motor disabilities or those using a screen reader.

     

    Top of Page

    The LABEL Tag

    This tag explicitly associates a form field with a label. The LABEL tag allows you to control the positioning of a label, although all results should be checked with a screen reader.

    Some examples are shown below.

    Sample LABEL Code

    * = Required Field

    Send Newsletter updates?

    See the Code

    Note that that because the LABEL is matched to a specified field ID, the label could follow a field (as is often the case for checkboxes and radio buttons.

    <p>* = Required Field</p>
    <p><label for="name"><b>Your Name *</b> </label>
    <input type="text" name="name" id="name" /></p>

    <p><b>Send Newsletter updates?</b><br />
    <input type="checkbox" name="newsletter" id="newsletter" />
    <label for="newsletter">Yes, please send e-mail updates once every five minutes.</label></p>

     

    Top of Page

    Optimal Layout for Forms

    Screen readers state the name of a field, then say to "input" data. Unless the labels are placed correctly users will not know which data to input in which field. Below are some accessible and inaccessible examples of form labeling.

    Inaccessible Form with Unlabeled Elements

    Instructions: Please enter your name, address, and phone number in the fields below.

      



    The form above is inaccessible because the form has three unlabeled fields. A screen reader would read it as:

    Instructions: Please enter your name, address, and phone number in the fields below.
    [INPUT] [INPUT] [INPUT]

     

    Inaccessible Form with Tables:
    Elements & Labels in Different Table Cells

     

    Inaccessible Form with Tables
    Name Phone Number Userid
    Street Address City,State Zip Code



    The form above would be read as follows in a screen reader:

    Name, Phone Number, Userid
    [INPUT] [INPUT] [INPUT]

    Street, City/State, Zip Code
    [INPUT] [INPUT] [INPUT]

     

    Accessible Form, Vertical Layout

    NOTE: You can use style sheets to make sure label text is always the same width.

     

    Accessible Form, Horizontal Layout With Tables

    Accessible Form in Table

    Although the above form is laid out in an HTML table, each label and corresponding field are in the same cell and on the same line.

     

     

    Top of Page

    Fieldset and Legend

    The FIELDSET tag is used to group similar options together and is signaled in visual browers with an outline. The LEGEND tag adds a text label to the field set. See example below.

    Fieldset and Legend for Student Year

    Identify Current Student Year

    View the Code

    <form>
    <fieldset>
    <legend>Identify Current Student Year</legend>


    <p>
    <input type="radio" name="radio1" id="freshman" value="1" />
    <label for="freshman">Freshman</label>

    <input type="radio" name="radio2" id="sophomore" value="2" />
    <label for="sophomore">Sophomore</label>

    <input type="radio" name="radio3" id="junior" value="3" />
    <label for="junior">Junior</label>

    <input type="radio" name="radio4" id="senior" value="4" />
    <label for="senior">Senior</label>
    </p>
    </fieldset>
    </form>

    SIZE in SELECT Dropdown Menus

    When a drop-down menu has a long list of selections (e.g. a list of Penn State campuses), selection may difficult for motion-impaired users who have difficulty manipulating a mouse or some cognitively disabled users who may lose track of where they are in the list.

    Including a SIZE="2" attribute increases of the height of the menu to two items displayed allowing users to enter it with a keyboard and for users to view more than one item. The SIZE can be set to other values such as "3" or "4" depending on user needs. See an example below.

    Sample Dropdown Menu of Size=3


    View the Code

    <label for="Campus">Penn State Campus Menu</label>
    <select name="Campus" id="Campus" size="3">
        <option value=""> </option>
        <option value="OZ::Abington Campus">Abington Campus (OZ)</option>
        <option value="AA::Altoona Campus">Altoona Campus (AA)</option>
    ...
    </select>

     

    Top of Page

    OPTIONGROUP in Drop Down Menus

    The OPTIONGROUP tag can be used in SELECT menus to group a long list of options into different categories in the menu. See the example below.

    Color Choice Example

    This form asks users to select a favorite color word and divides the list into types of blue-greens and types of reds.

    View the Code

    <label for="color">What is your favorite color?< /label>
    <select name="color" id="color">
    <optgroup label="Blue-Greens">

    <option value="bgteal">Teal</option>
    <option value="bgcyan">Cyan</option>
    <option value="bgaqua">Aqua</option>

    </optgroup>
    <optgroup label="Reds">

    <option value="rscarlet">Scarlet</option>
    <option value="rvermillion">Vermillion</option>
    <option value="rcrimson">Crimson</option>

    </optgroup>

    </select>
    </form>

     

    Top of Page

    Tab Order

    Most browsers enable users to use the Tab key to navigate from field to field, providing accessibility to the mobility impaired and users of screen readers. In most forms, the tab order follows a logical progression from top to bottom, but if the default order is not the one needed, then the TABINDEX attribute can be used to manually set tab order. For example:

    Sample TABINDEX Code

    <input type="text" id="textfield2" tabindex="2" >

     

    Top of Page

    Frames and iFrames

    HTML frames can be problematic because:

    • Some browsers, including mobile browsers, may have problems processing frames.
    • Individual pages can be difficult to bookmark.
    • The organization of the pages may not be clear to screen readers.
    • There is less screen space that can be used to present content.

    For these reasons, many users manually switch out of frames view for many sites. Consider avoiding frames unless they are needed for a particular Web application. If frames are needed, remember these tips:

    Synopsis

    1. Generally speaking, iFrames are better supported on screen readers than traditional HTML frames.

    2. Clearly identify each frame or iFrame in the following way:

      1. Include the TITLE attribute for each frame. The text within these attributes should describe the contents of the frame (e.g. "navigation" or "content") not position ("top" or "right") or an arbitrary number ("frame 1" or "frame 2").
      2. Make HTML file names for each frame meaningful (e.g. "navigation-menu.html") in case that is what a screen reader identifies.
      3. Include a text title on each frame (it can be hidden in visual browsers).
      4. Use the DOCTYPE declaration below for Web pages with frames. Doing so will signal a page with frames to a screen reader.
        <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">

      WCAG Guideline 4.1.2—For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

    3. Whenever possible, include duplicate navigation within the content frame. Especially important is a link to the site map. in case users right-click a frame to view it by itself (thus manually leaving frames mode).

    4. Include <noframes> content, including basic navigation functions, so your site is usable to older browsers that do not support frames.

    5. A link to a "No Frames" version of the site is often recommended. It is generally best to place this link towards the top of the homepage.

    6. Alternatives to using frames for layout include tables and server side includes. The latter can be used to place standardized headers and navigation on each page.

    Top of Page

    iFrames: Sample Accessible Code

    In general, iFrames are accessible on a screen reader, but a TITLE for the iFrame is recommended. See example of a Google Form iFrame below.

    View HTML for Accessible iFrame

    <iframe title="Survey Form Frame" src="https://spreadsheets.google.com/embeddedform?formkey=" width="760" height="820" frameborder="0" marginheight="0" marginwidth="0">Loading... </iframe>

    Top of Page

    Frames: Sample Accessible Code

    Table Mimicking Frames
    Top Title Frame

    My Accessible Frames Site

    Left Navigation Frame

    MAIN MENU


    No Frames View
    Right Content Frame

    H1 Header Here for Page Title

    Rest of content

    Duplicate navigation for accessibility

    Page 1 | Page 2 | Page 3 ... Page n

    View Sitemap

     

    View the Code for Accessible Frames

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd"> <head> <title>A page that contains frames</title> </head>

    <body>

    ....

    <frameset rows="80,*" frameborder="no" framespacing="0" border="0">
        <frame src="titlebar.html" title="Title Bar">
        <frameset cols="175,*" frameborder="no" framespacing="0" border="0">
            <frame src="mainmenu.html" title="Main Menu" name="mainmenu">
            <frame src="initialcontent.html" title="Page Content" name="content">
        </frameset>
    </frameset>

    Note that all NAMES , TITLES and file names indicate which type of content is available. Avoid using generic names like "left frame" or "frame01".

    No Frames Skeletal Navigation

    Here is an example of NOFRAMES code with skeletal navigation that makes the site accessible to non-frames browsers.

    <noframes>
    <h1> Welcome </h1> <p> This page... </p>
    <h2> Main Menu </h2> /!-- Alternative No Frames Navigation --/ <ul>
         <li> <a href="page1.html">Page 1</a></li>
         <li> <a href="page2.html">Page 2</a></li>
         <li> <a href="page3.html">Page 3</a></li>
         <li> <a href="pagen.html">Page n</a></li>
    </ul>
    </noframes>




    </frameset> </html>

     

    Top of Page

    Heading Tags (H1, H2, H3, P) in HTML

    Many tags in HTML were developed not to assist formatting but to provide information on the structural hierarchy of a document. In order to facilitate accessibility as well as standards, it is best to use the tags for the intended purpose in the information hierarchy rather than for pure formatting purposes. In many cases, this will make your document easier to edit as well.

    Synopsis

    1. Use the H1, H2,...H6 tags as indicators of section headings and subheadings within a document, not just as formatting elements. Screen readers in particular may just scan a page for appropriate H1, H2 and H3 elements. See Header examples below.

    2. Many experts recommend reserving H1 for the page title, H2 for major headings and H3 for major sub headings.

    3. If you need to indent text for a quote it is generally preferable to use the BLOCKQUOTE tag rather than a UL unordered list tag. The UL tag should be reserved for true lists containing LI elements.

    4. If you need to indent text stylistically (e.g. indent all paragraphs), it is better to use a CSS specification and add space to the left margin (e.g. {margin-left: 15px}) or left padding.

    5. Use the P paragraph tag to separate paragraphs instead of multiple breaks (e.g. BR BR ). This encloses blocks of text within their own structural elements. Some screen readers are able to jump from P to P but not BR to BR.

    6. Do not use the FONT tags to adjust formatting of heading tags. Experts recommend using cascading style sheets for specifying font color, font-size, font-face and backgrounds (versus the FONT tag). This allows a user with color vision or low vision to override a problematic stylesheet with one that they prefer.

    7. In Word, using the Heading 1, Heading 2 styles performs a similar function as H1, H2 do and may be converted to approproate H tags in different conversion tools. You can edit Word Styles to change the appearance of these headers.

    Heading Tag Examples

    Tagging Content Headers Appropriately

    Use the H tags to mark document headers instead of changing FONT sizes.

    Inaccessible Use of < font size > tag for headers

    In this example, the <font size="+1" color="#000066" (navy) > and <b > tags have been used to create large sub headings.

    Topic 1

    Content

    Topic 2

    Content

    A screen reader set to a scanning mode would not list these as topics. In addition the code contains more formatting tags than needed.

    View the Code

    <p> <font size="+1" color="#000066"> <b> Topic 1 </b> </font> </p>

     

    Accessible Use of H2 tag for headers

    In this example the H2 tag has been used and has been styled so that it is automatically navy.

    Topic 1 (example)

    Content

    Topic 2 (example)

    Content

    A screen reader set to a scanning mode would list "Topic 1" then "Topic 2"

    View the Code


    h2 {color: #000066}
    ...
    <body>
    <h2> Topic 1 </h2>

    Tagging Large Sizes Appropriately

    Do not use the H tags just to format text to a larger size.

    Inaccessible use of H1 tag

    In this example, the H1 tag is used to increase font size in the table cells. The screen reader in scanning mode will could read all the H1 cells out of context. In this case you could use CSS to ensure that the TH table header cells are styled with larger text.

    Summary of Jedi Knight Staff Review
      Vader Luke Obi-Wan
    Overall Grade C– A A+
    Summary Strong technical skills, but too quick to use them in an aggressive manner. Counseling on family issues may be needed. Technical skills still weak, but has excellent communication and relationship skills. May need to develop assertiveness. Strongly improved management and mentoring skills. Has clearly learned much from previous mistakes.

    A screen reader scanning H1 tags would read Vader, Luke, Obi-Wan, Overall Grade, Summary

    Top of Page

    Image ALT Tag Tips for HTML

    Synopsis

    Note: The term "ALT tag" is a common shorthand term used to refer to the ALT attribute within in the IMG tag.

    1. Any time you use an image, be sure to include an ALT tag or ALT text within the IMG tag. Doing so will provide a clear text alternative of the image for screen reader users.

      WCAG 2.0 Guideline 1.1.1.—"All non-text content that is presented to the user has a text alternative that serves the equivalent purpose."

    2. The description in the ALT tag should be meaningful in the context of the Web page, specifically:

      1. Images used as links should have alternative (or "alt") text describing the destination of the link, not the image itself.
      2. Alt text with acronyms should be written with spaces in between letters. For instance, <alt="I T S at P S U" > (read by a screen reader as "ITS at PSU") is preferable to <alt="ITS at PSU" > (read as "It's at Sue").
      3. Images used as spacers or in toolbars should have an empty ALT tag (i.e. <alt="" >). Screen readers will simply skip over images with empty ALT tags.
      4. Images that already include a text description within the main text of the page can have a summary ALT tag.
    3. If you want to provide a tooltip for visual browsers, use the TITLE tag in addition to the ALT tag, since it is supported in most browsers. For example:

    4. While there is no official length restriction on the length of alt text, many experts recommend 125 characters or fewer because of restrictions within the JAWS screen reader. Many versions of JAWS break up longer text tracts into blocks of 125 characters, which can be confusing to users.

    5. For an especially complex image, such as a chart, equation or diagram, a link to an extended text description should also be included.

    6. Images that are used as buttons or labels should use fonts that are readable to a large segment of the audience (probably 12 pixels/point or larger).

    7. In some cases you can replace decorative or layout-related images with styled HTML elements, such as HRs or DIVs, for which you change background colors and specify background images. See CSS tutorials for more details.

    Top of Page

    Implementing Alt Text

    The ALT tag adds a text description to an image on a Web page, and should be used for all images, graphical bullets, and graphical horizontal rules. The alt text within the ALT tag should let the user know what an image's content and purpose are.

    Alt text is accessed by screen reader users to provide them with a text equivalent of images. In visual browsers, the alt text is displayed when an image is broken, or when all images have been disabled. Using ALT tags is also beneficial to users on Palm Pilots or low-bandwidth connections, where images are slow to download.

    The ALT tag is included within the IMG tag. You can also include the TITLE and LONGDESC attributes within the IMG tag, as well, since these tags are also recognized by some devices.

    NOTE: Because of JAWS restrictions, it's recommended that ALT tags be limited to about 150 characters. If more information is needed, then use one of the long description strategies.

    Sample ALT Text Code

    Camp 2011 logo

    <img src="CampLogo.gif" alt="Camp 2011 logo">

    Demo Web Site With Image Links

    Fake Child Education Site Label

    Math Problems Label
    Science Labs Label
    Word Games Label
    History Facts Label

    Screen Reader Output With ALT Tag

    Fake Child Education Site Label

    Math Problems Label
    Science Labs Label
    Word Games Label
    History Facts Label

    View the Code

    <img src="K12Title.gif" alt="Fake Child Education Site Label"> </p>
    <p> <img src="K12MathProblems.gif" alt="Math Problems" <br>
    ...

    Screen Reader Output Without ALT Tag

     




    Screen reader says "Image" five times.

     

    Top of Page

    Use TITLE for Tooltips

    Some browsers, particularly Internet Explorer for Windows, may display alt text as a visible tooltip. Therefore, some Web sites use this feature to include supplemental information for those using visual browsers.

    However, this technique should be avoided since other browsers do not show ALT text as tooltips. In addition, this interferes with the basic function of the ALT tag, which is to provide a short text equivalent of an image. All navigational elements should be indicated by textual elements that can be accessed by a visual browser.

    Use the TITLE tag instead to create tooltips, since it is supported in all browsers. See the example below.

    TITLE Tooltip Example

    HTML Code
    <img src="bluemark.gif" alt="Penn State University" title="Founded in 1855" >

    Example: (Hold cursor over image to test tooltip)
    Penn State University

     

    Top of Page

    Alt Text for Navigational Elements

    For images used as navigational elements, the alt text can typically just state the link's target page. Providing a full description of the image is redundant in most cases.

     

    Inaccessible ALT Tag for Graphic Link

    This code is meant to implement the Penn State logo as a link to the homepage, but isn't fully accessible.

    View the Code

    <a href="http://www.psu.edu" > <img src="psulogo.gif" alt="Penn State Logo"> </a>

    A screen reader would say "Penn State logo," but would not indicate that this link goes to the Penn State homepage.

    Accessible ALT Tag for Graphic Link

    This code is a more accessible implementation of the Penn State logo as a link to the homepage.

    View the Code

    <a href="http://www.psu.edu"> <img src="psulogo.gif" alt="Penn State Home Page"> </a>

    The screen reader would say "Penn State homepage," which indicates the link's destination

    If more information about the image or its design is desired, then a D-link or LONGDESC tag can be provided.

    Top of Page

    Alt Text for Filler or Decorative Images

    Some images, such as invisible pixels or images used in toolbars, are used solely for layout purposes and provide no content. The ALT tag for these images should be blank ( <alt= "" >) so that screen readers will ignore them altogether. It is possible, however, that some older screen readers will say "Empty ALT tag" and read the file name.

    The example below will use a sample image of a rainbow toolbar, followed by some accessible and inaccessible code examples.

    Accessible Toolbar Image Code

    demo rainbow toolbar

    <img src="examples/spectrumtooltip.gif" alt=" " >

    Screen reader says nothing and goes on to the next section

     

    Less Usable Toolbar Image Code

    <img src="examples/spectrumtooltip.gif" alt="A Rainbow line used as toolbar" >

    Screen reader says "Rainbow line as a toolbar." If you have eighteen rainbow toolbars, the screen reader would repeat this eighteen times. This text is irrelevant to a screen reader user and increases reading time.

     

    Inaccessible Toolbar Image Code—No ALT Tag

    <img src="examples/spectrumtooltip.gif" >

    With no ALT tag, screen reader says "Image," which leaves users wondering if they are missing anything important.

    NOTE: Alt text combined with a transparent image can be used to provide special information just to screen reader users, such as a way to skip navigation.

    Top of Page

    Summary Alt Text

    If a text description is already provided for an image within the main text of the page, then the ALT tag can just provide a summary of the image, not a full description.

    Example Text with Image

    Below is an image of a saturated fat molecule with 18 carbon molecules. Notice that the single bonds between elements make the carbon chain relatively straight.

    Saturated Fat Molecule

    Accessible Summary ALT Tag

    <...alt="saturated fat molecule" >

     

    Less Accessible, Verbose ALT Tag

    <...alt="image of straight saturated fat with 18 carbons" >

    NOTE: This kind of description would be useful if it was needed to understand the content, although a better strategy may be to include the description in the Web page itself, or to link to a longer description as discussed in the next section.

    Top of Page

    Links to Extended Descriptions

    In some cases it may be necessary to add a link to an extended description of an image, especially in cases where images are used to convey significant content. There are several ways this can be accomplished—including a LONGDESC tag, a D-link or a more overt link to the longer description. See below for examples

    Link to Caption Text

    If the information is critical, then an overt caption link may be the best solution. This method provides the clearest indication that a longer description is available.

    saturated fat moluecule
    View Extended Text Description

    D-links

    Some experts advocate the use of a D-link to signal the presence of an extended text description. However, some users may not be aware of the convention. This method is best used to provide information that is purely supplemental.

    Saturated Fat MolueculeD

    LONGDESC Attribute

    This is an attribute that is hidden in visual browsers, but recognized by some screen readers. LONGDESC is best for providing extra detail that enhances content, but is not critical. It should be noted that LONGDESC has incomplete support among both visual browsers and screen readers, and is deprecated in HTML5.

    football player photo

    View the LONGDESC Code

    <img src="examples/runningfootbalplayer.jpg" alt="photo of football player" width="102" height="154" longdesc="dfootball.html" >

    LONGDESC Text (in dfootball.html)

    This is a publicity photo of a Penn State football player running with the football in a crowded football stadium on a sunny day.

    Top of Page

    Image Maps in HTML

    Image maps are used to define regions within a larger image as links. For instance, a Web site featuring a U.S. map with clickable states uses image maps. Altough image maps can be visually appealing, unless special precautions are taken, screen readers will not be able to identify the embedded links.

    Synopsis

    1. If you use a client-side image map, be sure to include the ALT attribute within each AREA tag (which defines the the hot spot) in order to provide an alternative text link for screen readers. The NAME attribute should also be included in the MAP tag.

    WCAG 2.0 Guideline 1.1.1—"All non-text content that is presented to the user has a text alternative that serves the equivalent purpose."

    2. If images are used as links in the image map, use the TITLE attribute in an AREA tag to provide a visual tooltip.

    3. Avoid CGI server-side image maps whenever possible. Use client-side image maps with the MAP tag instead.
    NOTE: Image maps produced by Dreamweaver, FrontPage and other HTML editors are usually client-side image maps.

    SECTION 508 Guideline 1194.22 (f)—"Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape."

    4. If CGI server-side image maps are needed, then provide a separate text-based menu.

    SECTION 508 Guideline 1194.22 (e)—"Redundant text links shall be provided for each active region of a server-side image map."

    Top of Page

    Client-Side Versus Server-Side Image Maps

    Generally speaking, client-side image maps are preferred to server-side image maps for accessibility purposes. In addition, a server-side image map is more difficult for one person to maintain, because it involves programming a CGI. Therefore client-side image maps are used much more often.

    A client-side image map includes coordinates for different links embedded within an image. Some source code for a client-side image map would look like this:

    Example Code for Client-Side Image Map

    Penn State Links Menu Penn State Home Page LIAS-Libraries Catalog Penn State Directory Penn State Registrar Penn State Google Search

    View the Code

    Note that the ALT tag is included at the top for the main image, and later for each hot spot. The ALT tag provides a text description of an image for screen reader users. Titles for hot spots are included in order to display tooltips.

    <img src="examples/ANGELHeader.jpg" alt="Penn State Links Menu" width="586" height="72" border="0" usemap="#Map">
    <map name="Map">
    <area shape="rect" coords="245,52,317,72" href="http://www.psu.edu" alt="Penn State Home Page" title="Penn State Home Page" >
    <area shape="rect" coords="324,55,366,70" href="http://wwww.lias.psu.edu" alt="LIAS-Libraries Catalog" title="Libraries Catalog" >
    </map>

     

    Top of Page

    A server-side image map uses a CGI script to access an image map file on your server. The source code for a server-side image map would look like this:

    Server-Side Image Map—Avoid

    <a href="/cgi-bin/imagemap/psu.map"> <img src="psu.gif" ismap width="160" height="140" border="0"> </a>

    Note that this code does not allow for any ALT or TITLE tags to be included.

    To make this server-side client map accessible, you can provide an additional, text-based menu like this one:

    Accessible Text-Based Menu for Server-Side Image Maps

    About Penn State | Prospective Students | Academic Units

    Top of Page

    Language Tags in HTML

    Synopsis

    1. Use Unicode encoding whenever possible.

    2. Use the LANG tag to mark words or passages of text in another language. This works for major languages only.

    3. Consider supplementing language changes with a textual indication (visual or hidden) to indicate when a foreign language word or passage is coming.

    Top of Page

    About Language Tagging

    The LANG tag (i.e. the lang="" attribute) is designed to signal screen readers pronunciation engines to switch to another language. For this reason and other, tagging Web text as being in a particular language is required in WCAG 2.0.

    WCAG 2.0 Guideline 3.1.1—"The default human language of each Web page can be programmatically determined. "

    Even more critical is to use language tagging to signal a switch in languages.

    WCAG 2.0 Guideline 3.1.2—"The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text. "

     

    Declaring Page Language

    The LANG attribute is designed to signal screen readers to switch to another language. The official W3C recommendation is to declare the primary language for each Web page with a <...lang => attribute in the <html> tag. Codes are ISO-639 Language codes, some of which are listed further down on this page.

     

    NOTE: You must also declare the encoding in addition to the language. The language and its script are independent.

     

    Declaring a U.S. English Page (Penn State)

    <html lang="en-US"> ... </html>

     

    Declaring a British English Page

    <html lang="en-GB"> ... </html>

    Screen readers supporting this tag could switch to a British accent.

     

    Declaring a French Page

    <html lang="fr"> ... </html>

    Screen readers supporting this tag could switch to a French accent.

    Top of Page

    Switching Languages

    If you switch languages within one page, you can embed the LANG attribute in other tags such as a P, TD, SPAN, DIV and other tags. For example

    Test Text with Lang Tags

    This sentence is in default American English.

    This sentence will be read with a British accent.

    Esta frase es en español. (Spanish)

    Cette phrase est en français. (French)

    Mae'r frawddeg hon yn cymraeg. (Welsh - Not Supported)

    View the Code

    <p> This sentence is in English. </p> <p lang="en-GB"> This sentence will be read with a British accent </p> <p lang="es"> Esta frase es en espa&ntilde;ol. </p> (Spanish) <p lang="fr"> Cette phrase est en fran&ccedil;ais </p> (French) <p lang="cy"> Mae'r frawddeg hon yn Cymraeg. </p> (Welsh, not supported) </p>

    Top of Page

    Common Language Codes

    Two Letter vs. Three Letter

    The first set of language codes (ISO-639) were two letter codes, but did not cover every language. As a result, sets of three-letter codes (ISO-639-2/ISO-639-3) codes were created to cover more languages.

    For any language, standards indicate to use the two-letter code if it exists. Only use a three-letter code if no other code is available. See the ISO 639 Code Tables for a complete list of language codes including the original ISO-639 codes and later variants.

    Western European Languages

    These codes are supported in many screenreaders, including JAWS.

    Language Code Variants
    English

    en

    • American English - Code: en-US
    • British English - Code: en-GB
    Spanish es
    • Castillian Spanish - Code: es-ES
    • Mexican Spanish - Code: es-MX
    French fr
    • Canadian French - Code: fr-CA
    Italian it  
    Portuguese pt  

    Non-Western European Languages

    Language Code Variants
    Arabic

    ar

     
    Chinese zh
    • Simplified Spanish - Code: zh-CN
    • Traditional Chinese - Code: zh-TW
    • Hong Kong - Code: zh-HK
    Hebrew he  
    Hindi hi  
    Japanese ja  
    Korean ko  
    Swahili sw  

    Ancient Languages

    Language Code Variants
    Ancient Greek

    grc

    • Modern Greek: el
    Latin la  
    Old English ang  
    Middle English enm  

    Top of Page

    Supplemental Signals of Non-English Content

    In addition to using the LANG tag, you can also include an indication in the text so that users of older screen readers can manually with languages. This can be done by spelling out the beginning/end of a passage in the text (preferably in an H1,H2 tag or as part of a set of links) or in the alt tag of an invisible graphic.

     

    Spelling Out Language Name in Text

    Translations of U.N. Universal Declaration of Human Rights

    Spanish | French ... (Menu provides quick list of where non-English passages are)

    Spanish Article 1 (Spelling it Out)

    Artículo 1
    Todos los seres humanos nacen libres e iguales en dignidad y derechos y, dotados como están de razón y conciencia, deben comportarse fraternalmente los unos con los otros.

    French Article 1

    Article premier
    Tous les êtres humains naissent libres et égaux en dignité et en droits. Ils sont doués de raison et de conscience et doivent agir les uns envers les autres dans un esprit de fraternité.

     

     

    With Invisible Graphics

    Artículo 1
    Todos los seres humanos nacen libres e iguales en dignidad y derechos y, dotados como están de razón y conciencia, deben comportarse fraternalmente los unos con los otros.

    View the Code

    <img src="transpixel.gif" alt="Begin Spanish">

    Links on a Web Page

    Helping users understand the destinations of links is an important step towards increasing the usability and accessibility of a Web page.

    Guidelines for In-Text Links

    These guidelines apply to links embedded within the text of a document or a Web page.

    1. Write links that make sense out of context. Use descriptive link text detailing the destination, not just "click here," or other ambiguous phrases. Link text should be made up of phrases rather than single words, so that users with limited motor control will not have difficulty selecting links.

      Unclear Link Text Examples

      Usable Link Text

       

      NOTE: Some search engines, such as Google, give higher rankings to sites that use "context-rich" text links.

    2. Maintain the standard that text links are underlined and are a different color value (lighter or darker) than the main text. This provision will help colorblind users find links more easily, and is good usability practice.

    3. Avoid links opening in a new window unless absolutely necessary. New windows are disorienting to users of both screen readers and visual browsers (because the Back button becomes "disabled") Also be aware that some users of visual browsers disable pop-up windows to avoid advertising.
      NOTE: If links do open in a new window, include a textual indication (e.g. External Resources [New Window]) so screen reader users are aware of the new window.

    4. If you use JavaScript links, such as those to open pop-up windows, make sure they are coded to be accessible to screen readers. Many JavaScript links are unusable in screen readers.

    5. If you use an image or image map to create links, make sure the destination is included in an ALT tag. See the Image Maps and Image pages for more details on creating accessible links with images.

    6. You can insert "Top of Page" links after each section in longer documents to reduce the need to scroll up (which can be difficult for motion impaired users). These links should be formatted differently from other links so that users know they are page-internal.

    Top of Page

    Guidelines for Blocks of Navigational Links

    These guidelines apply primarily to blocks of navigational links in Web pages or PDFfiles.

    1. If your Web site uses a block of navigational links on each page, make sure a skip navigation strategy has been implemented so that screen readers can avoid reading these links on each page.

      WCAG 2.0 Guideline 13.6—"Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group."

    2. Whenever possible, break up long lists of links into categorized blocks separated by headers (e.g. H1, H2). Otherwise, you may have to implement a Skip Navigation strategy.

    3. Maintain a consistent set of navigational links on every page of your site, even if you must implement a skip navigation strategy.

    4. You can place a breadcrumb trail, a listing of the page's location in the site's hierarchy, below the page's title bar to help users keep track of their location within a complex site.
      NOTE: The safest symbol indicating a subordinate page is the colon (:) instead of punctuation symbols like » ("Right double angle bracket) or > ("greater than") or. T.

    Top of Page

    Lists in HTML

    Synopsis

    If you are using nested lists (lists within lists), then use a different numbering system in the secondary levels than in the primary levels, to help users distinguish between them. See the nested list example below for details.

    Nested Lists

    Using different numbering/lettering schemes for each level of your lists will help both screen reader users and a general audience comprehend the content more easily.

    Inaccessible Nested list

    What a visual browser sees:

    University Park Colleges and Departments

    1. Agricultural Sciences

    1. Agricultural and Biological Engineering
    2. Agricultural Economics.

    2. Arts and Architecture

    1. Department of Architecture

    1. Department of Architecture
    2. Department of Landscape Architecture

    What a screen reader says:

    University Park Colleges and Departments

    1. Agricultural Sciences 1. Agricultural and Biological Engineering...2. Arts and Architecture 1. Architecture and Landscape Architecture 1. Department of Landscape Architecture.

    Accessible Nested List

    What a visual browser sees:

    University Park Colleges and Departments

    1. Agricultural Sciences
      1. Agricultural and Biological Engineering
      2. Agricultural Economics
      3. ...
    2. Arts and Architecture
      1. Architecture and Landscape Architecture
        1. Department of Architecture
        2. Department of Landscape Architecture
      2. Art History
      3. ...
    3. ...

    What a screen reader says:

    University Park Colleges and Departments

    1. Agricultural Sciences A. Agricultural and Biological Engineering...2. Arts and Architecture A. Architecture and Landscape Architecture i. Department of Landscape Architecture.

    Using Image Bullets (CSS)

    You can replace bullets with custom bullet images using the CSS attribute list-style-image:url(path).

    Example list with custom bullets:

    Penn State's two colors are:

    1. Blue
    2. White

    CSS file specification:

    ol.paw {list-style-image:url(examples/paw.gif)}

    View the HTML code:

    <ol class="paw">
        <li>Blue</li>
        <li>White</li>
    </ol>

    The list-style-image attribute replaces a bullet with the image.

    What a screen reader says:

    Penn State's two colors are:

    Item 1 Blue
    Item 2 White

    Multiple Columns in HTML

    Older screen readers had trouble reading tables, but this is not a problem for newer screen readers. See the tips section for information on how to make formatting tables more accessible.

    Synopsis

    1. Layouts with multiple columns are accessible to newer screen readers, but you must ensure that the flow of the text is coherent.

    2. You can use the TABLE attribute for layout, but keep in mind that cells are read left to right, top to bottom. You do not need to include data table accessibility tags such as TH and SCOPE.

    3. CSS formatting is often preferred, but you must ensure that positioning doesn't place elements out of visual order, causing the text to become incoherent when CSS is disabled.

    Older Screen Readers and Multi-Column Formats

    Older screen readers were unable to recognize columns (whether they were in TABLEs or formatted with CSS). Instead they would read the text on the page left to right as if it were linear, causing text to be read out of order

    For this reason, some accessibility experts used to strongly discourage the use of multiple column layouts, which were then mostly implemented with formatting tables.

    NOTE: Some screen reader software packages, such as JAWS, allow users to enter a table-reading mode, but some users may not be aware that this feature exists.

    Is CSS better than TABLE?

    With regard to accessibility, the difference is actually minimal. The main advantage of using CSS over TABLEs is that there is usually less code, making maintenance much easier.

    However, you can cause accessibility glitches with CSS if positioning is not properly implemented. There are also inconsistencies in how CSS is rendered across browsers.

    Some experts recommend using CSS-styled DIVs to set up layouts, but there are a number of serious pitfalls to be wary of. If in doubt, using tables for layout may be a better solution in the short term. It is not currently a part of Section 508 policy that all formatting tables be eliminated, just that they be accessible.

    Benefits of CSS-Styled DIVs

    1. Screen readers do not announce the number of cells for DIVs.
    2. There are more formatting options available.
    3. Code is less bloated.

    Pitfalls of CSS-Styled DIVs

    1. Floating DIVS may place content out of order for screen readers.
    2. They will probably not resolve the issues that older screen readers have with multiple column layouts.
    3. Implementation of CSS varies widely between browsers, so any design must be tested on multiple browsers. This problem has been lessening over time.
    4. Section 508 requires that content be readable with stylesheets disabled. Test to see that your site is coherent with CSS disabled.

      WCAG 2.0 Guideline 1.3.2—"When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined."

    Tips for Implementing Formatting Tables

    1. Make sure your text makes sense when read cell-by-cell, row-by-row, starting from the upper left . This is the default reading order of table cells for screen readers.

    2. If one of the columns is used for navigation, implement a Skip Navigation strategy so that users can navigate into content and skip repeating a set of site navigational links.

      WCAG 2.0 Guideline 2.4.1—"A mechanism is available to bypass blocks of content that are repeated on multiple Web pages."
    3. When using a table for formatting, you do not need to use the TH, SCOPE, or CAPTION tags. These are only used for data tables.

    4. You can use the SUMMARY tag to indicate to screen reader users that the table is being used for layout purposes.

    5. Avoid using tables to create "textbars". CSS has more formatting options for this purpose and generates cleaner code.

    6. Avoid nesting tables for visual effect. Screen readers read out the number of rows and cells for each table, so the fewer tables, the better.

    7. Whenever possible, set column and table widths to relative sizes (e.g. width="25%") rather than absolute sizes (e.g. width="200"). This way, tables can be adjusted to fit the screen more appropriately depending on monitor resolution or zoomed text.
      NOTE: Some users deliberately set their monitors to a lower resolution (e.g. 800 x 1200 or 640 x 400) as a way to increase text size in general.

    8. Some formatting tables can be avoided by using CSS to specify background colors and borders for elements such as H1 tags or DIV classes.

    Reading Order Issues

    As mentioned above, the default reading order of table cells is left to right, top to bottom as shown in the example table below.

    Example Table

    Table Showing Screen Reader Order
    Cell 1 Cell 2 Cell 3
    Cell 4 Cell 5 Cell 6
    Cell 7 Cell 8 Cell 9

    It's important that, when using tables for formatting, the text be coherent when read in cell table order. See the following example for details.

    Inaccessible Table Reading Order

    Here's a table with "3 2 1 Ignition" going from the lower left to the upper right.

          Ignition!
        1  
      2    
    3      

    Users of visual browsers would process the text as "3 2 1 Ignition," but because of how the table is laid out, a screen reader would say "Ignition 1 2 3."

    Top of Page

    CSS Options

    See the CSS page for links to tutorials, and for options regarding multiple column layouts.

    The DIVs Resembling Tables section of the CSS page shows some options for adding borders and background colors with more control than in HTML tables. The Inaccessible CSS section shows how CSS can be used to inadvertently position text out of logical order.

    Top of Page

    Pop-Up Windows (Issues and Some Solutions)

    The Issues

    Pop-up windows can add functionality to a Web site, but must utilize accessible scripting. Further, the site should still be functional even if JavaScript is disabled. Also, be aware that many users with visual browsers use pop up blockers in order to avoid pop-up advertising.

    JavaScript pop-up windows should only be used if they add a significant advantage in functionality.

    Synopsis

    1. If you do open a new window or new tab (with either the TARGET attribute or a script), then add a label that the link will open a new window/tab. Many users (on both screen readers and visual browsers) are confused when they do not realize a new window is open and are unable to use the "Back" button.

    2. Accessify.com provides a tutorial on creating an accessible pop-up window. However, this method should be tested before it's used on a Penn State Web site.

    3. Provide a <noscript> alternative that uses a plain link to direct users with JavaScript disabled to the appropriate information.

    4. Provide both a regular link and a pop-up link.

    5. Avoid disabling scroll bars and resizing options—readers with low vision may need to resize windows to accommodate larger text.

    Top of Page

    Redirects and Other Timed Responses

    Synopsis

    1. If you need to redirect users to a new Web address, then a static page with a link is recommended over a page with a timed redirect.

      WCAG 2.0 Guideline 2.2—"Provide users enough time to read and use content."

    2. When using redirects or forms requiring a timed response, make sure adequate response time is given for mobility impaired users, users with screen readers and readers with cognitive impairments. All of these audiences require extra time to process instructions.

    3. If you need to implement a permanent redirect for a URL, it is recommended that you use the "HTTP status code 301" on a server, rather than the <meta http-type="refresh" > tag. The 301 code is more standard, although it can only be implemented by a server administrator.

    4. If your Web site is set to automatically log a user out after a certain period of inactivity, make sure the Web site gives a warning with a reasonable window of opportunity for the user to choose to stay connected (e.g. 20 seconds to press a key).

    5. Avoid using redirects to circumvent navigation buttons. It is possible to code your Web page so that when users click on the Back button, they are redirected back to the current page, instead of going to the previous page. This is generally considered both non-usable and non-accessible because it interferes with the standard protocols of a browser, and could cause confusion for many users.

    Permanent Redirects Versus Temporary Redirects

    A permanent redirect, which directs users from one Web address to another, can be automated to be instantaneous. Since this redirect path will be maintained permanently and is meant to be transparent to users, there is no need to provide any time lag.

    An Automatic Permanent Redirect for ANGEL

    An example of a permanent redirect is angel.psu.edu (for the ANGEL Course Management System), which automatically redirects users to the true ANGEL Web address, cms.psu.edu.

    Click on http://angel.psu.edu to see the redirect in action.

    A temporary redirect is one that is implemented after a Web site has changed its permanent address. The purpose of this kind of redirect is to inform users that an address is changing, and that bookmarks and links should be updated.

    Since information about the redirect needs to be read and digested by users, an untimed static page with the new URL is recommended over a timed redirect. See the example below.

    Accessible Page Announcing New URL

    This page announces the new URL as a link, instead of doing a timed redirect.

    The TLT Cyberplagiarism Web site has been moved to:

    http://tlt.its.psu.edu/plagiarism

    Please visit the new URL to view the updated Web page.

    Top of Page

    Scripts for Web Pages

    Synopsis

    1. If scripts are used to generate HTML code for dynamic pages, then the generated code should comply with accessibility guidelines.

    2. If a script relies on the user clicking the mouse, then make sure to include event handlers that also allow him/her to use the keyboard to tab to the tool.

    3. Avoid using arbitrary database numbers for ALT tags, TITLE tags, FRAME tags and other text-only accessibility devices.

    4. A Web site should be reasonably functional even with JavaScript is disabled. An alternative, text-only navigational system utilizing <noscript > may add accessibility, as will text links.

    5. See the pages under Related Links for specific recommendations on different scripted elements.

    Top of Page

     

    Skip Navigation

    Synopsis

    It is recommended that a "skip to content" link be included before the site's main navigation tools. One link of this kind is usually sufficient.

    Users with screen readers can skip between major headers and subheaders, which are tagged H2, H3, and H4.

    Why Use Skip Navigation Links?

    Having a consistent set of navigation links at the top or left side of a Web page is beneficial both for general usability and for people with certain mobility impairments, as they may not need to move the mouse as far to reach the navigation.

    For users with screen readers, however, hearing the same list of links at the beginning of each page is time consuming and potentially irritating. Therefore a skip navigation strategy should be included to allow users of screen readers to skip over a block of navigational links.

    WCAG 2.0 Guideline 2.4.1—"A mechanism is available to bypass blocks of content that are repeated on multiple Web pages."

    Top of Page

    Skip Link Method 1—Hiding Text Off Screen

    One way to hide text is to place it literally off screen using CSS. In the example below, the class .offscreen moves text 10,000 pixels to the left of the visible portion of the screen. The text is not visible in the browser, but a screen reader will announce it because it disregards visual CSS.

    View the CSS

    .offscreen {
    position:absolute;
    left:-10000px;
    top:auto;
    width:1px;
    height:1px;
    overflow:hidden;
    }

    View the HTML

    <a href="#skip" class="offscreen">Skip Content</a>
    <!-- DIV tags are used to break the page into sections. No formatting is visible unless CSS formatting is applied--> <div id="navigation">[A Bunch of navigation buttons/tabs]</div> <div id="content">
    <a name="skip" > </a > [Content Starts Here]
    </div>

    Alternative Approaches

    The WebAIM Skip Navigation page lists some alternatives, including making the skip to content link visible when a user tabs to it with a keyboard. This allows both motion impaired users and screen reader users to take advantage of the tool.

    Top of Page

    Skip Link Method 2—Pixel with ALT Tag

    An older method is to place an invisible pixel graphic before the navigation links with an ALT tag reading "Skip to Content." The graphic is turned into a page-internal link that links to content further down the page. Note that the image BORDER should be set to "0" in order to keep the image hidden from visual browsers.

    View Example

    Skip Navigation [A bunch of navigation buttons/tabs]

    [Content starts here]

    In visual browsers the hidden graphic is marked by a blue dot before the "[A bunch...]" because the border was not set to 0.

    View the Code

    <a href="#skip">
    <img src="transparent-pixel.gif" alt="Skip Content " border="0" >

    </a >

    [NAVIGATION]

    <div id="content">
    <a name="skip" > </a >
    [Content starts here]
    </div>

    Top of Page

    Tables for Data in HTML

    A table can be classified as a data table whenever you need to specify a row or column with header information about that row/column. If no informational header is needed, then it is a formatting table.

    Synopsis

    1. When using tables to present data, use the use the TH and SCOPE tags to identify which cells are row and column headers. This helps the screen reader organize the data to be read in a logical order and identify data types.

      WCAG 2.0 Guideline 2.4.6—"Headings and labels describe topic or purpose."

      WCAG 2.0 Guideline 1.3.1 - "Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text."

    2. Avoid spanned rows and columns in data tables, especially as headers. Many screen readers cannot properly parse these.

    3. Make sure any abbreviations and acronyms used in the tables are accessible.

    4. For complex data tables, you must use newer accessibility tags such as SCOPE, CAPTION, SUMMARY, ABBR, ACRONYM, TFOOT and THEAD as needed to further organize information in complex data tables.

      Given the complexity of this tag set however, you may want to consider replacing one complex table with a series of linked simple tables. Screen reader access is generally more straightforward and code maintenance may be simpler as well.

      See the Complex Table Tags section for more details.

    Top of Page

     

     

     

     

    Simple Tables vs. Complex Tables.

    A simple table here means means that there is a maximum of one header row and one header column where a header column specifies the type of information in the column. In addition, there are no merged cells within a simple table. Below are examples of simple and complex tables. Because screen readers present information linearly (i.e. table cell by table cell), it is generally easier to parse tables when are set up as simple tables.

    Simple Table (More Accessible)

    Top 2008 Presidential Candiates by Party
    (num) = Primary Delegate Count
    Democratic Republican
    1. Barack Obama (1828.5)
    2. Hillary Rodham Clinton (1726.5)
    3. John Edwards (4.5)
    1. John McCain (1575)
    2. Mike Huckabee (278)
    3. Mitt Romney (271)

     

    Complex Table (Less Accessible)

    Top Presidential Candiates 2008
    Democratic Republican
    Name Del Name Del Name Del Name Del
    Barack Obama 1828.5 Hillary Rodham Clinton 1726.5 John McCain 1575 Mike Huckabee 278

    Top of Page

    TH and SCOPE

    Use of the TH and SCOPE tags combined with the CAPTION and SUMMARY tags will provide sufficient information for most newer screen readers to process simple tables. The TH tag is used to designate certain cells as row and column headers. Visually, the TH tag changes the text formatting to bold face and center in most browsers.

    The SCOPE attribute in the TH tag is used to further define whether the header is a row ( <th scope="col"> ) or a column ( <th scope="row"> ). Designating the SCOPE changes the order in which a screen reader reads the cells. Otherwise, screen reader users would hear the table read in the default left-to-right, top to bottom. This code is sufficient for most screen readers to process simple tables (one header row and one header column), but additional tags are needed for more complex tables. See below for details.

    When sighted users focus on a table cell, they are able visually determine which row and column the cell is in and what the data means. On the other hand, a screen reader can only read aloud each cell one by one from left to right top to bottom. One way to help blind users process the information is to read out what row and column header the cell refers too. In the table below, the headers are the top row (color names) and the left column (language names).

    Examples of TH and SCOPE

    Color Names in Multiple Languages
    Color Spanish French Irish Welsh
    Black negro noir dubh du
    White blanco blanc bán gwyn
    Red rojo rouge ruadh coch
    Blue azul bleu gorm glas
    Green verde vert glas gwyrdd
    Yellow amarillo jaune buí melyn

    NOTE: Gray cells with bold, centered text are TH. The gray background is from a style sheet.

    In Screen Readers

    Because this table contains TH tags with the proper SCOPE definitions, some screen readers will read the second row of the table as follows.

    black, Spanish: negro
    black, French: noir
    black, Irish: dubh
    black, Welsh: du

    View the Code

    <table summary="Color names for black, white, red, blue, green, yellow in multiple languages">
    <caption> Color names in multiple languages</caption>
    <tr>
         <th scope="col"> Color </th>
         <th scope="col"> Spanish </th>
         <th scope="col"> French </th>
         <th scope="col"> Irish </th>
         <th scope="col"> Welsh </th>

    </tr>
    <tr>
        <th scope="row"> Black </th>
        <td> negro </td>
        <td> noir </td>
        <td> dubh </td>
        <td> du </td>
    </tr>
    <tr>
         <th scope="row"> White </th>
       
     <td> blanco </td>
         <td> blanc </td>
         <td> bán </td>
         <td> gwyn </td>
    </tr>
    </table>

     

    Without TH and SCOPE

    The data would be read as a list with no identifiers. You would have to memorize which word went with a particular language.

    Black, negro, noir, dubh, du.
    White, blanco, blanc, bán, gwyn.
    Red, rojo, rouge, ruadh, coch...

    Top of Page

    CAPTION Tag

    The CAPTION tag can be used to display a title for a table. The caption can be visually formatted and positioned above or below the table as needed.

    Example of CAPTION

    Caption: Table Showing Screen Reader Order
    Cell 1 Cell 2 Cell 3

    View the Code

    <table>
         <caption>
        Table Showing Screen Reader Order
         </caption>

    <tr>
         <td> Cell 1 </td>
         <td> Cell 2 </td>
         <td> Cell 3 </td>
    </tr>
    </table>

     

    Top of Page

    SUMMARY Tag

    The SUMMARY attribute is placed within the TABLE tag, and is read only by screen readers. It can be used to clarify the organization of a table, or to provide a quick summary of the table's content. It shouldn't repeat the information in the CAPTION tag, but can be used to supplement that information.

    Example of SUMMARY

    Caption: Table Showing Screen Reader Order
    Cell 1 Cell 2 Cell 3

    View the Code

    <table summary="Table cells are read left to right, top to bottom. ">
         <caption>
        Table Showing Screen Reader Order
         </caption>

    <tr>
         <td> Cell 1 </td>
         <td> Cell 2 </td>
         <td> Cell 3 </td>
    </tr>
    </table>

     

    Accessibility Tags for Complex Layouts

    It is possible to structure complex tables to be accessible via the ID and HEADER attributes, but it is very time consuming to implement. Each cell within a table must be manually coded with an identification of the row and column of each cell. See the links below for examples of coding complex tables.

    An easier option may be to break up a complex table into a series of linked, simple tables, which can be more easily maintained. These tables may also be more usable for the general audience.

    Top of Page

    Complex Table HTML Example

    This is a code example of a complex table with a two-row marked up for accessibility in terms of HEADERS and ID. This is useful for tables with two header rows, but requires that each cell in the table be indexed. Since this mechanism is only supported by a few screen readers, many experts recommend the use of multiple simple tables to display this information.

    Example Complex Table

    In the table below, color names in four languages are given, but the first row (which includes merged cells) indicates whether the language is the Romance language or the Celtic language family. This type of table might be used in a course discussing the difference between the two language families.

    Color Names in Multiple Languages (Romance vs Celtic)
    Family Romance Lang Celtic
    Color Spanish French Irish Welsh
    Green verde vert glas gwyrdd
    Blue azul bleu gorm glas
    Black negro noir dubh du

    About the Tags

    The following tags are used to mark the header and data cells.

    • Header cells are marked with the TH tag with the ID attribute giving a header name.
    • Header rows are enclosed within the THEAD tag
    • Data cells are contained in TD cells with a header attribute which locates the row and column of the cell
    • Data rows are enclosed within the TBODY tag
    • And finally...the cells in the second row have both an ID attribute and a HEADER attribute.

    How it works

    To understand how this works, consider a data cell such as verde, the Spanish word for green. The position of the cell is in the Spanish column (which is in the Romance language column) and the the Green row. In terms of the table, the word is associated with "Spanish-Romance-green" properties. This is indicated with the headers="" attribute as follows.

    <tr>...<td headers="spanish-romance-green">verde</td>...</tr>

    Each element separated by a dash refers to an ID in a TH cell. Some examples are given below.

    <tr>...<th id="romance">Romance Language</th>...</tr>

    <tr>...<th id="spanish" headers="romance">Spanish</th>...</tr>

    <tr>...<th id="green">Green</th>...</tr>

    Putting them all together, this would be the code for the first three rows of the table above

    View the Code

    <table cellspacing="0" summary="Color names for black, white, red, blue, green, yellow in multiple languages, grouped by language family" class="chart">
    <caption>
    Color Names in Multiple Languages (Romance vs Celtic)
    </caption>
    <thead>
    <tr>
    <th id="fam">Family</th>
    <th id="rmc" colspan="2">Romance Lang</th>
    <th id="cel" colspan="2">Celtic</th>
    </tr>
    <tr>
    <th headers="hue">Color</th>
    <th headers="romance" id="es">Spanish</th>
    <th headers="romance" id="fr">French</th>
    <th headers="celtic" id="ga">Irish</th>
    <th headers="celtic" id="cy">Welsh</th>
    </tr>
    </thead>
    <tbody>
    <tr>
    <th headers="hue" id="green">Green</th>
    <td lang="es" headers="romance-es-green">verde</td>
    <td lang="fr" headers="romance-fr-green">vert</td>
    <td lang="ga" headers="celtic-ga-green">glas</td>
    <td lang="cy" headers="celtiv-cy-green">gwyrdd</td>
    </tr>
    ...
    </tbody></table>

    Top of Page

    Titles for Web Pages

    All online pages should have unique topics that describe the content of the page or document. Not only do unique titles allow screen readers to distinguish individual pages, but they also enhance search results.

    WCAG 2.0 Guideline 1.4.2—"Web pages have titles that describe topic or purpose."

    Depending on the type of document, this can be accomplished in a number of ways.

    HTML Web Page

    Web pages should include a TITLE tag within the HEAD area, and the title should be unique to each page on the Web site. The TITLE can be repeated as the H1 of the page. See examples below.

    Accessible Web Title

    <head> <title>Charts and Accessibility | AccessAbility Site</title>
    ...
    </head> <body> <h1>Charts and Accessibility</h1>
    ...
    </body>

    A less accessible method would be to repeat the site title alone on each page. If each page on the site has the same title, screen readers would not be able to easily distinguish different pages.

    Less Accessible Web Title

    <head> <title>AccessAbility Site</title>
    ...
    </head>

    Top of Page

    Frames

    A Web site with FRAMEs or iFRAMES should be sure that each frame is given a meaningful title via the title="" attribute.

    PowerPoint

    Individual slides in PowerPoint each should each have a title so that screen readers are can navigate to individual slides.

    Word

    Word files should also include a title styled as Heading 1 at the beginning of the document.

    Top of Page

    Contrast and Color on Web Pages

    Synopsis

    An important aspect of color on the Web for both low vision and colorblind users is sufficient contrast between foreground (text or graphics) and the background. Maximum contrast is black versus white, but this combination can be considered too overwhelming (it might cause glare). Other colors can be used—such as navy, dark green, or maroon for darks, and pastels for lights—to lessen the contrast.

    However, some modern designs are so "subtle" that the contrast can actually be insufficient for some readers. Examples include contrasting light grey versus middle grey, middle pastels versus darks, or white versus light cyan (blue-green). If you plan to use a subtle color palette, it is recommended that you use a color analyzer to ensure there is sufficient contrast.

    In most online tests, you enter in the hexadecimal color code for the foreground (text) and background colors, and the tester generates a numeric result. Usually a low number or ratio indicates too little contrast.

    Contrast Tests

    WCAG 2.0

    The WCAG 2.0 guildine 1.4.3 recommends the following luminosity ratio standard of 1 to 4.5 for main text and 1 to 3 for large-scale text (18 pixels+, or 14 pixels+ bold).
    NOTE: If your target audience is mostly low vision, then a ratio of 1 to 7 is recommended.

    WCAG 2.0 Guideline 1.4.3

    The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA)

    • Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
    • Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
    • Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.

    The following links allow developers to test contrast between two Web color codes.

    Sample Palettes

    Vivid Colors

    The contrast of many vivid colors (e.g. red/green, blue/orange, etc) fail the contras test because they are similar in values in terms of lightness darkness. See the Working with Bright Colors page for more details.

    Gray/White

    If your color scheme fails one of the above tests, it's likely that only a few minor adjustments will be needed to bring the color values to a more acceptable level. See the examples below.

    NOTE: "Large text"=18 pixels, or 14 pixels bold

    Tests on Different Values of Gray on White
    Grey Level WCAG Ratio
    #000000 (Black) 21 : 1 (pass)
    #333333 12.63 : 1 (pass)
    #666666 5.74 : 1 (pass)
    #777777
    #777777 (large)
    4.48 : 1 (fail)
    OK for large text
    #999999 2.85 :1 (fail)
    #CCCCCC 1.61 : 1 (fail)

    Gray/Black

    Tests on Different Values of Gray on Black
    Grey Level WCAG Ratio
    #333333 2.16 : 1 (fail)
    #666666
    #66666 (large)
    3.66 : 1 (fail)
    AA for large text
    #999999 7.37 : 1 (pass)
    #FFFFF (White) 21 : 1 (pass)

     

    Cyan/White

    Tests on Different Levels of Cyan on White
    Cyan Level WCAG Ratio
    #003333 13.8 : 1 (pass)
    Hard to detect as not black
    #006666 6.79 : 1 (pass)
    #009999
    #009999 (large)
    3.49 : 1 (fail)
    AA for large text
    #00CCCC
    2.00 : 1 (fail)

    White/Sea Green

    Two versions of Sea Green on Green
    Colors WCAG Ratio
    sea green on green
    #DDFFEE on #82C1B4
    1:92:1 (fail)
    sea green on darker green
    #DDFFEE on #32796D
    4.79:1 (pass at AA)

    Orange/White

    Orange can be difficult to work with because the color is neither very dark or very light and so is hard to contrast to a sufficent level.

    Colors WCAG Ratio
    Two versions of Orange/White
    orange on white
    #FF6600 on #FFFFFF

    2.94:1 (fail)

    red-orange on white
    #DD3300 on #FFFFFF

    4.61:1 (pass at AA)

     

    Top of Page

    Dreamweaver

    Adobe Dreamweaver comes with a variety of tools and reporting functions to help create sites that are accessible from the start.

    Activate Accessibility Options

    To (re)activate Dreamweaver's accessibility functions, do the following:

    1. Open Dreamweaver and go to File then Preferences (Windows), or go to the Dreamweaver menu, then Preferences (Mac).

    2. Click on Accessibility on the left side of the panel.

    3. Make sure the options for Show Attributes when Inserting are checked for each type of HTML object.

    4. Click OK to close the window.

    The next time you insert a table, graphic, form or other media, a pop-up window will appear to prompt you to enter the appropriate accessibility tags for each item.

    Properties Panel

    The Dreamweaver Properties panel includes options for inserting accessibility tags depending on the item being edited.

    For example, when an image is highlighted, the ALT tag can be edited in the Properties panel.

    Word Header Styles

    In Dreamweaver, when text is pasted from Microsoft Word, the Header 1, Header 2, and Header 3 styles are converted to H1, H2, and H3 tags. These styles are available in Word's Style menu.

    Word users can use the Format » Styles options to modify the appearance of these styles in a Word document.

    Top of Page

    Create Accessible Data Table in Dreamweaver

    1. In Dreamweaver, go to the Insert menu then Table. A pop-up window opens.
    2. Fill in desired settings for rows, columns, width, border thickness, cell padding and cell spacing.
    3. For the Header options, select from Left, Top, Both
      Note: Top or Both is the most widely supported in screenreaders.
    4. Enter in text for Caption and Summary as needed.
      Note: Caption is visible by default to all users, while Summary is used to provide extra information for those on screenreaders.
    5. Click OK to create the table

      Dreamweaver Tables Properties Window

    Top of Page

    Microsoft Expression and FrontPage

    This page lists tutorials for implementing accessibility features in Microsoft Expression and its predecessor, FrontPage.

    Microsoft Expression and Accessibility

    Microsoft FrontPage and Accessibility

    Navigation

    In terms of Web site navigation, accessibility and usability concerns are generally similar. Usability recommendations that are of particular concern to the accessibility community include the following:

    1. HTML navigation is generally recommended over Flash navigation because it is generally easier to tweak and test HTML and even JavaScript for accessibility than Flash.

    2. Use HTML H Tags to mark major divisions on the menu, including side menus.

    3. Be sure that the navigation scheme is consistent across the Web site. This helps users form a mental map of the site and also allows those on a screen reader to more efficiently navigate a Web site.

    4. Use language for navigational labels that is comprehensible to the target audience.
      Note: In many cases, the "language" of the target audience (e.g. students, customers, general audience) differs greatly from the content developers (e.g. instructors, support staff, programmers, etc.)

    5. Navigational icons can be beneficial for some learning disabled users, but icons for less-common functions should also include a text label. Images of icons for common functions such as "print" or "next" should include an ALT tag.

    6. Be sure that navigational elements such as buttons or tabs are legible to low vision users in terms of font face and font size as well as color contrast.

    7. If your navigation includes dropdown menus, be sure that they are accessible to users on screen readers and to motion impaired users. In some cases, a link to static menu, such as a sitemap, may be recommended.

    8. If your navigation includes any scripted or dynamic elements, be sure that they are tested for screen reader users.

    9. Be sure to include a Skip Navigation strategy so users, especially those on a screen reader, can skip large blocks of repetitive links.

    Top of Page

    WCAG 2.0 Guidelines

    Organization of WCAG 2.0

    The Web Content Accessibility Guidelines (WCAG) 2.0 are organized into general principles that apply to past, present and future technologies—that is, they tend to focus more on the needs of the user than on detailing specific technical guidelines. To assist in interpreting the principles, the WCAG and other guideline sysems have also provided implementation guidelines, which address common technical implementations of the principles.

    Both the WCAG 2.0 and the older WCAG 1.0 are further organized into priority levels, ranging from most important (A) to least important (AAA). At Penn State, Web sites should fulfill levels A and AA to be considered compliant.

    List of Principles and Implementation Guidelines

    Below is a list of principles summarizing WCAG 2.0 principles and guidelines (as of 2011), with simple implementation guidelines and links on where to find more details. These guidelines are not a list of HTML "dos and don'ts", but rather a list of accommodations that must be made for people with different disabilities.

    The "How to Implement" column represents a minimum baseline for HTML, video, audio and other common technologies, although adjustments can be made as needed. Note that not every technology may be covered in these guidelines.

    Top of Page

     

     

    Principle 1: Perceivable

    "Information and user interface components must be presentable to users in ways they can perceive."

    Examples of Principle 1:

    Guidelines 1.1–1.4

    Synopsis of WCAG 2.0 Guidelines 1.1–1.4
    Guideline Number Guideline How to Implement
    Guideline 1.1:
    Text Equivalent
    "Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language."

    Guideline 1.1 details

    Guideline 1.2:
    Time Based Media (Audio/Video)
    "Provide alternatives for time-based media."

    Guideline 1.2 details

    Guideline 1.3:
    Adaptable
    "Create content that can be presented in different ways (for example simpler layout) without losing information or structure."
    • Use appropriate semantic markup whenever possible for HTML documents, including header styles.
    • Use appropriate markup for table headers.
    • Use appropriate markup, including form LABELS, to identify form and application controls.
    • Preserve the visual sequence of content even with disabled styles.
    • Flash objects are implemented so that a screen reader will read them in the appropriate sequence.

    Guideline 1.3 details

    Guideline 1.4:
    Distinguishable
    "Make it easier for users to see and hear content including separating foreground from background."
    • Ensure appropriate contrast between text and background.
    • Ensure that content is distinguishable independent of color.
    • Avoid automatically-playing audio, slideshows and animation. Provide play buttons instead.
    • Use CSS formatting instead of graphics to format text whenever possible

    Guideline 1.4 details

    Top of Page

    Principle 2: Operable

    "User interface components and navigation must be operable."

    Examples of Principle 2:

    Guidelines 2.1–2.4

    Synopsis of WCAG 2.0 Guidelines 2.1–2.4
    Guideline Number Guideline How to Implement
    Guideline 2.1:
    Keyboard Accessible
    "Make all functionality available from a keyboard." All form and application controls can be operated from a keyboard. For example:
    • Arrows keys can control sliders, or numbers can be entered to set parameters.
    • Tab keys can be used to be navigate between form fields and buttons.
    • Keyboard commands can be used to activate and operate video players.
    • Keyboard commands can be used to close and control windows.

    Guideline 2.1 details

    Guideline 2.2:
    Enough Time
    "Provide users enough time to read and use content." When appropriate:
    • The user is warned of time limit expiration and permitted to extend time.
    • Scrolling or blinking text can be paused.
    • Users have the option to block an automatic update of content.
    Exceptions are allowed when changes in timing would interfere with an essential function.

    Guideline 2.2 details

    Guideline 2.3:
    Seizures
    "Do not design content in a way that is known to cause seizures."
    • Flashing objects should be avoided or limited to 3 flashes per second.
    • Exceptions are allowed for flashes below the general or red flash threshold.

    Guideline 2.3 details

    Guideline 2.4:
    Navigable
    "Provide ways to help users navigate, find content, and determine where they are."
    • HTML Frames are given meaningful titles
    • Users are given mechanisms to skip repetitive content.
    • Landmarks are provided to assist in screen reader navigation, e.g. meaningful page title, meaningful headers and meaningful and unique hyperlink text.
    • Multiple paths are provided to navigate through Web site content.
    • Keyboard users are able to see a cursor or other indicator of position on the screen.

    Guideline 2.4 details

    Top of Page

    Principle 3: Understandable

    "Information and the operation of user interface must be understandable."

    Examples of Principle 3:

    Guidelines 3.1–3.3

    Synopsis of WCAG 2.0 Guidelines 3.1–3.3
    Guideline Number Guideline How to Implement
    Guideline 3.1:
    Readable
    "Make text content readable and understandable."
    • Identify language of text or subsection of text with a language code.
    • Identify and define unusual words or jargon.

    Guideline 3.1 details

    Guideline 3.2:
    Predictable
    "Make Web pages appear and operate in predictable ways."
    • Avoid unannounced pop up windows.
    • Avoid disabling the browser's Back button.
    • Provide a separate Submit or Go button/link to initiate page changes (versus autosubmit upon selection).
    • Allow automatic slideshows and scrolling or blinking text to be paused.
    • Give users the option to block automatic updates of content.

    Guideline 3.2 details

    Guideline 3.3:
    Input Assistance
    "Help users avoid and correct mistakes."
    • Provide appropriate form field validation.
    • Provide clear labels for form and application controls.
    • Provide usable instructions for entering information into forms and applications (preferably before the form field).
    • Provide clear and usable error messages identifying the location of error and information for correcting it.

    Guideline 3.3 details

    Top of Page

    Principle 4: Robust

    "Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies."

    Guideline 4.1

    Synopsis of WCAG 2.0 Guideline 4.1
    Guideline Number Guideline How to Implement
    Guideline 4.1:
    Compatible
    Maximize compatibility with current and future user agents, including assistive technologies.
    • Use validated markup
    • Label the name and role of all user interface components.
    • Identify the value for all data fields, including parameters for interface controls.

    Guideline 4.1 details

     

    Top of Page

    Accessibility Checklist

    This Quick Accessibility Checklist is meant to help faculty and staff who want to develop or modify Web-based course material, lectures, and assignments in an accessible way.

    See also the Section 508 Requirements.

    Table of Contents

    1. Multimedia Elements
    2. Web Tools
    3. HTML Tags
    4. Advanced Web Design

    Multimedia Elements

    1. If you use images, use the ALT tag to provide a clear text alternative. Descriptive ALT text should provide equivalent information as the graphic. For complex images, an extended text description may be needed. If you want a tooltip for an icon, use the TITLE attribute, not the ALT attribute.
      View Details: Images

    2. If you use charts or graphs, provide a text alternative that summarizes the content of each chart or graph, and make sure color coding is not the only key used in the chart, but is supplemented with labels or differences in line shape.
      View Details: Charts

    3. If you use mathematical or scientific notation, be sure a screen reader can access the content either through an ALT tag on an image, an extended text description or some other mechanism.
      View Details: Math

    4. If you use motion or animation, make sure that it's necessary and that the flicker rate is lower than 2 Hz. and greater than 55 Hz; animations within these frequencies may trigger epileptic seizures. If the animation is needed, be sure to provide an alternate text description that clearly communicates the action and its purpose on a separate page.
      View Details: Animation

    5. If you use audio or video files, provide captioning or a description/transcript in text form. If a transcript is used, then text can be can be on the same page, or accessed via a hyperlink to a separate page can be placed near the clip.
      View Details: Video and Audio

    6. If you want to upload a PowerPoint file, then make sure all graphics are labeled and includes appropriate extended descriptions are included. All audio should be captioned or have a transcript. PowerPoint files converted to HTML should include ALT tags as needed.
      View Details: PowerPoint and Word

    7. If you want to use material from a Word file, then either upload it as is, recreate the HTML file or convert it to a PDF file. Avoid the Save as Web file option in Word as it creates inaccessible files.
      View Details: PowerPoint and Word

    Top of Page

    Other Web Tools

    1. If you use ANGEL or other course tools, make sure all uploaded images are described, all uploaded material is accessible and that all quizzes and forms are accessible.
      View Details: ANGEL

    2. If you use PDF files, make sure the PDF is restricted to appropriate uses and that files include labels or tags identifying embedded images and that text content is stored as text, not as a large image. Links to PDF files should include some sort of indication on the page that the link is different; this will reduce user confusion. When in doubt, create a text-only or HTML version of the content. Section 508 also requires that a Web site provide a link to the Adobe Acrobat Reader download page.
      View Details: PDF Files

    3. If you use Adobe Connect, make sure that the tool is usable by a screen reader if a participant is visually impaired. Captions or chat texting should be used if a participant is visually impaired.
      View Details: Adobe Connect

    4. If you use ASCII art in e-mail signature, then make sure it is placed below all the essential contact information so users of screen readers can stop reading the content.
      View Details: Chat and E-Mail

    Top of Page

    HTML Tags

    1. Basic HTML tips - Use appropriate H tags to structure your content into sections and be as concise as possible. Be aware of how screen readers pronounce acronyms and abbreviations as single words.
      View Details: HTML Structure | View Details: Abbreviations

    2. If you want to incorporate color, be sure that none of the content relies on color coding alone. Color coding should be supplemented by text or differences in lightness or shape. Contrasts of bright colors and strongly textured backgrounds should also be avoided to facilitate legibility.
      Note: Contrasts of red/green or red/black are the most likely to be confused.
      View Details: Color

    3. If you wish to specify a font, consider fonts designed for a computer monitor such as Arial and Verdana and always use relative sizes. Italics text should be used minimally, and blinking text should be avoided.
      View Details: Fonts

    4. If your page has a block of navigational links on each page, include a "Skip Navigation" strategy accessible to screen readers.
      View Details: Skip Navigation

    5. If your page has links, then make sure the text of the link describes the location of the new page. Avoid generic "Click Here" links.
      View Details: Links

    6. If you use lists, use ordered lists so that items are numbered, or include the item number within your text.
      View Details: Lists

    7. If you use tables, be sure to include header tags for data tables and that any table makes sense when read left to right, top to bottom. This is how a screen reader will read them by default.
      View Details: Data Tables | View Details: Layout Tables

    8. If you use frames, clearly title each frame, file name and use the TITLE attribute to facilitate navigation and frame identification. Provide basic navigation for each page in case user enters Frames Free mode.
      View Details: Frames

    9. If you use forms, clearly associate form labels with each elements by placing them to the left of the element. Use of LABEL and FIELDSET tags can facilitate accessibility.
      View Details: Forms

    10. If you need to include equations or formulas, make sure each one is labeled and that any equation or formula necessary for content includes a link to an extended text description which reads out the formula in words.
      View Details: Equations and Formulas

    11. If you use multiple languages, make sure to specify the LANG tag and use appropriate HTML entities for special characters and punctuation. For languages with low numbers of speakers, an audio transcript may be needed for full accessibility.
      View Details: Languages

    12. If you use CSS formating, make sure your CSS formatting produces an accessible page and that the page is still functinal if CSS is disabled.
      View Details: CSS

    Advanced Web Design

    1. If your page includes image rollovers, then make sure the alt tag includes the most relevant information. For rollovers showing complex concepts, a link to a text description should be included. If you use image rollovers to change text formats, consider switching to CSS style sheet rollovers since they are often more accessible.
      View Details: Rollovers

    2. If your page includes automatic datestamping, you may want to consider one of several non-Javascript options available in which a date is inserted by a server or Web editor. Otherwise a date would need to be automatically updated in order to be accessible.
      View Details: Date Stamping

    3. If your page includes dropdown or floating menus, then make sure a text-based menu is included. Floating menus are difficult for screen readers, users with mobility impairments, and users with some types of cognitive impairments to use.
      View Details: Dropdown and Floating Menus

    4. If your page includes redirects or timed actions (such as clicking OK to continue being logged in), then be sure to provide adequate response time for users of screen readers or users with mobility impairments. In some cases, a redirect should be replaced with a static page containing a link.
      View Details: Redirects and Other Timed Responses

    5. If your page includes popup windows, make sure a link to the content is available even if Javascript is disabled. Windows should permit scrolling and resizing for low vision users.
      View Details: Popup Windows

    6. If you use dynamic pages, make sure all HTML chunks include accessibility tags and that ALT tags or frame TITLE tags are meaningful and not numeric database entries.
      View Details: Dynamic Pages

    7. If you use scripts or applets, then make sure a NOSCRIPT alternative is available.
      View Details: Scripts

    Top of Page

    Accessibility Blog

    To view the Accessibility Blog, click on the "Accessibility Blog" at the top or the left

    External Links to Accessibility Sites

    Accessibility Books

    Implementing Accessibility

    Penn State Accessibility

    This Section: Policy | Assistive Technology Labs

    Penn State Accessibility

    Assistive Technology Labs

    Top of Page

     

    This Section: In-DepthAccessibility | Tool Demos | University Tutorials | Software Vendor Tutorials

    In-Depth Tutorials

    In-depth accessibility tutorials aimed for Web masters

    Assistive Tech Tool Demos

    Sites which provide demos of screen readers, text zoomers and other accessibility hardware and software.

    University Tutorials

    Aimed for instructors and Web masters.

    Tutorials from Software Vendors

    Top of Page

    This Section: WCAG 2.0 Guidelines | Section 508 Guidelines |Outside the U.S.

    Web Content Accessibility Guidelines (W.C.A.G.)

    Comprehensive recommendations developed by the W3C (World Wide Web Consortium). They are divided into three priority levels ranked from most crucial (AA) to least crucial (AAA). Penn State Policy A.D. 69 mandates A and AA compliance.

    Section 508 Checklists

    Section 508 is still the official standard for sites built by the U.S. federal government. Although most Section 508 and WCAG 2.0 guidelines, there are are some minor differences in what Section 508 requires. Note also that the first section of the guidelines applies mainly to the development of custom software applications for the federal government, not necessarily to Web sites.

    Outside the U.S.

    If you are working with agencies or organizations outside the U.S., this information may be useful.

    Top of Page

    This Section: Online Verification Services | Firefox Browser Plug Ins

    Verifications should be used as only one of several accessibility tests. See the Suggested Testing Protocol for suggested guidelines on screen reader tests, color tests and zooming tests.

    See Also: Lynx Browsers | Color Blindness Simulators

    Online Testing Services

    Firefox Browser Plug Ins

    These plug ins and tools allow you to easily view sites without images or stylesheets.

    Top of Page

     

    Different Audiences

    This Section: Lists of JAWS Commands | Screen Reader Vendors | Lynx Downloads | Advocacy Groups

    Lists of Jaws Commands

    JAWS is one of the most commonly used screen reader programs. It not only reads Web sites, but reads all text within the Windows system (application menus, document text, help screens, and so forth).

    Screen Reader Vendors

    See Also: Tools Demos

    Lynx Text Browser

    Lynx is an open source application much as in the Linux model. There are lots of sources for downloading Lynx, but some "installs" require more effor to set up than others.

    Advocacy Groups

    Top of Page

    This Section: Zooming Simulations | Design Tips   

    Low Vision Design Tips

    Zooming Simulations

    Top of Page

    This Section: Color Blindness Simulators | About Color Blindness

    Color Blindness Simulators

    About Color Blindness

    Top of Page

    This Section: Captioning Software | Captioning How-tos

    Captioning Software

    Captioning How-tos

    Top of Page

    Mobility Impairment Links

    Top of Page

     

    Cognitive Disability Links

    Top of Page

    Other Issues

    This Section: P.D.F Files | Microsoft Office | Flash Files

    P.D.F. File Accessibility Links

    Microsoft Office Accesibility Links

    Flash Accessibility Links

    Top of Page

    Top of Page

    This Section: Pop-Up Windows

    Pop-Up Windows

    These Websites provide advanced tips for implementing Javascript pop-up windows in an accessible fashion. Testing on multiple platforms is recommended.

    Top of Page

    Section 508 Summary Requirements

    List of Regulations

    Below is a table summarizing Section 508 requirements for federal government Web sites. Please note that as of 2011, Penn State Policy A.D. 69 mandated WCAG 2.0 Levels A and AA as the accessibility guidelines.

    Synopsis of Section 508 Requirements for Federal Government Websites
    Paragraph # Text of Regulation How to Implement
    A
    A text equivalent for every non-text element shall be provided. Use TITLE or ALT when available as a minimum. Provide longer text transcriptions and descriptions for more complex items.

    Details on pages for Images, Image Maps, animations, Audio and Video, Charts,Math
    B
    Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation. Use captioning software for video or Flash animations when possible.

    Details on page for Audio and Video
    C
    Web pages shall be designed so that all information conveyed with color is also available without color. Supplement color coding with other signals such as shape or text.

    Details on page for Color
    D
    Documents shall be organized so they are readable without requiring an associated style sheet. Use external stylesheets, but also make sure pages are structured with appropriate H tags to be readable with stylesheets disabled.

    Details on pages for CSS and HTML Structure
    E
    Redundant text links shall be provided for each active region of a server-side image map. If you use server side image maps, provide a text based menu. But client side maps are preferred (see next paragraph).

    Details on page for Image Maps
    F
    Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape. Client side image maps are preferred unless they can only be implemented with server-side image maps.

    Details on page for Image Maps
    G
    Row and column headers shall be identified for data tables. Use the TH tags for column and row headers of data tables

    Details on page for Data Tables
    H
    Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers. Additional accessibility tags are need for very complex data tables.

    Details on page for Data Tables
    I
    Frames shall be titled with text that facilitates frame identification and navigation. Use the TITLE attribute and meaningful frame titles.

    Details on page for Frames
    J
    Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hertz (cycles per second) and lower than 55 Hertz. Avoid rapidly blinking texts and animation.

    Details on pages for Fonts | Animation
    K
    A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of these standards, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes. Use a text-only page only as a last resort. The text-only page must be updated with the rest of the site or the site will be out of compliance.
    L
    When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology. Content must accessible on pages using scripts. Some screen readers are unable to process some types of Javascript links, so a NOSCRIPT alternative must be provided.

    Details on Scripts
    M
    When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with § 1194.21(a) through (l). 1. Always provide a link to an accessible Web page where a user can download a plug-in.

    2. Plug-ins used should allow you to create Section 508 compliant content. See vendors for details.

    Details on pages for PDF Files, Flash and Microsoft Office
    N
    When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues. Use new forms tags to facilitate accessibility

    Details on page for Forms
    O
    A method shall be provided that permits users to skip repetitive navigation links or very long lists of links. Details on page for Skip Navigation
    P
    When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required. Details on page for Redirects

     

    Top of Page

    Events List Archive

    A partial list of recorded webinars is also available.

    Note: Due to security issues, most Penn State webinars are limited to Penn State faculty and staff.

    Summer 2012

    August 2012

    Fall 2012

    September 2012

    October 2012 (Disability Awareness Month)

    November 2012

    December 2012

    Spring 2013

    January 2013

    February 2013

    March 2013

    April 2013

    Summer 2013

    May 2013

    Summer 2013

    June 2013

    July 2013

    August 2013

    Fall 2013

    September 2013

    October 2013

    November 2013

    December 2013

    Spring 2014

    January 2014

    February 2014

    March 2014

    April 2014

    Summer 2014

    May 2014

    June 2014

    July 2014

    August 2014

    Webinar Archives

    Below is a list of captioned recordings of past events.

    1. Introduction: Importance of Web Accessibility
      Bill Welsh from the Office of Disability Services reviews policy and issues relating to the need to provide accessible access to Penn State materials.
    2. 8 Main Blockers Webinar
      A review of some of the most critical blockers to accessibility, particularly for screen reader users.
    3. Beyond the Blockers: Accessible Doc Design
      Additional accessibility issues that should be addressed beyond the main eight blockers
    4. ANGEL Accessibility Webinar
      Some tips for making content in the ANGEL course management system more accessible.
    5. Dreamweaver and Accessibility Webinar
      Elizabeth Pyatt from TLT provides an overview of tools Dreamweaver provides to generate more accessible HTML.
    6. Firefox Testing Tools
      Elizabeth Pyatt of TLT gives an overview of WAVE, the Juicy Studios toolbar and other testing tools for Firefox.
    7. PDF: Escape from PDF Clinic
      Derick Burns of TLT discusses how his unit migrated from PDF to alternative document formats.
    8. PDF: Escape from PDF Webinar
      An overview of different accessibility issues relating to PDF accessibility and repair and recommendations for migrating PDF content or providing alternate sources.
    9. STEM Course (Match & Science) Accessibility
      Some basic strategies to make technical images and tables more accessible.
    10. Triage and Testing
      Christian Vinten-Johansen from TLT discusses how to prioritize your content for accessibility remediation.
    11. Understanding WCAG 2.0
      Christian Vinten-Johansen provides some guidance in how to understand the WCAG 2.0 guidelines.
    12. Video Captioning Clinic
      Pat Besong demonstrates captioning techniques including those of the MovieCaptioner software.

    Web Liaison Information

    The Penn State administration has appointed accessibility Web Liaisons for each campus, college and budget unit. To learn more about the program and receive news bulletins, you can join the Web Liasons group in the Penn State Yammer network following the instructions below.

    Note: Yammer messages can also be forwarded to e-mail as desired. See instructions for forwarding Yammer messages for details.

    Create Yammer Account

    To create an account in the Penn State Yammer network.

    1. Go to http://yammer.psu.edu.
    2. Follow the instructions on the First Steps page to join Yammer.

    Join "Web Liaisons" Group in Yammer

    1. Log in via http://yammer.psu.edu.
    2. On your profile page, and enter Web Liaisons in the search field. Click search result to view the group's profile page.
    3. On the Web Liaisons group profile page, click the + Join link.
    4. A request will be sent to the moderators of the group. You will receive a confirmation e-mail when you are approved.

    Access Files in "Web Liaisons" Group

    The Yammer group contains news bulletins and resources in the "Files" area including the current list of Web Liaisons.

    1. Log in to Yammer and click Web Liasons in your list of Groups.
    2. In the "Web Liaisons" group, click the "Files" tab to view a list of available files including the list of current Web Liaisons.

    Forward Yammer Messages

    You can set up Yammer to forward messages to e-mail, daily e-mail digest and other tools. To set up forwarding, do the following.

    1. Log in via http://yammer.psu.edu.
    2. Navigate to the Notifications page in your profile
    3. Open the options for the psu.edu network
    4. Check any Yammer group you wish to receive e-mail from.

    Additional Yammer Features

    Links to current documentation on Yammer, including options to push messages to e-mail, is at the Penn State Yammer page and at the Yammer Help Center.

    Top of Page

    Accessibility Syllabus Statement Language

    A syllabus for courses at Penn State must include a statement informing students with disabilities of their rights and options. Below is recommended language for the statement.

    Penn State welcomes students with disabilities into the University's educational programs. Every Penn State campus has an office for students with disabilities. The Office for Disability Services (ODS) Web site provides contact information for every Penn State campus: http://equity.psu.edu/ods/dcl. For further information, please visit the Office for Disability Services Web site: http://equity.psu.edu/ods.

    In order to receive consideration for reasonable accommodations, you must contact the appropriate disability services office at the campus where you are officially enrolled, participate in an intake interview, and provide documentation: http://equity.psu.edu/ods/guidelines. If the documentation supports your request for reasonable accommodations, your campus’s disability services office will provide you with an accommodation letter. Please share this letter with your instructors and discuss the accommodations with them as early in your courses as possible. You must follow this process for every semester that you request accommodations.

    See the Senate Policy 43-00 (Syllabus) for details on the policy.

    Note: Any syllabus posted online (e.g. a Word/PDF file or an online syllabus) should make destinations clickable links such as in the example above.

    Get Help

    For more information you can contact these sources.

    Technology Questions

    Yammer

    There are currently two groups in Penn State's Yammer account where announcements are posted – Accessibility and Web Liasons.

    The Web Liasons page contains information on how to join Yammer groups.

    Email

    Student Accommodations and Questions

    Assistive Technologies

    Staff Accommodations and Questions

    Training Events and Other Announcements

    Event announcements are posted at the following locations

    Tools for Accessibility