Creating Accessible Electronic and Information Technology
By Neal Albritton (July 29, 2011)
Who Among you are Content Creators?
•	Websites
•	Digital Documents
•	Print Media
•	E-mail

Who is this information intended for?
•	Employees
•	The Public
•	Customers
•	Contractors
What about people with disabilities?
Digital content, when developed, needs to take into account the needs of people with the following types of disabilities:
•	Hearing
•	Sensory
•	Motor
•	Cognitive
•	(Note: As our population ages, many will experience one or more of these functional limitations.)

Accessibility is the Law
The following laws may apply:
•	California Government Code 11135
•	Section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d)
•	The Americans with Disabilities Act (Title I)
•	California Unruh Civil Rights Act
•	Note: Numerous states already have laws in place that mimic or exceed federal civil rights laws. California is definitely one of them!

Issues to be concerned about:

Adobe PDF files, Microsoft Power Point presentations and Microsoft Word & Excel documents are the most common formats for digital documents. 
•	To be accessible, they must be perceivable, operable, understandable and robust.

Ah-hah!

As content creators… 
•	We all play an important part in complying with the law and ensuring that our customers and employees have access to our programs and services.

4 Principles to Consider

#1. Perceivable
•	Your digital documents must be perceivable. That is, visible to any person’s one or more senses, even if she is a blind user, or one with low vision.

4 Principles to Consider

#2. Operable
•	Digital content must be operable. That is, any user should be able to perform the necessary interactions with it. This most often involves interactive forms and navigation.

4 Principles to Consider

#3. Understandable
•	Information presented must be understandable by those attempting to use the information. 
•	That is why it is important to anticipate user-interaction. 
•	Targeted users should include people with learning disabilities and people with cognitive limitations.

4 Principles to Consider

#4. Robust
•	Digital documents should be designed for presentation to people with disabilities using different, current and future assistive technologies.

Best Practices for PDF, Word, and PPT

PDF (Portable Document Format)
•	Tagged Reading Order
•	OCR all Scanned content
•	Identify document language
•	Note: Remember to save multiple copies of your original document whenever editing PDF!!!

Portable Document Format (PDF)
Accessible PDFs - Quick Reference
•	Review & correct the Document Properties 
•	File > Properties or 
Keyboard shortcut – Ctrl + D

PDF
Accessible PDFs - Quick Reference
•	 Under “Description” tab: 
•	 Determine if the document has been tagged
•	Give the title of the document a meaningful name - which will be displayed on search results pages
•	Add the author’s name 
•	Give a meaningful subject of the document 
Apply keywords to the document separating each word by a comma – no spaces. 
•	Ex. keyword,keyword,keyword 
 
PDF
Accessible PDFs - Quick Reference
•	Apply tags to the document - if no tags are present from the Document Properties.
•	Advanced > Accessibility > Add Tags to Document 
•	Correct tags and fix - from the tags panel

PDF
 Accessible PDFs - Quick Reference
•	Correct tags and fix - from the tags panel 
•	Most common tags used: 
•	<P> tags are used for paragraphs of content 
•	<FORM> tags are used for form fields 
•	<LI> tags are used for objects that are listed on a page 
•	<Header>,<H1>,<H2>,<H3> tags are used for headers in a document

PDF
Accessible PDFs - Quick Reference
<FIGURE> tags are used for images inside of a document. 
<TABLE> tags are used for contents that pages that contain tables. 
<TH> tags within a <TABLE> represent Table Headers. 
<TR> tags within a <TABLE> represent Table Rows. 
<TD> tags within a <TR> represent Table Data.

PDF
Accessible PDFs - Quick Reference
 Form fields always need the following: 
•	Tooltips – provide a description to the viewer using an assistive technology tool for what the form field means and the action to apply to it. 
•	Example: a first name field should have a tooltip of, “Enter First Name:” Screen readers will read the tooltip as, “Enter First Name Colon”
•	Correct tab order – Document should have a tab order that will flow top to bottom, left to right. 

PDF
Accessible PDFs - Quick Reference
•	Alternative Text for figures (images) located on a page 
•	If the figure (image) has importance to a page, then Alternative Text (Alt Text) must be applied to it.

PDF
 Accessible PDFs - Quick Reference
