Highlights of Accessibility Issues for Editors
The text alternative to a PowerPoint presentation delivered by P.J. Gardner, founder of Boston-IA and president of Gardner Information Design, Inc., at the February 8, 2006 joint meeting of Boston-IA and the Technical Editing Special Interest Group (SIG) of the Society for Technical Communication (STC).
"Highlights of Accessibility Issues for Editors"
Boston-IA: Bringing Information Architecture and Internet Accessibility Together
Presentation by P.J. Gardner
© 2006 Gardner Information Design, Inc.
Back to Index
Truisms about Online Content:
- "People do not read web sites or user interfaces, they scan them."
- "When people need to read large amounts of text on screen, they print it."
- "When people are overwhelmed with too much information or not enough information—or they have to wait too long—they go elsewhere."
Who Are You?
- Editor on a team creating content for the Web, an application, or a Help system.
- Editor or author for multi-sourced print documents that also end up in electronic form.
- Author or content producer of online content specifically created for the Web.
- Author or editor for material to be placed in a content management system.
- "Webmaster" of a small web site, intranet, or non-profit web site.
- The owner of a do-it-yourself web site to promote your own services.
Accessibility Goals for a Content Producer
Accessibility Goals for a Content Producer or Editor:
- To make sure everyone has access to online content.
- To get information across without overwhelming or frustrating people.
- For this presentation, we will focus on Web sites.
Back to Index
What is Accessibility?
What does Accessibility mean?
- Access by people with physical impairments and disabilities.
- Access by people with functional or technological barriers.
- Access by anyone outside the imagined target audience.
- Access by senior citizens and Baby Boomers with aging eyes.
Potential Accessibility Audiences
Some of the people to think about when preparing text for online presentation:
- People who are blind (using screen readers).
- People with low vision impairments.
- People who are colorblind.
- The growing population of senior citizens online.
- People with mobility impairments.
- People who have learning disabilities.
- Non-native speakers of English.
- People with hearing impairments.
- People with older equipment or software.
For people with physical disabilities or other access needs, difficulties with on-screen text are compounded:
- Blind people using screen readers must listen to text.
- People with vision impairments must enlarge text.
- People with mobility impairments must tab or point to text.
- People who are non-native speakers of English or cognitively impaired must be able to comprehend the text.
How Much Accessibility is Enough?
"Text is accessible when the barriers to accessing it have been removed." —P.J. Gardner
The basic keys to content accessibility are to:
- Make sure text is really text.
- Make it easy to get to.
- Make it easy to read on-line.
How Much Control Do You Have?
- You may turn text over to others for online delivery.
- Other people may put your carefully crafted text into a web page or an application window for you.
- Formats like PDF (Portable Document Format) or online Help may not be inherently accessible.
- Content management systems may insulate you from the delivery method completely.
The more you know about accessibility needs, the more you can advocate to make online text accessible.
Back to Index
Preparing Accessible Text (1)
- Is the text clear?
- Is it as concise as possible?
- Is there a minimum of jargon or culturally biased terminology?
- Could it be easily translated into another language?
- Would it still make sense if read over a telephone?
Preparing Accessible Text (2)
- Is there a logical structure to the document and each subdivision?
- Does the document include a clear context or summary statement at the beginning of each major section?
- Is the document as internally consistent as possible?
- Are there clear heading divisions?
Preparing Accessible Text (3)
- Do the headings make sense out of context?
- Do the headings begin with keywords or action verbs?
- Do headings begin with a variety of letters?
- Is the information in the document "chunked" using paragraphs, bulleted and numbered lists, tables, etc.?
Preparing Accessible Text (4)
- Does the text contain as many keywords related to the topic as possible (for search optimization)?
- Are acronyms and abbreviations spelled out the first time they will appear in each potential Web page and included in parentheses?
- Are boldface and italics used for emphasis rather than for visual effects?
Preparing Accessible Text (5)
- Are tables organized from left to right with clear headings, preferably for both columns and rows?
- If created in a word-processing program, does the document use template styles consistently and correctly?
- Are platform-specific features (for example, curly quotation marks or em dashes) avoided in the document?
Back to Index
Preparing Accessible Text (6)
And a couple of controversial ones of my own for Web delivery:
- Are paragraphs no more than a sentence or two?
- Are commas included before conjunctions in all series of items?
- Is closing punctuation kept outside quotation marks for technical terms and phrases?
Converting Text for Accessibility (1)
The goal when converting text is to make it:
- Truly text-based, not image-based.
- Text that can be repurposed in any environment.
- Platform-independent and browser-independent.
Converting Text for Accessibility (2)
My favorite conversion tool is Notepad!
- Removes platform-specific formatting.
- Displays text in reading order.
- Quickly identifies special characters.
I can then paste text into my Web editor and apply HTML tags to identify the purpose of each piece of text (heading, paragraph, list item, table cell, etc.), not what it should look like.
Converting Text for Accessibility (3)
- Do not use the "Save as HTML" features of Microsoft Office products.
- They contain HTML syntax errors and bloated style information.
- It is actually easier to insert the correct tags on plain text than to remove the extraneous information inserted by Microsoft Office.
- Many high-end conversion tools use style information, so correctly styling word-processing documents pays off when converting for Web delivery.
Web Coding for Accessibility (1)
- Follow W3C or Section 508 coding standards strictly.
- Learn the differences between HTML and XHTML (see XHTML Conversion Checklist handout).
- At a minimum, learn how to read XHTML!
- If possible, use XHTML to code new pages or to convert existing pages.
- There are not many text tags to learn (see Modular XHTML Tags handout).
- Believe it or not, follow the rules and accessibility will almost happen.
Back to Index
Web Coding for Accessibility (2)
Some of the typical rules you've heard before:
- Use "semantic markup": use tags to identify what things are, rather than what they should look like.
- Separate presentation from content using cascading style sheets.
- Avoid font tags and other deprecated features for formatting.
- Avoid tables for layout and do not nest tables.
What follows is more related to content coding.
Web Coding for Accessibility (3)
- Be as consistent as possible in placing standard items on each page.
- Ensure that HTML order matches the text reading order. (Use style sheet positioning if you need to change the display order.)
- Ensure that the title in the Head section on every page is clear enough for search engines (5 to 15 words) and contains as many search keywords as possible.
- Make sure the meta tag description describes the page (and site) accurately and clearly enough for search engines.
Web Coding for Accessibility (4)
- Write clear alt text for figures and images (maximum 150 characters).
- Describe the purpose of an image rather than what it looks like.
- Use null alt text for images that contain no information, so that they can be skipped.
- Insert no more than 100 links per page.
- Make sure link text is clear if taken out of context, and that links begin with keywords and a variety of initial letters.
Web Coding for Accessibility (5)
- Add title attributes to links that need clarification and to indicate when links go off-site or open new windows.
- Ensure that headings are coded with H1 through H6 tags.
- Make sure that special characters work on as many platforms as possible (see the Special Characters handout).
- Use em and strong tags for emphasis, and style sheets for bold and italic.
Web Coding for Accessibility (6)
- Add summary descriptions for data tables, and use table header tags to indicate whether headers apply to rows or columns.
- Make sure that form fields and options are associated with their labels using the label tag.
- When required, use client-side image maps and make sure there is clear alt text for each area within the map.
- For detailed images, supply a separate file for a long description of the image, with a [d] link until more browsers support the longdesc attribute.
Back to Index
Testing for Accessibility (1)
- Even one test with a user with a disability will teach you a great deal.
- Try my low-tech accessibility test (see Web Site Testing for Accessibility handout).
- Visit Boston-IA.org for more information about testing for accessibility at:
- (See the next page for a few of them).
Testing for Accessibility (2)
- Make the goal to provide people with disabilities and special access needs as much information as anyone else.
- Remove as many barriers to text as possible.
- Create plain text that can be read by adaptive technologies.
- Make your web sites and other electronic information as text-based as you can.
Visit Boston-IA.org for more information about accessibility.
Bringing Information Architecture and Internet Accessibility Together
- P.J. Gardner
Gardner Information Design, Inc.
Back to Index
© 2006 Gardner Information Design, Inc. All rights reserved.
Back to top