•	Create the tag from the tags panel or 
•	Create the tag from the “Touch Up Reading Order Tool”
•	Apply the Alternative Text by right-clicking the <FIGURE> tag that is created and going to properties 
•	Under the “Tag” tab, enter a meaningful description in the “Alternative Text” box. 

PDF
Accessible PDFs - Quick Reference
•	Add Bookmarks to a document that consists of over 10 pages 
•	Tables must have the proper tags identified within the <TABLE> tag
o	<TH> for Table Headers 
o	<TR> for Table Rows 
o	<TD> considered Table Data within the Table Row

PDF
Accessible PDFs - Quick Reference
Entire document must flow in a logical reading order. 
•	Top to Bottom 
•	Left to Right 

Best Practices for PDF, Word, and PPT

Word Documents
•	Stop using “BOLD” and Instant Font and Font Size
•	Instead… create Style Sheets
•	Identify Table Headings using styles
•	Label image content by:
o	Right-click on the image
o	Select “Format Picture” option
o	Click on the “Alt Text” tab and provide a brief description.

Best Practices for PDF, Word, and PPT
PowerPoint
•	Create a text or HTML equivalent
•	Label image content

What about E-mail?
There are various email formats available. 
•	But for those who use screen readers, some formats may hinder access to email content and prevent the reader from making sense of the messages received. 

What about E-mail?
HTML Email:
•	The most common email formats are:
•	HTML and Plain Text.
•	HTML-formatted email is usually easier to navigate through links, headings, and tables if created with accessibility in mind. 

What about E-mail?
HTML Email:
•	Accessible emails in an HTML format enable the recipient to use the full functionality of their assistive technology. 
•	If the HTML-based email contains non-text elements such as images or links, then they must include alternative text descriptions ("alt-attribute") so that the information will make sense.

What about E-mail?
Plain Text Email:
•	Plain Text emails are accessible to recipients that require assistive technology to read the content. 
•	When several links are included within the email, screen reader technologies are apt to read the URL links without associating any textual description to those links. 

What about E-mail?
Plain Text Email:
•	This tedious task requires a screen-reader user to navigate through the entire message to determine which link is associated with which text. 
•	If the plain text email contains dialog from forwarded messages, then those messages may include different symbols (such as the "greater-than symbol") to represent headings or the beginning of paragraphs.
•	Screen-reader technologies read each individual character aloud creating extraneous noise.

What about the Web?
•	Validate to XHTML 1.0 Strict 
•	Use Cascading Style Sheet (CSS) and make sure to validate your CSS code! 

What about the Web?
•	Careful using JavaScript… 
Issues include:
•	Navigation: Inability or difficulty navigating using a keyboard or assistive technology.
Hidden content: Presentation of content or functionality that is not accessible to assistive technologies.

What about the Web?
•	Careful using JavaScript… 
Issues include:
•	User control: Lack of user control over automated content changes.
Confusion/Disorientation: Altering or disabling the normal functionality of the user agent (browser) or triggering events that the user may not be aware of.

What about the Web?
•	Broken Hyperlinks: 
o	Outdated web content may not have the most up-to-date links to external information.
o	Web sites heavy with external links are most prone to this dilemma.
o	If information on your web site is not current, visitors are likely to go somewhere else to get the information they are seeking.

What About the Web?
•	Color Contrast: 
o	People with color blindness and low-vision may not be able to clearly read or understand web content that has poor contrast.
o	Be careful with Red and Green!

What About the Web?
•	Luminosity: 
o	Sometimes color combinations do not provide sufficient contrast between background and foreground colors.

What About the Web?
•	Photosensitive Epilepsy and Animations: 
o	Some web animations or video may cause seizures to people with Epilepsy.
o	Content that contains video or animation should be evaluated, especially if that content contains flashing or rapid transitions between light and dark background colors.

What About the Web?
•	Bandwidth: 
o	Web pages that have not been optimized for easy download through slow modem connections quickly frustrate visitors and online customers - turning them away to resort to other alternative websites for information.
o	This includes large downloadable files such as PDF, video, audio and image files.

What About the Web?
•	Image Optimization: 
o	Image file size can quickly bloat a website if not properly optimized. 
o	Remove unused pixels.
o	Change the overall size of the image so it downloads faster while remaining viewable and undistorted.

What About the Web?
•	The following list addresses key features of web development that enhance the accessibility and compliance with state and federal web accessibility standards. 
•	They are in no particular order of priority, and each is equally as important as the rest. 

What About the Web?
•	A visible “skip to” navigation feature should exist at the top of each web page. This should be the first link that a visitor arrives to and allow access to content, accessibility features used within the website, and to the footer. 
•	For example: skip to: content | site accessibility for this website | footer

What About the Web?
•	Alt-attributes should not include the following words within their description:
•	“image of”, “picture of”, “.JPEG of”, “.GIF of” or “Photo of”.
•	Instead, label exactly what the image is (“Mickey Mouse” instead of “Picture of Mickey Mouse”). 

What About the Web?
•	For alt-attributes describing structural images that do not contribute any meaning, such as a white 2x2 pixel spacer, use empty-quotes (“”) without any description.
o	For example: <img src=“/spacer.jpeg” alt=“” />

What About the Web?
•	Make the search engine accessible and format input elements and buttons in a logical reading order. 
o	The title should come first, followed by the search field visibly labeled as “<keyword or phrase>” to describe what input is needed. This should disappear (use the “onmousedown” event handler) when the user clicks in the field to type their search word. 
o	Place the search button after the search within “yourwebsite.com” radio button. 
o	Use relative sizing for the button and field size instead of static or exact sizing.

What About the Web?
•	If incorporating an accessibility feature such as: 
 “Click to change text size to: small | medium | large” 
•	Be sure to use the title-attribute to provide greater meaning to the destination of these one-word links for when screen reader technologies are set to navigate by hyperlink-only mode. 

What About the Web?
•	Translation tools such as “Babelfish” are not accessible to people who are blind and should be removed. 
•	If translation is going to be offered, then content should be translated by qualified interpreters
•	Incorporate translated textual images, text on buttons and labels, and translated alt-attribute descriptions.

What About the Web?
•	Remove the redundant words “click here” from all alt-attributes descriptions. Instead, provide concise and meaningful descriptions for hyperlinked content to minimize confusion. 
•	Alt-attribute descriptions should contain 7-81 characters. If more characters are needed, then the “longdesc” attribute or a “d-link” should be used.

What About the Web?
•	All adjacent hyperlinks should be separated with a non-hyperlinked dash or hyphen so that the two links are not perceived as one single link if the content is significantly magnified for someone with low-vision. 
•	Example:   Instead of:  Small   Medium   Large, 
use:  Small | Medium | Large
•	Add a hyperlink to navigate to the top of the page from the footer (“Top of page”).

What About the Web?
•	Alt-attributes need to be understandable when read out of context. For example, hyperlinked images with the alt-attribute of “Click here to start” are not accessible. 
•	Imagine a webpage with ten adjacent links and images featuring links to various services and applications. 
•	If each image and/or hyperlink has an alt-attribute labeled as “Click here to start”, then a screen reader operating in “hyperlink mode” will read “Click here to start” ten times and not offer the user much insight into what each link is.

What About the Web?
•	It is important for the web developer to understand that a screen reader navigating from hyperlink to hyperlink cannot associate any meaning that may be intended by placement or color. 
•	Directions or cues to the user should be very clear so as not to leave the individual guessing as to what is expected of him or her.  

What About the Web?
•	Styles should not be forced on the web page. User preferences should be allowed to override the webmaster’s styles. 
•	Therefore, external cascading style sheets should be used for each webpage. This is done be creating a link to the style sheet from within the header area of the XHTML code. For example:  
<link rel="stylesheet" type="text/css" href="mystylesheet.css"/>
</head>
<body>

What About the Web?
•	As a best practice, any defaulted font sizes for the content should be set to at least 12 point font. 
o	 This will be appreciated by the many “aging eyes” that might choose to visit the website.

What About the Web?
•	Web pages should be coded to XHTML Strict 1.0. 
o	This allows for fewer validation errors, better browser compatibility across the board, and easier maintenance in general.

What About the Web?
•	Identify row and column headers for data tables. For complex data tables with two or more logical levels of row or column headers  be sure to use markup to associate the data cells and header cells.
•	Make sure web pages utilizing scripts (such as JavaScript) run when scripts are disabled from the user’s web browser.
•	Provide both a Rich Text Format (.RTF) and a Microsoft Word (.doc) copy of downloadable documents when possible.

What About the Web?
•	Make sure videos are captioned whenever possible. 
o	Otherwise, provide a text-equivalent transcript of the video.
 
What About the Web?
•	All pages should be tested, whenever possible, by live users with disabilities representing a diverse range of disability types such as:
o	 Total blind screen-reader user
o	 Low-vision, magnifies the screen to access
o	 Color blind user
o	 User with dyslexia
o	 Non-mouse users (keyboard-navigation only)
o	 Deaf and hard of hearing

What About the Web?
•	Identify content headings accordingly in order to assist screen reader users in navigating through website content, especially lengthy web pages. 
•	It can be very frustrating when a web page does not have headings to assist one in finding the different sections of content.

What About the Web?
•	Remember-- testing should be performed before uploading or updating any content to the web. 
•	Automated testing utilities lack the human experience, are unable to test every Section 508 standard, and may deliver erroneous results. 
•	However, automated testing utilities, when paired with human testers, can be very effective.

What else can we do?
It is important, as a start, to:
•	Train all content creators
•	Create accessibility policy with top-level buy-in.
•	Do not procrastinate!

Policies and Procedures
Organizations should have effective policies and procedures in place and publically posted to ensure that people with disabilities have access to information. 
•	Four Policies and procedures to include:
•	Accessibility Help 
•	Accessibility Policy
•	Reasonable accommodation and alternative format request policy and procedures
•	Privacy Policy

Policies and Procedures
Post policies and procedures to your website and make them available for distribution as print and electronic document formats.

Policies and Procedures
Accessibility Help: 
•	Describes accessibility features incorporated in the design of your website to help a visitor with a disability make the most of these features while using their assistive technologies.

Policies and Procedures
Accessibility Policy: 
•	Describes steps taken to deliver accessible content.  

Policies and Procedures
Reasonable accommodation and alternative format request policy and procedures: 
•	Describes how an individual may request alternative formats and timelines needed to provide alternative formats of Web content. 
•	Be sure to include phone and TTY numbers, mailing address, and email address.

Policies and Procedures
Privacy Policy: 
•	Describes steps taken by your organization to ensure that any information provided electronically will remain private and secure.

Resources
•	The Access Board: Section 508 (1194.22 a-p)
o	Website: www.section508.gov
•	The World Wide Web Consortium
o	Website: www.w3.org
•	Department of Rehabilitation
o	Website: www.dor.ca.gov/webaccessibility/
•	Section 508 Guru
o	Website: Section508Guru.com
Resources
•	Accessibility Color Wheel: gmazzocato.altervista.org/colorwheel/wheel.php
•	CSE HTML Validator (also checks accessibility [Section 508 and WCAG 2.0] and validates CSS): www.htmlvalidator.com/
•	Juicy Studio Quality Assurance Tools (online and toolbars): juicystudio.com/services.php

Resources
•	W3C’s HTML and CSS Validators (online): http://validator.w3.org/ and http://jigsaw.w3.org/css-validator/
•	WebAIM WAVE (online, upload, or toolbar): http://wave.webaim.org/

Resources
•	U.S. Access Board’s Guide to the Standards: www.access-board.gov/sec508/guide/index.htm
•	Ginny Redish and Mary Frances Theofanos’ Observing Users Who Work with Screen Readers: www.redish.net/content/papers/interactions.html
•	Henny Swan’s Setting Up a Screen Reader Test Environment: www.iheni.com/screen-reader-testing/
•	Section 508 Refresh: Draft Information and Communication Technology Standards and Guidelines: www.access-board.gov/sec508/refresh/draft-rule.htm

Resources
•	UW-Madison’s Screen Magnification and the Web: www.doit.wisc.edu/accessibility/video/screen_magnification.asp
•	WebAIM’s The Importance of Human Evaluation: webaim.org/articles/process/human
•	WebAIM’s WCAG 2.0 Checklist: webaim.org/standards/wcag/checklist
•	WCAG 2.0 Quick Reference: www.3pha.com/wcag2/

Contact Information
Neal Albritton 
Phone: (916) 947-9008
Email: neal@Section508Guru.com 
Web: www.section508guru.com